I have multiple (40) SYN_RECV sockets showing (with netstat) on a
Redhat 7.2 server.
They are all bogus requests to DNS server AFAICT, e.g.
tcp        0      0 dnsFG.mrexcessive.n:www
src.ip.addr.here:randomport      SYN_RECV

I think that they are an attack of some kind.
How do I get rid of them (they even persist through a shutdown).
How do I filter out the src.ip, without recompiling kernel !

---

Request for Question Clarification by bikerman-ga on 19 Oct 2002 04:36 PDT

Hello, mrexcessive.

This does in fact appear to be a case of SYN flooding--a type of DoS attack.
I haven't messed with Redhat 7.2 (I run RH 7.1), but I think I can help you.
First, I need to know

1) What version of the kernel are you running?

2) Do you have any type of firewall set up?  If so, are you using iptables
or ipchains?  Have you set it up manually (e.g., running a script from
/etc/rc.d/rc.local), or used the Redhat firewall config utility?

3) What level of administration are you comfortable with?  That is, are
you familiar with the command-line, shell scripting, etc?

4) You say the sockets persist even after shutdown.  Are you sure that they
are the same set of sockets, or could it be another round of attack? If
you reboot your machine, and run netstat before you bring up the interface
which the attacks are coming through, do you still show the sockets?

If you need help determining the first two, let me know.

Regards,
bikerman-ga

---

Clarification of Question by mrexcessive-ga on 20 Oct 2002 02:50 PDT

bikerman-ga
Tnx for your interest and help...
To clarify:
1) I don't know how to determine kernel version... I've never rebuilt
kernel just done installs
2) I've not done anything to setup a firewall on the machine, I don't
have anything other than packet filtering on the ISP's router
3) I can do most things, but I don't know Linux in detail... I can
read C, C++, Shell Script &c. and modify, but don't know shell syntax
inside out. Main langauges are Java, C, Perl and Python... Comfortable
with technical terminology provided documentation available. Just
never had time to get really inside Linux, been programming 25 yrs.
4) They could be another round of attack, but I don't think so as they
are there straight away after reboot.

Sub-question:
Why isn't there an easy way to just remove all the SYN_RECV sockets
when say timeout is > 10 minutes... HTTP or DNS access persisting
longer than 10 minutes must be something wrong !

Tnx.

---

Request for Question Clarification by bikerman-ga on 20 Oct 2002 05:23 PDT

I'm going to keep posting these as clarifications in order to make sure you
aren't charged unless we get the problem fixed...it may take several tries.
:)

To find the version of the kernel you are running, run 'uname -r'.  For
example, on my machine I get

$ uname -r
2.4.18

I need to know the kernel version because there is a kernel option that
you can turn on (you shouldn't have to recompile the kernel) that is
supposed to prevent SYN DoS attacks.  However, in certain kernel versions,
there was a bug that caused a security hole to be opened when the option
was enabled.  I want to make sure yours isn't one of those versions.

I found several news/list postings that said that the way to get rid
of a socket is to kill the process owning it.  They said that if the
socket is still open, there's still a process owning it.  You should
have the program 'lsof' installed.  Lsof lists open files and sockets, and
shows what process owns each one ('man lsof' for more details).  In order
to see all TCP sockets currently open, run (as root)

# lsof -i TCP

If all of the sockets in question on your webserver port (port 80),
you should be able to list only those with

# lsof -i TCP:80

Note that there is a PID column.  You should be able to kill the processes
with those PIDs using the 'kill' command.  You might try

# kill <pid number>

first, and then

# kill -9 <pid number>

If the first command works, you'll get a message like

"kill: no such pid" or
"kill: no process killed"

when you run the second command.

(The first command sends the process signal 15 (SIGTERM), but a process
may ignore the TERM signal.  The second command sends signal 9 (SIGKILL)
which can't be caught.  See 'man 7 signal' for more details on signal
names and numbers.)

Do you need to be running a webserver on this machine?  If it is only
needed as a DNS server, you could shut your webserver down and shouldn't
have anymore problems with this particular attack.  (DNS uses UDP instead
of TCP and therefore wouldn't be subject to a SYN attack, AFAIK.)  If you
want to shut the webserver down, I can tell you how to do that.  For that
matter, it is generally a Good Thing(tm) to shut down all services that
aren't strictly necessary.

Otherwise, my plan is to enable the option mentioned above (provided your
kernel version isn't buggy).  If that doesn't fix the problem, we could
set up an IPTables table to filter out the offending address.  You may
also want to contact your ISP and give them the IP of the offender.
Although we should be able to prevent the attacker from using up sockets
on your machine, I don't think that we can prevent them from continuing
to send packets and therefore use some portion of your bandwidth.  Perhaps
I'm wrong about that, but I got the idea from section 11.2.5 of the
"Securing Debian Manual".  The page is long, so you might want to search
for SYN_RECV:

http://www.debian.org/doc/manuals/securing-debian-howto/ch11.en.html

Let me know,
bikerman-ga

---

Clarification of Question by mrexcessive-ga on 20 Oct 2002 14:45 PDT

Tnx for rapid response...

#uname -r
2.2.14-5.0

Would you believe the sockets aren't there now, in netstat... perhaps
DoS has stopped temporarily.
I think question deserves to be closed.  I've tried the other things
you mention and am certainly better equipped to deal with it if
happens again (it has been intermittent in the past, symptom is web
clients hang getting pages from httpd. After restart httpd works a
couple of times, which made me think intermittent DoS attack, probably
not need to hang a socket very often once a particular machine stops
responding to SYN_RECV (if I'm using the terminology correctly)).

The process was named I think, but not there now... Killing httpd and
restart always got it back for a few minutes, perhaps the time to next
attack, presumably :80 is open, so is picked on to block webserver
which is listening there. When restart webserver get one socket back
until next attack...

Yes I do need to run webserver there, well in short term anyway. 
Depending on new business may increase machines and rebuild this one
as just dns or dns and samba.

Please would you let me know whether kernel version is ok and how to
enable option, then if/when problem happens again I can try that
straightaway.

Re. them using bandwith.
I suspect a simple attack, not distributed/DDoS or whatever it's
called. Just because src ip has always been same.
So if they are taking out lots of machines using the socket block
thingy(!) then they can keep a given machine under by trying it again
every few minutes - and blocking all sockets if they find its come up
again. Can be annoying if you can't get ssh connection - though I
don't think that this most recent attack has blocked that....
Presuming there is a more malicious reason than simply stopping the
servers, perhaps they are looking to spot newly booted machines,
perhaps they are more likely to be running unsafe servers, have a root
user logged in trying silly things, be open to telnet perhaps.  Maybe
you get a nastier attack briefly when restarting webserver... these
thing are all automated these days. Wonder if anyone writes evolving
ones, nasty!

Cheers for your help. I'll attempt to close it now, but would
appreciate the kernel version and option switch if possible.

Tnx
Peter