"Personal" Firewalls

I just received (i before e, except after c) a new laptop at work, and due to software requirements, I still need to keep Windows XP on the machine, otherwise it would be wiped and replaced with Linux or *BSD. (In this instance, I'll use Knoppix to resize the NTFS partition with (aptly named) ntfsresize to free up space for Fedora Core 5 for dual booting.)

The first task with this type of OS is to download a personal firewall (personal is a misnomer, it should be host-based) such that I can connect to the network and download updates for Windows. I've typically used ZoneAlarm, but I've been looking for an excuse to try others, and this seems like a good one.

At first glance, I'm very excited about Core Force, a host-based IPS/IDS with firewalling capability (using OpenBSD's pf firewall package ported to Windows). Best of all, it's freely licensed using the Apache license.

http://force.coresecurity.com/

The other product I intend to try is:

http://www.personalfirewall.comodo.com/

I'll post updates as I get more familiar with these products.

Vulnerability Management

I'm subscribed to numerous mailling lists from SANS, and this morning this little tidbit came across the @RISK list (full email here):

"For everyone who has ever tried to reduce vulnerabilities, and found it
very hard, today is a very good day.  NIST just announced (this morning)
that it is launching a cooperative effort involving NSA, DoD/DISA, DHS,
and the Center for Internet Security, with the help of security and
software vendors, to radically upgrade vulnerability management. The
program will bring automation and standardization to vulnerability
management, and it is real.  Within a few months, you should expect to
see new procurement language that can be used by any organization buying
software or system or system integration, that will require the vendors
and contractors to deliver systems and software compatible with the new
automated vulnerability management program.  SANS will do a free webcast
on it shortly to give you more details."

I'm pleased to hear this, as I think it has great potential. However, with every U.S. government program I reserve judgement until I see the results, as they often have good ideas or plans, but horrible implementation. A good example is FISMA, which gives government agencies scores based NOT on how they secure their infrastructure, but on how well they document it. In other words, they spend more time documenting than fixing the problems they've documented.

I know, because I do IT security work for the government. I spend up to 4 months a year focused on documentation and reporting, and I'm lucky in that I'm responsible for a "small" system, approx. 350 devices.

Inaugural post! RedHat IA64 "mixed-mode" RPMs

With RedHat Enterprise on Itanium (IA64), you can run both 64-bit and 32-bit applications. However, the way in which RedHat handles this is not particularly intuitive, and can cause problems/confusion with the RPM database.

For instance:

[root@ia64 root]# rpm -q zlib
zlib-1.1.4-8.1
zlib-1.1.4-8.1

You may be wondering why there are two zlib packages listed in the rpm database, and you'd be right to do so. On i386 RedHat, finding a package listed twice in the database typically means that something went wrong with installing the update package, causing the rpm transaction to quit before removing the old database entry. However, in this case, that isn't what's happening; note that the version numbers are identical.

This is how RedHat handles having both 64-bit and 32-bit versions of the files. For 64-bit applications and libraries, it uses the RedHat standard directory structure. For the 64-bit version of zlib, the package installs the following:

[root@ia64 root]# rpm -ql zlib-1.1.4.ia64
/usr/lib/libz.so.1
/usr/lib/libz.so.1.1.4
/usr/share/doc/zlib-1.1.4
/usr/share/doc/zlib-1.1.4/README

However, for the 32-bit version of zlib, the results are slightly different:

[root@ap1 root]# rpm -ql zlib-1.1.4.i386
/emul/ia32-linux/usr/lib/libz.so.1
/emul/ia32-linux/usr/lib/libz.so.1.1.4
/usr/share/doc/zlib-1.1.4
/usr/share/doc/zlib-1.1.4/README

Note the leading /emul/ia32-linux (emul short for emulation). Thankfully, within /emul/ia32-linux, RedHat duplicates the standard directory structure, so things are where you expect them to be.

To verify:

[root@ap1 root]# file /usr/lib/libz.so.1.1.4 /emul/ia32-linux/usr/lib/libz.so.1.1.4
/usr/lib/libz.so.1.1.4: ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), stripped
/emul/ia32-linux/usr/lib/libz.so.1.1.4: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped


When installing packages, be careful to remember this oddity, because RedHat Enterprise v. 3 tools aren't kind enough to say something, they will default to installing 64-bit versions. While this isn't often a problem, there are instances when you want both versions. To make sure that you get the 32-bit version, pass the --arch= flag to up2date:

up2date --arch=i386 -i zlib

Enjoy.