Alfa 500mW AWUS036H USB Wireless Adapter 802.11 b/g Network Radio Card is a win in Backtrack 4!
I picked up a Alfa USB Wireless Adapter about a month or so ago, and it’s a definitely a good card for Backtrak 4.
For some reason, I’m one of the few that had to switch the realtek driver for it, and boom, every wireless utility a tried in BT4 worked great. (I’m using BT4 RC1, on a Lenovo x201.)
So to get the good love, follow my simple steps in BT4:
find “blacklist r8187” (if you don’t know how to use vi or vim, I weep for you.)
comment that out with the hash / pound / number / whateveryoucallitinyourworld “#”, and add this line:
save it and reboot. (too used to dealing winblows.. probably could remove it and rmmod the rtl8187)
it should be using the r8187 kernel module instead of the rtl8187.
Boom, kismet should work and all the other good stuff should work in BT4 with this good card.
A side item: if you’ve never used wepbuster to show someone how bad wep is, *do it*.
Eric and I wrote some scripts for DEFCON a few years ago to automatically crack WEP with the parts that were around then. This does something just like it, but seems to run through all the different vectors you could use. Basically, start it, and let it go… very handy!
Aruba Network’s new remote office access point, the RAP-2WG, allows an enterprise to securely extend the corporate wireless network to remote offices. While REAP technology is nothing new, the price point on the RAP-2WG certainly is. List price is only $99, and the street price brings its price in line with that of a Linksys WRT54GL. The unit is extremely small, too: about the size of a deck of cards.
How does it work?
The RAP-2WG’s E0 port is connected to the internet connection at the remote or home office. The unit establishes an IPSEC tunnel (using your choice of 3DES or AES) back to the Aruba controller at the main office. Once connected, the controller extends the corporate wireless — including all security policies — to the remote unit. You can also configure the second wired port in any way imaginable – from 802.1x port security, to a vlan bridge, even as an 802.1q trunk. You can also apply an ACL and run the RAP-2WP in split tunnel mode so that client internet traffic doesn’t cross the tunnel.
Enough marketing, how well does it really work?
I tested an Aruba RAP-2WG as follows:
– Aruba OS 22.214.171.124
– 6000 Controller Cluster. The cluster was in regular production mode during this test.
– 100 Mb internet connection
– RedHat 5 running vsftpd – Server
– Ubuntu 10.04 – Client
– Dell D620 with an Intel 4965AGN wifi card
The Test Procedure:
After configuring the RAP-2WG to connect back to the mothership, I connected it to a high-speed remote network. To test the unit’s throughput, I created a file containing 20Mb of random data (testfile.tar.gz); this file would then be transferred via FTP to the client machine.
This technique generally works pretty well, the whole way up to 1Gb/s if you follow these two simple rules:
1) Ignore the results of the first test. The first time you download the file, the server has to read it from disk. Subsequent requests (within a few minutes, at least) will come from the server’s disk cache and be significantly faster.
2) Don’t actually write the file to disk on the client machine, otherwise you’ll just be testing the hard drive speed. The best way to do this is to use wget under Linux. The syntax I prefer is:
# wget -O /dev/null ftp://your-ftp-server.pskl.us/testfile.tar.gz
This will simply dump the data to /dev/null as it comes in. When wget completes, it will give you the average transfer rate in BYTES per second — don’t forget to multiply by 8.
Step 1: Baseline Test
To determine the maximum speed at this site, the client machine was connected directly to the local internet connection using the system’s wired ethernet port. The test file was then transferred ten times and the average bit rate computed.
Average Transfer Rate, No Crypto: 84.64 Mb/s
Step 2: IPSEC AES128, using the Wired port
The test system was then connected to the RAP-2WG’s E1 port. The test file was then transferred ten times and the average bit rate computed.
Average Transfer Rate, IPSEC 128, Wired Port: 2.73 Mb/s
Step 3: IPSEC AES128, Wireless 802.1X PEAP
The test system was then connected wirelessly to the RAP-2WG. The system established a solid connection at 54Mb/s using PEAP/MSCHAP/AES auth/crypto. The test file was then transferred ten times and the average bit rate computed.
Average Transfer Rate, IPSEC 128, Wireless PEAP: 1.821 Mb/s
The RAP-2WG works as promised. The rated IPSEC throughput of the unit is 2Mb/s, which agrees with my findings. The slightly slower throughput over wireless is due to a combination of effects, but most likely a result of the double-encryption (PEAP wifi plus the IPSEC tunnel) that the unit has to handle. The RAP-2WG is inexpensive enough that it can be deployed as a robust VPN solution for staff working from home. You could actually buy RAP-2WGs and hand them out to your staff for about the same cost as buying Cisco VPN licenses for your existing ASA. Yes, that ‘s right. A robust hardware solution for the same price as the competition’s software license.
Aruba, you guys rock.
Why, oh why, did you have to make this so difficult?
If you’re running Cisco WCS and would like to use a non-self-signed SSL certificate, you probably did what I did. Note: The following steps *look* right, but are not:
1) Dig through the WCS directories until you find the Apache SSL configuration files (in ./webnms/apache/ssl/ssl.conf).
2) Modify ssl.conf to point to your RSA Keys, Intermediate Certificate, and Signed Certificate files.
3) Restart WCS.
Yeah, that doesn’t work. Turns out WCS overwrites the contents of all of the Apache configuration files, including ssl.conf, with the files from the local “backup” directories (there are no less than 17 backup directories in WCS.)
[root@wcsbox WCS126.96.36.199]# du -a | grep backup | wc -l
So, here is the actual working procedure. For this example, I’ll be using the free .edu certificates from my pals over at ipsca.com (you guys rock!).
1) Generate a CSR and have your favorite CA sign it. When complete, you will have three files: Your key (server.key), the signed cert (server.crt) and the CA’s intermediate (intermediate.crt).
2) Edit /opt/WCS_version/webnms/apache/ssl/backup/ssl.conf and set the following directives:
I like to keep these files outside of the WCS directory so that I can re-use this config file after an upgrade. I also store a backup copy of ssl.conf in this directory. Ironically, WCS doesn’t make backup copies of these for you.
3) Restart WCS and *poof* enjoy your new signed SSL experience.