I’m really learning to love the Sidewinder product line. Don’t get me wrong, it’s still got it’s foibles that make you go “Erm… OK”, but it is quite a clear step up from the Cyberguard Classic and the Secure Computing TSP device. The one area that had people stumped (that I’ve spoken to) though was how to get the config out in a way that could be re-used. The Classics used pretty standard text files everywhere, and you could just pull those out… tada, instant config. TSP had a single XML file which made extensive use of GUIDs to link hosts to groups, services to groups, host groups and service groups to rules, and so on. When we got to the Sidewinder, I made the mistake of thinking you could just do the same thing here…
Nope, Sidewinder would only export it’s policies in a securely encrypted format, that would only de-encrypt on another Sidewinder.
But hang on, what if someone wants to do a rule-base review on that box, and you don’t want to give them access to *everything*… how do you get around that then?
The simplest way seems to be to use a couple of commands, wrapped up in the TCSH foreach command, but to figure out what to select, you need to know how I got here.
There’s a command called cf which you run with administrator rights, by running srole – once you’re an admin, run the command
cf help
and this returns a list of configuration details you can do stuff with. Let’s pick one of these at random:
cf help ipaddr
This tells you that you can do cf ipaddr [add|delete|query] or at least something like that. The bit we’re most interested in right now though is query because that’ll give you some details. When I run cf ipaddr query or cf ipaddr q for short, it gives me back a bundle of lines like this:
ipaddr add name=I_Am_A_Name ipaddr=10.10.10.10 description=”
last_changed_by=’admin on Tue Jan 01 01:01:01 2001′
For those of you who know some unix syntax, you’ll realise that the indicates “ignore (or do something special with) the next character” – in this case, ignore it, because it’s the “New Line” character. You’ll recognise here that it’s saying you should add a new ipaddr object with a fixed name, fixed IP address and sets some other interesting data.
Not all of the list of things you can do stuff with is actually queryable though, so it might be worth picking and choosing what you do and don’t query. For brevity sake, here’s a list (space delimited) of the ones you can query:
accelerator acl adminuser agent antivirus appfilter audit auth burb burbgroup catgroups cert cluster cmd commandcenter config crontab daemond dhcrelay dns domain export failover fips fwregisterd gated geolocation host hostname ids ikmpd interface ipaddr iprange ips ipsec ipsresponse ipssig knownhosts lca license mvm netgroup netmap nss ntp package policy pool proxy qos reports routed server service servicegroup snmp ssl static subnet sysctl timeperiod timezone trustedsource udb ups urltranslation usergroup utt whitelist
Now, I don’t know what *all* of those do, but if you’ve spent any time wandering around the Sidewinder GUI, then you’ll recognise some of these terms – and that they participate in how the policy fits together. For a simple no-VPN policy, here’s the list (again space delimted) of things that I was most interested in:
burb burbgroup interface ipaddr iprange netgroup netmap policy proxy service servicegroup subnet
So, let’s do something useful here. We already know that we can run cf <object> query and it’ll return some data, but how would we do that for a whole bundle of these things? Re-enter stage left the foreach command. Anyone who’s done any programming knows about the for-next-loop style of loops, and some also know about the foreach loops. That’s all we’ll use here, and get something akin to a single config file (or multiple – you’ll see why in a second).
foreach fe ( burb burbgroup interface ipaddr iprange netgroup netmap policy proxy service servicegroup subnet )
cf $fe q >> config_file
end
You’ll notice that we’re putting that previous list of config options into a foreach loop, and using the variable fe when we’re using it against the cf command. You could replace config_file with config_file.$fe to ensure that you had a separate config file per object.
Run this little lot through a simple text processor (looking for the backslash character and then a new line, replace it with nothing) should give you an easy-to-parse list of objects and their variables. Of course, if you notice, those lines are also saying “add” – there’s no reason why you shouldn’t be able to prefix each of those <object> add lines with cf and paste that into your terminal to rebuild a firewall with a complete policy, but I’ll leave that as an exercise for the reader :)