Daily Security Tips from Ed Skoudis - Week of February 3, 2003
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Security Tip for Friday, February 7th, 2003
Remove Unnecessary Stuff That Attackers Use
When installing and configuring the computers that support your critical infrastructure, such as mail servers, DNS servers, and web servers, make sure you remove software that is not needed but is often used by attackers. For example, does your DNS server really need a TFTP client? This program is used to move files around without any authentication, something you surely don't require on your DNS server. Yet attackers' strategies often include manipulating TFTP to move files to a target. So, remove TFTP, as well as a variety of other tools used by the bad guys that are not needed on production systems. Consider removing C language compilers, Perl interpreters, and X Window system tools if they are not required on systems.
Security Tip for Thursday, February 6th, 2003
Educate Your Software Development Team About Avoiding Buffer Overflows
Buffer overflow vulnerabilities continue to plague the security of our computer systems. A buffer overflow can allow an attacker to execute arbitrary commands on a victim machine, letting the attacker take over the system. Buffer overflows are caused by software developers who forget to verify the size of user-entered data before moving it around in memory. You need to make sure your developers always properly check the size of user input in their programs. For a good description of secure coding practices in Linux and UNIX, have your software developers read the document at http://www.dwheeler.com/secure-programs/. For secure software development in Windows, buy your developers the book Writing Secure Code by Howard and Leblanc.
Additionally, there are several notable free automated source code security analysis tools that look for flaws. Feed your source code to these tools, and they'll provide a high-level search for common security mistakes made by your developers. These free tools include:
ITS4: http://www.cigital.com/its4/download.html
RATS: http://www.securesoftware.com/rats.php
Flawfinder: http://www.dwheeler.com/flawfinder/
Security Tip for Wednesday, February 5th, 2003
Protect Your Linux Kernel
Computer attackers who break into systems are increasingly modifying them at the most fundamental level, the kernel itself. The kernel controls which programs run, the use of memory, access to the hard drive, and use of the network interface. By controlling the kernel, the attacker really owns the machine! One of the easiest mechanisms for controlling a Linux kernel involves using loadable kernel modules (LKMs). Normal LKMs are used to dynamically extend the kernel to support new hardware and other services. Malicious LKMs can be used by an attacker to gain backdoor access and to hide on a system.
To prevent such attacks, for sensitive systems, such as firewalls, web servers, mail servers, and DNS servers, limit attackers' (and your own) ability to dynamically alter your kernel. Build a kernel that does not support LKMs, known as a monolithic kernel. For a recipe about how to build a monolithic kernel, check out http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/custom-guide/s1-custom-kernel-monolithic.html. Alternatively, you can use the free Linux Loadable Security Module (LSM) for limiting what LKMs can do, available at http://www.packetstormsecurity.com/linux/security/lsm.tar.gz. Finally, a free tool called St. Michael can prevent and detect some malicious module behavior, available at http://sourceforge.net/projects/stjude.
Security Tip for Tuesday, February 4th, 2003
Make the Internet a Safer Place – Deploy Egress Anti-Spoof Filters
Suppose an attacker takes over one of your Internet accessible servers, such as your web server, DNS server, or mail server. The attacker could use your machine to launch a packet flood against another victim system in a Distributed Denial of Service (DDoS) attack. These attacks send a flood of packets, each with a spoofed source IP address so that the flood victim cannot trace the attack back. To minimize the chance of an attacker launching a flood from one of your own systems, you should implement egress anti-spoof filters at your border router or firewall connecting your network to the Internet. Most people have deployed incoming anti-spoof filters, which block incoming traffic whose source address is assigned to inside systems. But less than 50 % of networks have deployed egress anti-spoof filters. These filters block all outgoing packets whose source address is not on your network. If your web server suddenly starts spewing packets with a source address not on your network, an egress anti-spoof filter would stop it. If everyone implemented egress anti-spoof filters in addition to their current incoming anti-spoof filters, the Internet would be much less susceptible to DDoS floods.
Security Tip for Monday, February 3rd, 2003
Fight Back Against RootKits
RootKits are nasty suites of tools used by attackers to maintain control of victim machines. If bad guys take over your system, they could use a RootKit to set up a backdoor and hide out on your box. RootKits replace critical components of your operating system with the attacker's own malicious code. Some RootKits alter critical system binary applications (such as the UNIX login, ps, and ifconfig programs), DLLs, or even the underlying kernel itself. In addition to using a file integrity checking tool like Tripwire (www.tripwire.com), you should also regularly run a RootKit detection tool. One of the best RootKit checkers for Linux, BSD, and Solaris is called chkrootkit, available at http://www.chkrootkit.org/. This nifty free tool can detect over forty different RootKits, as well as look for symptoms of RootKit infestation.