Seit 2005 lief jeden Tag ein Portscan, der meine Server überprüft, und zwar alle Ports von 1-65535 TCP und UDP (getrennt in zwei parallelen Prozessen). Rausgefiltert wurden dann die Ports die offen sein sollen, alle anderen Ports wären ja Treffer und nicht gut. Natürlich hab ich keinen Bock das ich von nmap jeden Tag eine Liste mit über 130 000 Ports bekomme, also wird nochmal gefiltert ob der Status OPEN ist und damit eine Backdoor Shell läuft, sachen wie FILTERED sind ja nicht schlimm nur NMAP zeigt sie trotzdem an. Bei Hetzner wäre das z.B. der Port 6667 (IRC) der gefiltert wird, 7000 ist dafür offen und ein Bot kann trotzdem zu einem IRC Netzwerk verbinden. Was bei PsyBNC zwar eine absolute Katastrophe war, aber ok weiter im Text.
Jetzt habe ich allerdings mal summa sumarum durchgerechnet das der Scan von Server 1 von 3:00 Uhr bis 12:20 läuft. Da ich das Script immer nur um die IP Adresse erweitert habe kommen die ja auch noch dazu. Da fast 9,5h einfach zuviel sind musste das gedrückt werden, also hab ich die Paketto Keiretsu Tools[1] installiert damit ich die 65535 TCP Ports in extremst kurzer Zeit abscannen kann. Also via apt das Paket installiert und mal angetestet:
# scanrand -d bond0 -b512K -v -t 100 1.2.3.4:80
Stat|=====IP_Address==|Port=|Hops|==Time==|=============Details============|
SENT: 1.2.3.4:80 [00] 0.003s
Wumm, danach kam nichs mehr und der Timeout von 100 sek lief ab.
Was ist passiert? tcpdump zeigt uns das sicher:
Server # tcpdump -vv port 80
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
12:25:10.140290 IP (tos 0x0, ttl 248, id 255, offset 0, flags [DF], length: 40) p5493663D.dip.t-dialin.net.2959 > server.80: S [tcp sum ok] 3683956693:3683956693(0) win 4096
12:25:10.140318 IP (tos 0x0, ttl 255, id 0, offset 0, flags [DF], length: 40) server.80 > p5493663D.dip.t-dialin.net.2959: R [tcp sum ok] 0:0(0) ack 3683956694 win 0
Intranet # tcpdump -vv port 80 -i bond0
tcpdump: listening on bond0, link-type EN10MB (Ethernet), capture size 96 bytes
12:28:58.763668 IP (tos 0x0, ttl 255, id 255, offset 0, flags [DF], proto TCP (6), length 40) intranet.55412 > server.80: S, cksum 0x97f9 (correct), 580369251:580369251(0) win 4096
12:28:58.820891 IP (tos 0x60, ttl 248, id 0, offset 0, flags [DF], proto TCP (6), length 40) server:80 > intranet.55412: R, cksum 0xa7e6 (correct), 0:0(0) ack 580369252 win 0
Also kommt die Antwort zurück. Aber warum wird sie nicht verarbeitet? Das NAT macht das anscheinend etwas schwierig, also füge ich einfach mal aus Spaß einen seed ein mit -s scan. Jetzt kommt:
# scanrand -s scan -d bond0 1.2.3.4:1-1000
UP: 1.2.3.4:25 [07] 0.059s
UP: 1.2.3.4:80 [07] 0.118s
UP: 1.2.3.4:110 [07] 0.156s
UP: 1.2.3.4:143 [07] 0.192s
Erfolg! Also würde ein kompletter Scan theoretisch nur wenige Minuten dauern für die TCP Ports. Aber warum wird bis IMAP alles angezeigt, aber HTTPS (443), POP3s (995) und IMAPs (993) werden gar nicht mehr angezeigt. Nach einigem Nachforschen wusste ich das mein Router nicht die Engstelle ist da ich normal ins Netz kann, also Ports fürs NAT gehen ihm anscheinend nicht aus. Das selbe habe ich bei einem anderen Hoster probiert und noch 2 anderen, es ist immer das selbe Symptom, nach ein paar Ports ist kein senden von Paketen mehr an die IP möglich, Ausnahme ICMP (ping). Also muss die Telekom da einen Flood Schutz eingebaut haben im DSL Access Concentrator (DSL-AC) da ich auch kein Traceroute zum Server mehr durchbringe (der Traceroute wird mit dem UDP Protokoll durchgeführt)
# traceroute 1.2.3.4
traceroute to 1.2.3.4 (1.2.3.4), 30 hops max, 40 byte packets
1 intranet (192.168.2.1) 0.935 ms 0.446 ms 0.452 ms
2
3
4
5
6
7
8
......
16
Anders ein ICMP Trace:
# traceroute -I 1.2.3.4
traceroute to 1.2.3.4 (1.2.3.4), 30 hops max, 40 byte packets
1 intranet (192.168.2.1) 0.709 ms 0.427 ms 0.331 ms
2 *
3 217.0.70.90 (217.0.70.90) 5.648 ms 5.244 ms 5.617 ms
4 217.239.40.193 (217.239.40.193) 10.570 ms 10.670 ms 10.550 ms
5 193.159.225.146 (193.159.225.146) 17.977 ms 14.510 ms 10.413 ms
...
8 server (1.2.3.4) 11.108 ms 11.027 ms 10.750 ms
Also filtert die Telekom anscheinend wirklich alle höheren Protokolle aus zu einem Server, wenn viel zu viel Pakete gesendet werden. Was mich jetzt soweit gebracht hat das ich meine Leitung nicht mehr den ganzen Tag zum Scannen der Server missbrauche sondern mich darauf verlasse das meine Sicherheitseinrichtungen halten und das nichts passiert. 3 Server sind einfach nicht mehr in der Toleranz für solche Spielchen.