Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 19 Mar 2002 17:36:18 -0500
From:      "Joe & Fhe Barbish" <barbish@a1poweruser.com>
To:        <diesel@bsdvault.net>
Cc:        "FBSDQ" <questions@FreeBSD.ORG>
Subject:   sysctl security mibs
Message-ID:  <LPBBIGIAAKKEOEJOLEGOGEEKCLAA.barbish@a1poweruser.com>

next in thread | raw e-mail | index | archive | help
I read your article FreeBSD IP Stack Tuning Simplified
http://bsdvault.net/sections.php?op=viewarticle&artid=35
and have some new mibs with 4.4 that you should add,
blackhole & log_in_vain. The following list are the mib's
you suggest to modify for improved security. What I find
missing is any explanation of when these setting get control
in the flow of things. When user ppp with it's built in filter
statements and nat followed by ipfw in a gateway environment
where do these mibs get control to do their thing?

If these get their turn after the packet has traversed the
ipfw advanced stateful checkstate/keepstate rule set, wouldn't
all these conditions have all ready been caught by the ipfw
firewall making these setting useless?.

If it happens after user ppp drops the packet in the stack and
before ppp filter and nat then these mibs act as a pre screen
before any things gets a chance to play with the packet.
This then makes these mibs very important.

I think this should be pointed out in your article.

Also some of these setting can be set in
/etc/rc.conf and or in the kernel source. There just is no
documentation on these setting and the relationship to setting
then in other places.

If you know when these mib's get control I sure would like to know
whether you update your article or not.

Just giving you some info to base a update on like you requested.

Thanks
Joe


net.inet.icmp.drop_redirect=1
net.inet.icmp.log_redirect=1
net.inet.ip.redirect=0
net.inet6.ip6.redirect=0
net.inet.ip.sourceroute=0
net.inet.ip.accept_sourceroute=0
net.link.ether.inet.max_age=1200
net.inet.icmp.bmcastecho=0


used to control system behavior when connection requests are received on TCP
or UDP ports where there is no socket listening. 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. To enable

net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1


# Extra firewalling options in rc.conf
log_in_vain="YES"           # NO is default. YES enables logging of
                            # connection attempts to ports that have no
                            # listening socket on them. Put msg on console

icmp_drop_redirect="YES"    # YES will cause the kernel to ignore
                            # ICMP REDIRECT packets.

tcp_drop_synfin="YES"       # YES will cause the kernel to ignore TCP
                            # frames that have both the SYN and FIN flags
                            # set. Only available if the kernel was built
                            # with the TCP_DROP_SYNFIN option.
                            # change to NO if webserver behind firewall.

tcp_restrict_rst="YES"      # YES will cause the kernel to refrain from
                            # emitting TCP RST frames in response to
                            # invalid TCP packets (e.g., frames destined
                            # for closed ports). This option is only
                            # available if the kernel was built with the
                            # TCP_RESTRICT_RST option.

syslogd_flags="-ss"         # Don't use network sockets so portscan
			          # will not find (security tip)

portmap_enable="NO"         # Don't allow nfs portmapper (security tip)




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?LPBBIGIAAKKEOEJOLEGOGEEKCLAA.barbish>