Hosts Subnets Monitor (HSM): get notified when hosts’ subnets change


In the recent past I have been tasked to block traffic from a LAN segment toward some public websites by blackholing their subnets.

While this approach may be not fully convincing, it is easy to implement and with few impacts on the infrastructure. The real problem is the management overhead it introduces, since websites may change the IP subnet they are run on.

How does it work?

In order to ease this task I wrote a little script which, given a hosts list, resolves IP addresses and gets the most specific subnet they fall on. Public whois databases are used to acquire subnet information: RIPE RIS, TeamCymru IP to ASN Mapping, RIRs databases. Some of them (RIPE RIS and TeamCymru IP-to-ASN) are based on BGP feeds collected around the world, others (RIRs databases) are based on LIRs allocations and assignments; the configuration section of the script allows to set which databases have to be used and how.

Requirements

The script is written in Linux Bash and uses some basic programs and an optional (but really recommended) Perl addition (implemented in the hsm-utils.pl file).

The programs used by the script are dig (to resolve hostnames in IP addresses), whois (the improved Whois client by Marco D’Itri, to get data from whois databases) and sendmail, alias of exim4 (to send email notifications when subnets change).

The hsm-utils.pl script needs the NetAddr::IP::Lite module, which can be installed using the CPAN installer:

LINUX:~#perl -MCPAN -e shell
cpan>install NetAddr::IP::Lite

How to use it

To be used it just needs the “hosts” file in the working directory (/var/local/hsm by default) containing a list of hosts to be monitored:

LINUX:/var/local/hsm#cat hosts
www.facebook.com
www.blogspot.com
www.youtube.com
www.twitter.com

In order to receive email notifications the EMAIL_TO parameter has to be set with a working email address.

The script

Following is an excerpt from the script, I suggest you to read it since it contains some (I think) useful notes and configuration options; in the bottom of this post you may find the link to download it.

##################################################################################
# HOW DOES IT WORK?
# --------------------------------------------------------------------------------
#
# Everything is done in the DATA_DIR directory (default to /var/local/hsm); HSM
# reads a list of hosts to monitor from the 'hosts' file and, for each of them, it
# resolves the IP address and gets its subnet.
#
# In order to identify the subnet, it queries public databases using the whois
# client: it may be configured to use the following sources (see CONFIGURATION):
#
# - RIPE RIS database: http://www.ripe.net/ris/
# - TeamCymru IP to ASN Mapping: http://www.team-cymru.org/Services/ip-to-asn.html
# - general RIRs databases
#
# Subnets are stored in the 'subnets' file; at the end of the execution, if there
# are new subnets HSM notifies them in the output. It also notifies expired
# subnets, that is subnets appeared in the past which seem to be not binded to
# hosts anymore.
#
# Output is written to the 'output' file; you may let HSM to send the output by
# email too.
#
# The script may be scheduled to be run periodically through the crontab file.

##################################################################################
# REQUIREMENTS AND DEPENDENCIES
# --------------------------------------------------------------------------------
#
# dig           Used to resolve hostnames
#
# whois         I used the improved Whois client by Marco D'Itri:
#               http://www.linux.it/~md/software/
#
# sendmail      Used as alias of exim4; optional, only if EMAIL_TO is set
#
# awk, grep,    Some basic utilities
# tail, sed
#
# Highly Recommended:
#
# Perl with NetAddr::IP::Lite module, in order to execute the hsm-utils.pl script.
# Please see CHANGE LOG & KNOWN ISSUES and USEHSMUTILS in the CONFIGURATION
# section for more details about it.
#
# Developed and tested under Debian GNU/Linux 4.0 (Etch).

##################################################################################
# CHANGE LOG & KNOWN ISSUES
# --------------------------------------------------------------------------------
#
# Date          Ver.    Note
# 2010-11-15    0.1     First release
#
# If you configure HSM to not use the hsm-utils.pl script (see CONFIGURATION for
# more details) you have to consider the following issues:
#
# - subnets are stored as they appear on the whois output; that is
# "192.168.0.0/24" is different from "192.168.0.0 - 192.168.0.255". This may lead
# to a wrong behaviour when the same IP address is queried against a whois
# database which returns information in a format different from the previous one.
#
# - when GENERAL whois is used, or when GETLONGESTMATCH = 1, there are no
# guarantees that the more specific subnet is choosen among those returned.

##################################################################################
# CONFIGURATION
# --------------------------------------------------------------------------------

# USEHSMUTILS
# ------------------------------------
# If USEHSMUTILS = 1 then HSM uses the hsm-utils.pl file.
# It is a Perl script which implements some functions
# performing subnets normalization and selection. It is
# needed to solve some issues reported in the CHANGE LOG
# & KNOWN ISSUES section. If you can't run a Perl script
# or you prefer to avoid it you may set USEHSMUTILS to 0.

USEHSMUTILS=1
HSMUTILSPATH=`dirname $0`/hsm-utils.pl

# DATA_DIR
# ------------------------------------
# Where files are stored:
# - the file containing the input hosts list ('hosts')
# - one file for each IP address resolved by hostnames
# - the subnets file ('subnets'), where subnets information are stored
# - the output file ('output')
# - temporary files
# No trailing slash.

DATA_DIR=/var/local/hsm

# USECACHE and CACHE_TIME
# ------------------------------------
# If USECACHE = 1 then IP addresses resolved by hostnames
# are checked against whois databases only if they were
# checked before CACHE_TIME days ago.

USECACHE=1
CACHE_TIME=3

# DNS_QUERIES
# ------------------------------------
# HSM sends this number of DNS queries in order to resolve
# hostnames IP addresses. It may be useful to discover IP
# address of hostnames with round-robin records.

DNS_QUERIES=3

# SUBNET_EXPIRY
# ------------------------------------
# When a subnet is not seen for more than SUBNET_EXPIRY days
# it is removed from the subnets file and a notification
# is written in the output.

SUBNET_EXPIRY=15

# WHOIS_LIST and GETLONGESTMATCH
# ------------------------------------
# WHOIS_LIST contains a list of sources to be used to get
# subnets information from IP addresses.
# The following sources are allowed:
# TEAMCYMRU, RIPERIS, GENERAL.
# Sources are used in the order they appear in the list.
# If GETLONGESTMATCH = 0, as soon as HSM succeds to obtain
# the subnet it stops searching.
# If a source is not working properly it uses the next one.
# If GETLONGESTMATCH = 1 HSM grabs results from all the
# listed sources, then uses the most specific one.

WHOIS_LIST="RIPERIS TEAMCYMRU GENERAL"
GETLONGESTMATCH=1

# EMAIL
# ------------------------------------
# Set EMAIL_TO with your email address if you want the output
# to be sent by email. The other parameters are optional.

EMAIL_TO=
EMAIL_FROM=
EMAIL_SUBJECT=

Download and installation

Here you can download the scriptLicensed under the terms of the GNU General Public License.

To run it:

LINUX:/usr/local/bin#tar -xf hsm.tar # extract it
LINUX:/usr/local/bin#nano hsm # do your configuration
LINUX:/usr/local/bin#nano /var/local/hsm/hosts # edit hosts you want to monitor
LINUX:/usr/local/bin#./hsm # run it

You may also schedule it using crontab:

LINUX:/usr/local/bin#cat /etc/crontab
# /etc/crontab: system-wide crontab

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
53 22   * * *   root    /usr/local/bin/hsm
#

Any feedback, comment or suggestion is appreciated! 🙂

Automatically filtering bogons with BGP and Team Cymru Bogon Route Server Project


ThiefWhat do you do if someone knocks at your door, you see him through the peephole, and you notice he has a black cowl, a crowbar and a big bag? I’m quite sure: you do not open that door! Why? Because, sometimes, the gown does make the friar! And, actually, he’s really not a friar!

Same thing should happen in a network! If you know a packet is a bad packet, why should you let it go through?

In this (stupid) example bad packets are those coming from or going toward bogon IP addresses, that is, addresses picked up from unallocated or private (so, not routable) address spaces. As you know, there are many subnets used only for private addressing (RFC 1918), other are reserved (RFC 3330), and few subnets are still not allocated by IANA… so, if your router is sending or receiving a packet to/from one of these addresses, there is something you should be concerned about (of course, some restrictions may apply!)

How to identify bogons

In order to identify and catch bogon packets we need to know which subnets have to be marked as bogon.

One way to achieve this goal is to deploy static ACLs or route filters on every router we want to secure… a quite boring job on its own! But, what happens when IANA allocate one of the previously unallocated (so, bogon) subnets? Well, we have to change those ACLs on every router! This is a very boring job! Someone at RIPE knows that well!

Do you really want this?

Fortunately, we can use a great utility by Team Cymru: Bogon Route Server Project.

What is Bogon Route Server Project?

For the sake of our sanity, Team Cymru deployed some route servers running BGP which announce bogon prefixes over eBGP peering sessions. Once we have a BGP-aware box, we can get those prefixes and do what we want of them.

Here, I’ll show how to automatically handle bogon prefixes using a Linux box running Quagga, a routing software suite providing implementation of BGP.

What can we do with bogon prefixes?

From our central Quagga box we can distribute those prefixes to our routers, or to customers CPEs, and here we can filter traffic on the basis of source or destination addresses.

For example, we can avoid to route packets with a bogon destination address, simply by adding a route toward bogon prefixes with a null-pointing next-hop; it’s a kind of blackhole filtering:

ip route 192.0.2.1 255.255.255.255 Null0
ip route 1.0.0.0 255.0.0.0 192.0.2.1

With Cymru Bogon Route Server Project we can do this job in a fully automatic and central way.

Of course, we can also drop incoming packets presenting bogon source IP addresses; we can accomplish this using uRPF in a kind of source-based black hole filtering:

interface Serial1/0
 ip verify unicast source reachable-via any

Anyway, you, and only you know what’s better for your network!

Now, I would like to show you how to setup a Linux box running Quagga, with a peer session with Cymru routers, and how to use it to distribute bogon prefixes to our routers.

Peering with Cymru Bogon Route Server

At first, we have to ask Team Cymru to setup a BGP session with our Quagga box: to do so we have to contact them on the basis of what we can find on their website. We have to tell them our AS number, our peering IP addresses and optional MD5 passwords and GPG/PGP public key.

You don’t need to have a public AS number, you can also peer with them using a private AS number.

Quagga: bgpd configuration

Once we have installed Quagga and received Cymru details, we just have to edit the bgpd.conf file and add a few lines.

Quagga bgpd.conf:

router bgp YOUR_AS_NUMBER
 bgp router-id YOUR_ROUTER_ID
 neighbor cymru-bogon peer-group
 neighbor cymru-bogon remote-as 65333
 neighbor cymru-bogon ebgp-multihop
 neighbor cymru-bogon prefix-list cymru-out out
 neighbor cymru-bogon route-map CYMRUBOGONS in
 neighbor cymru-bogon maximum-prefix 100

 neighbor CYMRU_PEER_1_IP peer-group cymru-bogon
 neighbor CYMRU_PEER_2_IP peer-group cymru-bogon
!
ip community-list 10 permit 65333:888
!
route-map CYMRUBOGONS permit 10
  match community 10
  set ip next-hop 192.0.2.1
!
ip prefix-list cymru-out seq 5 deny 0.0.0.0/0 le 32

Prefix-list prevents any update to leave our box toward Cymru routers; route-map allows marked prefixes and set their next-hop to 192.0.2.1, null-pointing route.

Automagically our Quagga box gets bogon prefixes:

QuaggaBox#show ip bgp
BGP table version is 0, local router ID is YOUR_ROUTER_ID
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*  1.0.0.0          192.0.2.1                0             0 65333 i
*>                  192.0.2.1                0             0 65333 i
*  5.0.0.0          192.0.2.1                0             0 65333 i
*>                  192.0.2.1                0             0 65333 i
[cut]
*  192.168.0.0/16   192.0.2.1                0             0 65333 i
*>                  192.0.2.1                0             0 65333 i
*  198.18.0.0/15    192.0.2.1                0             0 65333 i
*>                  192.0.2.1                0             0 65333 i
*  223.0.0.0/8      192.0.2.1                0             0 65333 i
*>                  192.0.2.1                0             0 65333 i

Total number of prefixes 32

Now, setup our Quagga box to bring up peering with your routers; just add few config lines to bgpd.conf:

router bgp YOUR_AS_NUMBER
 neighbor Clients peer-group
 neighbor Clients prefix-list DoNotAcceptAnything in
 neighbor Clients route-map CYMRUBOGONS out
 neighbor Clients ebgp-multihop
 neighbor Clients send-community

 neighbor YOUR_ROUTER1_IP remote-as YOUR_AS_NUMBER
 neighbor YOUR_ROUTER1_IP peer-group Clients

 neighbor YOUR_ROUTER2_IP remote-as YOUR_AS_NUMBER
 neighbor YOUR_ROUTER2_IP peer-group Clients
!
ip prefix-list DoNotAcceptAnything seq 5 deny 0.0.0.0/0 le 32

Routers configuration

We can deploy iBGP or eBGP configuration on our routers and automatically get bogon prefixes.

This is a sample configuration:

ip route 192.0.2.1 255.255.255.255 Null0
!
ip bgp-community new-format
!
router bgp YOUR_AS_NUMBER
 no synchronization
 bgp log-neighbor-changes
 neighbor YOUR_QUAGGA_BOX_IP remote-as YOUR_AS_NUMBER
 neighbor YOUR_QUAGGA_BOX_IP update-source Loopback0
 neighbor YOUR_QUAGGA_BOX_IP prefix-list DoNotAnnounceAnything out
 neighbor YOUR_QUAGGA_BOX_IP route-map CymruBogons in
 no auto-summary
!
ip community-list standard CymruBogons permit 65333:888
!
ip prefix-list DoNotAnnounceAnything seq 5 deny 0.0.0.0/0 le 32
!
route-map CymruBogons permit 10
 match community CymruBogons
 set ip next-hop 192.0.2.1

Tests

And now, let’s verify our job…

Router#show ip bgp
BGP table version is 163, local router ID is X.Y.Z.W
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>i1.0.0.0          192.0.2.1                0    100      0 65333 i
*>i5.0.0.0          192.0.2.1                0    100      0 65333 i
[cut]
*>i192.168.0.0/16   192.0.2.1                0    100      0 65333 i
*>i198.18.0.0/15    192.0.2.1                0    100      0 65333 i
*>i223.0.0.0/8      192.0.2.1                0    100      0 65333 i

BGP gets bogon prefixes from our Quagga box; let’s take a look at our routing table, with focus on 192.168.0.0:

Router#show ip route | i 192.168
O IA 192.168.4.0/24 [110/196] via 192.168.254.3, 5d05h, Tunnel1
O IA 192.168.5.0/24 [110/196] via 192.168.254.1, 5d05h, Tunnel0
[cut]
O IA 192.168.1.0/24 [110/196] via 192.168.254.1, 5d05h, Tunnel0
B    192.168.0.0/16 [200/0] via 192.0.2.1, 1d01h

Here we have some private prefixes from OSPF, used for branch offices, and they have the right paths; in the last line, the whole 192.168.0.0/16 goes toward the null-pointing route.
Remember: more specific route wins; until we have our private prefixes from OSPF no packets will be filtered out.

Router#sh ip cef 192.168.222.1
192.168.0.0/16, version 411, epoch 0
0 packets, 0 bytes
  via 192.0.2.1, 0 dependencies, recursive
    next hop 192.0.2.1, Null0 via 192.0.2.1/32
    valid null (drop) adjacency

Well done: it’s simple and it works fine! Anyway, remember to take precautions: do no send bogon prefixes to your BGP peers (no-export plus safeguard communities) and keep in mind every network is different from others!

References

Team Cymru: Bogon Route Server Project

Quagga: Quagga Software Routing Suite

Andree Toonk: Bong Traffic Analysis in 2006

Rob Thomas (on Team Cymru website): 60 Days of Basic Naughtiness, a study conducted in 2001.