Friday, September 1, 2006

Firewalls

Fred Avolio's post about "experts" dredged up old memories and pain. It also triggered the need to vent, so here goes...

Building on what Fred listed:

  • We rarely agree (especially in groups larger than two).
  • We love to argue (though most cannot argue without using a whiteboard or scribbling on numerous pieces of paper).
  • Many of us are cynics.
  • Most of us have a nickname (though many don't know it). Most are along the lines of "Princess of Darkness" (POD, for short), "Network Nazi", or plain old "asshole" (you're the guy that blocks their IM, remember?).
  • Most of what we do, others find tedious or consider "anal retentive".

Regardless of what Gartner and the like say, the various rules for firewalls and firewall policy still haven't changed.

Rules for choosing a path through your firewall (displaying Fred's bullets that we state the obvious and rehash the same old stuff) (and at the risk of starting yet another religious war with various factions):

  1. Block the port (don't allow it).
  2. If you can't block it, use an application proxy.
  3. If you can't use an application proxy, use stateful packet inspection (SPI).
  4. If you can't use SPI, use a packet filter (or router ACL).

Rules of thumb for firewalls (in no particular order):

  • Filter/block as high as possible in the OSI model (protocol, then state, then port, then IP). Two or more of those at the same time is better.
  • Periodically have someone else review your firewall configuration. (e.g., Dump it to paper, give it to one of the techs for weekend "homework".) Then review it yourself. Any unanswered questions at the end of this process is an indication of a problem.
  • Don't "filter and forget". Make sure management realizes that adding exceptions to the firewall also adds monitoring requirements. At a minimum, periodic spot checks via net flow and packet capture.
  • Keep a record of any changes to the firewall, who needed them, and who authorized them. (Signatures, dates and justifications are valuable!) In other words, don't make changes without authorization and always document them.
  • Read your damn logs! Do so on a daily basis! Firewalls (and routers) (and servers) (and IPS/IDS systems) are not plug and play. Waiting to read your logs until there's an overt problem is plain lazy. Big problems start small and build over time.
  • Learn effective log file reduction.
  • If you're bored, you're working in the wrong field.
  • If you're worried about how other people think of you, you're working in the wrong field.
  • If you can't function without a budget, you're working in the wrong field.

If you have time on your hands:

  • Drag out tcpdump or netflow and take a look at what's crossing your internal network. (Be sure you have permission!) Again, this is another "big problems start small" preventive action.
  • Pick a tool and learn the switches. In other words, know your tools. You'd be surprised (or, at least, others will) what you can "glue together" with available tools and a bit of scripting.
  • Try and clean your desk. Yeah, you'll never finish the job but some of that stuff has to be thrown out. (Nobody uses ISA NICs any more so why are you keeping them?)
  • Write a tool that gathers metrics. Pick a service or node and graph the load on/through that service or node. Learn what "normal" looks like.
  • Script the above so that you can display it on a web page in real-time (or near real-time). I've found monitoring the following metrics to be valuable: mail traffic levels, number of viruses captured, traffic levels through specific router interfaces, and web traffic levels.
  • Wander through your organization and talk to people. You'd be amazed about the number of problems you can head off via simple conversation. You'd also be amazed on how much PR is generated for "security" if people get to see your face on a daily basis (in semi-social settings) (presentations and company meetings do not count)

Periodically scan your network (again, be sure you have permission) and try to answer one or more of the following:

  • Do you know how many workstations are on your network?
  • Do you know how many servers are on your network?
  • Do you know the MAC address of every node in your network, especially the workstations? (It is possible to grab MAC addresses remotely with MS Windows systems.)
  • Do you know what ports should be open on each of your servers?
  • What about your workstations?
  • Are there any open shares in your network?
  • Are there any unauthorized services running in your network?
  • Are there any unauthorized systems connected to your network?

No comments:

Post a Comment