I don't agree with the focus on the perpetrator, rather than the system itself. I could write some baseless conjecture about the number of naive legacy systems still in use... so I will.
There are probably a modest number of them, in various states of repair. My guess is that the better made ones might make news because they will live on longer than their buggier and already failing brethren. Generally though, I don't think it's a cause for concern. As said, they're well made and will have failsafe measures in place that will prevent anything from becoming too catastrophic, which isn't to say that no one would ever die, but that I wouldn't expect and really tragic instances.
The important thing is to get it right next time, and not overlook the simpler options when implementing them. Copper wire and serial data still works as well as it ever did...
Friday, January 11, 2008
Sunday, January 6, 2008
Upcoming Stuff
Hopefully within the next two weeks you'll see:
- a review of The Definitive Guide to Django (which I gifted myself for Christmas)
- a rundown of some work I'm doing driving Quartz Composer animations using python, OSC, JSON objects and all the goodies in between
- compelling reasons I might be picking up ObjectiveC and diving headlong into the Cocoa API
- Offensive to some, but a meaty rant by Zed Shaw here about Rails that's at least entertaining. I've been pointing to it for friends interested in getting into Rails, not so much that they avoid it, only that they go in a little more well informed. I've heard Zed on the Rails Podcast and I think he's a pretty smart guy.
- Caught the Dresden Dolls last night here in Chicago. Not my meat and potatoes sort of music, but an extremely entertaining show. Brian Vignioli is a total rock star. Show was totally sold out and they played "Fight For Your Right" as an encore.
rumination (a.k.a. wanking) then neighbor scanning
Where has I been? Same place, just varying combinations of too busy to think and nothing worthwhile to say, and one of my goals when I started this blog was to keep the signal:noise ratio from going to pieces without becoming an echo chamber.
Most interesting work I've done lately? I'd been tying more and more network management data together using splunk. At the moment, some of the most interesting applications of this data has been a dynamically generated network map built from logged CDP neighbor data using graphviz. Very cool stuff, but it still needs a few tweaks. At the moment, I've got a few problems that need ironing out. First one is that the native IP of the switch is not always the IP that other switches see presented via CDP, so we get two switches with the same name but different IP's and goofy looking interconnections on the graph. Bah. I'd originally wanted to key off of both the name and ip of the switch in order to hash out a few misfits on the network (other people's switches that aren't trunked but have ip's and are named 'switch' etc). The workaround is to make 'Switch' a special case and otherwise key solely off the name of the switch, and then weed out the misfits who are sharing a name (since that's outside of policy).
Working on standardizing the naming scheme of the switches into a ORG_BLDG_LOCATION_MODEL_ID format, which will let us do things like search for "switchname=DOA_GARG" and find all switches we've got in the garage. Couple that with being able to search through the configs on a line by line basis and we've got some pretty powerful auditing tools coming into place. I still need to work out how to specify a unique key for the results such that we only get the most recent results per interface / switch combo and no stale ones. I've also got some tuning on the neighbor scanning tool to do so that we handle unavailable switches more reasonably. Some of our wireless links are less reliable than others and if a switch doesn't respond, we mark all of that switches cdp links as down. This causes some flapping and I think the answer is to use another data source we created that monitors the network with broadcast arps over all the logical subnets we administer. If a switch's IP hasn't responded to an arp WHO-HAS? packet for an hour, then we can say it's definitely unavailable. The flipside is that it means we can't use the CDP scanner reliably for alerting. Interesting problems though.
Most interesting work I've done lately? I'd been tying more and more network management data together using splunk. At the moment, some of the most interesting applications of this data has been a dynamically generated network map built from logged CDP neighbor data using graphviz. Very cool stuff, but it still needs a few tweaks. At the moment, I've got a few problems that need ironing out. First one is that the native IP of the switch is not always the IP that other switches see presented via CDP, so we get two switches with the same name but different IP's and goofy looking interconnections on the graph. Bah. I'd originally wanted to key off of both the name and ip of the switch in order to hash out a few misfits on the network (other people's switches that aren't trunked but have ip's and are named 'switch' etc). The workaround is to make 'Switch' a special case and otherwise key solely off the name of the switch, and then weed out the misfits who are sharing a name (since that's outside of policy).
Working on standardizing the naming scheme of the switches into a ORG_BLDG_LOCATION_MODEL_ID format, which will let us do things like search for "switchname=DOA_GARG" and find all switches we've got in the garage. Couple that with being able to search through the configs on a line by line basis and we've got some pretty powerful auditing tools coming into place. I still need to work out how to specify a unique key for the results such that we only get the most recent results per interface / switch combo and no stale ones. I've also got some tuning on the neighbor scanning tool to do so that we handle unavailable switches more reasonably. Some of our wireless links are less reliable than others and if a switch doesn't respond, we mark all of that switches cdp links as down. This causes some flapping and I think the answer is to use another data source we created that monitors the network with broadcast arps over all the logical subnets we administer. If a switch's IP hasn't responded to an arp WHO-HAS? packet for an hour, then we can say it's definitely unavailable. The flipside is that it means we can't use the CDP scanner reliably for alerting. Interesting problems though.
Wednesday, October 24, 2007
Creating Automated Tools for Network Management
So, being a contractor has good things about it, and bad things about it. The bad things are that occasionally you have a hard time getting some tools that you need.
One of the great boons I've had is finding Splunk, since it will continue working for me until I can get someone to pay for it. What I love about it is that I can use it as an ad-hoc database, shooting tons of field=value pairs into it that are mapped together as an event. The latest thing I've done is designed a way to store Cisco switch configurations in the database and track changes over time, then set a co-worker on the task of getting it done. We're basically trawling the configs, creating a hash of their content, and storing them on a line by line basis with a line number and storing the line under which nested configuration directives are stored. Using a really simple CRC32 hash we can identify each config separately (since the unique information about the switch like ip and name is stored in the config itself, they are necessarily unique). We can pull the most recent hash from the database and compare it to the one we just generated, if it's new, we can store the new config under the new hash. Great so far.
What we end up with are lines like this:
ip="0.0.0.0" hash="-qQfjZe" name="BLDG4_2960_MDF" context="interface FastEthernet0/8" content=" spanning-tree portfast" lineno="45"
Since these are all available for searching, we can do things like search for "switch mode trunk" and see all of the trunk ports. I've got to see if there's a way I can restrict splunk to only display the most recent status of a switch, so that I don't have stale config information cluttering up newer more relevant stuff, but it's still a really great step forward to being able to track what we're doing on our gear.
One of the great boons I've had is finding Splunk, since it will continue working for me until I can get someone to pay for it. What I love about it is that I can use it as an ad-hoc database, shooting tons of field=value pairs into it that are mapped together as an event. The latest thing I've done is designed a way to store Cisco switch configurations in the database and track changes over time, then set a co-worker on the task of getting it done. We're basically trawling the configs, creating a hash of their content, and storing them on a line by line basis with a line number and storing the line under which nested configuration directives are stored. Using a really simple CRC32 hash we can identify each config separately (since the unique information about the switch like ip and name is stored in the config itself, they are necessarily unique). We can pull the most recent hash from the database and compare it to the one we just generated, if it's new, we can store the new config under the new hash. Great so far.
What we end up with are lines like this:
ip="0.0.0.0" hash="-qQfjZe" name="BLDG4_2960_MDF" context="interface FastEthernet0/8" content=" spanning-tree portfast" lineno="45"
Since these are all available for searching, we can do things like search for "switch mode trunk" and see all of the trunk ports. I've got to see if there's a way I can restrict splunk to only display the most recent status of a switch, so that I don't have stale config information cluttering up newer more relevant stuff, but it's still a really great step forward to being able to track what we're doing on our gear.
whrrl, captcha idea
Someone from school who I thought really highly of (translation: had a huge crush on) launched a new social networking site yesterday. It's called whrrl, and the basic pitch is that it's a more impulsive Yelp with two twists. First, its interface is mapped out onto a google map of the area, and you can restrict ratings and listings to a group of people you know, so that the results are more personally reliable. The trust network situation is actually a really good idea, since it helps to defeat the professional social networking plants that have started seeping into some of the other bases of this information. The second is that it has a dedicated mobile interface that adapts to the model of phone you have, or so I'm told, because my ancient i730 has about as much web savvy as my grandma.
The other neat thing is that its taken a page from twitter in that there's a nice, full featured SMS interface. I haven't played with it a bunch, but one of the things you can do via the web interface is "check in" to locations, sort of like manual GPS. I imagine this would be great for a group of barhopping friends trying to keep track of each-other, but I don't see how it doesn't avoid the usual "OMG WRU" "RT HERE" "I DUN SEE U" "IM LKING RT @ U" "NT HELPING" the same way that a real GPS solution might. It looks promising even if I'm not in the market for it. Perhaps the best thing about it is that its an evolutionary offspring of the social networking world, not necessarily revolutionary. The only problem at the moment is that it's Yet Another Site to try and get people you know onto so its useful, which I think most people have just finally gotten grandma onto Facebook so she can see their photo albums there. The good news on that end is that grandma will never use this - the demographic is purely younger, more technically minded people who are out and about and have their web enabled phones with them. The one feature that would probably help get the site moving is integration with existing networks like Facebook (API is there, no reason not to). I think that will be a major obstacle to a lot of new sites, including this one. It does have the crazy "give us your e-mail credentials and we'll let you choose people to invite" feature, not that I think that's a good trend to follow.
To get to the point - try it out. It's got promise and a solid feature set on its side. If you have a lot of friends on the web and can build social networks easily, I'd strongly recommend seeing what types of information you can cull from your flock.
The first complaint I had though was the registration captcha. It was really hard! I hate those things, there's got to be a better way to confirm that a human is at the helm than making them decode something that's INTENTIONALLY HARD TO DECODE. I had an idea this weekend about how to implement a decent test for human presence, using javascript to detect and transmit individual key-presses back to the server, where they could be composed. The only problem is that anything that is automated in the browser ends up being accessible via javascript, and since a lot of the automated attacks on sites can be effective on small scales, creating elaborate rigs to get into them is worth the time. What I think though is that there ought to be some kind of combination of javascript checks that make up a more holistic picture of what a real human browsing the web looks like, except that getting enough information to do that well breaches a lot of privacy issues. Even then, we're only entering into an arms race similar to the cracker / hash length race. So what's the solution? I'm not sure yet.
The other neat thing is that its taken a page from twitter in that there's a nice, full featured SMS interface. I haven't played with it a bunch, but one of the things you can do via the web interface is "check in" to locations, sort of like manual GPS. I imagine this would be great for a group of barhopping friends trying to keep track of each-other, but I don't see how it doesn't avoid the usual "OMG WRU" "RT HERE" "I DUN SEE U" "IM LKING RT @ U" "NT HELPING" the same way that a real GPS solution might. It looks promising even if I'm not in the market for it. Perhaps the best thing about it is that its an evolutionary offspring of the social networking world, not necessarily revolutionary. The only problem at the moment is that it's Yet Another Site to try and get people you know onto so its useful, which I think most people have just finally gotten grandma onto Facebook so she can see their photo albums there. The good news on that end is that grandma will never use this - the demographic is purely younger, more technically minded people who are out and about and have their web enabled phones with them. The one feature that would probably help get the site moving is integration with existing networks like Facebook (API is there, no reason not to). I think that will be a major obstacle to a lot of new sites, including this one. It does have the crazy "give us your e-mail credentials and we'll let you choose people to invite" feature, not that I think that's a good trend to follow.
To get to the point - try it out. It's got promise and a solid feature set on its side. If you have a lot of friends on the web and can build social networks easily, I'd strongly recommend seeing what types of information you can cull from your flock.
The first complaint I had though was the registration captcha. It was really hard! I hate those things, there's got to be a better way to confirm that a human is at the helm than making them decode something that's INTENTIONALLY HARD TO DECODE. I had an idea this weekend about how to implement a decent test for human presence, using javascript to detect and transmit individual key-presses back to the server, where they could be composed. The only problem is that anything that is automated in the browser ends up being accessible via javascript, and since a lot of the automated attacks on sites can be effective on small scales, creating elaborate rigs to get into them is worth the time. What I think though is that there ought to be some kind of combination of javascript checks that make up a more holistic picture of what a real human browsing the web looks like, except that getting enough information to do that well breaches a lot of privacy issues. Even then, we're only entering into an arms race similar to the cracker / hash length race. So what's the solution? I'm not sure yet.
Thursday, October 18, 2007
Monday, July 23, 2007
Good thoughts on targetted attacks, black list vs. white list, etc
Link above to a comment on Mr. Schneier's blog.
Whitelists are great until you whitelist someone who becomes compromised, just like blacklists are great until they're incomplete (read: always). Data backups are great until malware starts staying dormant longer. There are caveats to just about everything, the trick is creating a deeper, graduated stack, just like all physical filtration systems. You use a variety of different screens and filtering media to catch all the different types of particles you want removed, and then use checks on the output side to ensure that the resultant material is what you desired.
The one thing I'd like to rail against though is the adherance to high contrast filtration - there is a lot of traffic we can call unconditionally good - things we generate or identify as entering controlled systems that we've already shored up - XMLRPC traffic from a web app hitting a back end server, for instance. There's unconditionally bad traffic - shell login attempts from a host that's made 30 login attempts already within the past half hour, for instance. But then there's all the traffic that's neither good nor bad, but somewhere in between. We can't say whether the whole thing is good or bad, but with the right setup we can make decisions about some of it. We can say it's allright within these contexts - to these hosts, on these networks, etc. We can choose to let some of it through, make only simple decisions about where it can and can't go. Strip out parts of the packet, limit its size, filter out certain known-bad portions that might be innocuous in many situations, but we know can be bad in a few others. We can use score based rules to decide what access to provide to certain traffic - traffic that's got three strikes against it isn't allowed through this firewall, but up to two strikes still gets by.
Sometimes I don't want the girl to say yes or no, I'd prefer a maybe.
Whitelists are great until you whitelist someone who becomes compromised, just like blacklists are great until they're incomplete (read: always). Data backups are great until malware starts staying dormant longer. There are caveats to just about everything, the trick is creating a deeper, graduated stack, just like all physical filtration systems. You use a variety of different screens and filtering media to catch all the different types of particles you want removed, and then use checks on the output side to ensure that the resultant material is what you desired.
The one thing I'd like to rail against though is the adherance to high contrast filtration - there is a lot of traffic we can call unconditionally good - things we generate or identify as entering controlled systems that we've already shored up - XMLRPC traffic from a web app hitting a back end server, for instance. There's unconditionally bad traffic - shell login attempts from a host that's made 30 login attempts already within the past half hour, for instance. But then there's all the traffic that's neither good nor bad, but somewhere in between. We can't say whether the whole thing is good or bad, but with the right setup we can make decisions about some of it. We can say it's allright within these contexts - to these hosts, on these networks, etc. We can choose to let some of it through, make only simple decisions about where it can and can't go. Strip out parts of the packet, limit its size, filter out certain known-bad portions that might be innocuous in many situations, but we know can be bad in a few others. We can use score based rules to decide what access to provide to certain traffic - traffic that's got three strikes against it isn't allowed through this firewall, but up to two strikes still gets by.
Sometimes I don't want the girl to say yes or no, I'd prefer a maybe.
Subscribe to:
Posts (Atom)
