Tuesday, November 4, 2014

Physical Security with Kiwi Syslog Server and Cisco Router/Switch syslogging

This is something I've been working on the last few weeks.  We've run Kiwi Syslog Server forever, but have never done anything with it other than collect logs. I decided to try and implement some physical security measures using the reporting functionality of Kiwi Syslog Server.

Statements in bold are specific Cisco commands.  I'm not going to give away the farm, but I can direct you towards what I use.

I'm not going to say this is the best way to do this.  I just saying this is what I've done.

First assumption: you already have syslogging turned on and working.

Good.  Got that done?  It can be troublesome, but skipping past that.

Second, you ought to have some sort of scheme as to how you have everything plugged into your routers and switches.  Let's hope you already have that.

That 65 hour project done?  Good.  Moving on.

The purpose of having the first two things done is so you can limit the length of the exclusion list on your Syslog Server.   There are always some oddballs, but those can be accounted for without too many exclusions in the list.

I hope you also have hostnames that identify the device decently.  That makes writing the catch statements easier.  I call them catch statements, but really that is inaccurate.  They are text based filters.

What I've learned about writing these filters is you need to be simplistic in filter design.  You can have up to 100 different filters per action, so don't try and filter a complex statement in one filter.  Use multiples.  For example, I have one filter built that limits to switch traffic.  Should I need to write anything else that is based solely on switches, I can then copy that one filter and know I'm now working only on switches.

For physical security on switches, any unused port is in a shutdown state.  All other ports use MAC address sticky.  Because they use MAC address sticky, I alert on any time there is a port-security violation. So within two minutes of plugging in a cable to the switch, I'm aware.

For routers, I'm aware of what ports should be used.  I then monitor all router ports for up/down states.  So, should you plug into a router, the syslog will see the port status change and alert.  That can then be correlated with DVRs in the store to identify who plugged in, and with the port status down message, you get an indication of how long the person was plugged in.

The other option is to have the router ports shutdown as well.   Depending on the day, I can lean either direction.  

If you are going to leave the ports on, you need to be physically blocking them off with a tamper sticker.  I'd almost say use a tamper sticker anyways.

As for all the other port up/down messages, I would run those though whatever network analytic software you use.

I'm sure there are better ways to do physical security.  Locked rooms, locked doors, and cages come to mind.  But operationally, that's not always possible.   So you have to work with what you've got.  And despite being critical to operation, people who build buildings generally don't want to dedicate an entire lockable room to things that aren't sold out the front door.

No comments:

Post a Comment