Showing posts with label tool. Show all posts
Showing posts with label tool. Show all posts

Monday, October 29, 2007

Update! New god conditions added to source repository!

Click the link to go to the god source repository - as of today, it looks like two of the three conditions I submitted for inclusion have now been added (the third being the mysql_failed condition, which may end up in some kind of auxillary gem or something, as previously mentioned...). So... look for these new conditions in god v0.6.0!

complex.rb

disk_usage.rb

Thursday, May 3, 2007

IPTables Firewall Map

Filter vs. Nat? (Chicken vs. Egg, movie at 11...)

A few years ago I had to setup a couple relatively complex firewalls (under Linux), and in the process managed to find some documentation on the order in which a packet traverses each table and it's rules.

Sounds pretty basic, however nothing in the documentation or man pages for iptables itself explains how the tables relate to one another; for example, a packet arriving at a machine which is destined for another machine will go through the FORWARD chain of both the filter and nat tables, but which table's FORWARD chain will be examined first? A fairly significant question, since each chain can and likely will have vastly different rules which may affect the packet, and the order these rules are applied in will likely also affect the outcome in most cases...

Perl to the rescue!

And so, I created iptables-map.

Like most of us who have worn a sysadmin hat at one point or another, Perl often ends up as my Swiss Army Knife of choice. Something else may have been faster/simpler/more elegant/whatever, but I suppose at the time I must have been doing a lot of work in Perl and so it was a natural first choice... plus it's always awesome for anything where heavy string manipulation and/or regular expressions are involved, and so when I was starting it I probably would have assumed that there would be more of that kind of thing involved, although it ended up pretty basic...

A Sample of the Sweetness

SENT Packets
mangle::OUTPUT >>> ACCEPT
nat::OUTPUT >>> ACCEPT
filter::OUTPUT >>> DROP
-A OUTPUT -o lo >>> ACCEPT
-A OUTPUT -s 10.10.10.10 -d 11.11.11.11 -o eth0 -p tcp -m tcp --dport 22 >>> ACCEPT
-A OUTPUT -s 12.12.12.12 -d 13.13.13.13 -o eth0 -p tcp -m tcp --dport 22 >>> ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --dport 22 >>> DROP
-A OUTPUT -s 14.14.14.14 -o eth0 >>> ACCEPT
mangle::POSTROUTING >>> ACCEPT
nat::POSTROUTING >>> ACCEPT

This is a snippet of an imaginary firewall which is restricting outgoing ssh connections. We're looking at the portion of the iptables-map output which is displaying the firewall path for packets originating from the local host ("SENT Packets"). The order in which the tables are listed (along with their default targets) is the order in which a packet will traverse them: OUTPUT chain of the mangle table first, then of the nat table, then of the filter table, then the POSTROUTING chain of the mangle table, and lastly the POSTROUTING chain of the nat table.

Pretty obvious in this output, however not at all obvious nor intuitive when all you have to work with are man pages and packaged iptables documentation.

The rest of the output is clearly showing you the specifics for each rule in each chain, and is naturally listing these rules in the order in which they're traversed/examined.

The Laundry List

In resurrecting this script for SourceForge, I've noticed that there's a new table ('raw') which is now part of a default iptables install, and ip6tables is also ready for prime time. I'll be adding support for both of these in the very near future. As an aside, if you'd like to request a version of this script in a different language, ie: as a bash or awk script or perhaps even C source for a binary, please email me and let me know!

IPTables-Map

Thursday, April 19, 2007

Gmail and GreaseMonkey

So I finally got around to playing with GreaseMonkey... and I regret not doing it sooner, there's so much I could have done already!

If you're not familiar, GreaseMonkey is a Firefox plugin that lets you add your own/custom javascript code to websites. And it's dead simple - based on a handful of specially formatted comments and a file-naming convention, your javascript becomes custom code you can use to modify any site you want.

I used it to write a scripts for Gmail - when I switched over recently from mutt and pine (I know, to all you text-purists out there: I'm sorry, but I couldn't help it...) I lost the ability to use my nifty cron-based signature auto-rotater. I had written this dead-simple script a while ago to rotate my signature file names every 5 minutes, so essentially every time I sent an email I'd have a different/random sig. Not too useful for business communication, but great for my personal box.

Anyways, Gmail obviously doesn't do this by default, but I managed to get it working with a little bit of custom javascript code via GreaseMonkey in VERY little time... even considering the nasty size (depth) of Gmail's html tree (navigating this with the DOM inspector actually took more time than creating the script).

I'll post a link/the source once I've polished it - at the moment I just have a couple signatures hard-coded in that it chooses from, but I'll add a basic interface for managing signatures as well as post it to userscripts.org and/or SourceForge shortly...

Command-Line Highlighter

I was grepping through some logs the other day at home and I figured "wouldn't it be nice if I could pipe this through something that would highlight lines matching a regex instead of just having grep pull those lines out?" Wouldn't you know it, such a tool doesn't exist, as far as I can tell. Which is very weird, since I've already found it VERY useful...

grep *will* give you context lines if you ask for them explicitly, ie: give me 2 lines before and 4 after the matching line, but I wanted to see ALL the output, with the matches highlighted for easy-spotting.

Anyways, I wrote a little perl script to do the work - it just inserts 'standard' shell color-escape sequences before and after the matching word/line to highlight it (in bright-green-on-black by default... if you're a Matrix fan/l33t hax0r and use a green-on-black setup anyways, there's an option that lets you change the highlighting colors.

It's fairly basic at the moment, but I plan on porting this to C as soon as I have time (possibly tonight) now that it's up on SourceForge, and modify it a bit so that the options/usage syntax matches grep wherever possible/appropriate.

HighLite