I have a Linux dedicated server w/ Rackspace. I Usually average about 200 to 300 MB per day of data transfer, but my online admin panel indicates that I used 4.97 GB on Saturday!!! Then Sunday and today, my traffic dropped back down to normal.

Well, after slightly freaking out, I ran a WebTrends log report on my web logs, but it indicated that I only used about 200 MB Saturday (normal). I contacted Rackspace in the hopes that they could tell me where all this data came from and went to (I was hoping they could tell me what directory on my server most of it came from). They were no help, as they said they only monitor packets at the switch.

Something that seems really odd is out of the 4.97 GB of data, it's about 50/50 upstream and downstream.

All I can think of is that someone was accessing my server in a way that the web logs didn't record. Telnet? FTP? (although my anon ftp is supposed to be disabled)

Does anyone know of where I should look to figure out this mystery? I'm sure that there are logs somewhere on my server for FTP and Telnet, but I don't know where.

a spike that high usually means it was something else. Probably not apache. what you can run is find your access_log file and in that directory run

cat access_log | awk '{print $10}' | sort -n

that'll print out the file sizes of everything that was sent by your server. If you get a bunch of big high numbers do a

cat access_log | grep number

that'll tell you have was being accessed. If your ftp server is locked down then it sounds like an error in the code.

Hope it helps
Mike

If you don't see anything in any of your logs, it's possible that it was a DOS attack with spoofed IP addresses.

The attacker would most likely send a TCP SYN to your server from a spoofed IP address.

Your server would reply with a TCP ACK to the spoofed IP address.

The handshake process would not be completed, because the IP address was spoofed and there is no host there to acknowledge the TCP ACK. Therefore no TCP connection is established, which results in nothing being logged in your server's log files.

This results in the 1:1 I/O packet ratio.

You might want to set up some type of program that can detect this type of attack and block it.

Hmmm... That sounds like you might be right, bitserve. I checked all my system logs and have found nothing.

But if it was a DOS attack, is it common for this sort of attack to account for nearly 5 Gigs of data transfer? Any recommendations as to where I should look to get the appropriate security program?

Thanks.

I just consulted my security book about SYN floods, and it sounds like that's what happened, just as bitserve said. Unfortunately, the book also said there is little you can do except adjust some /proc entries to change the SYN timeout and the max number of SYN packets available in the queue. But this is only helpful for frustrating an attacker and it has to be done *during* an attack.

I was away from my computer most of Saturday and didn't notice the attack until this morning. At least the server seems to have held up just fine. The only damage is to my wallet (bandwidth).

If I find the bastard who did it, he owes me some money.

It would be neat to have software that detects syn floods, and blocks them, wouldn't it?

http://www.tech-mavens.com/synflood.htm

We actually just use a script that looks for incomplete TCP connections that runs every 5 minutes, and if they're higher than 2, it emails us.

Of course we usually get notified before that by the software that monitors the server load.

If an IP is being attacked, we typically just respond by blocking all traffic to the IP. This definitely results in a Denial Of Service, which can't be avoided.

Because syn floods don't result in actualy connections and requests, they typically don't use a LOT of bandwidth. To use 5GB of traffic, it probably was going on for awhile.

You can use syn cookies to help prevent the DOS if you don't mind weathering out the attack.

http://www.linuxdoc.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap5sec56.html

Originally posted by bitserve
It would be neat to have software that detects syn floods, and blocks them, wouldn't it?

http://www.tech-mavens.com/synflood.htm

We actually just use a script that looks for incomplete TCP connections that runs every 5 minutes, and if they're higher than 2, it emails us.

Of course we usually get notified before that by the software that monitors the server load.

If an IP is being attacked, we typically just respond by blocking all traffic to the IP. This definitely results in a Denial Of Service, which can't be avoided.

Because syn floods don't result in actualy connections and requests, they typically don't use a LOT of bandwidth. To use 5GB of traffic, it probably was going on for awhile.

You can use syn cookies to help prevent the DOS if you don't mind weathering out the attack.

http://www.linuxdoc.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap5sec56.html

not true. I have tested out "synflood programs"

and they run VERY quickly, and run up alot of bandwidth. Infact, it can very easily get to the point where you can't even login your server to block anything, or stop anything.. Very scary if you ask me.

Originally posted by clocker1996


not true. I have tested out "synflood programs"

and they run VERY quickly, and run up alot of bandwidth. Infact, it can very easily get to the point where you can't even login your server to block anything, or stop anything.. Very scary if you ask me.

You quoted me and then said "not true". What's not true? Please explain where I lied. Thank you.

Don't take things so seriously. I wasnt trying to make you look like some liar. Jeez

I was just saying, that in many cases you can't even get in the box to do anything about the attack.

Originally posted by clocker1996
Don't take things so seriously. I wasnt trying to make you look like some liar. Jeez

Next time, I would recommend just adding your comments, instead of stating that mine were untrue.

I was just saying, that in many cases you can't even get in the box to do anything about the attack.

I never said that a SYN flood attack couldn't slow down a server, but it has nothing to do with bandwidth.

If a host could push out 20 TCP SYN packets a second, it would still use up under 20kb/s in bandwidth. I'll say again, in general, this is not a lot of bandwidth.

I'll say again, using syn cookies can help to lower the resources on the machine during a SYN flood attack so that you can weather it out. You may want to check into this.

might wanna try using snort (www.snort.org) to monitor your server. just a suggestion...