From owner-freebsd-questions@FreeBSD.ORG Fri Feb 13 09:22:12 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C89316A4CE; Fri, 13 Feb 2004 09:22:12 -0800 (PST) Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1235C43D1D; Fri, 13 Feb 2004 09:22:12 -0800 (PST) (envelope-from Barbish3@adelphia.net) Received: from barbish ([67.20.101.119]) by mta10.adelphia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with SMTP id <20040213172210.ECTJ12673.mta10.adelphia.net@barbish>; Fri, 13 Feb 2004 12:22:10 -0500 From: "JJB" To: "Anton Alin-Adrian" , Date: Fri, 13 Feb 2004 12:22:08 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <402CFC4A.7020702@reversedhell.net> Importance: Normal cc: freebsd-security@freebsd.org Subject: RE: SYN Attacks - how i cant stop it X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Barbish3@adelphia.net List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2004 17:22:12 -0000 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@freebsd.org [mailto:owner-freebsd-questions@freebsd.org]On Behalf Of Anton Alin-Adrian Sent: Friday, February 13, 2004 11:33 AM To: freebsd-questions@freebsd.org Cc: freebsd-security@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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"