## Multi-Layered Security ## Mike Hoskins In this article I am going to stray from the 'hands-on' approach (i.e. focusing on syntax and prompt-based HOWTOs) and focus more on concepts (i.e. discuss ways to increase system and network trust in a more generalized fashion). These concepts will be FreeBSD-specific, but they will be relatively abstract. There is a popular misconception floating around the corporate IS world. Many individuals calling themselves 'administrators' often tout, "UNIX is not as secure as other operating systems. Free variants are especially vulnerable to attack." So the commercial retailers of minis would like us to believe... The fact is, UNIX has the most-tested network stack of any available OS... and that's not just 'commercial' UNIX, the same goes for the public domain versions like FreeBSD as well. To be honest, any OOB (Out Of Box) OS is relatively insecure (or has low 'trust'). The only way to maximize the trust of a system is to develop a strict security policy (read O'Reilly & Associates' Practical UNIX & Internet Security for good guidelines to follow when developing your own policy, or focus on Chapter 2 if you want a quick refresher course), and rigorously follow the rules of said policy when configuring any system installed on your network. As said in past articles, and pointed to in AUCERT's Security Checklist , disabling any services not specifically needed and/or compliant with your local security policy is a first step in increasing host and network trust. Furthermore, popular protocols which must be offered such as SMTP and HTTP should be regularly updated. Telnet should be replaced with SSH, the selected (if any) FTP server should allow thresholds to be set, POP-3 should support APOP (Authenticated POP), etc. Following the above guidelines and keeping abreast of late-breaking developments by subscribing to OS-specific lists such as freebsd-hackers and more generic security lists such as Bugtraq will greatly reduce the vulnerability of your network to outside attack. There is, however, a problem with this scenario... The majority of host and network attacks do not occur 'from the outside'. In fact, according to a recent Computer Security Institute/FBI study, 75% of all intrusions originate from internal sources. This means the demonized view of a modern-day 'hacker' (used in the commercialized sense... from the 'press-is ignoramus' genre) must be shifted from 'socially-inept teens gathered around make-shift Linux boxes late at night trying to impress their friends' to something more along the lines of your typical systems administrator. Not a pleasant thought... To counter internal attacks, a recent Enterprise Systems Journal suggests taking a multi-layered approach. They reported that an ideal multi-layer system would consist of the following layers: 1. Hardened perimeter 2. Host and server monitoring 3. Infrastructure monitoring 4. Conversation monitoring 5. Statistical user profiling 6. Vulnerability assessment 7. Encryption of remote sessions Number 4 can be a bit tricky to implement (without significant performance penalties during periods of high traffic) under any OS, and many solutions utilize RMON2. Due to a relative lack of RMON2 documentation at my disposal, I will not discuss conversation monitoring within this document. Hardened Perimeter The 'perimeter' is generally defined as the line between your LAN, Datacenter, NOC, etc. and the 'outside world'. You want to make this line as hard to cross as possible. To do so, you should implement both a firewall and and IDS (Intrusion Detection System). Here at Qwest, the powers that be have implemented a myriad of firewall technologies along with Internet Security Systems' IDS. There are many commercial firewall and IDS products on the market from such notable vendors as Cisco Systems (PIX Firewall, NetRanger and NetSonar IDS systems) and Tripwire Security Systems (Tripwire) . A few excellent resources for IDS information are COAST, the Computer Security Institute's Web site, and the home page of the Intrusion Detection Consortium. FreeBSD can utilize IPFW or IPFilter to provide a highly-configurable firewall solution. The advantages to such a system is cost-effectiveness and very granular access control. The disadvantages are that the rulesets can be fairly complex and logging facilities leave something to be desired (if you use this for a production environment, you will almost certainly want to develop a custom log analyzer script to make monitoring your firewall easier). Perhaps the best freely-available IDS solution is NFR (Network Flight Recorder). NFR can be effectively used from a commandline, but also provides GUI access and a web-based interface. There are commercial, research and free versions available. Check http://www.nfr.com for more details. Host and Server Monitoring Recent articles I've read tout 'computer misuse monitoring systems' as the wave of the future. There are a number of already-ported FreeBSD applications that provide similar functionality. Tcpd and Clog are just two such ports. Tcpd (TCP Wrappers) is an extremely popular program. If you run UNIX systems and have not yet installed Tcpd, you should do so... now. Tcpd gives you relatively granular access control over TCP connections to your machines. It also provides verbose logging of connection activity (successful and unsuccessful), which makes monitoring the use of your network services much easier. Clog allows you to log all connections on a subnet. It essentially logs SYN packets. It is, perhaps, a bit much for the majority of systems out there, but it is an example of the level of logging that is possible with pre-ported applications on FreeBSD. The default FreeBSD security scripts keep root updated of connection failures, passwordless accounts, and many other things. However, it is relatively easy to create a script to watch log files and email or even page administrators if something out of the ordinary takes place. Syslog can also be configured to dump messages to a centralized logging host (perhaps over a serial connection) which can further analyze critical events. Infrastructure Monitoring Infrastructure monitoring generally refers to keeping a close eye on things like MAC addresses, IPs, hostnames, etc. As a systems and/or network administrator, new MAC addresses or IPs shouldn't really just 'pop up' without anyone knowing why. Arpwatch (requires libpcap) is a nice utility to monitor Ethernet activity and will maintain a database of Ethernet/IP address pairings. This program can be routinely called from cron or some other facility and results can be posted to a private web site which administrators monitor, checked against a 'known good' database, or emailed to an administrator. Icmpinfo can be used without any flags to monitor ICMP packets and report potentially problematic findings (i.e. icmp_unreachable). It can also be used to provide packet-level anaysis of queries, etc. Big Brother provides a plethora of monitoring services. It can monitor basic connectivity, process status, disk usage, and more. It provides a web-based status display and can support pager notification and many other features of high-priced monitoring agents. If you prefer doing things yourself, you could even write a script to monitor MAC addresses... you could ping your broadcast (updating ARP table with all MACs on your subnet) and then 'arp -a' to see a list of valid IP/MAC pairs. You could then save this to a safe place and compare subsequent 'arp' output to this 'known-good' database. Netstat and/or strobe could also be worked into scripts to watch for running/listening services. Statistical User Profiling Most sources recommend user profiling. More than a 'software' issue, this is really a staffing issue. You, and any administrators attending to your machines, should know the habits of your users. A certain amount of logfile monitoring (swatch), history snooping, etc., can provide insights, but is typically too vague to be of much help. You may also want to design scripts to watch the output of utilities like 'last'. You may even be able to design user profiles, and send email or pager alerts to administrators if users login to core machines during non-typical times. Vulnerability Assessment Vulnerability assessment is one of those moderately-useful methodologies that gets way too much press. The problem is that it's very difficult to provide an actually useful level of vulnerability assessment without interfering with the normal operation of a network. This becomes especially true as the monitored network grows in size. Nonetheless, a limited amount of vulnerability assessment is a good thing, and is easily implemented with the use of a couple FreeBSD ports. Crack is one example of vulnerability assessment that many administrators do not think of. 'Weak' passwords are a common source of system break-ins... what better way to ensure the 'trust' of your users' passwords than to attempt cracking them yourself? If you find users who are violating your user policy (which should at least specify 6 character or more, alphanumeric passwords with at least one character that is not a letter or number), alert them immediately and ask them to select a more secure password. Once users know you are performing password audits, they will typically assume proper behavior. For those users who refuse to cooperate, programs like npasswd can be used to enforce strict password guidelines and disallow password reuse for an administratively-selected period of time. Perhaps the best step to take is to closely monitor OS-specific lists (such as FreeBSD-security and FreeBSD-hackers) and more generic lists such as Bugtraq. This will allow you to stay abreast of any late-breaking security flaws and take appropriate action. A port like strobe will allow you to see how your hosts look to curious outsiders. Encryption of Remote Sessions On the administrative level, encrypted remote sessions should be the standard... period. Noone uses telnet, r commands, etc. here. If you're new to ssh, you will learn... fast. For those who can't live without rcp... there's scp. Just as easy, and oh-so-private. SSH allows (relatively) secure remote connections and is easy to setup and use under FreeBSD. We even go so far as removing all other forms of access to boxes which only administrators require access to. On the user level, the choice is yours... Many users find it hard enough to 'telnet' and may be unreceptive to the idea of learning a new client that provides 'ssh' compatibility. Remember, however, that anyone sniffing between you and a remote client will be able to pickup passwords in plain-text traveling over a Telnet session. The implications are obvious, allowing the third party to gain unauthorized access to any machine your legitimate user has an account on. Summary FreeBSD provides a number of ways to increase host and network trust. Furthermore, it allows granular access control and multi-layered systems and network monitoring. FreeBSD is not only 'as secure' as other platforms, but provides numerous free applications that provide monitoring capabilities rivaling those of many, commercially-available products. These applications also include source code, allowing them to be customized to specific applications and client needs. FreeBSD (and UNIX in general) also provides easy access to development tools (the shell of your choice, numerous interpreted languages such as Perl and Python, C and C++, etc.) allowing die-hard admins to code their own solutions on the fly. By utilizing FreeBSD as a base and implementing a number of the freely-available utilities in the ports collection, the trust of an organization's systems and networks can be greatly increased. - Mike $Id: security.txt,v 1.1 2000/02/16 08:07:53 jim Exp $