Live monitoring of your network with syslog and email

If you're a control freak (like I am) here's a little tip for having live monitoring of what's happening on your network: have your switches/routers send syslog messages to a Linux box, filter those messages that don't interest you then send it to yourself via email. Here's how it's done...
First, point the device to the desired syslog server and make sure that you also use a ntp server to provide the correct time:

logging trap debugging
logging 10.0.0.1

Next, on the Linux box enable syslogd to accept remote logging: open the file /etc/init.d/sysklogd and make the change:

SYSLOGD="-r"

Restart sysklogd:

/etc/init.d/sysklogd restart

Add the following to /etc/syslog.conf:

local7.debug /var/log/network.log

If you're you're using iptables-based firewall add the following line to you firewall script to open port 514/UDP:

$ipt -A INPUT -p udp --dport 514 -j ACCEPT

Next test the config so far by watching the /var/log/network.log file for incoming messages (make sure there are any - log on to the device, make some config changes, save etc.):

tail -f /var/log/network.log

Next we need to do a script that parses this config. For example:

#!/bin/sh

MAILPL=/usr/local/sysm/mail_syslog.sh
TEMPF=/usr/local/sysm/out_syslog
EMAILS_SYSLOG=/usr/local/sysm/emails_syslog

pastminute=`date --date "1 minute ago" +%b' '%e' '%H:%M`
cat /var/log/network.log | grep "$pastminute" > $TEMPF
while read line
do
if echo $line | grep LINK-3-UPDOWN || echo $line | grep LINEPROTO-5-UPDOWN
then
else
for email in $( cat $EMAILS_SYSLOG )
do
$MAILPL $email "$line"
done
fi
done < $TEMPF

File TEMPF file contains the syslog lines from previous minute and it's generated at each execution. You should have a file, emails_syslog, containing the email addresses to which you want to send the emails.

The above script executes another script, mail_syslog.sh which sends the emails using msmtp (available on Debian: apt-get install msmtp):

#!/bin/sh

email=$1
text=$2
textfile="/usr/local/sysm/text"
date=`date`

echo "From: me@mycompany.com" > $textfile
echo "To: $email" >> $textfile
echo "Subject: syslog is saying" >> $textfile
echo "Priority: Urgent" >> $textfile
echo "Importance: high" >> $textfile
echo "" >> $textfile
echo $text >> $textfile
echo "" >> $textfile
echo "" >> $textfile
echo "--" >> $textfile
echo "Report generated at $date" >> $textfile

cat $textfile | msmtp --host smtp.mycompany.com $email -f me@mycompany.com

I know, the scripts aren't exactly top of the line but they do the job :)
Needless to say that you need to have your time correct on the syslog server if want to use the syslog data later.
 

Protecting your network against rogue DHCP servers

If you haven't done it yet you have a ticking bomb on your network. Possible "attackers" are: an unknowing user playing with "test" installation of some freeware software that bundles generously a DHCP server, a bug in a program (no offence to the developers, but I had this problem several times with VMWare which gave IP addresses in the "real" LAN in certain configurations) or even an attacker trying to bring down your network at least for a while or, worse, do a man-in-the-middle attack substituting the real default gateway with its own, eavesdropping on your traffic.

The Cisco solution to this is called DHCP snooping. This feature filters untrusted DHCP traffic and also builds a DHCP snooping binding table.

To use DHCP snooping on the Catalyst switch you must enable it globally:

ip dhcp snooping

To enable DHCP snooping on your VLANs:

ip dhcp snooping vlan number

From the DHCP snooping point of view there are 2 kinds of ports: trusted and untrusted. Trusted ports are the ones that should permit DHCP messages to pass. These are ports that are connected to legitimate DHCP servers and -very important - trunk ports, becouse they should carry DHCP traffic to DHCPD servers and clients. Untrusted ports are the rest of the ports, normal clients that act as DHCP clients.

Trusted ports should have:

ip dhcp snooping trust

Untrusted ports don't need any config option.

Additionally, you can configure a limit on the DHCP messages rate (per second) that can be sent on the port - usually untrusted ports. It's not recommended to configure a limit higher that 100 on untrusted ports:

ip dhcp snooping limit rate 100

To enable insertion of DHCP Option 82:

ip dhcp snooping information option

A common caveat in configuring DHCP snooping is the situation when you have multiple VLANs and one DHCP server and you use ip helper-address. To pass trusted DHCP messages you must configure on the routed interface (e.g. VLAN interface):

ip dhcp relay information trusted

To see the DHCP snooping binding table (the connection between MAC addresses, IPs, lease time and port) you can issue:

sh ip dhcp snooping binding

Another security use for DHCP snooping (if it's activated) is to do Dynamic ARP Inspection which is using the DHCP snooping binding table to discard ARP packets with invalid IP to MAC bindings in an attempt to stop man-in-the-middle attacks.
 

Using ASA/PIX with policy NAT to map an inside host

Possible scenarios when using policy NAT would be:

  • a LAN has private IP addresses that connect to the Internet using NAT overload; one host from this LAN needs to be accessed from outside with a public IP address only from certain hosts
  • a branch of an organization has a testbed with IP addresses that are routed only in the local network. In order to give access from other hosts in the intranet to a host in the testbed a PIX/ASA firewall is used to map the private IP address of the testbed host to a enterprise-wide routed IP that will be accessed only from authorised IPs.
We'll be tackling the latter situation. Here's the network diagram of our example:




Networks behind R are: a enterprise-routed VLAN (10.100.1.0/24) and a testbed VLAN (192.168.0.0/24) which only has static routes on R and FW. The desire is that host H2 could be accessed from the outside of the FW, only from 10.200.1.2. The IP address that will be mapped on the FW should be from the 10.100.1.0/24 subnet.
This can be accomplished using policy NATting on the FW firewall. In order to do this we need to create an ACL that will filter only specified IP pairs that will trigger NAT. The translation policy should look like this:

access-list acl_name permit ip real_ip real_mask foreign_ip foreign_mask

To keep the ACL manageable we'll use on object-group that contains the foreign_ip:

object-group network mapping
description List of IPs that can do policy NAT
network-object host 10.200.1.2

The ACL in our case is:

access-list policynat extended permit ip host 192.168.0.2 object-group mapping

Finally, to do the mapping we'll use a static translation:

static (inside,outside) 10.100.1.3 access-list policynat

10.100.1.3 is the mapped IP address. To test the configuration ping 10.100.1.3 from 10.200.1.2. The result is that FW will translate 10.100.1.3 to 192.168.0.2 which takes the route through R and then H2.
To troubleshoot:

ciscoasa# sh nat

NAT policies on Interface inside:
match ip inside host 192.168.0.2 outside host 10.200.1.2
static translation to 10.100.1.3
translate_hits = 10, untranslate_hits = 3

untranslate_hits are traffic from IPs other than 10.200.1.2.
  

Follow by Email

Sponsored Links

Labels