Archives 2021

Apparently, Linux’s favorite file sharing service can also double as an Active Directory Domain Controller. I’ve taken two Linux classes and was even a Linux Administrator for many months, and I had no idea this was possible. I stumbled upon this fact because I am looking for a centralized way to manage my user accounts across my entire home lab network.

Since I am using my free AWS Windows server for this site, I had no choice but to find an LDAP server implementation on Linux since AWS gives you a free Windows and Linux server. I spent a good bit of time looking at OpenLDAP, but that will not work since Windows cannot join an OpenLDAP domain. So back to the drawing board I go. I briefly looked at pGINA, but that looks like it hasn’t been updated in almost a decade. Finally, I stumble upon……

Samba.

What? Isn’t that just a file-sharing service???

---

Part 1: Pre-Installation

I fire up a RHEL instance within AWS’s EC2, and I get port 389 configured from Windows <-> Linux. I then follow the pre-install instructions on Samba’s site. To set up EPEL on AWS’s RHEL, you need to run the following commands:

sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm -y && sudo dnf config-manager --set-enabled codeready-builder-for-rhel-8-rhui-rpms && sudo yum repolist

Once everything finishes, you should see the EPEL repository in the output of yum repolist. If it is, you can install all the packages needed:

sudo yum install docbook-style-xsl gcc gdb gnutls-devel gpgme-devel jansson-devel keyutils-libs-devel krb5-workstation libacl-devel libaio-devel libarchive-devel libattr-devel libblkid-devel libtasn1 libtasn1-tools libxml2-devel libxslt lmdb-devel openldap-devel pam-devel perl perl-ExtUtils-MakeMaker perl-Parse-Yapp popt-devel python3-cryptography python3-dns python3-gpg python36-devel readline-devel rpcgen systemd-devel tar zlib-devel flex bison dbus-devel python3-markdown wget curl

I have added flex, Bison, dbus-devel, and python3-markdown because Samba’s configure command requires them. We will get to this in a moment.

Now we will need to set a hostname and change our /etc/hosts file. First, to change your hostname, run:

sudo hostnamectl set-hostname yourhostname

Next, get your IP address using:

ip addr show

Then add your hostname and IP address to /etc/hosts using:

sudo vi /etc/hosts

Press the “i” key to enter Insert mode, then use your arrow keys to navigate to the end of the file. Press enter, and add your IP address and new hostname like so:

Finally, exit insert mode with Ctrl+C, then type Shift+; (to enter : ), press x, and hit enter. This will save your new hosts change. After making your change, log out and log back in.

---

Part 2: The Install

If you look on the Distribution-specific Package Installation page, it explicitly states that installing Samba from the repository does not support Active Directory. We can either jettison this RHEL install and move everything to Ubuntu or build from source. Building any software from source is always a challenge, and well, that’s why we’re both here!

First, grab the most up-to-date tar.gz installation files (the most up-to-date version as of this writing is 4.15.2). In my case, it will be:

wget https://download.samba.org/pub/samba/stable/samba-4.15.2.tar.gz && tar -zxf samba-4.15.2.tar.gz && cd samba-4.15.2 && ./configure

The following command with download the tar.gz file, extract its contents, change the directory to the newly extracted folder, and run the ./configure command. For our purpose, we can leave the default configuration options alone. Once the configure command completes, you should get the following:

Next, run the make command. This will take some time. Once make finishes, you will see:

Finally, run the sudo make install command. This will also take some time. Once the install finishes, you will see:

Next up is creating the systemd file used to start and stop the Samba Active Directory Domain Controller automatically. Enter the following:

sudo vi /etc/systemd/system/samba-ad-dc.service

Like before, press “i” to enter insert mode, copy and paste the following:

[Unit]
Description=Samba Active Directory Domain Controller
After=network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
ExecStart=/usr/local/samba/sbin/samba -D
PIDFile=/usr/local/samba/var/run/samba.pid
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

Ctrl+C, then type Shift+; (to enter : ), press x, and hit enter. If you try to start Samba now using systemctl start samba-ad-dc, it will fail with the following:

Before starting Samba, SELinux will need to be adjusted to allow Samba to run. Run the following command:

chcon -R -t bin_t /usr/local/samba/sbin/

The above command will tell SELinux that Samba is permitted.

---

Part 3: Post-Install Configuration

Before Samba can be started, we will need to configure it. Begin by running the following commands:

sudo mv /etc/samba/smb.conf /etc/samba/smb.conf.bak ; sudo mv /etc/krb5.conf /etc/krb5.conf.bak

This will rename smb.conf and krb5.conf to a backup as we will be creating a new one soon. Run the following command:

sudo /usr/local/samba/bin/samba-tool domain provision --use-rfc2307 --interactive

This will tell samba-tool to provision a domain using the interactive tool and allow RFC-2307. Without RFC-2307, non-Windows clients would be unable to authenticate with this server. The interactive tool will ask many questions, but you only need to provide the Realm (internal.domain.com) and the administrator password. THE ADMINISTRATOR PASSWORD MUST BE SECURE. The other settings can be left as default. Once you see the following, the tool is complete:

The last thing that is needed is the following command:

sudo mv /usr/local/samba/private/krb5.conf /etc/krb5.conf && sudo systemctl start samba-ad-dc && sudo systemctl status samba-ad-dc

This command will move the Kerberos configuration file to the correct location, request systemctl to start samba-ad-dc, and output its status. If everything was completed successfully, you should see:

---

Part 4: Next Steps

Now that Samba’s Active Directory Domain Controller is running, we will need to test our configuration. If the tests are successful, we will need to deploy it to the other clients. That’s Part 2!

Last week I had to attend my grandfather’s funeral. He was 72 years old and in feeble health when he passed, so he is in a better place now. However, I had the chance to finally clean my storage unit out that I’ve had since 2018! It was a 5’x10′ unit, and the entire contents of the unit was dumped into my house. I finally got a chance to unpack, and I set up my new bookshelf and added new items to my home lab.

---

Introducing my new home lab!

The two major additions are the Commodore 64 plus a disk drive and the TI-99A. I have big plans for the C64, so stay tuned! From bottom to top: HP ProLiant ML350p Gen8, Edgewave iPrism 75g, Dell Poweredge R310, Cisco Catalyst Express 500, a Debian PC used as a network tap, a Windows PC where the motherboard failed, two legacy Windows 98 PCs, a Commodore 64, a TI-99A, and three VGA/DVI monitors

---

Next up is my bookshelf. Some of these books I already had, but the majority of them came from my storage unit.

---

These past few weeks have been wild. Beginning in the first week of June, I started a summer research position at North Carolina A&T’s autonomous robotics lab. I had to contribute 160 hours in the lab for the eight-week summer semester. Along with that, I worked full time while pursuing 12 credit hours at the local community college. I am SO glad that it’s over. I can finally get to my home lab projects and then begin a few others. I need to upgrade my uploader service and fully release it. After that, I will do some malware analysis within my analysis lab. Finally, I will sit down and write Part II to the mainframe series.

The only way one can gain legitimate access to a mainframe is by either shelling out five figures or more a year or getting a job supporting a mainframe. Since mainframes are used in 71% of all Fortune 500 companies, it’s not like you have slim pickings to snag a job.

But what if you already have a job and you don’t want to leave?

If you want to be legitimate, you must pay or get a new job.

Surely there must be a way.

Of course there is! It’s 2021 of course. And now your here. You really want to run your own mainframe from the comfort of your home. Sadly, you will have to wait for Part #2.

This post is about the pre-setup for getting a bootleg mainframe running in my home. I will discuss what I’ve been up to in my lab the past couple of days.

A while back, I wrote about how my XenServer did not like installing VMs through PXE Boot. Instead, I had to install it in VMWare Workstation on my main PC, export it, then import it into XenCenter. I have finally upgraded!

---

I present… Puppy Linux!

Puppy Linux is one of the most lightweight Linux distros there is. XenServer can pull ISOs from an NFS or Samba share, so I shared a folder from my Windows PC and set XenServer to boot from the ISO image there. After I installed Puppy Linux, I can freely install VMs from the server.

As you can see in the picture, my first VM installed this way is Lubuntu. It’s another lightweight Linux distro that will run the z/OS (mainframe) emulator. I have *ahem* acquired a copy of z/OS 1.10 that is floating around the internet. I will then run the mainframe emulator called z/OS Hercules. That will be covered in part 2!

After several weeks and a trip to Goodwill, I have successfully implemented my malware analysis lab as envisioned!

---

Part I: The Setup

My network is as follows:

I have the Edgerouter X serving several VLANs, but there are two in particular that I will discuss today. The two ethernet ports on the XenServer serve two purposes: one ethernet port connects to the VLAN aware switch and provides management functions, and the other is used by the VMs for a network connection. This network connection is connected to a Debian PC with two ethernet ports bridged together. That way I can snoop on any network activity silently to the VM. I can also break

Along with this upgraded network, I have revamped all of my firewall settings:

In this, let’s look at VLAN400 (my PC and its VMs), VLAN325 (XenServer MGMT), and ETH1 (both IN and LOCAL). ETH1 has the largest group of firewall policies (11 in total) than any other network. For IN, it can not communicate with any of the VLANs except for the FreeBSD VM located at 192.168.40.100, but only if it originates on the Debian PC. This way, I can have a full two full virtual layers of protection between this network and the rest of the network. If malware were to escape to my main PC, its chain of infection would be either:

Infected VM -> XenServer itself -> FreeBSD VM -> PC

Or

Infected VM -> Debian PC -> FreeBSD VM -> PC

For ETH1 LOCAL, it has two simple rules: Allow port 53 to the router, and deny everything else. This way, any VMs are unable to attack the switch itself through any of the VLAN IPs.

VLAN325 (the XenServer MGMT VLAN) has a similar firewall policy. It can only communicate with the FreeBSD VM:

All of this configuration is well and good, but does it work? All the configuration in the world does you no good if it simply doesn’t work in the first place!

---

Part II: Testing the configuration

Can my PC ping the Debian PC or the XenServer IP in the 10 network?

Can my PC ping the XenServer MGMT IP?

Can the XenVM ping the PC?

Can it ping the 10 network’s switch IP?

With our simple ping test, we can conclude that the firewall rules are working as expected. To confirm, I did do an NMAP scan of 192.168.40.* with the following commands:
nmap -T4 -d -v -F -Pn 192.168.40.1 192.168.40.2 192.168.40.10 192.168.40.100

Sure enough, not a single packet returned!

However, the 10 network isn’t so lucky. The switch gateway has DNS open; the Debian PC has ports 7, 9, 13, 21, 22, 25, 37, 53, 79, 80, 110, 113, 990, 995, and 3389 open; and the XenServer has ports 22, 80, and 443 open. I’m sure the iptables firewall could close the XenServer ports, but the open ports on the Debian PC are due to two programs I’ve installed.

---

Part III: PolarProxy and INetSim

By using this guide, we can capture, intercept, and blackhole any communication between the VM and the outside world. INetSim INetSim is an Internet Services Simulator Suite, and it provides simulation for popular protocols, such as HTTP/S, FTP/S, SMTP/S, and others. PolarProxy is a transparent SSL/TLS proxy created specifically for incident responders. These two programs plus Wireshark will form the backbone of the network analysis for malware, and since this is done off of the victim VM, it is practically undetectable.

One thing I do have to investigate is whether or not those SSL errors are fixable. However, that is not a show-stopper in any sort of the imagination! Here is the guide to install both PolarProxy and INetSim.

---

Part IV: What’s Next?

My first foray into serious malware analysis was in 2019. I was running a Windows VM within VMWare with an active internet connection and shared folders enabled. Fast forward a year and four months later, I have dedicated equipment and a very mature network and firewall setup. I think it has come time to do actual research on my setup and see just how well it can perform. As far as any upgrades to the existing setup, I would like to move the FreeBSD VM to its own PC altogether. After that, I would like to fully physically segment my lab network from everything else. Even up to the point of having its own router!