+------------------------------------------------------------------+ | Linux Security: Tips, Tricks, and Hackery | | Published by Onsight, Inc. | | | | 15-October-2002 | | http://www.hackinglinuxexposed.com/articles/20021015.html | +------------------------------------------------------------------+ This issue sponsored by: Gibraltar Software, Inc., the source for Automated Security Patch Management. Gibraltar Software's flagship security product, the Everguard(tm) System is your key to Distributed Vulnerability Patch Management across the enterprise. Securely deploy patches to Linux, Solaris, and Windows systems directly from the centralized management console and keep your network up to date. The Everguard(tm) System has powerful administrator alerting tools, feature rich and easy to decipher reporting tools, a centralized management interface and automated centralized patch deployment. For more information, visit http://www.dvpm.com/ -------------------------------------------------------------------- Firewalling /proc entries By Brian Hatch Summary: There are several network-related protections you can enable with simple change to the Linux kernel via /proc pseudo files. The Linux Kernel can be configured using iptables or ipchains to enforce strong network protections. However there are several useful kernel flags you can set to increase your default network security posture without any complicated rules. The /proc filesystem is a window into various parts of the Linux kernel. /proc is not an actual directory on your disk, but is a pseudo filesystem generated by the kernel itself. The files therein represent internal configuration settings of the currently running kernel. Some of these values are read only, while others can be changed. If you're new to /proc, you may also want to check out some previous[1] articles in which I described some other useful features of the /proc filesystem. Many configurable /proc entries have either a 0 or a 1 value, representing false (off) or true (on). For example the /proc/sys/net/ ipv4/tcp_syncookies can only be turned on or off. Other entries are numeric or ASCII data, for example the /proc/sys/kernel/hostname file which contains the hostname of the machine. You can view or change these entries in one of two ways: Direct /proc access To view a kernel variable directly, simply cat the associated file in /proc: $ cat /proc/sys/kernel/hostname flaky Shell output redirection is the easiest method to change a variable - simply write to the file: # echo 'snowy'> /proc/sys/kernel/hostname # cat /proc/sys/kernel/hostname snowy The kernel knows what kind of data to expect, and will convert appropriately. Thus newlines would be discarded from our hostname example above. Sysctl To view a kernel variable with sysctl, simply list it on the sysctl command line: $ sysctl kernel.hostname kernel.hostname = snowy Note that sysctl's argument is simply the /proc file without the leading /proc/sys component, and with slashes converted to spaces. Thus /proc/sys/net/ipv4/tcp_syncookies would become net.ipv4.tcp_syncookies. To change a variable, use the following command line: # sysctl -w kernel.hostname="sleety" kernel.hostname = sleety The kernel changes you make do not apply across a reboot. In order for them to persist, you need to either: * Create a new startup script in an appropriate /etc/rc#.d directory which runs the cat or sysctl commands, or * Put "variable=value" lines into /etc/sysctl.conf. These lines are just like sysctl commands, without the 'sysctl' keyword or '-w' flag. For example: $ cat /etc/sysctl.conf net.ipv4.ip_forward = 0 kernel.sysrq = 1 So now that you know how to change these settings, here's a shell script you can use to tweak kernel variables to increase the default network security of your machine. You can use this directly, or create an /etc/sysctl.conf file that does the same thing. # Handy functions to set the file to one or zero enable () { for file in $@; do echo 1> $file; done } disable () { for file in $@; do echo 0> $file; done } # Disable inbound source routed packets to prevent folks # from spoofing their IP address. No legitimate users # require source routing any more. disable /proc/sys/net/ipv4/conf/*/accept_source_route # Enable TCP SYN cookies to keep us from suffering from # syn-flood DoS or DDoS attacks. See DJB's page at # http://cr.yp.to/syncookies.html if you want to know # how SYN cookies work - it's cool. enable /proc/sys/net/ipv4/tcp_syncookies # Ignore redirects from machines that are listed as gateways # (routers set by 'route add ... gw IPADDR'). Not a good idea # if these routers do send redirects, which is likely if you # multiple routers on your net but only one default configured. # # Redirects can be abused to perform man-in-the-middle attacks, # so you only want them enabled from trusted sources. enable /proc/sys/net/ipv4/conf/*/secure_redirects # Reject any non-secure redirects disable /proc/sys/net/ipv4/conf/*/accept_redirects # Don't send any redirects either. (Only use if you're # not acting as a router that needs to send redirects.) disable /proc/sys/net/ipv4/conf/*/send_redirects # Do not respond to packets that would cause us to go out # a different interface than the one to which we're responding. enable /proc/sys/net/ipv4/conf/*/rp_filter # Reassemble fragmented packets. Usually a good idea. enable /proc/sys/net/ip_always_defrag # Log any packets that have IP addresses that shouldn't exist enable /proc/sys/net/ipv4/conf/*/log_martians; do # Disable packet forwarding # (Do not do this if you're a router/firewall!) disable /proc/sys/net/ipv4.ip_forward # Send an ARP for address to which we have a route. Good # for some firewall and VPN/router setups, bad for hosts. disable /proc/sys/net/ipv4/conf/*/proxy_arp # Ignore broadcast pings # (Don't participate in smurf attacks) enable /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts # Ignore all pings. # (May be considered a bit excessive.) #enable icmp_echo_ignore_all NOTES: [1] http://www.hackinglinuxexposed.com/articles/20020507.html ------------- Brian Hatch is Chief Hacker at Onsight, Inc and author of Hacking Linux Exposed and Building Linux VPNs. When not perusing Linux kernel code, he likes to obfuscate his office as a pro-active security measure. Some call it cluttered or messy, but he knows the truth. Brian can be reached at brianat_private -------------------------------------------------------------------- This newsletter is distributed by Onsight, Inc. The list is managed with MailMan (http://www.list.org). You can subscribe, unsubscribe, or change your password by visiting http://lists.onsight.com/ or by sending email to linux_security-requestat_private Archives of this and previous newsletters are available at http://www.hackinglinuxexposed.com/articles/ -------------------------------------------------------------------- Copyright 2002, Brian Hatch. - ISN is currently hosted by Attrition.org To unsubscribe email majordomoat_private with 'unsubscribe isn' in the BODY of the mail.
This archive was generated by hypermail 2b30 : Wed Oct 16 2002 - 04:17:07 PDT