Re: SYN Attacks - how i cant stop it
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
Re: SYN Attacks - how i cant stop it
Hi, I got this error when i tried to type for some of those. sysctl: unknown oid any idea.. my server seems to be very lagged, where else the network connection seems fine, i think BSD itself as my other redhat box is fine. What else can i do to get optimum protection. Thanks. - Original Message - From: Per Engelbrecht [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, February 07, 2004 5:58 PM Subject: Re: SYN Attacks - how i cant stop it Hi, snip all nights. Check this. Feb 6 11:54:24 TCP: port scan detected [port 6667] from 212.165.80.117 [ports 63432,63453,63466,63499,63522,...] Feb 6 11:58:09 TCP: port scan mode expired for 212.165.80.117 - snip It's hard to get rid of shit-heads like this - I'm talking about the person doing this attac, that is. You send a looong output of a log, but no info on your system or any adjustments you have made (or not made) on your system i.e. kernel (options), sysctl (tweaks) and ipfw (rules). If the problem is out-of-bandwith (and your system already has been optimized) then the only real solution is more 'pipe' a.k.a the Microsoft-solution. So fare I've only been guessing, but here is what I normally do with my setup. I'm not telling you that this is the solution! just adwises! Kernel; options SC_DISABLE_REBOOT options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options IPDIVERT options IPFILTER options IPFILTER_LOG options IPSTEALTH (don't touch the ttl/can't see the wall) options TCP_DROP_SYNFIN (drop tcp packet with syn+fin/scanner) options RANDOM_IP_ID (hard to do calculate ip frekv. number) options DUMMYNET (e.g. 40% for web, 30% for mail and so on) options DEVICE_POLLING(can't do this short and not with SMP) options HZ=1000 (can't do this short and not with SMP) Sysctl; kern.ipc.somaxconn=1024 #this is set high! kern.ipc.nmbclusters=65536 #this is set high! kern.polling.enable=1 #remember kernel options kern.polling.user_frac=5090 #remember kernel options net.xorp.polling=1 net.xorp.poll_burst=10 net.xorp.poll_in_trap=3 (if you use dynamic rules in ipfw [stateful] you can tweak this) net.inet.ip.fw.dyn_ack_lifetime=200 #shorte timeout on connection net.inet.ip.fw.dyn_syn_lifetime=20 net.inet.ip.fw.dyn_fin_lifetime=20 net.inet.ip.fw.dyn_rst_lifetime=5 net.inet.ip.fw.dyn_short_lifetime=10 #longer timeout for e.g. icmp net.inet.ip.fw.dyn_max=1500 #higher number of dynamic rules net.inet.ip.fw.dyn_count: #count of number of dynamic rules ipfw; There's a zillion ways to set it up. start with a few rules regarding lo0 and icmp. Then use stateful inspection and dynamic rules for the rest of the wall. ... and by the way, I could see that a few of the scan came from RIPE ranges. Do some digging and report it! Even if the boxes are use without the owners awareness, you can [we all can] bring this part to an end. respectfully /per [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SYN Attacks - how i cant stop it
Spades wrote: Hi, I got this error when i tried to type for some of those. sysctl: unknown oid any idea.. my server seems to be very lagged, where else the network connection seems fine, i think BSD itself as my other redhat box is fine. What else can i do to get optimum protection. Thanks. - Original Message - From: Per Engelbrecht [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, February 07, 2004 5:58 PM Subject: Re: SYN Attacks - how i cant stop it Hi, snip all nights. Check this. Feb 6 11:54:24 TCP: port scan detected [port 6667] from 212.165.80.117 [ports 63432,63453,63466,63499,63522,...] Feb 6 11:58:09 TCP: port scan mode expired for 212.165.80.117 - snip It's hard to get rid of shit-heads like this - I'm talking about the person doing this attac, that is. You send a looong output of a log, but no info on your system or any adjustments you have made (or not made) on your system i.e. kernel (options), sysctl (tweaks) and ipfw (rules). If the problem is out-of-bandwith (and your system already has been optimized) then the only real solution is more 'pipe' a.k.a the Microsoft-solution. So fare I've only been guessing, but here is what I normally do with my setup. I'm not telling you that this is the solution! just adwises! Kernel; options SC_DISABLE_REBOOT options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options IPDIVERT options IPFILTER options IPFILTER_LOG options IPSTEALTH (don't touch the ttl/can't see the wall) options TCP_DROP_SYNFIN (drop tcp packet with syn+fin/scanner) options RANDOM_IP_ID (hard to do calculate ip frekv. number) options DUMMYNET (e.g. 40% for web, 30% for mail and so on) options DEVICE_POLLING(can't do this short and not with SMP) options HZ=1000 (can't do this short and not with SMP) Sysctl; kern.ipc.somaxconn=1024 #this is set high! kern.ipc.nmbclusters=65536 #this is set high! kern.polling.enable=1 #remember kernel options kern.polling.user_frac=5090 #remember kernel options net.xorp.polling=1 net.xorp.poll_burst=10 net.xorp.poll_in_trap=3 (if you use dynamic rules in ipfw [stateful] you can tweak this) net.inet.ip.fw.dyn_ack_lifetime=200 #shorte timeout on connection net.inet.ip.fw.dyn_syn_lifetime=20 net.inet.ip.fw.dyn_fin_lifetime=20 net.inet.ip.fw.dyn_rst_lifetime=5 net.inet.ip.fw.dyn_short_lifetime=10 #longer timeout for e.g. icmp net.inet.ip.fw.dyn_max=1500 #higher number of dynamic rules net.inet.ip.fw.dyn_count: #count of number of dynamic rules ipfw; There's a zillion ways to set it up. start with a few rules regarding lo0 and icmp. Then use stateful inspection and dynamic rules for the rest of the wall. ... and by the way, I could see that a few of the scan came from RIPE ranges. Do some digging and report it! Even if the boxes are use without the owners awareness, you can [we all can] bring this part to an end. respectfully /per [EMAIL PROTECTED] ___ Most important, you did turn on syncookies, did you not? FreeBSD is pretty immune to syn floods. As for out of bandwidth, this has to do with your uplink and how much you pay for your traffic. root# sysctl net.inet.tcp.syncookies If it is not set to one, then do: root# sysctl net.inet.tcp.syncookies=1 Also edit /etc/sysctl.conf to contain net.inet.tcp.syncookies=1. A reboot would clear the tcp stack. You can't reboot remotely if kernel securelevel is enabled in /etc/rc.conf. If you don't have firewall support compiled in the kernel, kldload ipfw. Might be a good lesson to mirror back all incoming syn packets from the attacker's IP to him. To port 80, or 22, or to some any other open port. You can do that easely with ipfw. -- 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 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: SYN Attacks - how i cant stop it
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. How would one go about mirroring back the attackers syn packets to port 80 or 22? Please describe this easy method of yours. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Anton Alin-Adrian Sent: Friday, February 13, 2004 10:27 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: SYN Attacks - how i cant stop it Most important, you did turn on syncookies, did you not? FreeBSD is pretty immune to syn floods. As for out of bandwidth, this has to do with your uplink and how much you pay for your traffic. root# sysctl net.inet.tcp.syncookies If it is not set to one, then do: root# sysctl net.inet.tcp.syncookies=1 Also edit /etc/sysctl.conf to contain net.inet.tcp.syncookies=1. A reboot would clear the tcp stack. You can't reboot remotely if kernel securelevel is enabled in /etc/rc.conf. If you don't have firewall support compiled in the kernel, kldload ipfw. Might be a good lesson to mirror back all incoming syn packets from the attacker's IP to him. To port 80, or 22, or to some any other open port. You can do that easely with ipfw. -- 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 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
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 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: SYN Attacks - how i cant stop it
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Anton Alin-Adrian Sent: Friday, February 13, 2004 11:33 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] 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
