Re: SYN attacks
On Tuesday 06 April 2004 12:01 pm, Spades wrote: > Heya, > > FREEBSD 4.9-STABLE > > Is there anyway to block SYN attacks and prevent it from bring down > my server? > > Its been attacking for sometime. Checkout the link below. There's a series of articles regarding firewalls in FreeBSD: http://www.onlamp.com/pub/ct/15 Best of luck, Andrew Gould ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SYN attacks
Heya, FREEBSD 4.9-STABLE Is there anyway to block SYN attacks and prevent it from bring down my server? Its been attacking for sometime. ___ [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
n 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-Adr
RE: SYN Attacks - how i cant stop it
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: [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 inco
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
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
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, 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 - 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=50>90 #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
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, > > > > 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 - > > > > 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=50>90 #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]"
