If you would like to practice using NMAP commands, the nmap organization has made available a test site at scanme.nmap.org. You can use this as your target when learning how to use nmap.
Here I’m running a scan against the website scanme.nmap.org and piping it to a file. The results of the scan are shown below.
Just don’t run continuous scans against the site, after all, it is a shared resource.
This is a continuation of my previous post, NMAP and fping deep dive in that post I talked about fping and NMAP and how they worked at a basic level as NMAP, in particular, has a lot more parameters that you can use depending on the task at hand.
In this post I want to cover more of NMAPs capabilities and what commands we could use to discover more about the network and what potential vulnerabilities these hosts might have that could be used to exploit them.
In the last post we found out what hosts were alive on the network and we also found out what ports were open on those hosts. The next step is to find out what OS they’re running or at least get the best guess as to what it might be.
I am going to use the -sV (version) option and also the -O (OS fingerprinting option) to get more detail on the hosts. You don’t want to blindly attack a network without gathering all the information possible about your target or you run the risk of causing the target to crash because you ran the wrong tool against it. Information gathering is one of the most important parts of penetration testing.
As Abraham Lincoln once said, “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.”
The first command to run is the -sV command that will give us more information on the ports that are open and what version the service is running.
The administrator might have changed the port to a non-standard port as is the case for the host at 10.142.111.213. You can see the port is 81 but the service using that port is HTTP which is usually on port 80 also if you remember this is the host that did not respond to the ping sweep when using fping.
To build on this we can now run the -O command with nmap. This command will send special probes to try and figure out what OS is running, for example, IIS, Apache?
The command is $:nmap -O 10.142.111.1,6,48,96,99,100,213
Here instead of using /24 I am only running the OS scan on the hosts we already know are alive on the network, this saves us a lot of time as I am only concentrating the scan on specific hosts.
From the output you can see that host at 10.142.111.48 is a Windows XP machine. From this, we could start to look for vulnerabilities on Windows XP for the services they’re running.
To summarise we started off not knowing what IP addresses were alive for this we used the fping tool and also nmap -sn command. We then ran more nmap commands to figure out what ports were open and also the versions of those open ports. Lastly, we ran the OS fingerprint command to try to figure out what OS the hosts were using.
I hope this was useful.
NMAP and fping are used for scanning and OS footprinting of a network during the information gathering phase of a penetration test.
It is always good to know how to use these tools but also to understand what they’re doing and how they work at a deeper level. So with that in mind, I am going to run these tools and at the same time capture what is going on the wire using Wireshark.
First, let us see how fping works vs the same scan ran using nmap and why the results might be different.
I will run fping on the 10.142.111.0/24 network to see what hosts are alive. The command I will use is. #>fping -a -g 10.142.111.0/24 2>/dev/null
What are the additional parameters of -a and -g doing? The -a parameter is used to only report back hosts that are alive and the -g parameter is telling fping that it should carry out a ping sweep and not just a normal ping against one host. The 2>/dev/null parameter at the end of the command is sending err-out messages to the bit bucket so they’re not displayed while running the command.
After running the command we get the following 7 hosts responding to the ping sweep. Now I will run the same scan but this time using the nmap tool.
The nmap tool is a very powerful tool and it has a lot more capabilities compared to fping. To run the same scan that we did previously but now using nmap we run:
#>nmap -sn 10.142.111.0/24
The -sn parameter is requesting nmap to scan the subnet for hosts that are alive.
With the nmap scan we get back 8 hosts that are alive on the network vs the 7 reported by fping. That extra host is 10.142.111.213 but why? Let us take a closer look at what fping is doing vs nmap using the -sn parameter.
fping will first send out arp requests for each host on the subnet it is scanning. If a host replies to the arp request with its MAC address fping will then take that IP address and send an ICMP echo request message to it (ping).
Shown above are the arp request and the arp reply. Next the fping tool sends an ICMP echo request to 10.142.111.213. But if you look at the capture there is no response found! This host has probably been set up to not respond to ICMP messages.
If you compare this to one of the hosts that did reply the output would look like this with an echo request and an echo reply.
So the reason that fping does not show the 10.142.111.213 in its scan results is down to the fact that the host is configured not to respond to the ICMP ping request which is perfectly normal and is a good security practice.
On the other hand, nmap reported it to be alive this is because the nmap -sn scan only sends arp requests out and if a host replies to it with its MAC address nmap marks that host to be alive.
As mentioned earlier nmap is a powerful tool. Let us look at what other scans it can do. Now we know what hosts are alive on the network but that is all we know which lets face it isn’t that much. To see what services (daemons) are running on these hosts we can run another command using nmap.
The command is #>nmap -sS 10.142.111.0/24
The -sS parameter is telling nmap to perform a TCP SYN scan which is a stealthier scan because it does not complete a TCP 3-way handshake. When a client wants to communicate with a web server, for example, it first completes a TCP 3-way handshake and then it will start exchanging data. This is usually logged by the web server daemon that a new connection has been made which is bad news for us as it might alert a sysadmin that someone is scanning their network.
A TCP 3-way handshake looks like this.
When running the TCP SYN scan instead of completing the 3-way handshake nmap will send an RST message in reply to the servers SYN/ACK message as shown below. This stops the connection completing and also from the web server daemon logging the connection.
The result of the nmap TCP SYN scan is shown below. It goes through each IP address and sends a SYN message to each well-known port to see if the server will reply with a SYN/ACK message meaning that the port is open or a RST/ACK message meaning that the port is closed. For the IP of 10.142.11.1 ports 22, 53 and 80 are all open.
That is it for now. I’ll go through more of the capabilities of nmap such as OS fingerprinting in my next post.
===============================================================
DISCLAIMER
You should NEVER run any of the tools that are shown on my blog or on any of the IP addresses I’ve used for illustrative purposes without proper authorisation to do so.
================================================================
So you want to see what hosts are alive on a network that you have been asked to Pen Test. After you’ve done some reconnaissance you have an IP range of 100.10.0.0/16 that is used by the network in question. There are a couple of tools that will do the job for us here, they are fping and nmap. The focus of this blog post will be the fping tool a separate blog post will show the nmap tool.
fping is a ping sweep tool. If we were to try and test each of the IP addresses in the 100.10.0.0/16 range using traditional ping it would take a very long time.
fping is installed by default on Kali Linux if you are running a different flavour of Linux you can run the apt-get command to install it.
#sudo apt-get install fping
To use fping it is straightforward. I will use my own local Wifi address range to test what addresses are alive in the 192.168.88.0/24 range.
#fping -a -g 192.168.88.0/24
the -a option is used to only show addresses that are alive.
the -g option tells the tool that it is a ping sweep that needs to be carried out instead of a traditional ping test.
As you can see there are many IP addresses in use from that range. This is very useful information as we now know what IP addresses have been assigned to a device in the network they might be servers or hosts more on how to find that out in the next blog post using the nmap tool.
Note when using the fping tool on a LAN or WLAN you are connected to you will get [ICMP Host Unreachable] messages for IP addresses that aren’t in use. If you do not want to see these displayed in the output you can send the standard out errors to /dev/null using the following command.
#fping -a -g 192.168.88.0/24 2>/dev/null
In my next blog post, I will show you a very very powerful tool called nmap that does the same as fping and a lot lot more.
It has been a while since I have posted something on my blog. I’ve been busy studying for the CCNA Cyber Ops cert. Cisco created this certificate due to the serious lack of Cyber Security personal worldwide, Cisco will invest $10 Million into this program to close this gap. They opened up a CCNA Cyber Ops scholarship program which I applied for over a year ago now and I was successful in getting a place on the program (https://mkto.cisco.com/security-scholarship).
The scholarship gives students access to an online portal where you get access to all the training material which include text slides, videos and labs for hands on training. Unlike most Cisco certifications the Cyber Ops certificate is mostly vendor neutral, yes Cisco equipment gets mentioned from time to time but most of the security tools used on the course are not Cisco such as Kali Linux, Security Onion, Burp, Wireshark, Bro, ELSA to name a few.
The certificate is broken into two exams the SECFND 210-250 exam and the SECOPS 210-255 exam.
The SECFND 210-250 exam topics are broken out into the following main areas:
The SECOPS 210-255 exam topics are broken out into the following main areas:
I have to say that Cisco did a great job here and created a really interesting and engaging course. I hope they continue to develop this track into the CCNP level and beyond and that they stick to the vendor neutral delivery of this course.
I’ve now passed both exams and I’m officially CCNA Cyber Ops certified.
So what is next? I’ve started the PTSv3 course from eLearnSecurity which is a pentesting course and what I like about the course is that it is hands on learning in a lab environment and what is even better for me is the exam is hands on. You have 72 hours to carry out pentesting against designated targets. I think this is a great way to test you on what you have learned and I personally prefer this way of testing over just multiple choice questions.
On Wednesday 6th of September, I passed the CCNA Sec 210-260 exam on my second attempt.
In my first attempt, I got 808 passing score is 860 so I wasn’t a million miles away from getting a pass. I am sort of glad that I did fail the exam on my first attempt as strange as that may seem. The reason being it showed me where I was weak and where I was strong. I went back over topics I didn’t score well in and really dug deep to understand them better. Like all Cisco exams, some of the questions were hard to understand what Cisco was actually asking or what is the correct “Cisco” answer.
I did better with my second attempt getting a score in the 900 range. So that extra study did the trick.
The resources I used:
OCG from Cisco. There has been a lot said about the book and I have to agree with what others have said. Why CPP is in the book I will never know. Also some topics are not covered in great detail but the questions asked in the exam expect you to have a better understanding.
CBT Nuggets – CCNA Security 210-260 course is very good and highly recommend it.
31 days before your CCNA Security exam which filled in some of the gaps from the OCG Book.
GNS3 for labs. The more labs you can do the better. You’ll get a better understanding of the technologies and also troubleshooting mistakes you make while setting up labs will help you learn. In GNS3 you can run the ASA, Switches, Routers, End hosts, Kali Linux to run attacks against your own topology.
I have been accepted on the CCNA Cyber Ops Scholarship program. I start the cource on the 24th of September. I plan on updating this blog with what I am learning and how the course is going.
After that, I would like to do some pentesting courses maybe something from eLearning Security and then finish off with the gold standard OSCP cert.
In this post I’m going to setup a Clientless SSL VPN via the ASDM GUI and then connect to it via the TinyCore Linux PC all from GNS3.
Topology:
I’m using the topology above. The nodes I’m using will be the ASA with the ASDM connected via the cloud from my local PC, if you want to know how to set the ASA up with access via the ASDM check out one of my other posts: How-To: ASA in GNS3 with ASDM
I’ll also be using R4 and the Remote Worker PC which is running a TinyCore Linux to test the Clientless SSL VPN.
Configure the Clientless SSL VPN on the ASAv via the ASDM GUI
When you log into the ASDM GUI you’ll get the main screen above. Click on Wizards > VPN Wizards > Clientless SSL VPN Wizard…
The Clientless SSL VPN Wizard window will pop up, click on Next. You’ll get the following window.
Here you need to give your Clientless SSL VPN a Connection Profile Name I’ve named this one SSL_Remote_Access and I’ve also selected the Interface that the SSL VPN will connect in on which is the Outside Interface (Internet). I don’t have my own digital certificate so I’m leaving the Certificate set to None, because of this the ASA will provide a self signed certificate. I’ve also given the Connection an Alias of SSL. Click on Next
The next step is to configure User Authentication you’ll have the choice to use an AAA server (which I dont have) or the Local User DB which I’ve selected. Select Authenticate using the local user database and add a new user, here I’m adding Homer once added click on Next
The next step is to setup a group policy or select an existing policy. Here I’ve setup a new policy called Remote_Users, this policy will inherit the DfltGrpPolicy attributes which I can change later if I need to. Click on Next
In the next step you can configure a list of bookmarks that the Remote users will be able to click on to access resources on the Corp LAN. Click on Manage > Add
Here you give the bookmark a name like EMAIL. Click on Add
You need to configure the IP address of the EMAIL server. I don’t have an email server in my lab but the bookmark will appear once I connect to the Clientless SSL VPN (hopefully).
That is it, you’ll get a summary page click on Finish to send the config to the ASA.
With the ASA configured the next step is to configure R4 in my topology. I’ll have to give Gi0/1 an IP address (200.0.0.1/24) and also a default route to send all traffic to the ASA using the command “ip route 0.0.0.0 0.0.0.0 136.1.47.1” as shown below.
Next configure the TinyCore Linux PC with an IP address in the same range as Gi0/1 I’ll use 200.0.0.2 and set the default gateway to 200.0.0.1.
To configure an IP address on the Linux PC click on Control Panel > Network
Set the IP address and the Gateway and click on Apply
It is always good practice to test the connectivity, open a Terminal Window in the Linux PC and ping the Gateway at 200.0.0.1.
Now using the built-in Firefox browser on the Linux PC it is time to test the Clientless SSL VPN and see if we can connect to the Corp LAN. In the address bar enter the URL configured earlier which is: https://136.1.47.1/SSL
Looks good because this is a self signed certificate from the ASA the Firefox brower gives you a warning not to trust the site. Click on I Understand the Risks to continue. Once you accept the risk you will get the following login page.
Enter in the username and password in my case Homer.
Success !! I have logged in and as you can see the EMAIL bookmark I configured during the Clientless SSL VPN setup is there.
I hope you found this useful, get labbing and try it out for yourself.
Feedback always welcomed.
So you can’t afford a nice shiny ASA firewall, a well no firewall for me so. Not true, you can use a Cisco Router with the correct license and use it as a Zone-Based Firewall. YAY.
This is the topology I’ll be using in this lab. The goal is to allow icmp and http traffic from the LAN Router out to the Internet Router but drop telnet traffic.
I’ve setup the Internet Router to allow telnet connections via the vty lines. Also, I am running eigrp as the routing protocol between the routers.
First let’s show telnet working from the LAN Router to the Internet Router.
Success! I can log into it. And while I’m at it let me show http working. For this I enable the Internet Router as a http server using the following command #ip http server
Now it’s time to configure the Zone-Based Firewall.
Step 1: Create two zones INSIDE and OUTSIDE you can call this TRUSTED and UNTRUSTED if you like it doesn’t really matter what you call them once it’s meaningful.
Step 2: Create a class-map to match protocols you want to allow.
You must use the “type inspect” command when configuring the class-map otherwise it would be a normal class-map used for QoS for example. Also, the match-any command is also important, the match-any is equal to an OR as in match http OR icmp. If you used the match-all command this is equal to an AND as in match http AND icmp and if they match take action.
Step 3: Create a policy-map and reference the class-map in the policy map you will either drop (block) pass (allow the traffic this is none stateful) or inspect (allow the traffic and keep track of it in the stateful table)
Step 4: Create a service-policy, this tells the ZBFW in what direction to apply it, if you remember in Step 1 we created two different zones called INSIDE and OUTSIDE. It also references the policy-map in Step 3.
The zone-pair command got truncated so here it is in full:
ZBFW(config)#zone-pair security ALLOW_HTTP_ICMP source INSIDE destination OUTSIDE
Step 5: Now it is time to apply the two different zones to the interfaces. The reason I left this to last is a soon as you apply a zone to an interface it will start to block all traffic between the two different zones until you configure Steps 2 to 4.
That should do it now, let’s test it and see if it is working.
First I’ll try to telnet to the Internet Router this should fail.
As you can see from the output the firewall is configured correctly. It isn’t allowing telnet traffic anymore but it is allowing http and also icmp pings.
Check the zone-based firewall using the command #show policy-firewall session here we can see the http session allowed from the LAN Router (INSIDE) to the Internet Router (OUTSIDE) on port 80 and also the icmp session.
Hope you found this useful.
I’m still using the topology above. I am going to setup the following security measures BPDU Guard, Root Guard and Port Security and use the Kali Linux box in my topology to launch attacks FUN TIMES!
So BPDU Guard is used to protect the switch from an attacker that connects into the network via a switch port. Host port (Access port) shouldn’t send in BPDU messages into the switch. Once you enable BPDU Guard on an access port and a BPDU message is received on that port the switch will disable the port. This could prevent manipulation of your current STP topology.
The port was already configured as an access port on VLAN 10. I have R1 acting as a DHCP Server handing out IP addresses in the 10.1.10.0/24 range so the Kali Linux machine got the IP address of 10.1.10.2.
To enable BPDU it is straight forward using the command #spanning-tree bpduguard enable
Now that BPDU Guard is enabled it is time to send in BPDU messages on the access port Gi1/1.
On the Kali Linux machine I’m using an attack tool called Yersinia. I used the interactive option which is:
root@kali:~# yersinia -I
I know I’m not showing much in the screen above but the second line in the output is the BPDU packet getting sent into the access port of the switch which results in the port getting shutdown.
Before I sent the BPDU packet in on Access port Gi1/1 I checked the status of the interface and you can see that it is connected meaning it’s up and on VLAN 10.
Next, the BPDU is sent on Gi1/1 from the Kali Linux machine causing the port to go err-disabled and it was shutdown automatically by the switch as you can see from the second interface status command.
To get the port back up you have to bring it back up manually (there is a way to do it automatically which I will show later). You need to go into the interface do a shutdown followed by a no shutdown, doing just a no shutdown will NOT bring it back up.
So as you can see I just did a no shutdown first and the port didn’t come back up, but after doing a shutdown followed by a no shutdown the port came back up.
As I mentioned above you can have the switch automatically bring the port back up after a period of time with no BPDU violations.
Enter the commands below in global configuration to enable errdisable recovery for BPDU Guard.
I’ll launch another attack on that port and let us see the port go down and back up automatically.
As you can see (just about) that the port went down at 20:35:01 due to a BPDU Guard violation and 30 seconds later the port came back up at 20:35:31.
I have removed BPDU Guard from interface Gi1/1 and now I’m going to configure Root Guard. Root Guard is useful if you have your switch connected to another switch you do not manage or have no control over, to prevent it claiming root for STP and causing problems with your STP topology or you may have a less powerful switch in your topology and you never want that less powerful switch becoming the root switch.
Go into the interface that is connected to the other switch in my case I am configuring it on the port that is connected to the Kali Linux machine so I can run an attack to try and claim that I am the root switch. Once I run the attack you can see that the switch puts the port in blocking mode.
The port is now in blocking mode. The port will unblock once the attack or the switch stops trying to claim that it’s the root switch.
How many MAC addresses should a switch port have? One for the host that is connected to it? What about if that same user has an IP Phone? We might see two MAC addresses on that port. However, you do not want hundreds of MAC addresses on any given switch port and the main reason for that is the switch can only hold so many MAC addresses in its CAM table. If a switch is overloaded with too many MAC addresses than what it can’t hold in its CAM Table memory will be broadcast to all ports in the switch because it can’t add the MAC port mapping to its CAM table anymore.
This is where port security comes into play. We can use port security to restrict the number of MAC addresses allowed on a switch port. For example, if you set the limit to 2 MAC addresses and a 3rd MAC address showed up on that port the switch could shut the port down in doing so it is protecting itself from an attack such as the CAM table overflow attack where an attacker floods the switch with spoofed MAC addresses and filling up the CAM tables memory.
Before putting on port security on my access port I’m going to run a CAM table overflow attack using my Kali Linux machine and a tool called macof. This will send in thousands of spoofed MAC addresses and cause the CAM table to fill up.
At the moment I don’t have a lot of MAC addresses in my MAC table. Running the #show mac address-table count command shows me that I have one MAC addresses in VLAN 1 and another in VLAN 10.
I’ll now log into the Kali Linux machine and run the macof attack.
This is a screenshot of the macof attack in progress sending thousands of spoofed MAC addresses into the switch. My switch started to complain straight away about CPU load which isn’t surprising since I am running all of the nodes in VM as it is.
As you can see the number of MAC addresses on VLAN 10 is now at 11983 and I only ran the command for a few seconds as my switch wasn’t responding due to high CPU. This just shows how easy it is to cause damage to a network running a simple attack.
I’m going to configure port security on port Gi1/1 so it will shut the port down after it receives more than 5 MAC addresses. Again just like BPDU Guard you can configure the switch to automatically bring the port back up after a period of time, 30 seconds is the default and minimum time you can set the errdisable recovery command to.
Above shows how to configure port-security and setting the max allowed mac addresses to 5. Also, I set the port to shutdown if a violation happens. You can set a violation to take different actions depending on how you configure it. They are: Protect, Restrict or Shutdown.
Also included in the printout above is the current state of the ports with port-security configured on them. There is a mac address on each port and both of the max allowed set to 5 and there are no violations at the moment and lastly what action should be taken if a violation is triggered and that is to shutdown the port.
Time to run macof again and see what happens!
As you can see that port-security detected the attack and shutdown the port!
I am currently working Layer 2 best practices. To help reinforce this I am using the above lab setup. I’ll be mainly working on the switches you see in the topology although I might call in the Kali Linux machine and run some attacks on the switches after I have configured some of the security features to demonstrate how they work.
To get started lets see what the current state of the interfaces are, are they access ports or trunk ports and what vlan are they in? To do this use the command:
show interfaces status
We can see that port Gi0/0 is a trunk port. This is the port connected to R1. Gi0/1 is an access port and in VLAN 10 this is the port connected to the PC1 and ports Gi3/2 and Gi3/3 are trunk ports connected to SW2.
In the printout below I move ports Gi0/2 and Gi0/3 using the range command into VLAN 100. This VLAN is used as a placeholder for ports that haven’t been assigned to particular VLAN yet. I’ve also configured the port as an access port and disabled auto-negotiate which turns off DTP. To finish off I’ve ‘shutdown’ the ports instead of leaving them up.
Run #show interface status
As you can see ports (interfaces) Gi0/2 and Gi0/3 are now members of VLAN 100 and are also disabled i.e. shutdown. You would repeat this for all other unused ports on the switch to secure it. When a port is needed you just go into the interface and configure the VLAN it belongs to and do a ‘no shut’ to bring the port back up. Or you could change it over to a trunk port using the following commands:
Above shows how to configure a port (interface) as a trunk port. You first need to tell the port what encapsulation to use you can select dot1q or isl (cisco proprietary) or negotiate. I selected dot1q. I configured the port as a trunk and also told it to use the native vlan 99. Although not shown here you would also disable DTP on the port using the nonegotiate command.
So why disable DTP? Well if someone wanted to gain access to your network they could plug in their laptop to a switchport or a wall jack and run a piece of software that could run DTP and negotiate a trunk port tricking the switch into thinking it is connected to another switch. The attacker would have access to all the VLANs on that switch and could sniff the traffic to see what was on the network. By disabling DTP using the ‘nonegotiate’ command you prevent this from happening.
In my next couple of posts, I’ll be covering port security, BPDU Guard, Root Guard, DHCP snooping, and access lists and showing how to configure them and run some attacks against them.
