network security sysctl mib's

Tue Dec 2 09:40:32 PST 2003

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 at webteckies.org]
Sent: Monday, December 01, 2003 3:19 PM
To: fbsd_user at a1poweruser.com; freebsd-questions at 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 at sarevok.webteckies.org:/usr/obj/usr/src/sys/
SAREVOK_NOFW_DBG  i386
=======================================================