Sunday, August 20, 2006

Defcon 14 in Vegas

Defcon had its 14th year in Las Vegas just a few weeks back (specifically August 4 – 6). I haven’t attended for a few years. The old Defcon had gotten too glitzy and commercial. It had lost the juvenile antics and outlaw spirit, becoming another commercialized security fest, with slick marketing-like presentations lacking in technical substance. No more Mylar balloons launched over Area 51 anymore.

I decided to attend this year mainly because I felts I was losing my edge in technical security issues. My employer is going through fits regarding our training budget, so the $80 registration fee was something I could easily swallow.

After many years at the Alexis Park, Defcon moved to the Riviera. It’s a larger hotel, with a full-on casino (unlike the Alexis Park, which distinguished itself as the one place in Vegas with no gambling, hence friendly to the under-18 set). The hotel was OK as far as accommodations was concerned. It was at the chintzy side of the strip, though a reasonable walk to the better hotels. The layout of the hotel was very confusing – it took me the full 2 days before I could figure out how to get from point A to point B. I also found the staff to be a bit on the surly side.

I was very pleasantly surprised at the conference presentations. Defcon has made the full transition to a professional security conference very well. The speakers were all well prepared, spoke well, and presented valuable topics in a comprehensible fashion. No more swaying drunks trying to talk about PBX hacking.

Here are the sessions I attended with a short summary for each:

  • Visual Log Analysis – The Beauty of Graphs (Raffael Marty) – Different visual styles for presenting firewall logs, basically tree maps (node-to-node) and bar-charts ( leveled breakdown by protocol, with cell size proportional to number of events). He really likes Afterglow for parsing logs and providing them in a standard format for GraphViz or LGL to display.

  • 802.1x Networking (tommEE pickles) – Tutorial on how to build a small secured wireless access system, including use of RADIUS for authentication.

  • Evolving Art of Fuzzing (Jared DeMott) - Very good stuff on software quality assurance in general, and specific issues with fuzzing. Notes the trade-off between random tests and total test time (lots of random cases mean testign will take a lot longer). A big issue is how to know when the application is “broken” by input. For example, running the app in a debugger will give you useful information, but the debugger itself changes how the application responds (e.g., to timing attacks).

  • IBM Networking Attacks (Martyn Ruks) – Looks at Datalink Switching (DLSw) as a means of attacking large IBM mainframes. DLSw is a method for encapsulating SNA in IP. Very good intro, could be used as a tutorial in SNA.

  • Secure Cloaking and Anonymous Services (Michael Rash) – A lot about Tor and how to combine it with single packet authentication.

  • Fun with 802.11 Device Drivers (Johnny Cache) – Showed a video of a machine being rooted via a vulnerable 802.11 device driver. Nothing a firewall can possibly do about this attack, as it occurs at layer 2. Scary stuff.

  • UNCLASSIFIED Information Sharing with Non-Traditional Partners (Linton Wells) – The straight guy in the group. He gave a very polished talk on DoD humanitarian initiatives, ending with a pitch for Defcon attendees to join up and become part of the DoD team.

  • Corporate Network Spying (Andrew Whitaker) – Very basic Hacking 101. Nice summary of methods for attacking switched networks. I only stayed for the first hour.

  • Traffic Analysis Panel (Jon Callas, moderator) – Think your encrypted communications will keep you safe? Think again. An amazing amount of information can be inferred from traffic analysis, and there is no feasible way to mask traffic patterns given the current Internet. Typing patterns can reveal what you are saying, even if you use SSH.

  • Graphical Representations of Security Relationships: Awesome or Bullshit? (Foofus) – Awesome graphical representations are simple and illustrate a specific useful relationship. Bullshit presentations are complex and impossible to read.

  • Phishing Tips and Techniques: Tackle, Rigging, and How & Where to Phish (Peter Guttman, all the way from New Zealand) – Server certs mean nothing. Most Web users have absolutely no clue about what they mean. Users are trained by bad sofvtware to ignore security warnings, and US banks are miserable when it comes to securing their own Websites. A successful phish should skip the server cert and just make a nice fancy dynamic Web page
that looks just like a real bank’s.

Friday, August 04, 2006

Hardening Fedora Core 5

I revised a year-old hardening document designed for Red Hat Enterprise, forking it to create a hardening document for Fedora Core 5.


I followed the CIS recommendations in general. These consist of:
    Patch to OS
  • Remove (or don’t install) unnecessary services
  • Further harden with Bastille Linux
  • Apply a few more scripts to provide additional hardening.

The first two points are no-brainers. The difference is that yum is used to patch Fedora, while up2date is used for RH Enterprise. Do the following:
yum update

Fedora Core 5 supports SELinux to the extent of asking for configuration as part of the install process. I decided the hardening process should set SELinux to “warn” (permissive) mode initially, then set it to ‘enforce” mode once it is clear that applications would not be affected. There is an obvious analogy to installing RACF in this process. The trick is to eventually graduate from permissive to enforce mode.

Here’s how to do this:

  1. Review SELinux policy violation messages
    After applications have been installed and are running, search the messages log file for any SELinux error or warning messages:
    grep avc /var/log/messages

    If SELinux were to be installed in enforce mode, the listed errors would cause the application to fail. SELinux policy violations resulting from normal application use should be corrected by modifying the policy before setting SELinux to enforce mode.
  2. Revise SELinux policy to permit normal application functions
    A procedure is described in http://fedora.redhat.com/docs/selinux-apache-fc3/sn-debugging-and-customizing.html to modify the local SELinux policy to prevent authorization failures from normal application use. This procedure is summarized as:

    2.a. Install the yum module checkpolicy:
    yum install checkpolicy

    2.b. Create a file containing the SELinux error log messages
    grep avc /var/log/messages > avc

    2.c. Create a local SELinux policy file:
    /usr/bin/audit2allow –M local 

    2.d. Load the policy file into the kernel:
    /usr/sbin/semodule –i local.pp

    SELinux error messages should be tracked to ensure no other authorization failures occur.

  3. Set SELinux to enforce mode
    Observe the messages log file for any further SELinux error or warning messages. If no authorization failures occur due to normal application operations, SELinux should be set to enforce mode:
    /usr/sbin/setenforce 1


Bastille has turned out to be a real pain. Bastille allows use of batch files to automate the hardening process. The batch files are replicas of the questions and answers used in the interactive hardening. Unfortunately, the batch files must follow a specific format exactly, or the entire process aborts. If a question/response is missing or out of order, the hardening never happens. You then have the option of running Bastille interactively, in either graphical or curses-text mode.

Running in a graphical environment requires X. Hardened servers should not run X or even have the applications installed. First, I’ll be damned if I install X just to run a one time configurator. Second, if I’m going through the trouble to harden a server using Bastille, why would I introduce an unsafe application?

Text mode requires the perl curses modules. If you don’t have the modules, you would have to install them. Installing curses requires a ‘c’ compiler. Again, what hardened server keeps compilers around “just in case”? The same issues as with X – why go through the trouble, and why weaken security to run a hardening script?

Instead, I reviewed Bastille’s functions and specified shell commands to perform the same functions:

  1. Remove non-root access to the following commands: linuxconf, fsck, ifconfig, runlevel and portmap:
    chmod 700 command
  2. Disable suid for mount/unmount commands:
    chmod ug-s command
  3. Remove suid status for dump and restore, cardctl, at, news server stuff (inndstart and startinnfeed), printing utilities (if not using anyway), usernetctl:
    chmod ug-s /usr/bin/command

  4. Remove all permissions for r-utilities ( rcp, rlogin, rdist, RSH, REXEC, RCP) so not even root can run these utilities without changing permissions explicitly:
    chmod 000 command

  5. Enable password aging in /etc/login.defs. The password change interval should be set as required by ITD policy. The minimum password length should be set to eight characters using the parameter PASS_MIN_LEN 8

  6. Require use of strong passwords for user accounts. To set up password restrictions, edit the /etc/pam.d/system-auth file and add/change the following:
    password    requisite     /lib/security/$ISA/pam_cracklib.so retry=3    minlen=8 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=-1
    Note that running authconfig will destroy these changes, so permissions to authconfig should be set to avoid this:
    chmod 000 /usr/bin/authconfig
    chmod 000 /usr/sbin/authconfig

  7. Set default umask - always edit the /etc/login.defs file to change the default umask to 077. Add the line UMASK 077 to the end of the file.

  8. Remove unnecessary accounts: news, uucp, games, gopher. Also remove ftp, apache, and named if not using these service. Remove all associated groups having the same name as the removed accounts. userdel account groupdel group

  9. Create authorized use banner in /etc/motd .

  10. Disable these services unless specifically required: nfs, nfslock, ypbind, portmap, rpcidmapd, rpcgssd, netfs, cups, cups-config-daemons, hplib, and kudzu. Note that many servers may require printer access. Printer services may remain enabled if documented in the SIS and approved by ITD Security.

    These services are specifically described in the CIS hardening document. Other unnecessary services should be disabled as well, including isdn and bluetooth-related services.

    To disable services, from the System menu select the option Services. Select the background tab to remove services started at boot time.

  11. Remove these applications unless specifically required: apmd, PCMIA services, GPM, and news. To remove applications, from the Applications menu select the option Add/Remove Software.

These don’t cover everything Bastille could cover, but they reflect the needs of the environment. I specifically excluded hardening steps designed to protect against inappropriate physical access (e.g., USB boot devices, boot passwords, etc.). The servers are in a secured data center, so physical security should be adequate. An intruder with physical access can always work around logical security measures. Conversely, these measures will make needed emergency maintenance more difficult.