This is the computed list of SSH bruteforce IP’s and commonly used usernames for April 2013.

Top 50 SSH bruteforce offenders IP’s.

Top 50 SSH bruteforce usernames.

I maintain a radius server that proxies requests from publicly accessible SSH servers which, unfortunately must run on port 22.

There are over 140 SSH servers that proxy all requests through this server and due to the logging which is configured I am able to capture all failed attempts including username password and IP address. I frequently scan these logs to find the top offending IP addresses and common usernames so I can add them to a blacklist for the radius server to drop straight away.

There are many public projects that compile sources of such information, however these logs are easy for me to divulge for others to incorporate into similar lists.

I will throw some old stats of interest and work on this to become a monthly release.

October 2012
Failed Attacks: 19,969,074

November 2012
Failed Attacks: 11,335,220

December 2012
Failed Attacks: 5,277,817 <- I guess everyone went quite over the holiday period?

January 2013
Failed Attacks: 6,786,138

February 2013
Failed Attacks: 17,375,929

March 2013
Failed Attacks: 16,437,020

April 2013
Failed Attacks: 5,542,223

May 2013
Failed Attacks To Date: 3,347,659

As mentioned, I can confirm that Cisco Call Manager 9 (CCM9 ) does work in VirtualBox and can be installed in a similar manner to CCM7. I have had both 9.0.1 and 9.1.1 have been installed with all services running perfectly.

As we did with CCM7, CCM9 must first be installed in VMware and then moved over to VirtualBox. CCM9 is now 100% supported in VMware, so the install process should be flawless. Keep in mind though that VirtualBox is definitely not officially supported, so you will get no help from TAC. This should only be used in a lab environment.

The minimum requirements for CCM9 are the same as they were in CCM7, 1x 80GB SCSI disk with 2048MB RAM. The CUC prerequisites have changed slightly and if you use 80GB/2048MB you won’t be able to install CUC. I haven’t been bothered to find the minimum requirements for CUC but I’ll post them up when I get some time.

I’ve used VMware Workstation 8.0, but you should be able to use any version of VMware to build the initial machine. All we need to do is to have the install complete and boot successfully, all other finer details can be changed once we move over to VirtualBox.

1. Start by creating a new VM and choose a custom config.
2.  Depending on your version of VMware this may change, but I used Workstation 8.0 as the hardware platform.
3. We don’t want to use the auto deployment scripts and we will need to modify the hardware before boot, so just choose the ISO later.
4. Any version of Red Hat should work here, but I used 64-bit version of Enterprise 6.
5. Name it appropriately.
6. One processor is enough but if you’ve got more resources to throw at it, you may be able to do it here as long as you match the same in VirtualBox later.
7. Same goes for the RAM. The minimum requirements call for 2048MB but if you’ve got more, chuck it in.
8. I hate using NAT, but it’s probably useful for labs. In any case I’ve got bridged here, but we will redo this step later in the VBox config.
9. Make sure you use SCSI here. I haven’t tried SAS but it may work too.
10. Create a new HDD.
11. Make sure this is set to SCSI, it won’t work with IDE here.
12. I’ve got the minimum as 80GB here, but if you’ve got more throw it here.
13. This is where the vmdk is stored, make sure you take note of the location as we will need this file later to import into VBox.
14. Finish it up.
15. Edit your VM before powering it on, we’ve got a few things to do here.
16. Select the CD/DVD drive and browse for your ISO.
17. Select your ISO.
18. I’ve finished up here, but if you want you can remove the floppy, sound cards etc.
19. Power on the VMWare image.
20. The install process here is exactly the same as a typical CCM9 install, I’ve included it just for the sake of doing so.
21.  
22. Notice here that CUC isn’t available because our hardware config is too low speccd.
23.  
24. This will take quite a while.
25. Once the installation has finished, log in and shut it down.
26. Now it’s time to fire up VirtualBox.
27. Add a new Red Hat 64-bit guest.
28. Make sure your memory size is the same as what you built in VMware.
29. We need to not add a new hard drive here (we will be reusing the one built by VMware).
30. Just accept this.
31. We need to edit our VM before powering it on.
32. Remove the SATA controller, if you remember we built the VM in VMware using SCSI disks.
33. Add a SCSI controller.
34. Select Choose Existing Disk.
35. Browse to the vmdk file that was outputted by VMware.
36. Your disk setup should now look like this.
37. Choose the IDE CDROM drive to boot from the CentOS live boot disk. Note that you can boot of any live distro, I actually used the Ubuntu 12.04 live CD because I was having issues with remote key forwarding to the VM whilst using CentOS.
38. Again, I hate NAT’ed NIC’s so I switched mine to bridged.
39. Mount your CCM partition and chroot to it.
40. vi/nano/whatever the hardware_check.sh script in /usr/local/bin/base_scripts/ which is similar to what we did in CCM7.
41. Find the function check_deployment() as shown below.
42. Like we did for CCM7 edit out the isDeploymentValidForHardware function.
43. Make sure you save the file, I used vi to edit this so :wq! it.
44. Throw the following lines in to change the hardware type to match those by VMware.
    

    vboxmanage setextradata “<VM name>” “VBoxInternal/Devices/pcbios/0/Config/DmiBIOSVersion” “6 ”
    vboxmanage setextradata “<VM name>” “VBoxInternal/Devices/pcbios/0/Config/DmiSystemVendor” “VMware”
    vboxmanage setextradata “<VM name>” “VBoxInternal/Devices/pcbios/0/Config/DmiBIOSVendor” “Phoenix Technologies LTD”
    vboxmanage setextradata “<VM name>” “VBoxInternal/Devices/pcbios/0/Config/DmiSystemProduct” “VMware Virtual Platform”
    

45. Now you’re ready to fire up CCM9 in VirtualBox so just run that thang.
46. On bootup you should be able to see the OS detecting all your hardware as VMware devices – this is a good thing, don’t worry
47. If you receive some weird output, don’t worry too much, the important thing is that the OS boots and services start successfully.
48. Again, ignore any of these types of errors, this is why this shouldn’t be used in production.
49. Login, hooray!
50. Because the hardware has been modified slightly, the OS is unable to detect the vCPU and the amount of RAM.
    
51. However, everything still works perfectly 😉

Just a few notes about the install. In the CCM7 install I did before, I added a new user whilst chroot’ed over to the CCM partition so we could SSH in later to modify the check_deployment() script. I only attempted a few times, but every time I tried my SSH user couldn’t log in. All permissions were set correctly, the user was added to the OS properly but SSH wouldn’t work. I’m sure if I dug deeper I would probably find some sort of SSH permission script in Cisco’s funky land, but for the purposes of getting CCM9 into VirtualBox it wasn’t needed.

I’ll be posting some more info on the topic as I use this more. Also, due to CCM9’s new licensing model I *may* look at loading licenses on to get this running past the 60 day limitation.

Good luck

x90

Following on from the previous article I wrote about CCM7 in VirtualBox I can confirm that CCM9 can be installed in a similar manner. Both 9.0.1 and 9.1.1 have been installed with all services running perfectly.

I will post up a detailed guide on how to install and configure CCM9 in VirtualBox shortly.

For the sake of shits the site has been moved to a new host 🙂

I’m a pretty big fan of TeamViewer.

There are heaps of remote desktop apps like GoTo Assist and the like that are able to punch through NAT by creating a reverse tunnel, but each to their own.

The latest Ubuntu install 8.0.17864 creates a daemon to bring your machine online. Maybe I’m just being a fritata but whenever the daemon was active, the machine would show online, but I could never connect to it. Even when the machine was a added as a partner it would show online, but it would always sit at “Connecting” when you try and remote into it.

The only way I could get into the remote machine was to open the GUI on the remote machine. Once the GUI was open the machines “online” status never changed, but I could remote in.

Due to the nature of a remote machine, you’ll never have remote access to open the GUI in order to remote to it. So the below startup script will launch the GUI upon login so you can successfully remote in. It is exactly the same script that is run when you click on the GUI icon for TV.

/opt/teamviewer8/tv_bin/script/teamviewer

HTH

I’ve had an annoying problem with my Linux VirtualBox Host + Guest combo for some time and have now only just got around to solving it, so hopefully this can help others in the same situation.

My Host runs Ubuntu 11.04 Desktop, but I run this headless. Unfortunately when it’s run headless and you VNC/TeamViewer/Weaponofchoice you get an 800×600 res. The latest version of VirtualBox + guest additions for Windows guests lets you define resolutions up to 6400×1200 without having to resize the guest window from the host GUI of VirtualBox.

Unfortunately my Ubuntu 12.04 guest wasn’t so lucky, and it defaulted to 800×600 even with the guest additions. The resizing of the guest window from the host worked, but in my case my host was at 800×600 and resizing was a massive pain in the ass.

I spent many hours scouring for how to manually resize a guest and came across many answers, none of which worked for me. I’ll throw what didn’t work below just in case anyone tries the same thing.

x90@ban-roy-x90-vm:~$ cvt 1280 102
# 1280×1024 59.89 Hz (CVT 1.31M4) hsync: 63.67 kHz; pclk: 109.00 MHz

Modeline “1280x1024_60.00”  109.00  1280 1368 1496 1712  1024 1027 1034 1063 -hsync +vsync

x90@ban-roy-x90-vm:~$ xrandr –newmode “1280x1024_60.00” 109.00  1280 1368 1496 1712  1024 1027 1034 1063 -hsync +vsync
x90@ban-roy-x90-vm:~$ xrandr –addmode VBOX0 1280x1024_60.00
x90@ban-roy-x90-vm:~$ xrandr –output VBOX0 –mode 1280x1024_60.00

vboxmanage setextradata global GUI/MaxGuestResolution 1280,1024
vboxmanage setextradata “VM name” “CustomVideoMode1” “1280x1024x16”

None of these worked. In the end I had to create a custom xorg.conf file that manually specified the resolution. As newer versions of Ubuntu did away with a default xorg.conf file I created:

/usr/share/X11/xorg.conf.d/20-monitor.conf

Which contained the below:

Section “Device”
Identifier      “Configured Video Device”
Driver   “vboxvideo”
EndSection
Section “Monitor”
Identifier      “Configured Monitor”
Option   “DPMS”
EndSection
Section “Screen”
Identifier      “Default Screen”
Monitor  “Configured Monitor”
Device   “Configured Video Device”
DefaultDepth    24
SubSection      “Display”
Depth   24
Modes   “1280×1024”
EndSubSection
EndSection

I guess I could have restarted gdm but after a reboot everything was finally working as expected without ever having to resize the guest window!

WARNING: This will be a very long (hopefully) and comprehensive series on rolling your own security distribution from picking hardware to installation and exploitation.

NOTE: This page will be most likely edited every time a change is committed so as to keep the information up to date in the real world. If anything major changes (new version of breaking WPA/WPA2 etc a new post will most likely be made to feature the tool/method). Check the modified date on the post to find the latest updates.

As mentioned in the first part of the series, any of these steps can be completed in either a virtual or physical environment. In fact, I have done the below in both environments and everything is working as well as can be expected.

Just to re-iterate my requirements were:
– VMware Workstation/Physical install.
– Ubuntu 12.04 base.
– Alfa AWUS036H wireless adapter.
– Ability to audit wireless networks (aircrack, reaver etc).
– Ability to audit generic network devices (metasploit, openvas etc).
– Ability to audit VoIP networks (ucsniff etc) .

Therefore this guide will show you how to install and configure:
– Ubuntu 12.04 i386 (explained as a note).
– VMware tools for those inside VMware workstation.
– Patched rtl8187 drivers to fix the channel -1 issue in airodump-ng.
– Nmap.
– Kismet.
– Aircrack-ng with Wesside-ng.
– Reaver.
– Gerix Wifi Cracker.
– UCSniff.
– Metasploit.
– TeamViewer.
– Chrome.

NOTE: As mentioned, I’m installing the i386 version of 12.04. Typically I would stick with the amd64 version, however the installation notes on UCSniff mention that 64bit 12.04 is not supported. I have yet to test UCSniff under 64bit (because perhaps 1 or 2 functions fail to work?) however, just for now, I have opted for the safe option in going i386.

As the post defines this is how to roll your own distro, I’m going to assume that everyone know how to install Ubuntu, but just in case, I’ve thrown a screenshot for every step along the way. As the screenshots for just the OS install are self explanatory there is no text to go with these steps.

NOTE: The screenshots were taken when installing into a VM. There are slightly different steps when installing to an external HDD or a different partition. If you want to try something else, watch out for step 3.

Installing Ubuntu 12.04

Installing VMware Tools

Obviously this is only applicable to those inside a VM.

A rough outline of steps:
1. Mount the VMware tools .iso.
2. Copy the tar to the desktop.
3. Open a shell as root.
4. execute tar zxvf <vmwaretoolsfilename>.
5. cd <vmwaretoolsfilename>.
6. execute ./install.pl.
7. Enter on all defaults.
8. Say yes to configure.
9. Enter on all defaults.
10. Reboot the machine by executing shutdown -r now.

NOTE: Most of the below steps require root for installation, file editing etc. I’m going to leave out the sudo on most commands but if you run into problems, just use your head and su or sudo.

Patching The RTL8187

There is a bug in the rtl8187 drivers that are distributed with the 12.04 distribution. Injection works straight out the box, but when trying to explicitly run an airodump-ng on a particular channel, airodump complains that the channel your card is bound to is -1. Luckily there is still an old patch for this driver which fixes the issue. For anyone wanting to dig into the details you can follow the process here: http://www.aircrack-ng.org/doku.php?id=compat-wireless

Here is the process I used:

wget http://www.orbit-lab.org/kernel/compat-wireless-3-stable/v3.5/compat-wireless-3.5-rc5-1.tar.bz2
tar -jxf compat-wireless-3.5-rc5-1.tar.bz2
cd compat-wireless-3.5-rc5-1
wget http://patches.aircrack-ng.org/mac80211.compat08082009.wl_frag+ack_v1.patch
patch -p1 < mac80211.compat08082009.wl_frag+ack_v1.patch
make
make install
make wlunload
modprobe rtl8187
wget http://www.orbit-lab.org/kernel/compat-wireless-3-stable/v3.5/compat-wireless-3.5-rc5-1.tar.bz2tar -jxf compat-wireless-3.5-rc5-1.tar.bz2cd compat-wireless-3.5-rc5-1wget http://patches.aircrack-ng.org/mac80211.compat08082009.wl_frag+ack_v1.patchpatch -p1 < mac80211.compat08082009.wl_frag+ack_v1.patchmakemake installmake wlunloadmodprobe rtl8187

Nmap

The next is an easy one. Nmap just install directly from the ubuntu repository.

apt-get install nmap

Kismet

I still love using Kismet for wireless mapping. I’m sure there are more fancy graphical tools for wireless (which I don’t know about – so please let me know about them!) but at the moment, I’m still preferring Kismet. Kismet also installs from the ubuntu repository which is nice. After installation we will edit the source interface to capture from. Obviously if you’re using a different card type or interface number adjust accordingly.

apt-get install kismet
nano /etc/kistmet/kistmet.cfg
edit line 28
source=rt8187,wlan0,wlan0

Aircrack-ng with Wesside-ng

I am still yet to review pyrit properly, but for a while now aircrack-ng has been the default standard for wireless auditing. We need to install some decencies first and then compile from source.

NOTE: I have yet to have success with wesside-ng on 12.04, however I still have hope as it has to be the easiest way to break WEP encryption. If you don’t want to try wesside (or easside for that matter) then don’t build unstable=true.

apt-get install build-essential
apt-get install libssl-dev
wget  http://download.aircrack-ng.org/aircrack-ng-1.1.tar.gz
tar zxvf aircrack-ng-1.1.tar.gz
cd aircrack-ng-1.1
nano common.mak
at line 70 replace
CFLAGS ?= -g -W -Wall -Werror -O3
with
CFLAGS ?= -g -W -Wall -O3
make
make install
airodump-ng-oui-update
make install unstable=true
make install
cp src/wesside-ng /usr/local/sbin

Reaver

Reaver is our next tool, which is an interesting vector attack on WPA2 devices. Reaver attempts to bruteforce the WPS auto-provisioning feature of the router to gain access and expose the PSK. For Reaver we will install some dependencies then compile from source. The details for this install were originally found here: http://nakedproof.blogspot.com.au/2011/12/installing-reaver-12-on-ubuntu.html

apt-get install libpcap-dev aircrack-ng sqlite3 libsqlite3-dev
Download the latest Reaver from: https://code.google.com/p/reaver-wps/downloads/list
tar zxvf 
cd 
cd src
./configure
make
make install

Gerix Wifi Cracker

I first stumbled across Gerix whilst in Backtrack. Gerix is neat python based tool for automating the process of aircrack/airodump commands. There is a fair bit of information on the net/youtube videos on how to use Gerix (which I have yet to nail down) but for now just having it on the system is good enough. There is a python dependency for Gerix before downloading and moving the app.

apt-get install python-qt3
wget https://github.com/TigerSecurity/gerix-wifi-cracker/zipball/master
mv master gerix.zip
unzip gerix.zip
mv  /opt/
cd /opt/
ln -s gerix.py /usr/local/sbin

UCSniff

As mentioned in my previous posts from ages ago, UCSniff is an awesome tool for testing VoIP security. It is heavily focused on the Cisco Call Manager arena, but it works on other platforms too. In recent versions, they’ve wrapped a pretty easy to use GUI around the app and have pretty good video support. As mentioned earlier, the UCSniff team mentioned that they only support UCSniff under i386, so that’s what I’m working with. As from their site, we need to install some dependencies from the ubuntu repository and then compile from source.

apt-get install zlib1g-dev liblzo2-dev libpcap0.8-dev libnet1-dev libasound2-dev libbz2-dev libx11-dev libxext-dev libfreetype6-dev vlc libvlc-dev libavformat-dev libavdevice-dev libswscale-dev libavfilter-dev libx264-dev libav-tools
apt-get remove pulseaudio
wget http://downloads.sourceforge.net/project/ucsniff/ucsniff/ucsniff-3.2%20src/ucsniff-3.20.tar.gz
tar -zxvf ucsniff-xxx.tar.gz
cd ucsniff-xxx
./configure –enable-libvlc –enable-gui
make
make install

Metasploit

No security distro would be complete without Metasploit. Back in the day Metasploit was a little difficult to install, but now it’s dead simple. Nothing too hard here just download, chmod, run and do as the screenies say.

download metasploit for linux (either 32 or 64bit)
chmod 775 metasploit-latest-linux-installer.run
sudo ./metasploit-latest-linux-installer.run

TeamViewer & Chrome

Even though this is a security distro, I’m personalising it with my own apps. There’s nothing worse than being stuck in an environment waiting for something to happen with no niceties from a normal distro.

Chrome can be installed via the Ubuntu Software Centre while TeamViewer can be installed by opening the .deb that you download from their website.

Keep in mind that this page will be added to when more software is needed/discovered/remembered.

WARNING: This will be a very long (hopefully) and comprehensive series on rolling your own security distribution from picking hardware to installation and exploitation.

NOTE: This page will be most likely edited every time a change is committed so as to keep the information up to date in the real world. If anything major changes (new version of breaking WPA/WPA2 etc a new post will most likely be made to feature the tool/method). Check the modified date on the post to find the latest updates.

The reason that this has come about is I was messing with the latest Backtrack 5 R2 in a VM. I’m not sure whether it is only a problem with the prebuilt live VM distro or 5R2 as a whole, but I could not for the life of me get OpenVAS reports to export. After digging around the closest I came to solving the issue was to find that the user running OpenVAS could not write the temporary report to /tmp. In the log files I could see

/bin/bash /usr/local/share/openvas/openvasmd/global_report_formats/b993b6f5-f9fb-4e6e-9c94-dd46c00e058d/generate /tmp/openvasmd_OHKB4T/report.xml > /tmp/openvasmd_OHKB4T/report.out 2> /dev/null

When I tried to run the command from the commandline it reported “No such file or directory found”. After trying to contact OpenVAS via IRC and not getting any response, reading through multiple sites and blog posts I came to the conclusion that OpenVAS would not work under BT5 and that if I wanted it to work I would have to roll my own.

So I concluded to roll my own security distro, one that I could build how I wanted with the tools that I needed. This would also give me a good insight into the tools that are available for different exploits etc.

For anyone wanting to follow this process, these are the requirements that I was working with – and I will post the details using these requirements – so your mileage may vary depending on your requirements.

– Ubuntu 12.04 base. The BT5 apps have had good support running an Ubuntu base for the last 2 iterations and this is my distro of choice for every day use.
– VMware Workstation/Physical install.
– Alfa AWUS036H wireless adapter.
– Ability to audit wireless networks (aircrack, reaver etc).
– Ability to audit generic network devices (metasploit, openvas etc).
– Ability to audit VoIP networks (ucsniff etc) .

Any of the below processes outlined will work in either a virtual or physical environment, however, 2 things to note is that any form of wired NIC manipulation (macchanger, ucsniff, VLAN hopping etc) will NOT work in a virtual machine. Also, when trying to run aircrack-ng against a wordlist, or pyrit for CUDA based cracking is very slow and limited inside a VM. It was due to this that I explored the variables in installing the new security distro to an external drive.

External Installation Variables

Installing a distro to external harddrive is nothing new. In fact I blogged about doing a persistent install for BT4 to a 500GB USB HDD. However, my recent research at work has led me to explore other options that I would not have though about.

In a blanket statement, for Operating System installs, you want the highest number of read and write IOPS that you can get your hands on. In a nutshell, you can test for IOPS by reading and writing 4kb packets randomly to a disk. This is much different than testing sequential read/writes which most disk types are quite good at these days.

Obviously, different disk types will give you different IOPS readings. When exploring installing Cisco Call Manager to a SAN, Cisco advised us that the SAN must support 100 IOPS per operating system you wanted to host. Obviously in a SAN using 15K SAS disks the IOPS will be in the thousands but this was good starting point for me.

I started off by wanting to test a SD card, USB thumbdrive, USB harddrive and a SATA attached 2.5″ drive. Obviously anyone will undoubtedly say that the SATA drive will be the best option. True. However, I didn’t have the luxury of re-partitioning my internal disk.

I fired up HDTune to test the disks that I had on hand. As a warning, different disk types, manufacturers and individual disks will give you different mileage so don’t take this as gospel.

I have posted a photo of each device that I remembered to, so that anyone can match up the results if they have the same drive. The first screenshot shows sequential read time and drive access time. The second screenshot show sequential read/write times and 4k read/write IOPS.

USB – Toshiba TransMemory 1GB

USB – SanDiskCruzer Edge 8GB

NOTE: I would love to do this test again, perhaps on a brand new Cruzer. The IOPS far outweigh any others that I tested, so I’m not sure whether this is an anomaly or not.

USB – Toshiba USB Drv 16GB

SD – Sandisk Class 2 SDHC Card

USBHDD – Seagate Portable USB2 500GB

USBHDD – Seagate FreeAgent GoFlex USB3 500GB

USB HDD – Seagate FreeAgent GoFlex USB3 1TB

SATA HDD – Western Digital WD3200BEVT-22ZCT 320GB

From these tests you will notice that:
– Sequential read for all the drives are actually quite good.
– The old, cheap USB thumbdrives had quite poor sequential write, but I’m sure newer drives would be much better.
– Any flash based memory has excellent access speeds
– Most flash based memory has excellent 4kb read speeds creating a high IOPS read rate.
– Most flash based memory has absolutely shit 4kb write speeds creating very a low IOPS write rate.
– External USB harddrives are “ok” at everything.
– Internal SATA or any physically attached disks are where you want to be at.

The option that I opted for was to use the 500GB USB3 Seagate GoFlex HDD. Mainly because IOPS and sequential read/writes are quite OK, I have enough storage space to hold rainbow tables (unlike small USB thumbdrives), it was relatively cheap, and I’m a sucker for the GoFlex interface.

Wireless NIC’s

Unfortunately, I do not have much information on the wireless NIC front. A while ago I opted to buy the Alfa AWUS036H 1000Mw. Anyone who does some sort of research on the backtrack forums etc will pick up that the Alfa cards are highly powerful and capable of injection. There are newer cards available like the AWUS036NH 2000Mw, but I have not tried these, nor know whether they are capable of injection as they use newer RTL chipsets.

The Running System

A while ago I was working on a project to decommission the old TACACS server and we chose to replace it with Radius for Cisco router authentication.

After trying a few different radius packages (on Linux) one of our engineers said that he had luck in the past with Radiator – a closed source radius package for Linux. The Radiator software http://open.com.au/radiator/index.html is probably under-utilised for basic authentication, but has been rock solid in our production environment for 6 months+.

What we now have is a radius server that accepts authentication requests from our Cisco devices, checks whether the username or Calling-Station-Id is in a blacklist, authenticates them against LDAP to our Domain Controller and then checks the users group membership to allow them to authenticate. All failed and accepted attempts are also logged.

Whilst the documentation is huge and detailed (376 pages) I couldn’t find any specific examples on the net to tie everything we wanted together. So below is a sample configuration for what we are running as detailed above. Essentially we make a Radius user on the domain who can read LDAP (because we don’t allow anon ldap queries right?). We also make a RadiusSG security group which will contain the users that we want to allow login to our devices (because we don’t want to allow a terminal login for all our other AD users).

Note, I have also included a clients-group1.cfg file to specify each NAS into nice groups. I use this option to create multiple includes to split devices by region/country.

file: /etc/radiator/radius.cfg

#Foreground
LogStdout
LogDir          /var/log/radius
DbDir           /etc/radiator
# Use a low trace level in production systems. Increase
# it to 4 or 5 for debugging, or use the -trace flag to radiusd
Trace           3
# You will probably want to add other Clients to suit your site,
# one for each NAS you want to work with
# INCLUDE OUR REGION SETTINGS
include %D/clients-group1.cfg
<Realm DEFAULT>
# LOG ALL FAILED REQUESTS TO /var/log/radius/<YEAR>-<MONTH>-attempts-failed.log
<AuthLog FILE>
Filename %L/%Y-%m-attempts-failed.log
LogFailure 1
LogSuccess 0
FailureFormat %d/%m/%Y %H:%M:%S FAIL Username: %U Password: %P from %{Calling-Station-Id} on %{NAS-IP-Address}
</AuthLog>
# LOG ALL ACCEPTED REQUESTS TO /var/log/radius/<YEAR>-<MONTH>-attempts-ok.log
<AuthLog FILE>
Filename %L/%Y-%m-attempts-ok.log
LogSuccess 1
LogFailure 0
SuccessFormat %d/%m/%Y %H:%M:%S  OK  Username: %U Password: <hidden> from %{Calling-Station-Id} on %{NAS-IP-Address}
</AuthLog>
# CHECK BAD USERNAMES THEN BAD IP’S THEN LDAP FOR AUTHENTICATION
<AuthBy GROUP>
# FLOW THROUGH OUR BLACKLIST MODULES
AuthByPolicy ContinueUntilReject
#CHECK FOR BAD USERNAMES
<AuthBy FILE>
Blacklist
Filename %D/reject-usernames
</AuthBy>
#CHECK FOR BAD IP’S
<AuthBy FILE>
Blacklist
AuthenticateAttribute Calling-Station-Id
Filename %D/reject-ip
</AuthBy>
#CHECK AGAINST OUR AD VIA LDAP
<AuthBy LDAP2>
# SPECIFY THE DOMAIN CONTROLLER ADDRESS AND LDAP PARAMS
Host <INTERNALIPOFDOMAINCONTROLLER>
SSLVerify none
UseTLS
Port 3268
# OUR DC WONT ALLOW ANON READING SO WE HAVE TO AUTH AS A VALID USER
AuthDN cn=Radius, OU=Service Accounts, DC=<DOMAINHERE>, DC=prd
AuthPassword <RadiusUSERPASSWORDHERE>
# USE THE CACHE FOR MULTIPLE ATTEMPTS WHICH SAVES LDAP QUERIES
CachePasswords
# START SEARCHING LDAP FROM THIS DN FORWARDS
BaseDN DC=<DOMAINHERE>, DC=prd
UsernameAttr sAMAccountName
ServerChecksPassword
# REQUIRE GROUP MEMBERSHIP
SearchFilter (&(%0=%1)(memberOf=CN=RadiusGroup SG,  OU=Security Groups, DC=<DOMAINHERE>, DC=prd))
</AuthBy>
</AuthBy GROUP>
</Realm>

I have also created some scripts to poll for top IP offenders (bruteforce attempts etc) so I will most likely post these details soon.