16

The environment I'm operating in is a large-scale web hosting operation (several hundred servers under management, almost-all-public addressing, etc -- so anything that talks about managing ADSL links is unlikely to work well), and we're looking for something that will be comfortable managing both the core ruleset (around 12,000 entries in iptables at current count) plus the host-based rulesets we manage for customers. Our core router ruleset changes a few times a day, and the host-based rulesets would change maybe 50 times a month (across all the servers, so maybe one change per five servers per month).

We're currently using filtergen (which is balls in general, and super-balls at our scale of operation), and I've used shorewall in the past at other jobs (which would be preferable to filtergen, but I figure there's got to be something out there that's better than that).

The "musts" we've come up with for any replacement system are:

  • Must generate a ruleset fairly quickly (a filtergen run on our ruleset takes 15-20 minutes; this is just insane) -- this is related to the next point:
  • Must generate an iptables-restore style file and load that in one hit, not call iptables for every rule insert
  • Must not take down the firewall for an extended period while the ruleset reloads (again, this is a consequence of the above point)
  • Must support IPv6 (we aren't deploying anything new that isn't IPv6 compatible)
  • Must be DFSG-free
  • Must use plain-text configuration files (as we run everything through revision control, and using standard Unix text-manipulation tools are our SOP)
  • Must support both RedHat and Debian (packaged preferred, but at the very least mustn't be overtly hostile to either distro's standards)
  • Must support the ability to run arbitrary iptables commands to support features that aren't part of the system's "native language"

Anything that doesn't meet all these criteria will not be considered. The following are our "nice to haves":

  • Should support config file "fragments" (that is, you can drop a pile of files in a directory and say to the firewall "include everything in this directory in the ruleset"; we use configuration management extensively and would like to use this feature to provide service-specific rules automatically)
  • Should support raw tables
  • Should allow you to specify particular ICMP in both incoming packets and REJECT rules
  • Should gracefully support hostnames that resolve to more than one IP address (we've been caught by this one a few times with filtergen; it's a rather royal pain in the butt)
  • The more optional/weird iptables features that the tool supports (either natively or via existing or easily-writable plugins) the better. We use strange features of iptables now and then, and the more of those that "just work", the better for everyone.
womble
  • 96,255
  • 29
  • 175
  • 230
  • I'll bite-- what do the terms "balls" and "super balls" in your posting? I'm guessing you're not talking about bouncy rubber spheres, but I can't infer if the context means "good" or "bad". – Evan Anderson Aug 07 '09 at 01:37
  • balls == bad. Super balls == extra bad. – womble Aug 07 '09 at 04:24
  • With that many rules, make sure you have an ACCEPT rule at the top accepting established and related connections. PCs don't have a TCAM and that many rules do affect performance. A lot. – Thomas Aug 07 '09 at 06:22
  • @thomas: Yes, there's a certain amount of optimisation that goes into the ruleset. Having that "knowledge" about optimisation in whatever firewall tool is chosen would be a bonus, of course. – womble Aug 07 '09 at 09:02

5 Answers5

4

If you're perhaps wanting to make a move from a rule-driven approach to a "describe the final state required" way of doing things, have a look at fwbuilder.

Pros:

  • multiple firewalls supported - your core + host-based rules - from 1 set of objects
  • SQL-esque "tell me what you want" rather than "tell me how to do it" approach (NB I'm not saying there's any SQL in there! Just that it's descriptive Vs procedural :-)
  • It's a GUI, kinda like commercial hardware f/w vendors' interfaces, so it's possible to push some tasks down the employee/skills stack
  • supports most "wierd' usage I've tried
  • can generate rules for a variety of f/w implementations - BSD/cicso/iptables/etc
  • seperates front-end from rule-compiler, which makes me hopeful that speed is a concern to the authors. NB I've nothing near the scale to which you're alluding
  • File format isn't binary
  • does IPv6
  • Creates an iptables-save stylee config for atomic and quick loading

Cons:

  • It's a GUI
  • Moving your existing ruleset is unlikely to be pain-free
  • Whilst GPL and in Debian, Windows+OSX clients are 30-day eval, as no-one's cross-compiled a Free version yet for those OS; hence the commercial arm of the devs has a monopoly on those binaries
  • File format is technically XML; NB don't let this put you off: take a look at the tools that they provide (you can use the gui binary to manipulate it via the CLI for example), the CLI XML tools that already exist, and remember that - at your scale - some semblance of meta-data + structure ain't a /bad/ thing! It diffs quite nicely across edits, IIRC.

Link : http://www.fwbuilder.org

Jonathan Matthews
  • 156
  • 5
  • Hrm... I'll take a look. The existence of a GUI (not to mention the XML) makes me twitch rather violently, but you raise some interesting ideas (single set of rules for the entire infrastructure). The OS X thing isn't going to be a problem. – womble Aug 07 '09 at 04:33
  • I agree, a GUI did make me WTF at it originally, but I was pleased with what I saw from the CLI side, too. How dynamic is your setup, anyway? Would it be 10 changes a day or 10 changes a year? That might be a useful factor to detail here. Also, a nice function of the XML file format might be that, using XML-aware tools, you could have the whole config in one file, using single-definition objects, but produce a node-specific changelog for documenting individual server's configurations and changesets. Just a thought ... – Jonathan Matthews Aug 07 '09 at 14:28
  • @Jonathan: You're right, the dynamicism of the ruleset is important to know. I've edited the question; it's a few times a day most working days for the core ruleset. – womble Aug 08 '09 at 06:37
3

write your own. seriously - at this scale it is reasonable.

use ipset and/or plenty of iptable tables / subtables. whenever possible reload only some subtables / some sets of ipset - this will speed up reconfiguration.

probably you already do it, but still it's worth mentioning - use nested tables to decrease load on the router and average number of lookups needed for packets setting up new connections. obviously -A FORWARD -m state --state ESTABLISHED,RELATED is your topmost rule.

pQd
  • 29,981
  • 6
  • 66
  • 109
  • "Write our own" isn't off the table, but it's what got us filtergen in the first place -- it was written by a now-ex-employee. We'd prefer to not produce yet-another-firewall-management-tool if it's at all possible. – womble Aug 07 '09 at 09:05
  • IPSET is lightning fast for large rule sets. "store multiple IP addresses or port numbers and match against the collection by iptables at one swoop; dynamically update iptables rules against IP addresses or ports without performance penalty; express complex IP address and ports based rulesets with one single iptables rule and benefit from the speed of IP sets " I Use it with shorewall. I have NO idea how shorewall would perform at your scale though. – artifex Mar 20 '10 at 23:05
2

holy balls (keepin' the theme alive!) man...12,000 core rules?

I'm assuming you've considered all the easy options like simply dropping the sets into CVS? Puppet or CFengine?

Honestly, from the broad overview you've given, I'd strongly suggest re-evaluating your network design. I'm probably a little too simplistic, but I simply cannot fathom a design that would necessitate 12k iptables rules. This really sounds like something that would benefit more from an SLB type solution than a better way to manage the firewall rules.

On a side note, how does one add a comment versus adding an "answer"?

Greeblesnort
  • 1,759
  • 8
  • 10
  • You need a minimum amount of reputation to comment. When you do a link will appear. – jay_dubya Aug 07 '09 at 03:48
  • There is probably a certain amount of redundancy in our iptables rules, but that is largely a function of filtergen maybe not being as efficient as it could. We do have a /19 of IP space, though, and per-customer VLANs, and a fairly restrictive "default policy" (necessitating per-IP exceptions to open ports as required by customers). We're certainly not going to be able to get rid of more than a few of those rules. Oh, and yes, we already use Puppet, and we're not about to start writing rulesets by hand at our scale of operations. – womble Aug 07 '09 at 04:27
  • well, you certainly maintain a larger IP space than myself, but I still find it difficult to somehow justify that many rules. Have you given thought to breaking these out into a tree structure where you could utilize fall-thru rule setups at chokepoints? i.e., all the web only servers in subnet X, all the web + smtp servers in subnet Y? You wouldn't actually have to subnet them off, just logically group them behind a tiered firewall... sorry if I'm just adding noise at this point...I may simply not be sophisticated enough for this one. I like my firewall rulesets short and brutal =) – Greeblesnort Aug 07 '09 at 15:37
  • We're not really in a position to "tier" things out like that; we're largely a dedicated server hosting provider, so what our customers decide to do with their machines from day-to-day might change, necessitating a lot more dancing around than if we were just doing a dedicated infrastructure for an internal service. – womble Aug 08 '09 at 06:40
0

12000 rules? are you insane? Do you not suffer performance problems with this amount of filtering going on? I can't see why you would need 12,000 rules? How do you verify that you rules set is actually enforcing the policy?

What is the policy?

How do you test your policy?

12,000 rules possibly breaks every security rule in the book.

The Unix Janitor
  • 2,458
  • 15
  • 13
-2

you can also try a SAAS solution for managing iptables -> https://www.efw.io/Forum it can do AWS cloud integration also.

Paul Ma
  • 57
  • 3