Monitoring IP segment usage with MRTG

Here's a little ready-made script for graphing the usage of a subnet or a VLAN with multiple subnets.

We'll be using nmap for quickly surveying the subnets and MRTG for creating graphs like this:



First, the script:

nets="192.168.200.128/25 192.168.200.0/26"
nrips=188

for net in $nets
do
nrup=`nmap -sP $net | grep "Nmap finished" | column -t | cut -d ' ' -f 11 | cut -d '(' -f 2`
done

nrtot=$nrup

proc=`echo "scale=2; $nrtot/$nrips*100" | bc -l | cut -d '.' -f 1`
echo $proc
echo 0

The script doesn't calculate the number of total IPs, so you must do it yourself, in $nrips.
It returns the usage percent and 0 (to suit MRTG).

The MRTG config:

Target[xyz]: `/etc/mrtg/the_script`
MaxBytes[xyz]: 100
Options[xyz]: growright,gauge,noinfo,nopercent
ShortLegend[xyz]: %
Title[xyz]: % IP usage
YLegend[xyz]: Percent
...

And don't forget to schedule the script every 5 minutes in /etc/crontab:

0-59/5 * * * * root /usr/bin/mrtg /etc/mrtg/ip_usage >/dev/null 2>&1
     

Squid RADIUS authentication

If you use a RADIUS server for other authentication needs in your organisation why not use it for proxy access? One possible scenario is giving access to web services only to users in specific Active Directory groups.

As a RADIUS server you can use freeRADIUS or Microsoft's IAS server. If you're using the latter you can find info and basic configuration for the IAS server in the first part of this article. Basically you have to declare the client and set up a remote access policy (set Service-Type = Login) and a connection request policy. You also need a security group that will be allowed to validate the remote access policy (you can't specify single users).

I won't describe the installation of Squid, it's not this article's topic.

The authenticating module I used is squid_radius_ath. You can find it here. Download it, unpack it and compile it. You will get a squid_radius_auth executable that you can move to a safe place. It needs a config file, squid_radius_auth that should contain the name of the RADIUS server and the secret:

server radius_server
secret secret_phrase

You need to point Squid to the authenticator so place something like this in squid.conf:

auth_param basic program /path_to_auth/squid_radius_auth
auth_param basic children 5
auth_param basic realm Please enter your domain credentials
auth_param basic credentialsttl 8 hours

Next you have to condition Squid to allow only authenticated users. In the following example users that are in the local LAN are allowed without logging in but users that don't show up in the local users file (localusers) are asked to login:

acl passwd proxy_auth
acl localusers src "/etc/squid/localusers"

http_access allow localusers
http_access allow all passwd
http_access allow all

You'll also have a log of who and when logged on to use the web services on the RADIUS server's logs.
   

PuTTY Connection Manager

I discovered a very useful new toy: PuTTY Connection Manager.

It simply provides a tabbing interface with PuTTY consoles.

You still have to use the classic PuTTY for this to work. They recommend the latest - 0.60.

PuTTY Connection Manager - http://puttycm.free.fr/
PuTTY - google it!
 

Automating SSH and telnet tasks

This is a short tutorial about automating those annoying tasks that need to be done on a (large) number of routers of switches with the same commands.

I used rancid (http://www.shrubbery.net/rancid) for that purpose. It supports Linux among other operating systems. Those of you that use Debian will have it installed with a simple apt-get install rancid-core.

The tool we'll be using, clogin, is located in /usr/lib/rancid/bin/. It needs a bit of configuration that can be stored in a ~/.cloginrc file. The file should look like this:

add user * {user}
add password * {password} {enable_password}
add method * {ssh}

The method can be ssh or telnet. After this, clogin can be called like: clogin -c "commands" IP.
Here is a simple example script for sending the same commands to a list of Cisco routers/switches:

clogin=/usr/lib/rancid/bin/clogin
switch="192.168.0.1 192.168.0.2 192.168.0.3 192.168.0.4"

$clogin -c "conf t\ncommand1\ncommand2\nend\nwr mem\n\n\n" $switch > logs/log_`date`

That's all there is to it.
 

VPN and Radius with Cisco ASA and Windows 2003 Server

Here's an article about integrating the Cisco ASA firewall/VPN concentrator 5500 family with Windows 2003 Server's RADIUS server, called Internet Authentication Server - AIS. What I will describe is setting up a ASA 5500 appliance to do Remote Access VPNs authenticating against a MS IAS RADIUS server; the twist to this setup is differentiating between multiple Windows user groups - linking a Windows AD group to a specific tunnel-group.

I decided to write this article becouse I had to search for too much how to do some of the things described below.

In the first part we'll take care of setting up the 2003 Server.

First of all make sure that if you're deploying RADIUS for a large organization you're using the Enterprise flavor of Windows 2003 Server. It has more extensive capabilities than the Standard edition - see http://www.winsupersite.com/showcase/winserver2003_editions.asp for example.

Second, install IAS on the 2003 Server - it doesn't come installed by default:


In order to use the IAS with a client (in our case, the ASA device) you have to declare the client to IAS, otherwise the server will not answer to the queries: enter the IAS management console, right click on the "RADIUS Clients" on the left > New RADIUS Client. Here choose a name for the ASA device; this will be unique and you'll be using it later. Next, as Client-Vendor choose RADIUS standard, and as secret - a phrase that you'll use later in your ASA config to pair with the IAS server.

Next, the server needs a Connection request policy to allow the client to connect: Connection Request Processing > Connection Request Policies > New... Here make a custom policy and as Policy Condition you can use for example "Client-Friendly-Name" and specify the name you chose in the previous step when you declared the client:


The next thing to do is to create a Remote Access Policy, again a custom one. For this you have to have prepared one or more Windows groups (local or better - AD groups) in which you include the users that can access the VPN. So, in policy conditions add the Client Friendly name (for example) and the Windows-Groups attribute; here you'll be asked for the group. Next, "Grant remote access permision" and edit the profile. In the Authentication tab choose only "Unencrypted authentication" and in the Encryption tab choose only "No encryption". We'll handle the Advanced tab later.

Now, the ASA appliance.

I won't describe in detail how to set up a Remote Access VPN, there are plenty of tutorials and guides for doing this. One would be http://www.cisco.com/warp/public/110/asa-remotevpn-asdm.pdf.
Here's a sample setup of doing this:

aaa-server group1 protocol radius aaa-server group1 host 192.168.1.2 key secret

group1 will be used to authenticate the VPN users against the 192.168.1.2 server (this is the IP of the 2003 Server box with IAS). Before continuing with the setup let's test the RADIUS communication:

ASA# test aaa-server authentication group1 username user password passwd
Server IP Address or name: 192.168.1.2
INFO: Attempting Authentication test to IP address <192 .168.1.2=""> (timeout: 12 seconds)
INFO: Authentication Successful

If the authentication was successful you will get the above message. If not, you need to debug it. On the IAS server side you can check the Event Log in the System category. Every attempt of authentication is logged there is successful or not. Typical pitfalls are misconfigured Remote Access Policies of Connection Request Policies. You will get a "Reason" for the failure.

If you don't even get a Event Log message then you need to check your security device configuration or IP connectivity.

The rest of the configuration:

ip local pool vpn-pool 10.0.1.2 - 10.0.1.255
group-policy testvpn internal
group-policy testvpn attributes
dns-server value 192.168.1.3
vpn-tunnel-protocol IPSec
default-domain value test.local
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto dynamic-map outside_dyn_map 10 set transform-set ESP-3DES-SHA
crypto dynamic-map outside_dyn_map 10 set security-association lifetime seconds 288000
crypto map Outside_map 10 ipsec-isakmp dynamic outside_dyn_map
crypto map Outside_map interface outside
crypto isakmp enable outside
crypto isakmp policy 10
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
crypto isakmp nat-traversal 20
tunnel-group testvpn-group type ipsec-ra
tunnel-group testvpn-group general-attributes
address-pool vpn-pool
authentication-server-group group1
default-group-policy testvpn
tunnel-group testvpn-group ipsec-attributes
pre-shared-key *

Please note that is only an example config and your needs may require some other config options.
To complicate matters, if you have multiple VPN tunnel groups then you need to differentiate between users that are allowed to access each tunnel then you need to add a special attribute in the Remote Access Policy: go to the Remote Access Policy you're editing and in the Advanced tab add a Class attribute with a string value of OU=value. The value must match the name of the tunnel group:


On the ASA:

group-policy testvpn attributes
group-lock value testvpn-group

What I couldn't figure out is how to differentiate the VPN users from the management users (console, ASDM etc). If anybody knows please let me know.
   

Follow by Email

Sponsored Links

Labels