Set up Debian PXE boot server

I have always wanted to set up a Debian PXE (Pre-eXecution Environment) server, so I could have machines boot from the network and select an OS to install. Ultimately I expect to be able to do this with any OS, but at first I will have it boot various versions of Debian, from my local partial Debian mirror (maintained with debmirror).

    Right now I’m downloading the Debian installer images with debmirror. For the PXE boot server, I will be following this Debian Administration guide:

  1. The first thing it has me install is tftpd-hpa, which is easy enough:
    
    aptitude install tftpd-hpa
    
    

    This automatically started the tftpd-hpa daemon. The guide suggested I need to edit /etc/default/tftpd-hpa:

    
    # /etc/default/tftpd-hpa
    TFTP_USERNAME="tftp"
    TFTP_DIRECTORY="/srv/tftp"
    TFTP_ADDRESS="0.0.0.0:69"
    TFTP_OPTIONS="--secure"
    
    

    The above are the defaults, and since those looked alright to me, I didn’t modify them. The directory /srv/tftp already existed on my system (probably from an earlier attempt at setting up PXE boot), and was empty.

  2. Next, I needed to set up my DHCP server. This is provided by my custom-built router/firewall, running pfSense. Many home routers don’t allow one to set DHCP options, but pfSense ain’t no ordinairy router. (-; I added my worksation/tftp server’s IP address (hostname did NOT work), put “pxelinux.0” as the filename, and that seemed to be it.
  3. The next step was to configure the PXE boot. I copied the pxelinux files, and debian-installer directory from my local debmirror:
    
    cp -R /var/spool/mirror/dists/sid/main/installer-amd64/current/images/pxelinux.* /srv/tftp/
    cp -R /var/spool/mirror/dists/sid/main/installer-amd64/current/images/netboot/debian-installer /srv/tftp/
    
    
  4. The final step was to test it. Once I configured my VirtualBox test machine, it booted into PXE, saw my server/workstation, and it is now installing Debian Sid!

Where to go from here?

  • Figure out the best way to list multiple Linux distributions
  • Figure out a way to have this boot Windows images

Neither of the above look trivial.

StartCom SSL intermediate certificate chain fix…

In the past year I’ve installed two SSL certificates from StartCom, for my two websites: amberandtrey.us, and eldon.me. Both of these sites (now) are running Debian Sid, and have almost identical configurations. For most browsers/devices I’ve tried, the StartCom SSL certificates work fine (notice the appropriate lock icon in the address bar [in Google Chrome/Chromium it’s a green lock icon]). However, on some devices–most notably my Samsung Galaxy S II running CyanogenMod 9.10, and my mother’s aging iMac–I get a message similar to the following following:

(Sorry for picking on you Midnight Commander, but yours is a website I know generates this error for me consistently. Maybe I can link to this post and have you fix that!)

Searching for the string “entity is not trusted” on the StartCom forums guided me to this posting, which suggests using a free tool called SSL Checker to verify that my SSL installation is complete and without problems. The site gives me the following:

So it is verified that my SSL certificate is not trusted by all browsers. They give a hint back to StartCom’s extensive FAQ. It led me to the Apache Web Server configuration page. I needed to copy both the ca.pem and sub.class1.server.ca.pem, and configure apache2 appropriately (in the sites-available/eldon.me configuration file). My configuration ended up being like this:



DocumentRoot /var/www/eldon.me
ServerName eldon.me
ServerAlias www.eldon.me
ServerAdmin trey@blancher.net
ErrorLog /var/log/apache2/wp-error.log
TransferLog /var/log/apache2/wp-access.log
RedirectPermanent / https://eldon.me



SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM
SSLCertificateFile /etc/ssl/certs/eldon.me.pem
SSLCertificateKeyFile /etc/ssl/private/eldon.me.crt
SSLCertificateChainFile /etc/ssl/certs/startcom_sub.class1.server.ca.pem
SSLCACertificateFile /etc/ssl/certs/startcom_ca.pem
DocumentRoot /var/www/eldon.me
Customlog /var/log/apache2/eldon.me-ssh-access.log combined
ErrorLog /var/log/apache2/eldon.me-ssh-error.log
HostnameLookups On



  Options FollowSymLinks
  AllowOverride Limit Options FileInfo
  DirectoryIndex index.php


I was missing the ChainFile and CACertificateFile, and I added the extra bits about CipherSuite and Protocol. Now the SSL Checker validates everything on eldon.me. The same configuration isn’t working for amberandtrey.us, the checker says “No SSL could be found,” yet my browser indicates SSL is active and enabled. I’ll have to do a closer comparison… [Edit 2013-01-27 0554 -0600]Looks like the SSL certificate is tied directly to www.amberandtrey.us (which redirects to amberandtrey.us). The opposite problem exists for eldon.me. If I have the SSL Checker scan www.eldon.me, it says “No SSL could be found.” Must be a difference in the way I set up the SSL certificates.

Now I can be sure that folks won’t have to click through an SSL warning when they visit my sites!

Thinking…

I went to Lowes to make up for the spare apartment key I lost (and discovered a really cool key-making kiosk). On my way home I decided I needed to reward myself for the substantial raise I received at Digium. So, I dropped by The Cigar Room in Madison, AL. I’ve been there at least thirteen times in the past, but never ventured into the back lounge to smoke a cigar. I bought my favorite cigar, the Acid Kuba Kuba from Drew Estate. Thankfully The Cigar Room has reasonable prices (not like another local store in their overpriced, shopping-mall real estate). I cut my cigar with a cutter called “The Shuriken,” and lit my cigar with the shop’s hand-held Bunsen burner-like device. I mosied on back to the lounge, to check it out and smoke my cigar.

There were large TVs on both walls, and in one corner. The walls were painted a reddish brown, very classy. There was cigar and classic martini lounge decor hung on those walls, and the floor was some kind of rich, wooden tiling. The floor was littered with leather sofas and chairs, and there were plenty of end tables with ash trays for your cigars, and there were ottomans for your feet. The place had a really class lounge feel. Since there were folks watching television, there was no music. There was a wet bar in the back, but it wasn’t the kind where people can sit at it and interact with a bartender. It was like something you’d find in a house, that didn’t have room for an entire bar. This got me to thinking…

My hometown, Mobile, AL, does not appear to have anything like this that I know of. I think an excellent business idea would be to open my own place like that there. My thoughts may be quite ambitious here, but I’d also like to add a small but full-service bar, and sell choice wines on top of that. Maybe even have a small kitchen to serve wine bar food. As always, it would be location, location, location! I don’t think I’d be able to start on this for several years, but at least I have a seed of an idea. At least now I’m documenting that! I’m wondering if there is an Alabama state law against allowing smoking in a cigar lounge and serving alcohol directly to customers. One of the many things I will have to research. However, my first order of business is to research this heavily. I may not have all the time in the world, but I can’t be bothered with that now. Someone, or some organization, may be way ahead of me yet. Can’t control that.

Installing tripwire on Debian Sid.

One security tool I use on my Linux servers is tripwire. Essentially, it hashes both a file/directory and its metadata (modify/access/creation timestamps, file size, inode, etc.) into the tripwire database. Daily (or more often) tripwire re-scans the designated filesystems and alerts the administrator of any changes. This is glossing over many of the finer points, but if a system is compromised and key files are changed the administrator is notified at the next re-scan. Tripwire shouldn’t be the only line of defense, but it can be useful as a catch-all to notify the system manager so corrective action can be taken.

    To install and set up tripwire on Debian Sid, follow these instructions (inspired by this):

  1. Actually installing tripwire is very simple:
    
    # aptitude install tripwire
    
    

    The curses-based menu prompts will instruct you to create a pair of keys to cryptographically sign many files, in order to ensure their contents or metadata haven’t changed. The first tripwire installation prompt warns that these passphrases exist unencrypted for a period of time. Because of this I have elected not to enter these passphrases at this time, and will follow the instructions in twadmin(8) for creating these keys.

  2. To generate the keys, I ran the following command:
    
    # twadmin --generate-keys \
    --verbose \
    --local-keyfile /etc/tripwire/local.key \
    --site-keyfile /etc/tripwire/site.key
    
    

    This generated the following output:

    
    Open Source Tripwire(R) 2.4.2.2.2 built for x86_64-unknown-linux-gnu
    
    Open Source Tripwire 2.4 Portions copyright 2000 Tripwire, Inc. Tripwire is a registered
    trademark of Tripwire, Inc. This software comes with ABSOLUTELY NO WARRANTY;
    for details use --version. This is free software which may be redistributed
    or modified only under certain conditions; see COPYING for details.
    All rights reserved.
    
    (When selecting a passphrase, keep in mind that good passphrases typically
    have upper and lower case letters, digits and punctuation marks, and are
    at least 8 characters in length.)
    
    Enter the site keyfile passphrase:
    Verify the site keyfile passphrase:
    Generating site key: /etc/tripwire/site.key
    Generating key (this may take several minutes)...Key generation complete.
    Enter the local keyfile passphrase:
    Verify the local keyfile passphrase:
    Generating local key: /etc/tripwire/local.key
    Generating key (this may take several minutes)...Key generation complete.
    
    

    It may have said it may take several minutes to generate these keys, but it processed through very quickly on my li’l VPS. It took mere seconds to generate the keys. It actually took more time for me to select my passphrases then it did to generate the keys. The keys are nice and encrypted (the “file” command just says they’re data!). Some notes on my passphrases:

    • I use keepassx to maintain my password database. It has an added feature of generating random passwords! I back up my password database religiously, and I use sshfs on all of the workstations I control to always keep the same file updated, no matter what machine I’m using. It’s great!
    • I used keepassx to generate a 128 character password for the site key, and a 64 character password for the local key. I was sure to use characters from every character class (upper, lower, underscore, hyphen, space, symbols). The site key ended up being a whole 1,024 bits of entropy, and the local key was 512 bits of entropy.
    • I probably should have collected fresh entropy before generating those keys, but then I’m getting really pedantic. I have unchecked that option, so it should collect fresh entropy more often, if not every time I generate a new password.
  3. Next step is to actually configure tripwire. This is done by modifying /etc/tripwire/twpol.txt, and removing or commenting out the stuff we don’t have or need. The first step is to run this command:
    
    # tripwire --check
    
    

    This will compare the system with the current /etc/tripwire/twpol.txt, and report on the differences. On first run, I got:

    
    # tripwire --check
    ### Error: File could not be opened.
    ### Filename: /etc/tripwire/tw.cfg
    ### No such file or directory
    ### Configuration file could not be read.
    ### Exiting...
    
    

    I changed the following line in /etc/tripwire/twpol.txt:

    
      $(TWETC)/tw.cfg    -> $(SEC_BIN) -i ;
    
    

    To this:

    
      $(TWETC)/twcfg.txt    -> $(SEC_BIN) -i ; 
    
    

    Turns out that’s not right, so I reverted the change above. What I had to do was initialize the tripwire configuration file like so:

    
    # twadmin --create-cfgfile --site-keyfile site.key twcfg.txt
    
    

    That brought me to the following:

    
    # tripwire --check
    ### Error: File could not be opened.
    ### Filename: /etc/tripwire/eldon-local.key
    ### No such file or directory
    ### Exiting...
    
    

    I had to edit twcfg.txt and regenerate tw.cfg (since my local key is /etc/tripwire/local.key, not /etc/tripwire/eldon-local.key). My next problem was that the tripwire database did not exist. I entered the following command:

    
    # tripwire --init
    
    

    After entering the local key passphrase, I got the following output:

    
    ### Error: File could not be found.
    ### /etc/tripwire/tw.pol
    ### Exiting...
    
    

    I generated that policy file using the following command:

    
    # twadmin --create-polfile twpol.txt
    Please enter your site passphrase: 
    Wrote policy file: /etc/tripwire/tw.pol
    
    

    Next I could run the initialization:

    
    # tripwire --init
    ...lots of messages about missing /proc files, then
    Wrote database file: /var/lib/tripwire/eldon.twd
    The database was successfully generated.
    
    

    I removed /proc, and a bunch of other stuff from twpol.txt, then regenerated the policy file. I then could finally run the check:

    
    # tripwire --check
    
    

    This listed a bunch of files that couldn’t be found. I removed those from the policy file (twpol.txt), regenerated the policy, reinitialized the database, and got the standard report on standard output (I won’t reprint it here because it’s rather long). Now I can modify my upgrade alias in .bashrc:

    
    alias upgrade='aptitude update && aptitude full-upgrade && \
                    aptitude clean && rkhunter --propupd && tripwire --check'
    
    

    I do not run tripwire on any of my workstations or laptops, simply because I am constantly futzing with them, and getting the near-constant email warnings that there are violations, created, deleted, or modified files outside the .twd file. Here, usability trumps security, in the ever-constant stuggle.