Security and certification at LinuxWorld Toronto
The first day of this year's LinuxWorld Conference & Expo Toronto started off with its traditional two threehour long tutorials. From the provided list, I selected "The Open Source Security Tool Arena," presented by Tony Howlett for the morning, and DeeAnn LeBlanc's "Hit the Ground Running: Red Hat Certifications Preparatory" in the afternoon.
Tony Howlett, president of Spring, Texasbased Network Security Services and author of a book on the topic, gave the opening seminar to a crowd of around 30 people. He described his session as the Reader's Digest version of his book, and started out his session with a warning not to use tools and methods he described on systems without getting written permission to do so. He warned that with verbal permission only, when something goes wrong, the person who gave that permission can deny it and you can be reprimanded or lose your job for trying these security tools in a way that brings down a productivity system.
Howlett's presentation and book are based on Mandriva 10.1, though most of his presentation actually took place in Windows XP. He had two laptops set up with a KVM switch attached to the overhead projector.
Howlett noted as he started into his presentation that while open source security tools exist for Windows, they are not as common as their Linux counterparts, but their numbers are increasing. Within Linux, he says, just about every domain of security is covered by good open source tools.
Many security vendors, Howlett said, use open source tools as the base of their products. As well, many open source tools compare favorably to their proprietary and expensive counterparts; Howlett cited Snort as one example of this.
Howlett addressed the ageold question, "Is open source or proprietary software more secure?" His answer was neutral, suggesting that it is a difference in philosophy, not a difference in security. In the case of Windows, he noted, security was not the priority until recently. Microsoft's priority had been to get releases out the door, and it has only recently begun making security a serious priority, and now Windows is catching up to Linux for security.
What advantages does using open source security tools offer? Howlett says one key one is cost reduction.
Should you use a $15,000 piece of software when a free one will do the same thing? "Be the budget hero," he advised, and get yourself noticed and promoted in your company by recommending open source solutions. He suggested that saving a company large sums of money by implementing free versions instead of proprietary ones can be the difference between keeping and losing a job when layoffs come around, too.
He also advised users to use more than one tool. No single tool can do everything, and some have weaknesses that others don't.
He suggested that the best way to get into network security as a career is to get into it. Find the tools and get into the development through Sourceforge.net and freshmeat, Howlett recommended. Read the code and learn how the tools work. Offer help on the appropriate mailing lists lists, do beta testing, and get your name out. Having good security knowledge is good for your résumé, he advised.
On the topic of mailing lists, he noted that they're much more efficient than the commercial approach of putting you on hold for two hours and transferring you overseas to a tech support person elsewhere. While spending that time on the phone, Howlett commented, your email reply will come back and your problem will be resolved.
When using security tools, Howlett says, make sure you're building security onto a secure operating system. Building on top of an insecure operating system is like building on sand. The best way to build a secure system, he says, is to start from a fresh system and build security tools into it as you add your services. He recommended a suite of scripts designed to help lock down your system called Bastille Linux. Bastille, which requires Perl and some associated tools, is supported on Debian, Red Hat, Mandriva, Mac OS X, HPUX, and Solaris, Howlett says. It works by interactively asking what a system will be used for and applying security to the system to prevent other uses of it.
Firewalls started as open source software, Howlett says, suggesting that they are the most basic level of network security. In Linux, iptables has been the standard firewall since the release of kernel 2.4, following the 2.2 kernel's ipchains and the 2.0 kernel's ipfw. Iptables can have rules set as needed or within a startup script, he says, and added that a lot of commercial firewalls use iptables under the hood, citing Watchguard Firebox as an example.
Turtle Firewall, he says, is iptables with a Web interface using Webmin. Turtle Firewall allows you to see all your firewall rules, he says, adding that this tool with iptables is as good as or better than a Linksys hardware firewall.
He also suggested Smoothwall Express as a useful open source firewall. Smoothwall, he explained, is a turnkey dedicated firewall system. A system running Smoothwall should not be expected or intended to run anything else. Smoothwall is available commercially or as a free download (as Smoothwall Express).
Smoothwall is a strippeddown Linux system with only the essentials for the firewall remaining.
Port scanners were the next security tool he discussed. They are important to both security professionals and those who would seek to harm systems, he noted. For the purpose, he says, Nmap, from Insecure.org, is the best tool "bar none." He described Nmap as a lightweight port scanner that can run on most Unixes, Linux, Windows, and from either the command line or within a graphical environment.
Howlett said that Nmap is useful for ping sweeps, where the program pings an entire range of IP addresses on a network to see what is alive; OS identification; and determining what services are active on a system. He recommended scanning your own systems other people won't hesitate to do so, he said, so you might as well see what they're going to see.
In the case of OS identification, he described TCP fingerprinting as a way to determine the operating system of a networked system by the way it assembles its packets. He described the process of TCP fingerprinting as 80% accurate, and noted that if you query something for its operating system and find that Nmap does not know what it is, you can add that fingerprint to the existing database for others to be able to identify it in the future. He noted that determining the operating system can also be useful for a "bad guy."
He explained that port scanning is useful for finding running services on a computer that are not meant to be active. It can also be used to track down and identify running spyware and legacy services that waste resources and can lead to denial of service attacks. One example of this is chargen, a service that runs on port 19 and merely generates random characters when queried.
From port scanners Howlett moved on to the next logical step, which is vulnerability scanners. Howlett described vulnerability scanners as port scanners that take it a step further, and cited Nessus as his favorite. When a vulnerability scanner finds an open port it checks to see what software is running on that port, and compares its results against a database of security vulnerabilities. If an option is set to do so, it will attempt to exploit anything it finds in an effort to determine whether the system has any vulnerabilities.
Howlett noted that the company behind Nessus was no longer developing the current version as open source. This has resulted in a number of forks, the most popular of which is OpenVAS. Nessus is still free, but has a limited license. It's still good, but not open source, Howlett said.
After extensive discussion of Nessus, OpenVAS, and a related application developed by Howlett and others called NCC, Howlett went on to the topic of intrusion detection and intrusion prevention systems. In brief, intrusion detection systems are complex packet sniffers that also do other tasks, identifying any vulnerability exploited. Intrusion prevention systems, on the other hand, take proactive measures when potential attacks are discovered, but with the downside that false positives can cause problems for a network or system.
Howlett warned about the hazards of wireless networks, and how a lot of security compromises are made possible by careless use of wireless. Using a tool called Kismet, he showed that 37 unsecured wireless access points were visible from our conference session room, not all of which were the ones providing the conference's wireless connection.
Using a variety of tools, he demonstrated that information going over a wireless network including hashed passwords are readily obtainable and can be used nefariously.
Howlett covered so much material in the morning session that it would be impossible to describe it all in one article, and he continued in the afternoon with another threehour session covering still more. All in all, this was a highly useful session for anyone interested in securing their computer systems and networks, as everyone should be.
Red Hat certification
In the afternoon, I attended DeeAnn LeBlanc's session covering what one needs to do to be able to pass the Red Hat Certified Technician and Engineer exams.
Addressing the question of whether a certification is actually important, she acknowledged that it depends on what you want it for. Years of experience administering Linux systems will be at least as valuable as a certification, but some companies may insist that their employees be certified whether or not it's relevant.
To prepare for an RHCT or RHCE exam, LeBlanc said you need to start by reading Red Hat's published exam goals, and get lots of practice administering Red Hat systems. On the test, there will be no Internet access, but all documentation included in a standard install, namely man pages and the information found in /usr/share/doc/, will be available.
Before considering taking an exam, you should know how to create, modify, and view files, have a basic familiarity with console text editors, and at least one console Web browser in the event that your graphics system is down you need an alternative that you are familiar with, she explained.
Knowing awk, Sed, grep, and a text editor like vi is important, as is knowing how to redirect input and output on the command line. A basic understanding of TCP/IP networking, file compression and archiving tools (namely tar and gzip), email clients, and the "switch user" (su) command are also important to know and understand. Finally, you need to be able to find your way around a console FTP client.
The RHCT and RHCE exams are divided into two parts, she says: troubleshooting and maintenance, and installation and configuration. Red Hat used to include a written section in the tests, but abolished it after finding no significant difference in the results with or without the section.
Under the first category for the RHCT test, which is the basic technician's exam, you must be able to perform such tasks as booting into a specific runlevel such as single user mode, diagnose network problems, configure X and a desktop environment, create filesystems, and know your way around the command line.
For installation and configuration, she explained, you must know how to install a Red Hat system over a network, partition a hard drive, configure printing in the graphical and console environment, use cron and at to schedule execution of programs, and know how to look up commands you don't already know, for starters.
A candidate must also know how to set up and run Lightweight Directory Access Protocol (LDAP) and Network Information Service (NIS), use the automounter for filesystems that don't need to be mounted at all times, manage user and group quotas, alter file permissions and ownership for collaborative projects, install RPM packages manually, update a kernel RPM properly that is to say without deleting the previous version alter a boot loader configuration, set up software RAID during or after installation, and set or modify kernel parameters in /proc or using sysctl.
The Red Hat Certified Engineer exam requires all those skills, she said, and then some. She suggested that you set up a disposable system to practice for an exam and to learn the skills needed to pass it, and repeatedly break and then fix it. For example, deliberately put a typo in a boot loader configuration, she suggested, and see the results. Explore and understand.
You cannot cram for an RHCT or RHCE test, she said, you must simply practice.
Originally posted to Linux.com 2006-04-25; reposted here 2019-11-24.
Posted at 11:08 on April 25, 2006
This entry has been archived. Comments can no longer be posted.