[SYN Attack] Op eigen server

[battler]

Ik probeer mijn eigen server te laten vollopen met halve TCP requests. Een android applicatie creeert een aantal sockets, de server accepteert deze maar blocked het antwoord. Dit gebeurd door middel van de volgende IPTables rules

code:

sudo iptables -A INPUT -i eth0 -p tcp -m state -s [IP PHONE] --state NEW -j LOG --log-prefix "TCP SYN RECV: "
sudo iptables -A OUTPUT -o eth0 -p tcp -m state -d [IP PHONE] --state ESTABLISHED -j LOG --log-prefix "TCP ACK Blocked: "
sudo iptables -A OUTPUT -o eth0 -p tcp -m state -d [IP PHONE] --state ESTABLISHED -j REJECT

In mijn logs zie ik ook dat dit gebeurd.

code:

TCP ACK Blocked: IN= OUT=eth0 SRC=[IP server] DST=[IP Phone] LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=60344 WINDOW=28960 RES=0x00 ACK SYN URGP=0 
TCP SYN RECV: IN=eth0 OUT= MAC=00:18:8b:f7:ca:91:00:1c:23:81:aa:2b:08:00 SRC=[IP Phone] DST=[IP server] LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=21457 DF PROTO=TCP SPT=48599 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0 
TCP SYN RECV: IN=eth0 OUT= MAC=00:18:8b:f7:ca:91:00:1c:23:81:aa:2b:08:00 SRC=[IP Phone] DST=[IP server] LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=21457 DF PROTO=TCP SPT=48599 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0 
TCP ACK Blocked: IN= OUT=eth0 SRC=[IP server] DST=[IP Phone] LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=48599 WINDOW=28960 RES=0x00 ACK SYN URGP=0 
TCP SYN RECV: IN=eth0 OUT= MAC=00:18:8b:f7:ca:91:00:1c:23:81:aa:2b:08:00 SRC=[IP Phone] DST=[IP server] LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=45046 DF PROTO=TCP SPT=36292 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0 
TCP SYN RECV: IN=eth0 OUT= MAC=00:18:8b:f7:ca:91:00:1c:23:81:aa:2b:08:00 SRC=[IP Phone] DST=[IP server] LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=45046 DF PROTO=TCP SPT=36292 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0 
TCP ACK Blocked: IN= OUT=eth0 SRC=[IP server] DST=[IP Phone] LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=36292 WINDOW=28960 RES=0x00 ACK SYN URGP=0 
TCP SYN RECV: IN=eth0 OUT= MAC=00:18:8b:f7:ca:91:00:1c:23:81:aa:2b:08:00 SRC=[IP Phone] DST=[IP server] LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=25468 DF PROTO=TCP SPT=56612 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0 
TCP SYN RECV: IN=eth0 OUT= MAC=00:18:8b:f7:ca:91:00:1c:23:81:aa:2b:08:00 SRC=[IP Phone] DST=[IP server] LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=25468 DF PROTO=TCP SPT=56612 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0 
TCP ACK Blocked: IN= OUT=eth0 SRC=[IP server] DST=[IP Phone] LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=56612 WINDOW=28960 RES=0x00 ACK SYN URGP=0 
TCP SYN RECV: IN=eth0 OUT= MAC=00:18:8b:f7:ca:91:00:1c:23:81:aa:2b:08:00 SRC=[IP Phone] DST=[IP server] LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=20071 DF PROTO=TCP SPT=54179 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0 
TCP SYN RECV: IN=eth0 OUT= MAC=00:18:8b:f7:ca:91:00:1c:23:81:aa:2b:08:00 SRC=[IP Phone] DST=[IP server] LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=20071 DF PROTO=TCP SPT=54179 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0 
TCP ACK Blocked: IN= OUT=eth0 SRC=[IP server] DST=[IP Phone] LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=54179 WINDOW=28960 RES=0x00 ACK SYN URGP=0 
TCP ACK Blocked: IN= OUT=eth0 SRC=[IP server] DST=[IP Phone] LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=57781 WINDOW=28960 RES=0x00 ACK SYN URGP=0 
TCP ACK Blocked: IN= OUT=eth0 SRC=[IP server] DST=[IP Phone] LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=52534 WINDOW=28960 RES=0x00 ACK SYN URGP=0 
TCP ACK Blocked: IN= OUT=eth0 SRC=[IP server] DST=[IP Phone] LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=52424 WINDOW=28960 RES=0x00 ACK SYN URGP=0 
TCP ACK Blocked: IN= OUT=eth0 SRC=[IP server] DST=[IP Phone] LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=53723 WINDOW=28960 RES=0x00 ACK SYN URGP=0 
TCP ACK Blocked: IN= OUT=eth0 SRC=[IP server] DST=[IP Phone] LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=55082 WINDOW=28960 RES=0x00 ACK SYN URGP=0 
TCP ACK Blocked: IN= OUT=eth0 SRC=[IP server] DST=[IP Phone] LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=35883 WINDOW=28960 RES=0x00 ACK SYN URGP=0 
TCP ACK Blocked: IN= OUT=eth0 SRC=[IP server] DST=[IP Phone] LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=46408 WINDOW=28960 RES=0x00 ACK SYN URGP=0

Maar als ik vervolgens kijk hoeveel half open TCP verbindingen het OS ziet dan is dit 0.

Ik gebruik hiervoor het command "ss -s"
Total: 125 (kernel 0)
TCP: 12 (estab 1, closed 3, orphaned 0, synrecv 0, timewait 2/0), ports 0

Transport Total IP IPv6
* 0 - -
Hoe weet ik zeker dat ik het besturingsysteem belast met half open sessies (het lijkt erop van niet). Is er misschien een andere manier om dit te controleren?

[Hero of Time]

Ik denk dat het juist het hele idee van IPTables is om geen open verbindingen achter te laten. Het dropt de verbinding, dus is deze niet meer open of in welke andere staat dan ook. Zou dat wel zo zijn, dan zijn een hoop servers kwetsbaar voor een (D)DoS aanval als het als firewall wordt gebruikt.

[battler]

Dat lijkt inderdaad te kloppen. Als ik de iptables rules weghaal zie ik wel gewoon sessie via netstat -t. Maar dit is juist niet wat ik wil bereiken. Enig idee hoe ik ervoor zorg dat iptables echt alleen de outgoing packet droped en niet de hele sessie?

- Een aparte statische route werkt niet naar 127.0.0.1 werkt niet.

[ Voor 12% gewijzigd door battler op 19-07-2014 14:28 ]

[blaataaps]

Wat voor "statische route naar 127.0.0.1" en hoe zou die moeten werken?

code:

--tcp-flags ALL ACK -j DROP

in de INPUT chain voor het IP van de betreffende client doet hier wat je wil (voor zover ik dat goed begrijp). Dan blokkeer je de ACK die volgt op de SYN/ACK naar de client. Zolang je geen data verstuurt over de socket vanaf de client blijft hij in de state SYN_RECV. ss -s laat dit niet zien, maar netstat en ss state syn-recv wel.

[battler]

Uiteindelijk ook gekozen voor de laatst genoemde oplossing. Het idee van de statisch route was om de response van de SYN te null routen.

[H!GHGuY]

Heb je niet gewoon syncookies aan staan?

Syncookies voegen wat data toe aan de syn-ack response zodat er geen server resources gekoppeld worden aan een half-open verbinding. Wanneer de ack dan terugkomt met die info, kan de server achteruitrekenen en kijken of die data klopt. In dat geval gaat de connectie pas echt open en worden resources aangemaakt.

[Kees]

syncookies inderdaad. Overigens kun je zoiets ook goed met hping3 testen, dan kun je ook makkelijk ip's spoofen e.d. (wel oppassen dat je niet je netwerk ermee sloopt, liefst een volledig gescheiden netwerk zonder internet )