Archive for January 2009

Filtering Out the Noise on the Edge

There’s a lot of noise on the Internet.  I’m not talking about certain news sites, either; I’m talking about stuff like port scans or attempts on weak services from all sorts of bad people on the Internet.  A large chunk of that noise can be filtered by the edge routers, taking some of the load off of the network and firewalls.

Here are a few things that we filter inbound on our Internet links.  Your mileage will vary.

  • Packets from RFC 1918 space — You should never see a packet from 10/8, 172.16/12, or 192.168/16.
  • Packets from your IP space — Why would you receive packets from yourself from the Internet?
  • SSH, telnet, cmd, rlogin, RDP, etc. –  You should be doing all your admin stuff from the internal network or from a VPN, right?
  • Windows ports — For God’s sake, drop these at the edge.
  • Packets to your network services subnets — If you use public addresses for things like your FWSM or CSM sync networks, no one should ever talk to those subnets.
  • SNMP, SNMPTrap — No monitoring from the Internet!
  • SMTP to non-MX hosts — If you have a lot of hosts, you probably have email run amongst them.  Only the MX hosts should accept connections from the Internet.
  • TCP/UDP small services — whois, finger, chargen, etc., are just waiting to be used for something bad.
  • DNS, RNDC — You may have some name caching servers or hidden masters somewhere that shouldn’t be reachable from the Desolate Plains of the Internet™.
  • Syslog — No logging from the Internet.  Use a VPN tunnel or something if you really need it.
  • NTP — You’re not a time service, are you?

That should cut out a significant amont of noise for you.  Remember to allow stuff, too.  You may want to end your ACLs with an old-fashioned permit ip any any log to see what else is coming through and maybe block some of that noise, too.

A Better (?) Way to Handle Logs

Happy new year, all.  I’m finally over my hangover from the party and ready to blog.

Everywhere I go, I always wind up in a debate about how to alert on log messages as they come in.  I was at the grocery store yesterday, and the cashier told me that she had a list of log messages that she watched for, and, if she saw one of them, she sent an email.  I asked her what she would do if she got a log message that she had never seen before, and she said that she would have to find it first, then research the message and put in an alert for the next time it showed up.

This is probably a decent method for most setups, but what if that one message was that someone was DOSing your Internet router or that your firewalls were all at 100% CPU?  My preferred logging method (and others’) is to send an alert on every message and, if I don’t really care about it, to filter it out for the next time.  Now, when I see a message that hasn’t come in before, I know that something has happened instead of finding the message after all my routers have died.

The big disadvantage to using this method, though, is the noise you’ll get at first.  If there are no filters on the messages, you’ll see denies from your firewalls, port up/down from your switches, and a whole bunch of other messages that you get 4849278 times a day.  If your network is large enough, you may get so many that you fill up your syslog server.  That sucks, but it’s it’s the price you pay for being able to know when something unknown is happening.  As the alerts DB matures, you usually only see stuff that doesn’t come up very often — like when a power supply dies or someone is attacking your web server.

Just some food for thought.

Video — History of the Internet

Here’s a short but nifty video I found on the history of the Internet.  We all say “DARPA” or “ARPANET”, but I had no idea that the French developed the router first.


History of the Internet from PICOL on Vimeo.

Leap Second

Did anyone notice (or care about) the leap second?  I did neither.  Here’s some cool output from Kevin Oberman on the NANOG list, though.

bash-2.05b# date
Thu Jan  1 00:59:58 CET 2009
bash-2.05b# date
Thu Jan  1 00:59:59 CET 2009
bash-2.05b# date
Thu Jan  1 00:59:60 CET 2009
bash-2.05b# date
Thu Jan  1 01:00:00 CET 2009
bash-2.05b# date
Thu Jan  1 01:00:01 CET 2009
bash-2.05b#