Tag: iptables

irgendwann haben mal irgendwelche drecks bots einen uralten webserver lahm gelegt.
an die robots.txt haben sie sich nicht gehalten und eigentlich sollte die seite von keiner suchmaschine gecrawled werden. also aussperren nach diesem muster:

for i in `cat /var/log/apache/*.log | grep YandexBot|cut -d" " -f1|sort|uniq`; do iptables -A INPUT -s $i -j DROP; done 

das parst die apache logs, filtert nach dem entsprechenden bot, und sperrt die genutzten ips.
quick and dirty 😉

wenn mann einen oder mehrere proxmox server installiert, lauschen standardmaessig ein paar dienste auf diversen ports. darunter auch der portmapper/rpcbind auf port 111. den will man nicht im internet am lauschen haben.

oft kann man das ding z.b. mit einem freundlichen “apt-get remove rpcbind” deinstallieren. aber proxmox scheints wohl zu benoetigen 😉

proxmox beinhaltet eine iptables basierte firewall, welche standardmaessig deaktiviert ist. damit man sich nicht gleich aussperrt, sollte man als erstes regeln fuer port 22 und 8006 anlegen. (“Destination” ist die (ggf. oeffentliche) ipadresse des servers). dazu habe ich azf “Datacenter” ebene unter “firewall” diese regeln definiert:

in meinem fall ist noch icmp erlaubt und kommunikation meines nagios servers zu proxmox auf port 5666. danach kann man in den options die input policy auf DROP setzen und die firewall aktivieren.

den kram von gestern wollte ich noch ein wenig verfeinern. im logfile des bind konnte ich auf einen blick erkennen, dass diese beiden die groesste menge der (mittlerweile “sinnlosen”) abfragen darstellt:

[...] query: deniedstresser.com IN ANY +E
[...] query: . IN RRSIG +E

um nur genau diese per iptables raus zu filtern, muss man erstmal im netzwerkverkehr mithorchen, um sich dann die genauen strings rauszusuchen. das macht man am einfachsten mit dem tool tcpdump, welches anders als der name vermuten laesst auch udp und icmp mitschneiden kann 😉

tcpdump -i eth0 -s 0 -w /tmp/tcpdump.dump udp port 53

die damit erzeugte datei schaut man sich am besten mit wireshark an und sucht sich die entsprechenden teile der pakete raus:

die relevanten (im screenshot markierten) teile, nach denen ich filtern wollte, sind dann in hexadezimaler schreibweise diese:

# hex fuer "deniedstresser.com: type ANY, class IN"
0e 64 65 6e 69 65 64 73 74 72 65 73 73 65 72 03 63 6f 6d 00 00 ff 00 01 00
# hex fuer ": type RRSIG, class IN"
00 00 2E 00 01 00 00 29

die abfrage des typs ANY kann ich bedenkenlos komplett rausfiltern, da ich den abgefragten namen (deniedstresser.com) mit reingenommen habe. niemals hat dieser dns server genau diese abfrage zu beantworten.

iptables -I INPUT 1 -i eth0 -d xx.xx.xx.xx -p udp --dport 53 -m string --from 30 --algo bm --hex-string '|0e 64 65 6e 69 65 64 73 74 72 65 73 73 65 72 03 63 6f 6d 00 00 ff 00 01 00|' -j DROP

die abfrage nach der “recource record signature” der root zone darf ich nicht komplett rausfilter, da dem dns server vertrauete ipadressen sehr wohl genau diese abfrage machen koennen und duerfen. dafuer ist diese loesung mit iptables eigentlich eher ungeeignet. aber da ich weiss, dass die server mit den “vertrauten” ipadressen noch nichts mit DNSSEC am hut haben, nutze ich die regel erstens nur temporaer und zweitens sicherheitshalber nur wenn “geflutet” wird – sprich mehr als vier abfragen pro minuten von einer ipadresse kommt.

erst wieder die ip “taggen”:

iptables -I INPUT 2 -i eth0 -d xx.xx.xx.xx -p udp --dport 53 -m string --from 35 --algo bm --hex-string '|00 00 2E 00 01 00 00 29|' -m recent --name dnsrootrrsig --set

und die anfrage wegschmeissen, wenn der counter in 60 sekunden die vier erreicht hat, :

iptables -I INPUT 3 -i eth0 -d xx.xx.xx.xx -p udp --dport 53 -m string --from 35 --algo bm --hex-string '|00 00 2E 00 01 00 00 29|' -m recent --name dnsrootrrsig --rcheck --seconds 60 --hitcount 4 -j DROP

klar muessen die “angreifer” nur eine kleinigkeit an einer der abfragen aendern, um diese regeln zu umgehen. aber so schickt der dns server wenigstens nicht mal das “REFUSED” an den gefaelschten absender zurueck. ich hoffe ja, dass dieser “angriff” irgendwann vorueber ist, da der bind sowieso kein offener resolver mehr ist und somit fuer die angreifer uninteressant wird.