asellus
March 31st, 2008, 01:07 AM
Get ready for a pretty lengthy post...
In the beginning, the server was running 6.06LTS on a naked connection. It hosted apache2, CS:S, and TF2.
All was fine and dandy until I noticed that the apache2 server would stop responding periodically. I noticed that the maxclients setting was being hit 1-2 minutes after apache loading. I did a little digging, and with a helpful tool called tcptrack, I noticed that I was being HAMMERED. Example:
Client Server State Idle A Speed
124.43.40.92:6683 x:80 RESET 0s 0 B/s
124.43.40.92:6752 x:80 RESET 0s 0 B/s
124.43.40.92:6753 x:80 RESET 0s 0 B/s
124.43.40.92:6743 x:80 RESET 0s 0 B/s
124.43.40.92:6737 x:80 RESET 0s 0 B/s
124.43.40.92:6740 x:80 RESET 0s 0 B/s
124.43.40.92:6741 x:80 RESET 0s 0 B/s
124.43.40.92:6742 x:80 RESET 0s 0 B/s
124.43.40.92:6729 x:80 RESET 1s 0 B/s
124.43.40.92:6727 x:80 RESET 1s 0 B/s
124.43.40.92:6722 x:80 RESET 1s 0 B/s
124.43.40.92:6749 x:80 RESET 1s 0 B/s
124.43.40.92:6723 x:80 RESET 1s 0 B/s
124.43.40.92:6721 x:80 RESET 1s 0 B/s
124.43.40.92:6730 x:80 RESET 1s 0 B/s
124.43.40.92:6726 x:80 RESET 1s 0 B/s
Take care to notice the seemingly sequential client-side port attacking port 80. In this example however, apache is stopped, hence the RESET state.
Having noticed all these connections (which at the time were ESTABLISHED) I set to it to figure out how to stop them. Very simple!
iptables -A INPUT -p tcp -s 124.43.0.0/16 --dport 80 -j REJECT
That worked great! I made a small list of 'problem countries' and blacklisted them. My webserver is mainly for people around Minnesota, anyways. No biggie, all is well.
Fast forward a month or two. I upgrade to 7.10. A week passes, and I noticed that there's an average of 250-1000 k/s going through my server (again, noticed with tcptrack). The breakdown of the connections appeared to be on port 80 again. All the connections were ESTABLISHED at this point, not SYN_SENT (which is how they appeared when iptables was working).
I thought oh crap, my iptables entries were destroyed. I checked.. they weren't. Reapplied them to be safe, checked tcptrack, and noticed the connections were still being accepted and sucking up a ton of bandwidth.
That's it, I thought. Stopped apache, killed the straggling processes, removed --dport 80, -p tcp, and switched -j REJECT to -j DROP on all my iptables scripts, and re-applied them. Moment of truth.... I fired up apache.
No go. They were listed as "RESET" but STILL SUCKING UP BANDWIDTH!! Now, is this an Ubuntu 7.10 thing, or have I missed something stupid like iptables --activate ?
Help!
Cliff notes:
- server hosting apache2 on 7.10
- attacked by many IP's on sequential client ports, all directed to 80
- despite iptables DROP on these hosts, they suck up lots of bandwidth when apache is running
In the beginning, the server was running 6.06LTS on a naked connection. It hosted apache2, CS:S, and TF2.
All was fine and dandy until I noticed that the apache2 server would stop responding periodically. I noticed that the maxclients setting was being hit 1-2 minutes after apache loading. I did a little digging, and with a helpful tool called tcptrack, I noticed that I was being HAMMERED. Example:
Client Server State Idle A Speed
124.43.40.92:6683 x:80 RESET 0s 0 B/s
124.43.40.92:6752 x:80 RESET 0s 0 B/s
124.43.40.92:6753 x:80 RESET 0s 0 B/s
124.43.40.92:6743 x:80 RESET 0s 0 B/s
124.43.40.92:6737 x:80 RESET 0s 0 B/s
124.43.40.92:6740 x:80 RESET 0s 0 B/s
124.43.40.92:6741 x:80 RESET 0s 0 B/s
124.43.40.92:6742 x:80 RESET 0s 0 B/s
124.43.40.92:6729 x:80 RESET 1s 0 B/s
124.43.40.92:6727 x:80 RESET 1s 0 B/s
124.43.40.92:6722 x:80 RESET 1s 0 B/s
124.43.40.92:6749 x:80 RESET 1s 0 B/s
124.43.40.92:6723 x:80 RESET 1s 0 B/s
124.43.40.92:6721 x:80 RESET 1s 0 B/s
124.43.40.92:6730 x:80 RESET 1s 0 B/s
124.43.40.92:6726 x:80 RESET 1s 0 B/s
Take care to notice the seemingly sequential client-side port attacking port 80. In this example however, apache is stopped, hence the RESET state.
Having noticed all these connections (which at the time were ESTABLISHED) I set to it to figure out how to stop them. Very simple!
iptables -A INPUT -p tcp -s 124.43.0.0/16 --dport 80 -j REJECT
That worked great! I made a small list of 'problem countries' and blacklisted them. My webserver is mainly for people around Minnesota, anyways. No biggie, all is well.
Fast forward a month or two. I upgrade to 7.10. A week passes, and I noticed that there's an average of 250-1000 k/s going through my server (again, noticed with tcptrack). The breakdown of the connections appeared to be on port 80 again. All the connections were ESTABLISHED at this point, not SYN_SENT (which is how they appeared when iptables was working).
I thought oh crap, my iptables entries were destroyed. I checked.. they weren't. Reapplied them to be safe, checked tcptrack, and noticed the connections were still being accepted and sucking up a ton of bandwidth.
That's it, I thought. Stopped apache, killed the straggling processes, removed --dport 80, -p tcp, and switched -j REJECT to -j DROP on all my iptables scripts, and re-applied them. Moment of truth.... I fired up apache.
No go. They were listed as "RESET" but STILL SUCKING UP BANDWIDTH!! Now, is this an Ubuntu 7.10 thing, or have I missed something stupid like iptables --activate ?
Help!
Cliff notes:
- server hosting apache2 on 7.10
- attacked by many IP's on sequential client ports, all directed to 80
- despite iptables DROP on these hosts, they suck up lots of bandwidth when apache is running