SYN Attacks - how i cant stop it
Anton Alin-Adrian
aanton at reversedhell.net
Sat Feb 14 06:54:30 PST 2004
JJB wrote:
> 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.
>
Syn cookies are "relatively" new to FreeBSD. "Long" time ago, FreeBSD
had different protection for syn attacks (dropping of random SYN
packets, progressively increasing as SYN flood increases).
I use an ipfw pipe with dummynet kernel options, to limit icmp bandwidth.
My 100 MB/s server, is forced to behave as a 128 Kbps ISDN link when
dealing with
ICMP packets,with a big enough buffer for queueing packets.
This way, ICMP flood attacks are efficiently taken out, while not
ignoring RFCS, and replying back to all ICMP traffic, in normal
circumstances.
Also I have a similar setup for UDP traffic, which limits it's bandwidth
to 90% of all. This way TCP will always have a 10% room of our total
bandwidth.
Eventually, if all bandwidth is taken out by the flood, and the ISP does
nothing about it, we're going to sink.
If you write an article on FreeBSD security, there is *no way* to skip
over the CERB Reality project. Check it at http://cerber.sourceforge.net/ .
FreeBSD is pretty secure from head to toe.Without CERB, there's not
really much to be done.
All BSD fammily of packet filters are excellent. This is valid for all
of the ipfw,ipfilter and openbsd pf suite.
It's simply the most powerfull and complete level of security on unix.
It is 10 times more powerfull than linux's grsecurity system, because it
has the power of controlling syscalls.
--
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
More information about the freebsd-questions
mailing list