Re: [cobalt-developers] SYN flooding

["E.B. Dreger" <eddy+public+spam@xxxxxxxxxxxxxxxxx>]

> Date: Tue, 26 Mar 2002 18:08:22 -0800
> From: William L. Thomson Jr. <wlt@xxxxxxxxxxxxxxxxxxxx>


> I did that prior to posting and it was 1 which is on.

Okay.  It's on by default on your system; not in the kernel
(IIRC), but on your system.


> > You might be blocking innocents.  How do you know those packets
> > aren't spoofed?
> 
> I do not know. Any recommendations on finding out?

Unfortunately, you don't know without completing the handshake,
or tracing it back... provider cooperation.


> > Let's say someone wants to be really nasty.  They send spoofed
> > SYN packets at you that appear to come from DNS root servers.
> > You block those IPs.  No more outside DNS requests for you.
> 
> I did make sure the IP were nothing like that. They seem to be home DSL 
> users, one or two cable modems, and a couple others.

Okay, good... glad you checked. :-)  At first I was getting a bit
worried that you were arbitrarily blocking.  I shouldn't have
ass-umed, but so rarely does someone check. :-)


> > DO NOT block packets unless you know the ramifications.
> > 
> > There's always TCP intercept on a border router.
> 
> What do you mean by TCP intercept on a border router?

Cisco routers have something called TCP intercept that was
introduced in IOS <I forget the version>.  When you receive an
incoming SYN, the router pretends to be the protected host, and
replies with a SYN+ACK.  If the connection is successfully built,
the router then passes on a proxied connection to the system in
your network.

If you run your own border router, you can do this.  If you're
colo'ed, hopefully your provider will understand and help.  If
neither, then it's back to the drawing board.


> What concerns me most is the logs. I would assume it would not be 
> logging what it is without receiving some sort of impact. Hard to tell 
> if it has effected any services. Hasn't seemed to but I am hoping to 
> address it before it becomes a problem.

Agreed.  And, after seeing your other post, you certainly are
receiving many SYN requests.

I noticed that the IPs on your machine were private.  Are you
running NAT?  If not, the attacking machine has to be pretty
close by, else it wouldn't get routed.

If you are running a firewall, I almost have to wonder... might
there be a problem with something such as ECN blocking legitimate
requests?  Might the heavy hitters be proxy caches?

Somebody certainly is interested in HTTP/80 on your machine,
though.  Most port scans don't look like that.  One interesting
tidbit was the attempt that came from port 854 on the original
machine:  On *ix boxen, one must have root to use low port
numbers.


> I did nmap each IP before blocking them. To begin with I had to disable 
> pinging on the few that I could probe. The ones I were able to probe 
> showed ports filtered and some abnormal ones open. Also none had DNS for 
> the IP's beyond the ISP DNS, like you see on DSL and cable modem lines.

Okay.


> A couple did not respond to the probe at all and my probes were timing 
> out. So I am pretty sure these were not your average web surfers. Each 
> had some sort of fire walling/filtering on open ports.

Hmmmm.  If no response, it is quite possible.  Did you get a RST
back?  Nothing at all?  Did any ICMP queries respond?


> I have seen allot more SYN_RECV sockets than the six I have blocked. But 
> each of the six that I blocked had many simultaneous sockets active that 
> did not seem to time-out in a reasonable time.

The timeout is controlled on your end.  If there are that many
sockets open, it sounds like <whoever> is being rather
persistent.


> When this first came to my attention, I simply restarted the web server 
> which dropped the socket connections. Almost immediately after a few had 
> timed out and Apache was restarted several connections appeared.

Okay...


> I also did ARIN lookups on a few IP addresses that did not appear to be
> 
> owned by an ISP. If it became a problem I had a few companies who I could
> 
> contact and let them know one of their IP addresses was attacking me.

You might try using "whois.geektools.com" to run queries.  You
can always find the origin ASN using a public route server, and
contact its POC... although IP space should be registered.


> Still my biggest concern is the logs, since I would assume it would only 
> log a valid SYN attack?

I presume.  I'd need to go back and review the specifics of the
Linux kernel version in question.  (Somebody help me out,
here...)


> Although I may be a little trigger happy. I do not think so though, I 
> tried to take my time and be as thorough as possible.

Yes, you did more than I ass-umed from your first post.  Knowing
what I know now, I'd not say that you were trigger-happy...
blocking first and figuring out later sounds prudent.


Eddy

Brotsman & Dreger, Inc. - EverQuick Internet Division
Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence
--

Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist@xxxxxxxxx>
To: blacklist@xxxxxxxxx
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.  Do NOT
send mail to <blacklist@xxxxxxxxx>, or you are likely to be blocked.