POTENTIONAL FIX: etded.x86 getstatus exploit Options

[Guest_Dutchman_*]

Hi,

since a few months there is a exploit floating around abusing the getstatus requests to launch dos attacks against random targets and as a side effect creating massive lags on clients and the server.
Cause of this Yada from Staatsschutz.org made a patch for linux wich reduces the effectivity of this exploit.

etfix_getstatus 0.2 by yada / staatsschutz.org / jan. 2011
------

This patch will ratelimit etded.x86 2.60b getstatus requests to 1 per IP every
4 seconds. This approach is not ideal as the real fix would be to change the
protocol to require some kind of handshake but this would break compatibility
with existing clients so its not really practical. The worst part is that the
patch is (in theory) vulnerable to a dos where legitimate clients could be
denied access to the getstatus command but i feel this is less of a headache
than kiddies using the server to flood random targets and thereby lagging the
server and pushing bandwith usage through the roof (master server is excluded
from ratelimit so no need to worry about it being denied using spoofed
packets).

Download the file right here.

A readme.txt, the sourcecode and a small howto are included.

Your free to distribute this file.

This post has been edited by Dutchman: Jan 6 2011, 11:33 AM

[Ligustah]

For those running a dedicated server:

i hacked together some tiny script that watches network traffic and uses iptables to ban offending IPs,
thereby stopping the incredible lags and saving bandwidth. It's based on PCAP.

Requires pcapy and Impacket from over here: http://oss.coresecurity.com/

QUELLTEXT

#!/usr/bin/python
# Slightly modified version of this
# script:
# http://oss.coresecurity.com/impacket/sniff.py


import sys
import os
import string
from threading import Thread
import time

import pcapy
from pcapy import findalldevs, open_live
import impacket
from impacket.ImpactDecoder import EthDecoder, LinuxSLLDecoder

class Watcher(Thread):
    def __init__(self, pcapObj):
        # Query the type of the link and instantiate a decoder accordingly.
        datalink = pcapObj.datalink()
        if pcapy.DLT_EN10MB == datalink:
            self.decoder = EthDecoder()
        elif pcapy.DLT_LINUX_SLL == datalink:
            self.decoder = LinuxSLLDecoder()
        else:
            raise Exception("Datalink type not supported: " % datalink)

        self.pcap = pcapObj
        self.tab = {}
        self.lastCheck = time.time()
        Thread.__init__(self)

    def run(self):
        self.pcap.loop(0, self.packetHandler)

    def packetHandler(self, hdr, data):
        #packets are guaranteed to be UDP
        sll = self.decoder.decode(data)
        ip = sll.child()
        udp = ip.child()
        ip_addr = ip.get_ip_dst()
        
        if not self.tab.has_key(ip_addr):
            self.tab[ip_addr] = 0
        self.tab[ip_addr] = self.tab[ip_addr] + 1
        
        if time.time() - self.lastCheck >= 3:
            #uncomment the following line to see the number of packets
            #print self.tab
            self.checkLimits()
            self.lastCheck = time.time()
            self.tab = {}
            
    def checkLimits(self):
        for k in self.tab:
            v = self.tab[k]
            #change the number below to adjust the limit of packets
            if v > 1000:
                print "offending ip %s, packets: %i" % (k, v)
                os.system("iptables -A INPUT -s %s -j DROP" % k)

def main(filter):
    dev = 'any'

    p = open_live(dev, 100, 0, 100)
    p.setfilter(filter)

    print "Listening on %s: net=%s, mask=%s, linktype=%d" % (dev, p.getnet(), p.getmask(), p.datalink())

    #not calling start() here, because it doesn't work well
    Watcher(p).run()

# insert your ip there
filter = "udp and src host 123.456.789.123 and udp[8:4] = 0xFFFFFFFF"

main(filter)

This basically watches the outgoing traffic and counts the packets sent.
If packets sent to a certain IP exceed a specified limit it will issue a ban using iptables.
You might have to tweak the limit to meet your requirements.

For me it checks every three seconds and bans when sending more than 1000 packets in that time.
(they are constantly sending about 2000 packets per second to my servers).

Oh, and it only counts connectionless packets (e.g. getstatus, rcon, getinfo, etc) so it won't trigger on game packets.

[Sickboy]

works nicely Ligustah, thank you ;)

[$mart]

Hello, does anyone know a Windows version of this script please ?
My home server, with no human playing, has 900 kbps in upload stream !
Thx in advance

[Ligustah]

Ugh, programatically banning IPs on Windows is by far not as trivial (at least it was not for us, when we used a Windows server some years ago).
I'm afraid you will have to try finding a solution like the one posted by Dutchman. Maybe ask the creator of that patch if it can be applied to
the Windows version of the server as well, though i'd rather doubt that.

This post has been edited by Ligustah: Aug 25 2011, 11:32 PM

[ETc|Jay]

Hello, does anyone know a Windows version of this script please ?
My home server, with no human playing, has 900 kbps in upload stream !
Thx in advance

maybe install commview. there you see all traffic

here a pic:

[Guest_Dutchman_*]

Ugh, programatically banning IPs on Windows is by far not as trivial (at least it was not for us, when we used a Windows server some years ago).
I'm afraid you will have to try finding a solution like the one posted by Dutchman. Maybe ask the creator of that patch if it can be applied to
the Windows version of the server as well, though i'd rather doubt that.

Sorry, it's a Linux only patch.

[$mart]

Thanks guys,
Yes, on Windows, it is difficult to make such a script, maybe the new PowerShell could do it ..
Thanks JAY your graphical tool will fit my needs, I'm gonna download it, but for the moment, Upstream is normal: 2 kbps (just my remote access RDP) when server is empty (... and often empty lol grrr... nobody wants to test chaos mod ??).

If I suspect any new spoofing, I will try to find IP and will update this post.

Good frags for all xD
V55

This post has been edited by $mart: Aug 26 2011, 08:36 AM

[Ligustah]

As for the CommView program, i see two problems with that.

1. price = 200€ at least
2. no packet filter (as in dropping unwated traffic)

You can of course use that program to find out which IPs are being used on your server, but then you will have to manually ban them
(you can find out how to manually ban IPs with a quick Google search: http://lmgtfy.com/?q=how+to+block+an+ip+on+windows).

Yes, on Windows, it is difficult to make such a script, maybe the new PowerShell could do it ..

The problem would not be getting the script to run on Windows (there are even pre-built binaries of the libraries used by the script i posted), but getting the IP banned. It does not seem to be very common to have automated firewalls on Windows systems. It seems to be possible via the netsh (net shell) provided by Windows. Something along the line:

QUELLTEXT

netsh advfirewall firewall add rule .......

Read up on the manual of that program, if you type the command above (without the dots of course) it will prints lots of useful information.

QUELLTEXT

os.system("iptables -A INPUT -s %s -j DROP" % k)

If you have found the command line that will do the trick for you simply replace it in the script i posted

If I suspect any new spoofing, I will try to find IP and will update this post.

There is no point in posting IPs. You will only see the IPs of the victims getting DDoS'd, besides, at least on my machine I record about 30 to 50 different IPs per day (that is why i strongly advise looking into automated solutions).

Hope this helps.

This post has been edited by Ligustah: Aug 26 2011, 10:31 AM

[Dookie7]

ty guys :P

[daredevil]

You can also try netlimiter. In windows 2008 R2 Enterprise, you can see all IP's connected to your server live. I think it's same for standard edition also.





it's 30$.

This post has been edited by daredevil: Aug 28 2011, 04:21 PM

[Sickboy]

i've noticed on our server a few slower attacks packetting us just below our threshold. yesterday i reduced the threshold too low and legitimate game clients were dropped upon connecting. what i decided to do was run a second instance with a longer check time (10 mins) and higher packet #. seems to be working well along with the 3 sec script. wouldn't it be possible to write an iptables rule to only allow those packets from specific ips? ie legitimate trackers: et master server, trackbase, splatterladder, etc? the downside being that game clients couldn't do a /serverstatus, but i think its a small price to pay until theres a permanent solution.

[Ligustah]

It is certainly possible to make iptable rules that work like the script i posted. I actually experimented with that for quite a while,
though i can't remember why i went for the script in the end.

Blocking getstatus alltogether might not be a good idea. Game trackers are not the only ones who send getstatus requests.
Programs like XFire, HLSW or RCON Unlimited all rely on getstatus and will probably show the server offline if you block them.
You might however apply the script i posted above only to getstatus packets. At the moment it will count all connectionless packets (getinfo, rcon, getchallenge, etc).

QUELLTEXT

filter = "udp and src host 123.456.789.123 and udp[8:4] = 0xFFFFFFFF"

The last part of the filter checks the next 4 bytes at offset 8. You can change that to check for a longer byte sequence so as to catch getstatus only. I never bothered doing that.


I have been using a limit of 300 packets for quite a while now and it seems to work out very smoothly, haven't heard of legit clients getting dropped or being unable to connect. You will however have to adapt that limit depending on the number of game servers you run on your machine.

This post has been edited by Ligustah: Aug 29 2011, 09:36 AM

[Old-Owl]

Thanks Ligustah for you nice script that seems very fast and efficient.
I tried it since I like the idea of real time bans and after some inconvenient attepts,
(script banned the server from itself due to another script that use a connector)
I changed this part to avoid it:

CODE

            if k == "ServerIPhere":
                        print "own IP not banned %s, packets %i" % (k, v)
            elif v > 150:
                        print "offending ip %s, packets: %i" % (k, v)
                        os.system("iptables -A INPUT -s %s -j DROP" % k)

Now I run it in a screen session, I like it, but I would log in a text file the banned IP's and the packets they produce.
The main reason is to debug why the script from time to time ban one of my admins that run two clients and HLSW
in the same time. If I can understand the threshold I have to set then I can sleep good. :)

Last thing is that I don't understand the "filter" how it have to be set to catch the 'getstatus' requests, or maybe
I don't have to modify that line except put there the server IP address .

Thanks for your support.
Owl

[Ligustah]

I am actually using a simple wrapper about my iptables, which will log the ip and number of packets.
http://85.214.159.249/banip.txt

Just save that file somewhere on your machine and make it executable.

QUELLTEXT

os.system("banip %s automatically banned, %i packets" % (k, v))

That's how i call it from my script.

To change the filter line, you need to get a HEX representation of getstatus and add that to the number in the filter line, also increase the length that is checked.

[-sunkist-]

I didn't see any getstatus floods since april 2011! Anyway...

For whom this may be interesting, please have a look at http://www.vollspack.org/ and see the linked script.

With best regards, Sunkist

[$mart]

Still attacks 10/10/11 : http://www.hirntot.org/distribution/viewto...f8577789#p14936
My hoster 87.98.168.156 is down still yesterday ... maybe same reason.
And when I run home-server (windows), after some minutes, my bandwith goes to 100% busy even with no players ...

So no, ddos always present, like hacks, like virus, ... grrrrrrrr


(anyway thanks man to share your script-shell with community)


This post has been edited by $mart: Oct 15 2011, 10:03 AM

[schnoog]

The getstatus exploit is more active than ever.

I talked to some admins and more than 10 000 incoming packets per seconds are not very rare.

OldMan posted a modified version of the q3_getstatus_ddos script here: http://wolffiles.de/index.php?forum-showposts-44-p5#

This one not only spoil plaintext getstatus attacks, it also handles zoneRef getstatus attacks.


That is like it looks after the script finnished his work:

CODE

rx: 6,1 Mbit/s 13862 p/s tx: 12 kbit/s 2 p/s

OldMan integrated some very nice features (delayed unban for example)

Unfortunality I`m not familar with the windows powershell, but there should also be a possibility to do such things.

[-sunkist-]

The getstatus exploit is more active than ever.

I talked to some admins and more than 10 000 incoming packets per seconds are not very rare.

Oh WOW! That's true! Holy shit!

I didn't see any attacks because I didn't list my ET servers in the Masterlist. Since I listed one of my ET servers again, the attacks are back - more then before!

Thank's for the hint!

Now I know where the attackers get the targets from: The Master Browser List!

When you use:

seta sv_master1 ""
seta sv_master2 ""
seta sv_master3 ""
seta sv_master4 ""
seta sv_master5 ""

in your server.cfg, your servers will not get listed in the Master Browser List and therefor they will not get attacked.

[Guest_Dutchman_*]

blabla

this has nothing to do with the topic about a patch for linux servers.
Is there a possibility you communicate in a normal way? thnx.

[-sunkist-]

blabla

this has nothing to do with the topic about a patch for linux servers.
Is there a possibility you communicate in a normal way? thnx.

Well, I regret to communicate in a higher level.

There will be no patch for linux servers from the vendor. But you may use one of the iptables scripts offered by me (http://www.vollspack.org/) or by others. These scripts will block these attacks. But you still will receive the traffic. There is nothing you can do against it.

This post has been edited by -sunkist-: Oct 17 2011, 11:05 PM

[Guest_Dutchman_*]

blabla

this has nothing to do with the topic about a patch for linux servers.
Is there a possibility you communicate in a normal way? thnx.

Well, I regret to communicate in a higher level.

There will be no patch for linux servers from the vendor. But you may use one of the iptables scripts offered by me (http://www.vollspack.org/) or by others. These scripts will block these attacks. But you still will receive the traffic. There is nothing you can do against it.

The fix i posted for linux servers as stated from yada in the readme file if fine.
Your post has nothing to do with solving it if you wan't to get your server(s) listed.

[-sunkist-]

blabla

this has nothing to do with the topic about a patch for linux servers.
Is there a possibility you communicate in a normal way? thnx.

Well, I regret to communicate in a higher level.

There will be no patch for linux servers from the vendor. But you may use one of the iptables scripts offered by me (http://www.vollspack.org/) or by others. These scripts will block these attacks. But you still will receive the traffic. There is nothing you can do against it.

The fix i posted for linux servers as stated from yada in the readme file if fine.
Your post has nothing to do with solving it if you wan't to get your server(s) listed.

Wrong!

The "fix" will not just drop the attackers traffic, it will let the traffic go to your servers ET software (server side) and will cause lag! Iptables will prevent the software from receiving the attackers traffic and will cause much less lag.

The listed cvars will prevent you from receiving the traffic at all!

This post has been edited by -sunkist-: Oct 17 2011, 11:21 PM

[Guest_Dutchman_*]

ok:)

[AmericanPie1979]

good morning :)


i found maybe a solution for this problem ^^

i look for it now :P maybe it works ^^

i was on server to play so it works :)

we dont let us flood :P but why it woks now ??

i used many fixes.....from schnoog........i updated the Kernel and getted flooded again ^^

and now i have cpu usage from 13 % ^^ befor it was 50 % :)



This post has been edited by AmericanPie1979: Oct 18 2011, 08:31 AM

[-sunkist-]

good morning :)


i found maybe a solution for this problem ^^

i look for it now :P maybe it works ^^

i was on server to play so it works :)

we dont let us flood :P but why it woks now ??

i used many fixes.....from schnoog........i updated the Kernel and getted flooded again ^^

and now i have cpu usage from 13 % ^^ befor it was 50 % :)

Kannst Du bitte mal in Deiner Muttersprache sagen, was Du sagen willst? Ich kann zwar Deinen englischen Text uebersetzen, aber dabei kommt irgendwie nichts sinnvolles raus.

[TomDome]

Ich denke es ist rauslesbar was er sagen will und daß er in englisch schreibt ist eher von Vorteil, da dann mehr Leute daran teilhaben können.

[AmericanPie1979]

Ich würde mal sagen wer lesen kann ist klar im Vorteil ^^

ich habe eine gepatchte Gameserver Kernel installiert und noch paar sachen geändert

ist aber bis jetz nur ein test ^^

hab gemerkt das es besser wurde als ich die Masterserver aus der cfg rausgenommen habe.....

sind einige Sachen die ich geändert habe ^^

PS : werde denk ich mal wieder angegriffen.......cpu auslastung steigt wieder stetig.......man wasn kack ey frag mich was die deppen davon haben

32 % cpu usage.....nich soooo viel aber naja man sehen wie es sich entwickelt

This post has been edited by AmericanPie1979: Oct 18 2011, 10:43 PM

[$mart]

Hello

32% CPU => with how many players and/or bots ?

Because when my home-server is "attacked", I don't notice CPU increase. ( I just see, with "NetMeter.exe" my Upload traffic growing to 110-120 kB/s (the maximum!), and confirmation is given by "CommView.exe" )

So are you sure your 32% CPU is due to an "attack", maybe another problem ?

GoodLuck

This post has been edited by $mart: Oct 19 2011, 08:02 AM

[Ligustah]

Hello

32% CPU => with how many players and/or bots ?

Because when my home-server is "attacked", I don't notice CPU increase. ( I just see, with "NetMeter.exe" my Upload traffic growing to 110-120 kB/s (the maximum!), and confirmation is given by "CommView.exe" )

So are you sure your 32% CPU is due to an "attack", maybe another problem ?

GoodLuck

It might be due to the fact the the upload rate of servers is much greater than just 120 kB/s. When the attacks first started on my server it reached
upload rates of up to 80 Mbps, which caused high CPU utilization (mostly due to I/O waits)

[AmericanPie1979]

i have 16 bots now


i disabled the master server list last night i get now a cpu usage from 22 %


//set sv_master1 "etmaster.idsoftware.com"
//set sv_master2 "master.gamespy.com:27900"
//set sv_master3 "master0.gamespy.com"
//set sv_master4 "clanservers.net"
//set sv_master5 "master3.idsoftware.com"
//set sv_master6 "wolfmaster.idsoftware.com"


hm maybe they are right with master server list




ich bekomm den kack nicht über Plesk geblockt........ka warum hab die IP der Domain rausgefunden


rx: 102.67 kB/s 1729 p/s tx: 698.75 kB/s 551 p/s

thats my traffic

This post has been edited by AmericanPie1979: Oct 19 2011, 10:00 AM

[Ligustah]

ich bekomm den kack nicht über Plesk geblockt........ka warum hab die IP der Domain rausgefunden

Die domain die dort steht verweist nicht zwangsläufig auf die dazugehöre IP. Das liegt daran, dass der Name dem reverse DNS Eintrag der IP entspricht, nicht umgekehrt.

Wenn du iftop aufmachst drück einfach mal N auf der Tastatur. Dann zeigt iftop keine reverse DNS Namen mehr an, sondern die ursprünglichen IPs.

[AmericanPie1979]

hab gesehen das es auf 3 roots die gleichen flood Attacken sind schon komisch oder ^^


ist die IP die ich rausgefunden hatte ^^

naja wenn man in Plesk nur die IP reinmacht bannt man doch den dazugehörigen Provider oder ?? seh ich das falsch ^^


hab was gefunden ^^


11.11.11.11/32 <- just the host 11.11.11.11

11.11.11.0/24 <- the whole 11.11.11.0 network (254 ips)

11.11.0.0/16 <- the 11.11.0.0 network (64k ips)


11.0.0.0/8 <- the 11.0.0.0 network (16million ips)

This post has been edited by AmericanPie1979: Oct 19 2011, 11:19 AM

[schnoog]

Das Problem ist doch, dass die Angreiffer IP gespooft ist. Die ändert sich z.T. minütlich. Statische IP Bans werden da auf Lange Sicht nicht viel nützen.
Deshalb bevorzuge ich die von OldMan modifizerte Lösung durch das getstatus_ban Skript.
Einen höheren CPU load erhalte ich jedoch kaum wenn ich die Firewall deaktiviere, auch wenn der Traffic extremst hochrast.

----------------------------------------------------------------------------------------------------

The main problem is that the offenders IP is spoofed and changes very fast. Static IP bans will not help for a long duration.
This is why I prefer the getstatus_ban script modified by OldMan.
Nevertheless I couldn`t recognize any significant CPU load increase when I disable the firewall, even if the traffic raises extremly.

[Guest_Dutchman_*]

American, i see you are running your game on a linux machine. Ever tried the patch i've posted at the very beginning of this topic?
Works fine for me:) That is if you are running a 2.60b server. Or at least test it. You can backup the original etded if it ain't working for you but it should work.

[AmericanPie1979]

Dutchman :) thx for info but i have 2.55+ so all patches can connect 2.55 - 2.60b


it would be great when the patch works on this one too :)

etded.x86


Gruss von Opa :)


:P

This post has been edited by AmericanPie1979: Oct 19 2011, 03:31 PM

[Guest_Dutchman_*]

I don't know wich etded.x86 version you have "hochgeladen" but i ran the patch on your etded.x86 without any problems:

CODE

et@*******:~$ ./etfix_getstatus etded.x86
------------------------------------------------
** limit getstatus patch 0.2 for etded.x86 2.60b
           yada // staatsschutz.org // jan. 2011
------------------------------------------------
Patching: 23 bytes at offset 71BC0.
Patching: 117 bytes at offset 71BE0.
Patching: 11 bytes at offset E4EF.
Patching: 5 bytes at offset E507.
Patching: 4 bytes at offset 10C13.
Success: etded.x86 patched.

So ,you should patch it on your linux box and try it. If you don't know how to do it, we can help:)

This post has been edited by Dutchman: Oct 19 2011, 03:49 PM

[AmericanPie1979]

it says unknown etded.x86 version

can you send me the patched version ???.......please :)

xfire : wildehilde1979


:)


PS : it worked now ^^ v-v Version is patched now ^^

i try it out :P

This post has been edited by AmericanPie1979: Oct 19 2011, 04:12 PM

[daredevil]

English please so others having same issue can understand? Also possible to make windows patch for it? Also possible to make 3 request per IP every 4 sec because then HLSW will perfectly well. If it works with 1 request per 4 seconds, please let me know.

Thanks

This post has been edited by daredevil: Oct 19 2011, 06:32 PM

[AmericanPie1979]

i am writing english but sry its little bad :P

THX Dutchman ^^




This post has been edited by AmericanPie1979: Oct 19 2011, 04:26 PM

[Guest_Dutchman_*]

i am writing english but sry its little bad :P

THX Dutchman ^^

Glad it worked AmericanPie:)
Any results on the cpu load or network usage?

[AmericanPie1979]

cpu is on 21 - 22 %

network is now ok

rx: 130.66 kB/s 2191 p/s tx: 14.47 kB/s 74 p/s


^^ Danke :)

Ich weiß nicht ob du ihn noch kennst aber Opa hat nach dir gefragt ^^



PS : old network usage ^^

rx: 102.67 kB/s 1729 p/s tx: 698.75 kB/s 551 p/s

lG

This post has been edited by AmericanPie1979: Oct 19 2011, 06:32 PM

[Guest_Dutchman_*]

cpu is on 21 - 22 %

network is now ok

rx: 130.66 kB/s 2191 p/s tx: 14.47 kB/s 74 p/s


^^ Danke :)

Ich weiß nicht ob du ihn noch kennst aber Opa hat nach dir gefragt ^^



PS : old network usage ^^

rx: 102.67 kB/s 1729 p/s tx: 698.75 kB/s 551 p/s

lG

OPA hehe...yes and his fellow "MOERDER" ....offcourse i know them, they were a while on our server.....4 years ago? ...crazy people :-D
We can PM about this but please say hello to him :)

Well, glad it worked for ya dude :-)
and ps. with the linux command 'top' you can check wich process uses most of the cpu.

[AmericanPie1979]

they are both on my Teamspeak ^^ Opa and Mörder ;)


i try this command ^^


most usage is etded.x86 23 % ^^




This post has been edited by AmericanPie1979: Oct 19 2011, 06:48 PM

[Old-Owl]

The scripts against that getstatus exploit works fine. But I don't understand one thing.
I give an example:

All Attackers are banned through iptables, but they keep to send packets.
I can see it through iptraf:

CODE

│ Incoming rates:    3385.7 kbits/sec
│                   6555.2 packets/sec
│                                            IP checksum errors:           0    
│ Outgoing rates:    1811.4 kbits/sec
│                    581.2 packets/sec

Results:

My service hosting provider keep to send me alerts about high traffic even the offending Ip's are banned. And when I go to check, the IN traffic is always more (twice) than OUT traffic.

I am not sure if that high amounts of incoming packets may spoil the game play; I am afraid that is possible since some players keep to complain about lags.

Someone have an idea or explanation of this problem?

Thanks :)

[schnoog]

There`s nothing you can do against the incoming traffic.

But the data which "comes" ("" because that are spoofed IPs) from an IPTables blocked IP isn`t reaching the gameserver at all.

The only traffic direction you can "handle" is the outgoing traffic. If your server are empty, the outgoin traffic should be near 0.
(it is not 0, because HLSW, SL, TB and many more are requesting serverdata from time to time).

Maybe you can lower the limit to catch offenders, but when I see the stats (6500p 3,3kB/s vs. 580 1,8kB/s) the script seems to do what it was developed for.
Each incoming getstatus request amplifies the traffic in outgoing direction with a factor >5.

[Ligustah]

I just recently had to answer that question to someone else and I think came up with a rather simple example.

Suppose you have a mail box infront of your house. Every day you check the letters. There are some "spam" mails in there every day, so you sort them out right away and trash them, without even reading (or answering) them.
However, you cannot stop people from putting spam letters into your mailbox.

It's the same with software firewalls. You can prevent your server from "reading/answering" the packet, but it will still reach your machine (be put in its "mailbox"). There is nothing you can do about that, unless you control the upstream router (which you don't).

Hope this example clarifies the situation to people who might have not understood before.