Turning Routers into Firewalls

Posted January 15th, 2008 by

Not that anyone would find themselves in a situation like this: you have a firewall that’s actually a router and you want to fix it. Maybe it’s that you’re replacing a router with a firewall, maybe it’s that you had some doofuses who set up the firewall as a “Default Allow” in the first place.

Hey, we’re not being judgemental here at the Guerilla CISO, we’re all about fixing things. =)
So here is the process to follow:

  1. Get a logging server. Even better if you point it at something that lets you sort through the data better (Chuvakin, you can chime in with a subtle bit of log evangelizing here =) ). But hey, grep still works, the key here is that we’re logging and we can store a month’s worth of data.
  2. That “Default Allow” rule at the end of the chain? Set it to log everything that hits it. Keep it as “Allow” for the time being.
  3. Build and implement a ruleset for your core services that should be “Global” or “Enterprise-Wide”:
    • DNS
    • Active Directory
    • NTP
    • SNMP/NMS
    • Patching
    • Vulnerability Scanners
    • Identification and Authentication (TACACS, Radius, etc)
    • File Servers
    • Any Application-Specific Traffic
    • Remote Management/RDP/SSH/$foo
  4. Wait it out. A month is probably a good sample of network traffic that will show you where the obvious trends are.
  5. Review the data flows that were logged passing through the last rule. You might have to do some correlation with scan results, server inventory, or network drawrings.
  6. Add rules for the data flows that you want to keep. There might be some things here that are obviously misconfigured and you need to push them to the server and network guys to fix.
  7. Do another sample period or if you’re feeling confident/BSOFH-ish, skip it. I can hear a voice in the back of my head saying “It’s an iterative process after all…” but I’ll ignore it for the time being.
  8. Flip the last rule in the chain to “Deny”.
  9. ????
  10. Profit!

Similar Posts:

Posted in Technical, The Guerilla CISO, What Works | 4 Comments »

4 Responses

  1.  dre Says:

    Wow, I usually look at this from the completely opposite perspective.

    I prefer to turn firewalls into router-firewalls. Reason one: all firewall products/appliances suck. Reason two: some routers support firewall/IPS features better than firewalls or IPSes do – and perform extremely better while doing them.

    I’m not even going to list reasons such as support for SNMPv3, IPv6, being able to reliably encrypt or wrap any protocol in GRE *and* IPSec, using Anycast routing to create a defensible infrastructure, or any of the various other little things.

    It is very likely that the code base for any router is also more tested (quality and security testing) than an equivalent firewall product.

    I’m sure that there are people who will say, “but RFC 2196 says that physical separate of duties and devices is warranted in all situations”. Actually, first of all – it doesn’t say that. It talks about separation of services and models of trust. You’re probably better off reading NCSC-TG-005 (aka the Red book). Secondly, there is no reason why you can’t have two functional types of routers: one type for routing and the other to be a router-firewall.

    Personally, I’ve never understood the reasoning behind physical separation to create trust areas. You want to create trust areas – then test them! Test them using tools after hardening configurations. I don’t want PCI-DSS or FISMA telling me that firewalls on separate VLAN’s but on the same switch isn’t good enough when I know that it is!

    I’m sick of these three-tier, six-firewall architectures that make security professionals wet, yet make every network engineer, system engineer, front-end engineer, programmer, software architect, and DBA cry. I think it requires a certain amount of sadism to be a security professional who won’t bend on such issues.

    I realize that you might be talking about routers that are setup with access-lists (read: packet filters with no stateful inspection). Probably setup by a system administrator when the organization installing expensive Cisco gear didn’t swing for a real network engineer. Without stateful inspection, servers listening for TCP ACK can be nasty network backdoors.

    Let me let you in on a little secret though. Stateful inspection is not rocket science. Cisco IOS Reflexive ACL’s do about the same stateful inspection (or better) as any firewall that doesn’t support stateful failover. Just take a look at OpenBSD pf and CAPP – perfect technologies that don’t cost a dime, but actually work. Cisco IOS firewall feature set is light years ahead of any PIX or Checkpoint NG technology, which hasn’t advanced past 1994.

    I would also like to mention, “Microsoft’s latest operating system, Windows Vista, uses TCP window scaling for non-http (web) connections. So do Linux kernels from versions 2.6.8 on. This behavior is incompatible with some firewalls that use SPI (Stateful Packet Inspection) as found in routers like the Checkpoint NG R55, Cisco PIX and IOS, NetApp Cache Appliances, SonicWall, D-Link DI-724U, Netgear WGR614, and Linksys WRT54GS”. See: http://support.microsoft.com/kb/934430/en-us

    In summation: don’t use a PIX just because it passed EAL4+ Common Criteria and the OS “has never been hacked”. Projects like Frankenpix should prove this concept entirely wrong. Same goes for Checkpoint on Nokia or Juniper Netscreen. Test before you deploy; including performance and security!

  2.  Ronald Says:

    The situation you describe is not that uncommon in Mergers & Acquisitions. The company being acquired has hit the skids, and security has been their last concern as they try and keep their head above water.
    Personally, I would rather use a Netflow tool than a logging server. I think it is quicker.
    Also Rule 1 should be the local FW access and management rule with each additional rule added according to hit rate. Older FWs performed better with this strategy but with faster processors it doesn’t matter. However, having this strategy makes it easier to audit the rule set and troubleshoot. Also each rule should have the comment field used aggressively. When does the rule expire? What is the change reference? Who is the business owner? etc…

  3.  rybolov Says:

    Hi Dre

    That’s a mouthful. I agree with you. =)

    In my particular case, the guys who set everything up had the equipment in place but did nothing to restrict the traffic.

  4.  Anton Chuvakin Says:

    Going for a not-so-subtle variety 🙂

    >grep still works

    No, it doesn’t – well, it does if you are really, really patient (and almost nobody is – in this age of instant gratification)

    Also, try grepping for something like ‘root’: you’d see way too much stuff that you don’t need…

    >a month
    Why a month? It is not uncommon under the circumstances that you describe that, say, 3 mos of data will come handy. I see “one month” as we-know-we-need-to-store-more-but-we-think-we-can’t retention period, not the one that actually balances the operational needs and storage costs (the latter is probably 90 days…)

Leave a Comment

Please note: Comment moderation is enabled and may delay your comment. There is no need to resubmit your comment.

Visitor Geolocationing Widget: