From owner-freebsd-questions Tue Mar 19 14:36:29 2002 Delivered-To: freebsd-questions@freebsd.org Received: from mail.mango-bay.com (mail.mango-bay.com [208.206.15.12]) by hub.freebsd.org (Postfix) with ESMTP id 9241537B404 for ; Tue, 19 Mar 2002 14:36:22 -0800 (PST) Received: from barbish ([63.70.155.126]) by mail.mango-bay.com (Post.Office MTA v3.5.3 release 223 ID# 0-52377U2500L250S0V35) with SMTP id com; Tue, 19 Mar 2002 17:36:20 -0500 From: "Joe & Fhe Barbish" To: Cc: "FBSDQ" Subject: sysctl security mibs Date: Tue, 19 Mar 2002 17:36:18 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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