SYN Attacks - how i cant stop it
JJB
Barbish3 at adelphia.net
Fri Feb 13 09:22:12 PST 2004
Very interesting reading about net.inet.tcp.syncookies 'knob'.
Thank you for such an curious and informative reply.
I am running 4.9 and net.inet.tcp.syncookies=1 is the default.
I am writing an 'Harding you FBSD system' article for the local
FBSD club, would you please review the following.
Are my comments correct? Are there any other knobs I should include?
I got the rc.conf securelevel ok as it from the man page.
####################################################################
#
# The sysctl.conf file contains MIB's to change the default setting
# of internal options of the kernel at boot up time. These Mib's
# control how network packets are handled after IPFW or IPFILTER
# software applications firewall returns the packet to the kernel.
# Some of these MIB's may seem like they are doing the say thing,
# but because there is no FBSD provided documentation on the order
# these MIB's get control, they all get enabled here and we let the
# kernel do it's thing.
#
# NOTE: Some of these MIB's can also be set in rc.conf and or the
# Kernel source. This will not hurt anything.
#
####################################################################
####################################################################
# Redirect attacks is the purposeful mass issuing of ICMP type 5
packets.
# In a normal network, redirects to the end stations should not be
required.
# To defend against this type of attack both the sending and
accepting of
# redirect should be disabled". The first statement below enables
the MIB
# to drop all inbound icmp redirect packets without returning any
response.
# The second statement turns off the logging of redirect packets
because
# there in no limit and this could fill up your logs consuming your
whole
# hard drive. But there is no information about where the redirect
packets
# get logged. The last statement changes the FBSD default about
allowing
# redirects to be sent from this system to the internet from yes to
no.
# This option is ignored unless the host is routing IP packets, and
# should normally be enabled (=1) on all systems
# man icmp(4) and inet(4) and man ip(4) do not contain info about
these MIB.
# man sysctl(3) does have info on ip.redirect
net.inet.icmp.drop_redirect=1
net.inet.icmp.log_redirect=0
net.inet.ip.redirect=0
####################################################################
# Source routing is another way for an attacker to try to reach non
routable
# addresses behind your box. It can also be used to probe for
information
# about your internal networks. These functions come enabled as part
of the
# standard FBSD core system. The following will disable them.
# man inet(4) and man ip(4) do not contain any information on these
MIBs.
net.inet.ip.sourceroute=0
net.inet.ip.accept_sourceroute=0
####################################################################
# This MIB only drops ICMP Echo requests which have a destination of
your
# broadcast address. For example, if your network is 10.10.0.1/24,
# (making your subnet mask 255.255.255.0) then your network
broadcast address
# is 10.10.0.255. When a host on your network needs to send a
message to all
# other hosts on the subnet (which happens more often than you may
think) it
# uses this address. Everyone listens on it. Hosts outside your
network have
# no reason to be sending packets to your broadcast address. This
MIB rejects
# all of the broadcast echo traffic from the outside world to your
network
# broadcast address. If this host is a firewall or gateway, it
should not
# propagate directed broadcasts originating from outside your
private network.
# The following statement sets the default to no, rejecting all
external
# broadcasts requests.
# man sysctl(3) has some info.
# man inet(4) and man icmp(4) do not contain any information on
these MIBs
net.inet.icmp.bmcastecho=0
####################################################################
# To change the system behavior when connection requests are
received
# on TCP or UDP ports where there is no socket listening. The normal
# behavior, when a TCP SYN segment is received on a port where there
# is no socket accepting connections, is for the system to return a
# RST segment, and drop the connection. The requesting system will
# see this as a "Connection reset by peer".
#
# By turning the TCP black hole MIB on to a numeric value of one,
the
# incoming SYN segment is merely dropped, and no RST is sent, making
# the system appear as a blackhole.
#
# By setting the MIB value to two, any segment arriving on a closed
# port is dropped without returning a RST.
# This provides some degree of protection against stealth port
scans.
# The following enables this MIB. man tcp(4) and man udp(4)
blackhole(4)
# contain a little information on these MIBs
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
####################################################################
# The log_in_vain MIB will provide you with logging of attempted
# connections to your box on any port which does not have a service
# running on it. For example, if you do not have DNS server on your
# computer and someone would try to access your computer through DNS
# port 53, you would see a message such as: Connection attempt to
# UDP yourIP:53 from otherIP:X (where X is some high port #)
displayed
# on the root console screen. This message also gets posted to
# /var/log/messages & /var/log/security.log.
# The following statements enable this function.
# man tcp(4) and man udp(4) contain a little information on these
MIBs
net.inet.tcp.log_in_vain=1
net.inet.udp.log_in_vain=1
####################################################################
# To defend against SYN attacks more commonly known as SYNFLOOD
attacks,
# the two queues which are targeted by this type of attack should
# have it's size increased so that the queues can withstand an
attack
# of low to moderate intensity with little to no effect on the
stability
# or availability of the system. FBSD maintains separate queues for
# inbound socket connection requests. One queue is for half-open
sockets
# (SYN received, SYN|ACK sent), the other queue for fully-open
sockets
# awaiting an accept() call from the application.
# The following statement increases the queue size from 128.
kern.ipc.somaxconn=1024
####################################################################
# By allowing aged ARP entries to remain cached or lying around
# allows for the possibility of a hacker to create a resource
# exhaustion or performance degradation by filling the IP route
cache
# with bogus ARP entries. This in turn can be used as Denial of
# Service attack. To prevent this sort of problem the following
# statement shortens the amount of time an ARP will be cached
# from 1200 to 600 seconds.
net.link.ether.inet.max_age=600
###################### end of sysctl
####################################
The system logs default to being able to bind to an internal socket
which allows logs to be sent to some other system for recording.
If you are not doing that on purpose then this option should be
disabled using this statement in rc.conf.
syslogd_flags="-ss"
Kernel options.
options TCP_DROP_SYNFIN # Adds support for ignoring TCP packets
# with SYN+FIN. This prevents nmap from
# identifying the TCP/IP stack, but
# breaks support for RFC1644 extensions
# & is not recommended for web servers
# behind the firewall.
The comments with this option are from the LINT kernel source word
for word. I have an Apache web server running on my gateway/firewall
box, and I use this option and can not see any thing wrong
happening.
Options ICMP_BANDLIM # Enables icmp error response bandwidth
# limiting. This will help protect from
# D.O.S. packet attacks.
Options RANDOM_IP_ID # Causes the ID field in IP packets to be
# randomized instead of incremented by 1
with
# each packet generated. This closes a
minor
# information leak which allows remote
# observers to determine the rate of packet #
generation on the machine by watching the # counter.
Thanks for your help.
-----Original Message-----
From: owner-freebsd-questions at freebsd.org
[mailto:owner-freebsd-questions at freebsd.org]On Behalf Of Anton
Alin-Adrian
Sent: Friday, February 13, 2004 11:33 AM
To: freebsd-questions at freebsd.org
Cc: freebsd-security at freebsd.org
Subject: Re: SYN Attacks - how i cant stop it
JJB wrote:
> You talk about the net.inet.tcp.syncookies=1 knob,
> how about an description on what it does and why you
> are recommending using it.
The net.inet.tcp.syncookies 'knob', if set to 1, enables syn
cookies.
Syn cookies were invented specifically for syn flood protection. A
brief
description of syncookies idea can be read here:
http://cr.yp.to/syncookies.html
> How would one go about mirroring back the attackers
> syn packets to port 80 or 22?
> Please describe this easy method of yours.
>
Mirroring back packets to the attacker is, first of all, a nasty
thing.
Secondly, it is only possible if the attacker's IP is known. If it
is
not known, then obviously it's not possible.
Knowing the attacker's IP does not necessarly mean that he is
performing
the current attacks from that IP.
Packet redirection with ipfw is done using divert sockets. One needs
to
have it compiled into the kernel. Divert sockets are also used by
ipfw
nat redirection. It's all in the man pages of ipfw.
If the flood is severly intense (from the point of stack memory
exhaution), it might be a good improvement to drop 5% of incoming
SYN
packets. This can also be done with ipfw, and is described in the
manual
pages. However, I don't think one would ever come to this.
Asking the ISP to put the server behind a decent cisco router, and
implement syn cookies on hardware devices, is the best protection.
--
Alin-Adrian Anton
Reversed Hell Networks
GPG keyID 0x1E2FFF2E (2963 0C11 1AF1 96F6 0030 6EE9 D323 639D 1E2F
FF2E)
gpg --keyserver pgp.mit.edu --recv-keys 1E2FFF2E
_______________________________________________
freebsd-questions at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribe at freebsd.org"
More information about the freebsd-questions
mailing list