Broadcasts on UDP port 41224

In case it helps someone else:

I was seeing broadcasts ( dst: ) about every 30 seconds (top and middle of the minute) to UDP port 41224 from a windows box. The a process named "java" was sending to UDP port 41224, and a different "java" thread was listening on UDP port 41224.

The UDP payload only included the text, "KEY:ABCDXYZ"....

It turns out, it’s an e-trade streaming quote applet, runs in an IE window, but uses the java plugin (process name ‘java.exe' ). Apparently it's pay-ware, and it regularly sends out its key and listens for other applets with the same key, ostensibly to ensure that someone isn't running the same license on multiple computers.


Quickly create or request ssl certificate for Apache

#Create different directories for the different data (this is the path for RedHat derivatives)
cd /etc/httpd/conf
mkdir ssl.csr ssl.key ssl.crt
chmod 700 ssl.*

Self-Signed Certificate

# Create the cert request. Common Name (CN) should be the FQDN, e.g., myhost.foo.com
# 2048 bits is probably adequate these days. Expiration more than 5 years makes little sense.
# PEM passphrase is what the server process (or user) will have to type to use the cert; it
# can be bypassed if you want with the key file in the next step.  EDIT: current versions
# of openssl that ship with CentOS/RHEL do not let you bypass the PEM
# passphrase. Give it one, then create the key file if you want to eliminate the need for it.
openssl req -newkey rsa:2048 > ssl.csr/myhost.foo.com.csr

# create the key file, myhost.foo.com.key (careful! this makes it so that e.g. httpd will
# not prompt for the key on startup, but so that the cert is easily
# read if the host is compromised.)
openssl rsa -in privkey.pem -out ssl.key/myhost.foo.com.key

# self-sign/create the cert, myhost.foo.com.crt
openssl x509 -in ssl.csr/myhost.foo.com.csr -out ssl.crt/myhost.foo.com.crt -req -signkey ssl.key/myhost.foo.com.key

Externally signed certificate request
openssl req -newkey rsa:1024 -keyout ssl.key/myhost.foo.com.key -out ssl.csr/myhost.foo.com.csr

mail the myhost.foo.com.csr file to your ssl provider.
Make the key unencrypted if you want:
openssl rsa -in ssl.key/myhost.foo.com.key -out ssl.key/myhost.foo.com.key.unenc
...and reference the unenc file in your ssl host config file. This will prevent having to enter the encryption key passphrase every time the httpd is restarted, but it will mean your key could be compromised if the box is compromised.

Linux password policies

Password expiration (when password is changed or account is created):

edit login.defs

parameters are:
Password policies include: PASS_MAX_DAYS, PASS_MIN_DAYS, PASS_MIN_LEN

From http://www.puschitz.com/SecuringLinux.shtml#EnforcingStrongerPasswords and http://kbase.redhat.com/faq/FAQ_80_6045.shtm:

Create backup then list contents of the tar file:

# tar -cvf backup.tar /etc/pam.d/system-auth /lib/security/*
# tar -tf backup.tar

Open file /etc/pam.d/system-auth file with an editor such as vi. Inside the /etc/pam.d/system-auth file you will find line:

password requisite /lib/security/$ISA/pam_cracklib.so retry=3 type=

To require a password of at least 8 characters, including at least one lower-case, one upper-case, on numeric, and one other character, replace that line with:

password    requisite     /lib/security/$ISA/pam_cracklib.so retry=3 minlen=8 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=-1

reset perl CPAN configuration

# run cpan shell

# reset config options
cpan> o conf init

Getting started - MySQL on CentOS

yum install mysql-server.x86_64
# ( or .i386, etc)


/usr/bin/mysqld_safe &

# (please don't use "password" -- duh!)
/usr/bin/mysqladmin -u root password "password"

# start mysql client
mysql -u root -p

# give remote access to root if root is accessing mysql from hostname.foo.com (think before you do this -- you probably don't want to leave it like this:
mysql> GRANT ALL PRIVILEGES ON *.* TO 'root'@'hostname.foo.com'

# give root access to root from localhost, .e.g, for accessing mysqld locally over tcp socket.
mysql> GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' IDENTIFIED BY
mysql> 'password' WITH GRANT OPTION;

# give root access to root from anywhere -- why on earth would you want to do this???!!
mysql> 'password' WITH GRANT OPTION;

# give reload+process access to all databases for admin@localhost
mysql> GRANT RELOAD,PROCESS ON *.* TO 'admin'@'localhost';

# give usage access to all databases for dummy@localhost:
mysql> GRANT USAGE ON *.* TO 'dummy'@'localhost';

# now, stop mysqld from running in "safe" mode
service mysqld stop
service mysqld start


Open Source CMS Comparison

One of my clients has a static web site. When they need content or layout changes, they tell me and then I edit the html. Very painful, for them and for me (that's not how I like to earn my keep).

I'm preparing a comparison of various free (and open source) Content Management Systems. The spreadsheet comparison is here:

Open Source CMS Comparison


TIP: grub+RAID1 /boot

Adapted from http://gentoo-wiki.com/HOWTO_Gentoo_Install_on_Software_RAID :

If you are using a RAID 1 mirror disk system, you will want to install grub on all the disks in the system, so that when one disk fails, you are still able to boot. The find command above will list the disks, e.g.

grub> find /boot/grub/stage1

Now, if your disks are /dev/sda and /dev/sdb, and /boot is its own partition at /dev/sd(a-?)1 , do the following:
device (hd0) /dev/sda
root (hd0,0)
setup (hd0)

This will install grub into the /dev/sda MBR, and

device (hd0) /dev/sdb
root (hd0,0)
setup (hd0)

...will install grub onto the /dev/sdb MBR. The device command tells grub to assume the drive is (hd0), i.e. the first disk in the system, when it is not necessarily the case. If your first disk fails, however, your second disk will then be the first disk in the system, and so the MBR will be correct.
...repeat for all physical disks that have a mirror of /boot.

The grub.conf does change from the normal install. The difference is in the specified root drive, it is now a RAID drive and no longer a physical drive.