SYN flooding test

i’ve been testing the idea i described in my last post. in the vid below, i use james woolley’s python script to flood the ball drop game with syn packets. i execute the script to send 2000 packets consecutively to the ip and port that the server is listening on. while that’s going, i connect to the game with the ball drop client. the client seems to connect with no delay which is unfortunate since i want a delay. i’m not sure whether i’ve set something up wrong or whether 2000 packets just isn’t that many.

update:

well, here we are, a thousand rabbit holes later. when i tried executing the syn flood script with 20,000 packets and the connection didn’t change, i decided i was doing something wrong. i looked into a few other kinds of attacks, but ultimately came back to this one. below are some characteristic screen shots of my wireshark readings.

in the first one, you see a SYN from assigned port to port 8080, SYN/ACK from 8080 to me, and RST from me to 8080. RST means to close the connection because something’s gone wrong, and the client started by the python script kept sending them out when the connections were (predictably) broken. sometimes, a message from the actual ball drop client would get through in the middle of all this SYN/ACK/RSTing, which suggested to me that maybe there was something multi-threaded about the connection? and if there are multiple threads, how do you know how many there are and what their capacities are? and how do you block them all? 😱

screen-shot-2016-11-01-at-12-00-40-am

here’s another thing that happened: a bunch of SYN packets, with no RST packets (great!) with ball drop client messages in between (not great!). the ball drop client messages here are the two not-gray ones in the middle. the arrow is pointing to the payload, which is “L” for directing the paddle to go left.

syn-pax

so, like, wtf? i went back to where i’d originally gotten the syn flood python script. i realized that i’d totally skipped the first script, which blocks RST packets from being sent out. alas, the utility it relies on, iptables, is for linux and isn’t a thing on mac os x. i went hunting for alternatives and learned about pf.conf and tried to implement a block on RST flags using this solution. double alas. i could edit pf.conf, but couldn’t load the new file to be executed.

screen-shot-2016-11-01-at-12-20-06-am

Leave a Reply