PXE - Preboot eXecution Environment - Let's PXE! (Part 2)

LET'S PXE!

Now that DHCP is working, it's time to get to the PXE stuff. I got the image file striaght from Ubuntu for my server. I found the files here:
http://cdimage.ubuntu.com/netboot/12.04/

I used curl for single files and wget (poorly but somewhat effectively) for an AMD64 build. I figured one build to start and see if I could just get that working even. Curled the pxe version from ubuntu proper (above).

I used the basic format of curl, done as root (probably foolish). In retrospect it
would have been smarter to curl it as a user into a temporary dir and then move it as root or sudo. Anyhow:

curl url/file > file

or you can

curl -O url/file to keep the existing name.

wget -r -l 0 url/  (copies *everything*) but if you point it right at the stuff you
want, you can kill it halfway through, copy over the other things and delete the extra junk which is what I did.

It is probably easier to just curl the 20 or so small boot-screens files than to use wget.

To start with you can put the kernel, initrd and boot-screens directory in
/var/lib/tftpboot/ Go ahead, just dump it in for now.

Assuming you have curled initrd and linux from ubuntu, now edit
/var/lib/tftpboot/pxelinux.cfg/default to look like this:

$ sudo vim /var/lib/tftpboot/pxelinux.cfg/default

# D-I config version 2.0
# include ubuntu-installer/amd64/boot-screens/menu.cfg
# default ubuntu-installer/amd64/boot-screens/vesamenu.c32
include boot-screens/menu.cfg
default boot-screens/vesamenu.c32
prompt 0
timeout 0
label ubuntu distro xxxx
  menu default
  kernel linux
  append initrd=initrd.gz
so, now in /var/lib/tftpboot/ we should have the following, all of it from ubuntu:

$ ls -l

drwxr-xr-x 2 root root        4096 May 12 08:25 boot-screens
-rw-r--r-- 1 root root 21256771 May 12 02:21 initrd.gz
-rw-r--r-- 1 root root  5778968 May 12 02:22 linux
-rw-r--r-- 1 root root    26461 Apr 19 13:22 pxelinux.0
drwxr-xr-x 2 root root     4096 May 12 07:19 pxelinux.cfg

FOR NOW, just read the following - or come back to it later and skip down to:
*fire up your client!*

WHAT THINGS ARE - ubuntu boot-screens

# boot-screens - a directory of text files that show dialogue for OS selection
# vesamenu.c32 - an executable that gets the ball rolling: as far I can tell this is a glorified jpg, but you need it.
# f1.txt - f10.txt - text files mostly for errors during load
# *.cfg    - primarily text files that allow specific configuration beyond the default screen. You may choose to update the paths in these to accurately reflect where the kernels are. For instance, the path provided by most of these cfg files says something like:

menu default
kernel ubuntu-installer/amd64/blahblahblah/ubuntu64/linux

but you should change them to where the linux file really is. On my server that same line reads: 

menu default
kernel ubuntu64/linux


The following detail caused me a fair bit of grief: 

RECALL that the path to all files in PXE are considered to start at /var/lib/tftpboot/  REGARDLESS of whether the path begins with / or not....    / does not operate as an absolute path with tftp in this case.

WHAT THINGS ARE - pxelinux.cfg

pxelinux.0  -  a modified version of part of an open source project called syslinux. Although pxelinux.0 is primarily a Linux loader, it is capable of loading other operating systems. It operates by using configuration files located on a TFTP server to provide boot instructions.

pxelinux.cfg - the directory where those config files that say which operating system to use (based on the choice you select on your client).

/var/lib/tftpboot/pxelinux.cfg/default - where the magic happens. this is important. this is where you set up what the options for OS will be. Each entry choice has the form:
label <label name>
    menu <which menu to use>
    kernel <relative path to kernel for this choice from /var/lib/tftpboot/>
    append initrd=<relative path to initrd for this chioce from /var/lib/tftpboot>

So, using my example of how I configured my directories and where I put my OS choices as indicated previously in the directory structure sample, the menu choice for the 64 bit Ubuntu 14.04 OS looks like this:

label 64 bit ubuntu 14.04
  menu default
  kernel 14ubuntu64/linux
  append initrd=14ubuntu64/initrd.gz

as many as you want, just configure them here and put the corresponding files in the matching locations.

FIRE UP YOUR CLIENT!

Since you have enabled DHCP you should just be able to plug your client box into your network, hit f12, select your OS and follow the instructions. If it were that easy, the text would have ended by now

 

C L I E N T

You need a box that is pxe capable, I worked with a lot of ancient equipment and not all of it had that capability.  Anything 64 bit is probably a safe bet, but check the bios to ensure your client can do it.

A couple of different difficulties you may run into with your client:

 - is your client pxe capable?
 - is your client configured to pxe?
    * perhaps you have to hit f12?
    * have you adjusted the bios to try pxe first rather than look to the drives?
    * do you need to adjust the NIC settings in the bios?
 - can you tail the logs on the pxe server to verify that your client and server are talking?
      * on my server (batman): $ tail -f /var/log/syslogs    > May 12 07:33:48 batman dhcpd: DHCPDISCOVER from 00:1a:xx:xx:xx:xx via eth0
    > May 12 07:33:49 batman dhcpd: DHCPOFFER on 1xx.2xx.xxx.xxx to 00:1a:xx:xx:xx:xx via eth0
    > May 12 07:33:52 batman dhcpd: DHCPREQUEST for 1xx.2xx.xxx.xxx (1xx.2xx.xxx.xxx) from 00:1a:xx:xx:xx:xx via eth0
    > May 12 07:33:52 batman dhcpd: DHCPACK on 1xx.2xx.xxx.xxx to 00:1a:xx:xx:xx:xx via eth0 - if you don't see this sort of conversation between your client and the server, then perhaps:
      * your client isn't plugged into a swtich port that is on the same vlan as the server
      * other plug problems, bad cable
      * dhcp not configured correctly on the server
      * the switch is ancient and is S... L...O... W... . . . . . make sure the light has a chance to turn green. This happened to me, really.

SERVING MORE THAN ONE OS

If you want to have your server host multiple OS there are a variety of ways to go about this. I preferred putting all my different OS kernels and initrd files into their own directories - a little more work but ultimately nice and clean. Alternatively you could give each of them a unique identifier and dump it all into one directory. The reality is that how the client knows where they are and what to load is based in the config files.

that being said here is what my /var/lib/tftboot dir looks like

/var/lib/tftpboot$ ls -l
drwxr-xr-x 2 root root  4096 May  8 04:19 12ubuntu32
drwxr-xr-x 2 root root  4096 May  8 03:52 12ubuntu64
drwxr-xr-x 2 root root  4096 May 12 02:22 14ubuntu64
drwxr-xr-x 2 root root  4096 May 12 07:06 boot-screens
drwxr-xr-x 2 root root  4096 May  8 02:46 coreos
-rw-r--r-- 1 root root 26461 Apr 19 13:22 pxelinux.0
drwxr-xr-x 2 root root  4096 May 12 07:19 pxelinux.cfg
in each directory is its own initrd and kernel:

/var/lib/tftpboot/14ubuntu64$ ls -l
-rw-r--r-- 1 root root 21256771 May 12 02:21 initrd.gz
-rw-r--r-- 1 root root  5778968 May 12 02:22 linux

WHERE IS EVERYTHING AGAIN?

dhcp activity:   server        /var/log/syslog          dir
dhcp leases:     server        /var/lib/dhcp            dir
dhcp config:     server        /var/lib/dhcp/dhcpd.conf file
dhcp service:    server        isc-dhcp-server          service
hosts you know:  server/client /etc/hosts               file
pxe config:      server        /var/lib/tftpboot/pxelinux.cfg/default         file
OS options:      server        /var/lib/tftpboot/MY_OS/ (kernel and initrd)

TREMENDOUS THANKS!

blkperl - my primary mentor

https://help.ubuntu.com/community/PXEInstallServer
http://blog.alainodea.com/en/ipxe-smartos

Also good:
http://askubuntu.com/questions/412574/pxe-boot-server-installation-steps-in-ubuntu-server-vm
https://help.ubuntu.com/community/UbuntuLTSP/StaticIPsWithDHCP
https://help.ubuntu.com/community/isc-dhcp-server

tailing the logs can be helpful too: sudo tail -f /var/log/syslog

Additional hugely complicated reading:
http://www.openbsd.org/faq/faq6.html

PXE - Preboot eXecution Environment - Setting Up DHCP

PXE - Setting Up DHCP

For fun in one of the labs I set up my own PXE server and made notes about the problems that I encountered in doing so. If you aren't really sure what PXE is, a decent description exists at wikipedia. In a nutshell the client sends/ broadcasts a request for a Network Bootstrap Path. The server authenticates that the request comes from a legit source and, if so, sends the path to the client. The client then executes the path and installs the given OS.

I am running an older 64 bit Dell Poweredge with Ubunutu 12.04.

To get started you will want to do a little bit of reading if you haven't already. I found the following two posts to most informative:

https://help.ubuntu.com/community/PXEInstallServer
http://blog.alainodea.com/en/ipxe-smartos

So do a little bit of background reading if you haven't yet, but odds are you already looked at those which is why you are here. If you already have DHCP configured skip those parts.

Got DHCP?

After I read these through a few times, I noted that I had several constraints. I needed at least one box to be the client. Several desktops exist in the lab that will likely serve (they did not). Additionally when I started, DHCP in the lab was broken so I had to see if I could get that resolved too.

You'll need:

isc-dhcp-server which is the dhcp server and handles networking. You'll also need tftpd-hpa which is Trivial File Transfer Protocol and it handles the transfer of the OS from the server to the client.

$> sudo apt-get install isc-dhcp-server 
$> sudo apt-get install tftpd-hpa   

Create or edit  /etc/default/tftpd-hpa with the following content (may already exist):

    # /etc/default/tftpd-hpa
    TFTP_OPTIONS="--secure --verbose"
    TFTP_USERNAME="tftp"
    TFTP_DIRECTORY="/var/lib/tftpboot"
    TFTP_ADDRESS="0.0.0.0:69"

Most of it was already there, but I added verbose.
   
$> sudo service tftpd-hpa restart
     

Editing dhcpd.conf

Now create or edit /etc/dhcp/dhcpd.conf

with the following content (adjust the subnet, range and domain-name as required):

    server ip:     1xx.2xx.2xx.2xx  // this will be same as 'next-server'
    gateway:    1xx.2xx.2xx.1xx
    subnet:        1xx.2xx.2xx.1xx
    netmask:    255.255.255.xxx
    filename:    determined by OS we will be loading basically.

So you'll need the information about your gateway, subnet and netmask. I found that information by asking around. So the file will look something like:


#----------------------------------------------------
subnet 1xx.2xx.2xx.1xx netmask 255.255.255.xxx {
  pool {
    range 1xx.2xx.2xx.2xx 131.2xx.2xx.2xx;  
    next-server 1xx.2xx.2xx.2xx;
    filename="pxelinux.0"
  }
}
#-----------------------------------------------------

But since no one was going to be authoritative about Dynamic Host Configuration Protocol in the labs, I asked if I could and so got permission. Now the file looks like this:

#-----------------------------------------------------
 18 # If DHCP server is the official DHCP server for the local
 19 # network, the authoritative directive should be uncommented.
 20  authoritative;
 :
 :
 34 subnet 1xx.2xx.2xx.1xx netmask 255.255.255.2xx {
 35 # option definitions common to all supported networks...
 36 # subnet mask advises client to use that mask
 37 # broadcast-address: where all clients receive messages from
 38 # option routers tells the client that the gateway is there
 39 default-lease-time 600;
 40 max-lease-time 7200;
 41 option subnet-mask          255.255.255.2xx;    # /27 - cidr
 42 option broadcast-address    1xx.2xx.2xx.2xx;    # town crier
 43 option routers              1xx.2xx.2xx.1xx;    # the gateway
 44 option domain-name-servers  1xx.2xx.2xx.2xx;    # DNS server
 45 option domain-name          "foo.bar.org";      # our domain!
 46   pool {
 47     range 1xx.2xx.2xx.1xx 1xx.2xx.2xx.2xx;      # I control
 48     # range 2xx-2xx; if not authoritative so I can be less
 49     # controlling :)
 50     next-server 1xx.2xx.2xx.2xx;                # pxe server
 51     filename="/pxelinux.0";                     # pxe loader
 52   }
#----------------------------------------------------------------------------------
The pxe server is the next-server and is presumably your server that you control. The client is the one who (assuming you have a PXE enabled machine - check the bios) when you hit f12 gets an ip now from your dhcp server and then is provisioned by the server with the OS you select. You can test what you have so far by plugging in a box and seeing if you get assigned an IP address.

Next Up: LET'S PXE!

Bandit - overthewire.org final stages

The key to most of these final stages was snooping around in the areas described. Using cat to view a file or strings to look into the guts of an executable was an important step in being able to discern what was going on at the level.
For example, for level 21, you wanted to get to the right place then take a look at the script that was being run.

bandit21@melinda:/etc/cron.d$> cat /usr/bin/cronjob_bandit22.sh 

#!/bin/bash

chmod 644 /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv

cat /etc/bandit_pass/bandit22 > /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv 

Now that we see that the password is being placed in a file in /tmp. /tmp is meant to be like a scratch pad or an extra hand to briefly hold onto something. We can see however that the script then does a chmod or 'change mode' which sets permissions on the file in to be readable by anyone. For a perms primer try:
http://www.tldp.org/LDP/GNU-Linux-Tools-Summary/html/x9543.htm

Now that you know where the file containing the password is just take a look at it:

$> cat /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv

Level 23: The trick here is that since you know what is being run by virtue of being able to view the script you can duplicate the output of the script. The output of the script is the name of a file in which the next password is created. So, by duplicating the output of the script you have the file name where the data is stored.

$> echo I am user bandit23 | md5sum

8ca319486bfbbc3663ea0fbe81326349 -

$> cat /tmp/8ca319486bfbbc3663ea0fbe81326349

Finally we hit the last level which wants us to write a script. I guess I had written a few specifically for the game by this point even though the game says this will be your first one. A bash script starts with a sh-bang! That is: #! and then is generally followed by /bin/bash, so the first line of a bash script should look pretty much like:

#!/bin/bash

More on that here: http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_02_02.html

So you could write a simple script to do the thing that gives you the answer and it certainly is good practice to do so if you haven't written very many, and it's always fun to explore the environment of the game by seeing how it reacts when you give it the script  .... 
or you can game the game.

And isn't that what hacking is really all about? Why write a script when a thousand other people before you already have? As we know the code of the script you would write are the same as what everyone else has already written and the answer already stored in a predictable location. Use what we did in level 23 to achieve the same result, the file may still be hanging around in /tmp with the answer just waiting for you to find it. The same vulnerability of temp that we learned about in level 23 still exists to be exploited.

Hope you have enjoyed the tour of bandit. And don't keep . in your path!