My first RHCE lab setup

Since I’m just starting out with my RHCE I decided not too nuke my homelab and go the lightweight route. For my first RHCE lab I made some local disk space available to Virtualbox and will be using this to spin up some basic stuff and get this going.

My first setup is a simple server that will be my router in the minivirt.local domain. This router has two nics, one that is the WAN side (simple NAT setup to my workstation) and the other will be our LAN side (host-only network in Virtualbox).

I won’t be using CentOS for my lab setup (which is great by the way, don’t hesitate to use CentOS in any lab setup) since Redhat now offers a Developer license to Redhat Enterprise Linux for free.

First steps

I will probably go through the RHCSA and RHCE objectives to build some sort of learning path. Setting up a usable lab environment will probably go over all objectives a bit since this involves basic installation, networking and some service installation.

The router.minivirt.local machine has DHCP enabled on the WAN interface and has a static IP (10.0.0.254) on the LAN interface. Next I’ve setup a DHCP server on the LAN interface to serve our virtual network. The Redhat documentation for setting up a DHCP server was very easy to follow and didn’t allow for much error.

After installing a new RHEL7 virtual machine called michael.minivirt.local I attached it to the LAN network and it got an IP from our DHCP server on router.minivirt.local. Interesting information here is in the /var/lib/dhcpd/dhcpd.leases files that shows all current leases on the DHCP server.

Networking between router and michael is now possible, but our router isn’t really routing anything yet. We need to get the client (michael) to receive a default route from the DHCP server and our router needs to enable NAT (Network Address Translation) for clients on the internal network.

First, here is the DHCP server configuration I’m using:

This provides our DHCP clients with the route information (using the routers option) as you can verify with the following command

The problem is that router.minivirt.local isn’t setup to allow NAT from our clients. I used to do this using iptables but since RHEL7 (or RHEL6?) we have firewalld and the firewall-cmd command so I’ll be using that to get full routing functionality.

A great resource for firewalld is the FedoraProject wiki: https://fedoraproject.org/wiki/Firewalld?rd=FirewallD#Dynamic_firewall_with_firewalld

I will go into more detail on firewalld and firewall-cmd later (I’ve only read up on the basics to get stuff working for this lab) but basically you have a number of zones in your firewall, the default being public. What we are going to do is move our LAN interface ( enp0s8  in my case) to the internal zone. Then we will allow NAT from all hosts in the range 10.0.0.0/24 via the WAN interface ( enp0s3  in my case).

Next up we can verify that we have NAT traffice working on our internal host:

This is all very fine but what would be without DNS in our internal network? So next up is installing a basic DNS server that will handle name resolution for the hosts in our lab network.

Setting up a recursive DNS server

We will setup a simple recursive DNS server that will allow host name resolution for clients in our network. A recursive DNS server is a server that has no authoritative information on a zone, it merely asks questions to other DNS servers and relays the answers to the client.

Just like setting up our DHCP server, the Redhat documentation for setting up a DNS server is very useful. After installing the bind package all I had to do was change the listen-on option and the allow-query option in the /etc/named.conf file. Since our router.minivirt.local has a nice firewall guarding its ports, we need to change the firewall settings to allow DNS queries to the BIND server.

And now we have working DNS resolution on our client!

Time to update those packages on the client!

Getting my RHCE certification

In this series of posts I will document my journey to getting my RHCE certification. Since I don’t hold any Redhat certifications yet, I’ll be taking on the RHCSA and RHCE exams. In this blog I will try and document as much about my lab environment, exercises and things I’m learning as possible. Truth be told, I’m in love with technology and there is just so much cool stuff out there that sometimes it’s hard to stick to something without getting sidetracked. I’m hoping that by staring a blog series about my RHCE learning path that I won’t get sidetracked too much.

I have been using Linux for almost 20 years now, making my first steps with Corel Linux (yeah, you should check that out 😉 So you can hardly call me a Linux newbie but I wouldn’t call myself an expert either. I can really handle myself on a Linux desktop and server, feeling confident with things like LVM, iptables, automating using Ansible and other great (and fun!) technology. But there is a lot of other stuff out there I’m not so comfortable with (yet).

This doesn’t mean a break from development or infosec for me but I view it as an extra layer of knowledge I’m adding to help me out when taking on all those great projects.

RHCSA Objective: Operate running systems

This lab exercise uses the Alpha Lab we have setup. The point of this lab exercise is to cover the requirements of the RHCSA objective Operate running systems.

Useful documentation

List of objectives

Boot, reboot, and shut down a system normally

  • systemctl poweroff
  • systemctl reboot

Extra information: https://askubuntu.com/questions/64995/what-is-the-difference-between-shutdown-and-poweroff-commands

Boot systems into different targets manually
Interrupt the boot process in order to gain access to a system
Identify CPU/memory intensive processes, adjust process priority with renice, and kill processes
Locate and interpret system log files and journals

  • journalctl

Access a virtual machine’s console
Start and stop virtual machines
Start, stop, and check the status of network services

  • systemctl -at service
    Show all configured services
  • systemctl start name.service
    Start a service
  • systemctl stop name.service
    Stop a service
  • systemctl restart name.service
    Restart a service
  • systemctl enable name.service
  • systemctl disable name.service
    Enable / disable a service

Securely transfer files between systems

Linux Lab Setup: ‘Alpha Lab’

This post documents the setup of our Linux lab ‘Alpha Lab’. This lab is a basic setup that focusses on basic Linux system administration.

I have used CentOs version 7 (CentOS-7-x86_64-Minimal-1611.iso) for this lab and the lab exercises but use the term RHEL7 to indicate the Linux version.

VM: E7-Router

  • Standard RHEL7 virtual machine
  • Two NICS
    • enp0s3: NAT connection ‘to the internet’
    • enp0s8: Internal network
  • During installation:
    • Configure enp0s3 for DHCP
    • Configure enp0s8 with a static IP 192.168.99.254/24
    • Don’t select other packages
    • Default filesystem / partition layout
    • Set timezone and configure NTP
  • After installation, update all packages, install vim and tmux (my personal preference, substitute as desired)
    • yum update -y
    • yum install -y vim-enhanced tmux
  • Create a snapshot called ‘Clean slate’ for easy rollback

VM: E7-Server1

  • Standard RHEL7 virtual machine
  • One NIC
    • enp0s3: Internal network

S3Uploader: Simple S3 upload script

For a project of mine I needed a simple script or application to upload files to an Amazon S3 bucket. I couldn’t quickly find something that scratched my itch so I wrote  a simple application called S3Uploader.

Using S3Uploader is very simple, once you have your S3 bucket and credentials configured, simply install the application using

and you can start uploading files to your bucket, for example

The code is quite simple and is actually very suitable or a beginner to learn from. You can check it out the code from the source repository on BitBucket and the PyPi package page.

Diving into the code

The most interesting bit, the actual uploading of a file happens in the s3uploader.uploader module:

It’s a very simple class that takes a path to a file and uploads it to the S3 bucket. The interesting bit here is at the beginning of the store_file method where we extract the filename from the path using the os.path.basename function.

Another interesting piece of code can be found in the s3uploader.main module where we use the argparse module to process arguments.

Creating an ArgumentParser is quite easy using the following code (bits have een removed from the original source for clarity)

The  action='store_true' flag changes our argument parsing so the parameter acts as a flag instead of variable. The bucket parameter requires a variable and the –verbose parameter gives a true or false value.

The  nargs='+'  on the file parameter enables the user to pass multiple values for our file parameter.

We can process the parameters from argparse like so

Interesting parts here is the change from the parameter name store-paths to store_paths and the fact that the file parameter is an iterable due to the nargs='+'  option.

This little application was a quick and dirty job and can be improved. I’ll save that for a later time and try and write more about it if it’s interesting.

The learning revolution

It’s been some time since the media reported about MOOCs or other online / new studying platforms. In case you haven’t been following, MOOC stands for Massive Open Online Course. With the rise of the internet and the democratization of knowledge a new frontier was breached: specialised courses are no longer restricted to universities, schools or commercial training centers. Now it is possible to learn new skills from experienced instructors in an online course, in real time, with fellow students from around the world!

But as things go on the internet, yesterdays hype is todays old news. And the same applies for MOOCs. New technology has enabled anyone to create and share video courses that have been made available at an extremely low cost and sometimes even free.

The MOOC courses of yesterday would cost you anywhere from € 10,00 to a couple of hundred euros. But platforms such as PluralSight, Lynda or TutsPlus are available at a monthly subscription cost. This cost lies somewhere around € 20,00 a month and offers you access to a course library that offers you thousands (yes, 1000’s) of courses.

I have been using PluralSight for some time now and have been really happy with the quality of the courses and the content that is available.