From owner-freebsd-questions Mon Mar 18 17:50:50 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 E61DE37B41C for ; Mon, 18 Mar 2002 17:50:07 -0800 (PST) Received: from barbish ([63.70.155.73]) by mail.mango-bay.com (Post.Office MTA v3.5.3 release 223 ID# 0-52377U2500L250S0V35) with SMTP id com for ; Mon, 18 Mar 2002 20:50:06 -0500 From: "Joe & Fhe Barbish" To: "FBSDQ" Subject: Security knobs, when do they execute? Date: Mon, 18 Mar 2002 20:50:03 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 To all the FBSD security wizards. I have found this list of special security knobs that have impressive sounding names. The information that is missing is WHEN do these knobs get control to do their thing? The normal flow for inbound packet would be kernel, Nat, and ipfw. Where does each one get control to do it's thing? When these knobs do there thing is there some way to record the event happened? I know log_in_vain issues a message, but I have not gotten anything from the others. Are there any knobs I missed? log_in_vain="YES" icmp_drop_redirect="YES" tcp_drop_synfin="YES tcp_restrict_rst="YES" syslogd_flags="-ss" portmap_enable="NO" sysctl net.inet.tcp.blackhole=2 sysctl net.inet.udp.blackhole=1 Background Info # Extra firewalling options 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 consol 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 web server 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) Another very obscure option is blackhole, new in FBSD 4.4 The blackhole sysctl(8) is 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 setting the TCP blackhole MIB to a numeric value of 1, 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 2, any segment arriving on a closed port is dropped without returning a RST. This provides some degree of protection against stealth port scans. In the UDP instance, enabling blackhole behavior turns off the sending of an ICMP port unreachable message in response to a UDP datagram which arrives on a port where there is no socket listening. It must be noted that this behavior will prevent remote systems from running traceroute(8) to a system. The blackhole behavior is useful to slow down anyone who is port scanning a system, attempting to detect vulnerable services on a system. It could potentially also slow down someone who is attempting a denial of service attack. The sysctl net.inet.tcp.blackhole=2 command can be entered from the command line and will be in effect until the next boot. The sysctl command can also be in the /etc/sysctl.conf file (which you must create) and if present will be activated during the boot process. Read man sysctl for command format to display settings of this option and some others that allow you to change to default dynamic rules time out values. /etc/sysctl.conf file contents sysctl net.inet.tcp.blackhole=2 sysctl net.inet.udp.blackhole=1 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message