Date: Tue, 2 Dec 2003 12:29:45 -0500 From: "fbsd_user" <fbsd_user@a1poweruser.com> To: "Melvyn Sopacua" <freebsd-questions@webteckies.org>, "freebsd-questions@FreeBSD. ORG" <freebsd-questions@FreeBSD.ORG> Cc: listone@deathbeforedecaf.net Subject: RE: network security sysctl mib's Message-ID: <MIEPLLIBMLEEABPDBIEGEEDPEPAA.fbsd_user@a1poweruser.com> In-Reply-To: <200312012119.20967.freebsd-questions@webteckies.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Thank you for responding with pointers to where I can find some very limited documented info on the MIB's I asked about. No where does any of the doc sources say when these MIB's get control so I set up an test to find out myself. I have 24/7 connection using Adelphia cable. A while back when I was installing a fresh install of FBSD 4.7 I enabled log_in_vain MIB before I had an firewall enabled and the log_in_vain MIB started to display on the root console messages about log_in_vain attempts. This is what the log_in_vain MIB is suppose to do. After enabling IPFILTER firewall the log_in_vain console messages stopped. Yesterday after receiving your replies, I set up a little test on my test bench. I installed an FBSD 4.9 version basic setup and enabled just the log_in_vain MIB. With in an hour I had log_in_vain console messages. I then enabled the IPFILTER load module in rc.conf with only 2 rules which blocked and logged every thing. The log_in_vain messages stopped. I also tried same test compiling IPFILTER into the kernel and that also stopped the log_in_vain messages. The only conclusion one can draw from the test results is that IPFILTER gets access to the packets before the log_in_vain Mib does. To extrapolate on this, it would indicate the other network security Mibs I pointed out in my original post are in the same boat as log_in_vain. The remaining question then is does the IPFW firewall work the same way. If it does then all those network security Mib's only have effect on FBSD systems that are not running an firewall. Today I an going to run my test again this time using IPFW to verify my conclusions. It's my opinion that in today's world of such emphasis on network security that an clear understand of these MIB's are absolutely necessary, indispensable, requisite information that has to be disseminated to the FBSD community and not buried in some obscure, very hard to find place like it currently is. Here is the documentation I created in the sysctl.conf file. What do you think about it? #################################################################### # # # 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 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 redirects. # 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 # To protect your box from the well publicized SMURF attack. This attack # works by sending ICMP 8 0 (ECHO REQUEST) messages to a broadcast address # from a spoofed address. The host should not propagate directed broadcasts. # The following statement sets the default to do not answer broadcasts. # =1 means, answer an ICMP echo request to a broadcast or multicast address. # 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 connecting 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 server 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 -----Original Message----- From: Melvyn Sopacua [mailto:freebsd-questions@webteckies.org] Sent: Monday, December 01, 2003 3:19 PM To: fbsd_user@a1poweruser.com; freebsd-questions@FreeBSD. ORG Subject: Re: network security sysctl mib's On Monday 01 December 2003 20:59, fbsd_user wrote: > net.inet.icmp.drop_redirect=1 > net.inet.icmp.log_redirect=0 icmp(4) > net.inet.ip.redirect=0 > > net.inet.ip.sourceroute=0 > net.inet.ip.accept_sourceroute=0 inet(4) > net.inet.icmp.bmcastecho=0 icmp(4) > net.inet.tcp.blackhole=2 > net.inet.udp.blackhole=1 > > net.inet.tcp.log_in_vain=1 > net.inet.udp.log_in_vain=1 tcp(4) and udp(4) -- Melvyn ======================================================= FreeBSD sarevok.webteckies.org 5.2-BETA FreeBSD 5.2-BETA #2: Mon Dec 1 17:58:47 CET 2003 root@sarevok.webteckies.org:/usr/obj/usr/src/sys/ SAREVOK_NOFW_DBG i386 =======================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?MIEPLLIBMLEEABPDBIEGEEDPEPAA.fbsd_user>