The limitation of time and space are human nature which is aggressively prohibits by developing and implementing multi-dimensional technology for the past decades. This trend also came to my concern when I’m limited to them to refresh my brain and must wait ‘till I reach my physical machine, or when some idea came up suddenly while I’m in the middle of anything I’m doing, I can’t just brought them up to my lab or simply document it.
This document is for personal use, nothing commercial, nothing academic. If someone finds this journal fits their purposes, -well, good for you then- but, I will not take any responsible nor credits for the usage of what I’m about to write by anyone but me.
I need an environment for my lab, which can be access anytime, anywhere, not to depend on physical device, and not supposed to be installing some bothersome apps as privilege to it. It should also persistent, durable, and secure system, since it will also be my “jumper” into another dimension.
So, I’ll be using Kali-2020 as my basic platform, and (still comfy with) my Cisco IOU as my lab environment. All of ‘em will be standing over VMware Hypervisor 6.5.
Let’s begin..
1. Preparing the platform.
- VMware Hypervisor 6.5.
Well, some guys already prepared for it, so I don’t need to pull my hair off to do so.
- Installing Kali-2020.
Again, some other guys already prepared .ovf file for me, so I just load it up into the VM host.
2. Preparing & hardening Kali-2020.
I’ll be using this machine to public area, so I don’t want it to be so easily accessible by anyone but me or my privileged.
In this stage, I’ll need linux text editor. I use ‘vi’ since it was pre-installed on my kali.
2.1. Changing ‘hostname’
To do this, change the file named hostname in /etc.
kali@kali:~$ sudo vi /etc/hostnamereplace ‘kali’ to whatever we want to be named. I chose ‘mchn’. Save the document, and then reboot the system.
After booting, it’ll shows like this:
kali@mchn:~$2.2. Add ‘user’ to ‘root’ group.
create new user named ‘user‘:
kali@mchn:~$ sudo useradd -m user-m’ indicates that we’ll create home folder upon user creation.
2.3. Set password for ‘user’.
kali@mchn:~$ sudo passwd user1st entry chars for passwords, and 2nd entry for password clarification.
2.4. add ‘user’ to group ‘sudo’.
kali@mchn:~$ usermod -a -G sudo user
2.5. Add ‘user’ to the default shell typing.
kali@mchn:~$ sudo chsh -s /bin/bash/user
2.6. Update & upgrade image.
kali@mchn:~$ sudo apt-get update
kali@mchn:~$ sudo apt-get upgrade
kali@mchn:~$ sudo apt-get dist-upgrade
2.7. Change default ssh keys.
I'll be accessing my lab via public ssh, so this part is a must-do, at least to not make it so easily come-in to your machine, by anyone but me and my privileged.
Ssh keys we need to change, located in /etc/ssh
2.7.1. Find local ssh keys.
kali@mchn:~$ ls /etc/ssh/
ssh_host_*
2.7.2. Relocate current ssh keys.
kali@mchn:~$ mkdir /etc/ssh/oldkeys
kali@mchn:~$ mv /etc/ssh/ssh_host_* /etc/ssh/oldkeys/
2.7.3. Create new ssh keys.
kali@mchn:~$ dpkg-reconfigure-openssh-server
ignore any warning messages appeared.
2.7.4. Compare ssh keys. (if you want)
kali@mchn:~$ md5sum /etc/ssh/oldkeys/ssh_host_* /etc/ssh/ssh_host_*
the result between those ssh keys, should NOT be same! it means now we indeed have new ssh keys.
2.8. ssh services.
I need to know what services are already running on my kali.
2.8.1. verify local service ports.
kali@mchn:~$ nmap localhost
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
23/tcp open telnet
3389/udp open rdp
2.8.2. enabling ssh service.
Two ways to do this:
ssh.service => ssh service will always be running.
ssh.socket => sssh service in listening state. It will listen and wait for connection, when it happens, system will then start the ssh service.
Starts the ssh service:
kali@mchn:~$ sudo systemctl start ssh.socket
Add the service to system startup:
kali@mchn:~$ sudo systemctl enable ssh.socket
Verify the service status:
kali@mchn:~$ sudo systemctl status ssh.socket
2.8.3. ssh access via wan.
Service port 22 somehow cannot go thru easily in wan, so I tricked this by using PAT in my gateway.
The logic would be; ".. direct access to my kali using pre-given public-ip with specific customized custom port, which will then translated to my kali's local-ip serviceport 22.."
(If you don't know or don't have the privilege to do this, contact your IT guy..)
3. Preparing the lab environment.
I’m migrating my lab into Kali, so it’d no need for me to reveal how to build it. But on my second thought, I’ll do it so I’d have in-one-page docs. ;)
IOU raw-files.
Retrieve these files and put ‘em into /home/me/Downloads/
Files are:
- Image files.name’d be like i86bi_linux-ipbasek9-ms or something like that.
Size varies, largest I have, around 40 MB. - License generator. an exe file called ‘iougen’, some licensing agent that locked iou for commercial use. Well that’s what they said when it was still on development.When extracted, will shows:
[License]
= <16 char="" random=""> - App. Caller. => an exe file called ‘wrapper-linux’, some kind of an app-caller in linux.
- Machine starter.
an exe file called 'ioustart', it will run the iou image(s) as predefined before.
scroll-down for explanation on how to predefined it. - Machine killer.
another exe file called 'ioustop', it'll kill all iou process.
no need to preconfigure it, just put it on lab folder and run it. - Topology map.
a text file called NETMAP, it'll define my iou images "physical connection".
scroll-down for explanation on how to predefined it.
Step-1: Container-ing.
Put all extracted sources into kali. Extracted means out of .zip .7z anything.
user@mchn:~$ cd /opt/
user@mchn:/opt$ sudo mkdir /iou/ (non-propetiary name)
user@mchn:~$ cd iou
user@mchn:/opt/iou$ sudo cp /home/me/Downloads/i86bi_linux* ./user@mchn:/opt/iou$ sudo cp /home/me/Downloads/wrapper-linux ./user@mchn:/opt/iou$ sudo cp /home/me/Downloads/iougen ./user@mchn:/opt/iou$ sudo chmod a+x ./* (makes sure all are executable)
Step-2: Dependencies.
This is the hard part. Cisco developed iou back in the 2012-ish, while I’m using a 2020 distro. So it’s a must for me to create dependencies into kali library.
First of all, I need 2 more files to download: libcrypto.so.0.9.8 & libcrypto.so.4 <= thank God I still found it on Kali download center.
user@mchn:/opt/iou$ cd /usr/lib/
user@mchn:/usr/lib$ sudo apt-get install libssl0.9.8user@mchn:/usr/lib$ sudo cp /home/me/Downloads/libcrypto.so.4 ./user@mchn:/usr/lib$ sudo ln -s ./libcrypto.so.0.9.8 ./libcrypto.so.4
Step-3: Shortcut-ing.
I’ll be accessing my image files from somewhere else inside kali, and for some best-practices, wouldn’t be from inside the system folders. So I need to make ‘em accessible without enclosing its full path.
user@mchn:/usr/lib$ cd /sbin
user@mchn:/sbin$ sudo ln -s /opt/iou/i86bi_linux-ipbasek9-ms ./i86bi_linux-ipbasek9-msuser@mchn:/sbin$ sudo ln -s /opt/iou/wrapper-linux ./wrapper-linux
Step-4: Licensing.
To be fully applied, license file must be:
- .iourc file.
- Into /home/
folder.
user@mchn:/sbin$ cd /opt/iou/iougen
user@mchn:/opt/iou/iougen$ iougen (‘run’ it to generate license)
[License]
mchn = 1234567890123456; (differ to each machine names)
Write it to .iourc file!
user@mchn:/opt/iou/iougen$ cd /home/me/
user@mchn:/home/me$ vi .iourc
Step-5: Don’t tell cisco ;)
Since it was a ‘beta’ app -well at least when it first came up in 2012- we should reroute updates regarding iou NOT to cisco..
user@mchn:/opt/iou/iougen$ sudo vi /etc/hosts 127.0.0.1 xml.cisco.com
4. Getting start with the lab..
Step-1: Lab folder.
Better prepare dedicated folders for lab files. I’m kinda organized person, so I liked my folder be hierarchical.. ioulabs/route/static/101 so on..
Step-2: Starting the device(s).
Cisco made a file named ‘ioustart’ as its control-plane. This file needs modifications every time its parameters changes.
user@mchn:~$ cd ../labfolder/
user@mchn:/labfolder$ ./ioustart
user@mchn:/labfolder$ cat ./ioustart
wrapper-linux -m i86bi_linux-ipbasek9-ms -p 2100 -- -e 1 -s 0 -c generic 100 &
wrapper-linux = must, as a caller to iou system.image file = must, device’s image to load.
2100 (or any available port) = must, linux process ID to be use during lab.-e = must, set amount of ethernet interfaces to be use. 1 set interface = 4 virtual ports.-s = must, set amount of serial interfaces to be use. 1 set interface = 4 virtual ports.generic = good-to-have, devices’ initial configs.100 or any I'd like to put = must, pointer to be use for topology reading.& = must, end-of-process.
Step-3: Topology.
Topology is written into file called ‘NETMAP’, iou took this file to read devices physical connection.
user@mchn:/labfolder$ cat ./ioustart
wrapper-linux -m i86bi_linux-ipbasek9-ms -p 2100 -- -e 1 -s 0 -c generic 100 &
wrapper-linux -m i86bi_linux-ipbasek9-ms -p 2200 -- -e 1 -s 1 -c generic 200 &
wrapper-linux -m i86bi_linux-ipbasek9-ms -p 2300 -- -e 1 -s 1 -c generic 300 &
wrapper-linux -m i86bi_linux-ipbasek9-ms -p 2400 -- -e 0 -s 1 -c generic 400 &
user@mchn:/labfolder$ cat ./NETMAP
200:1/0 300:1/0
300:1/1 400:0/1
100:0/0 200:0/0 300:0/0
Step-4: Stopping the device.Serial interfaces would be created after the ethernet interfaces. 1 set of interface consists of 4 virtual ports (0,1,2,3).Reading of the NETMAP file above would be: Line-1: Connect 200 s1 to 300 s1 Line-2: Connect 300 s2 to 400 s2
Line-3: Connect 100 et1 to 200 et1 to 300 et1
To stop IOU running machine, can be done by kill-ing the running service.
user@mchn:/labfolder$ top
PID USER ..... COMMAND
xxxxx user ..... i86bi_Linux*
yyyyy user ..... i86bi_Linux*
user@mchn:/labfolder$ kill xxxxx
user@mchn:/labfolder$ kill yyyyy
or, simply by using:
user@mchn:/labfolder$ ./ioustop
KILL IOU XXXXX
KILL IOU YYYYY
.... : Happy Learning : ....
No comments:
Post a Comment