Inexpensive Firewalls, BayLISA, 2000-04-20
Simon Cooper, sc@sgi.com


A specific-use device.
Filters, apps.  Not just a filtering router.
Uses readily available hardware.
Uses an OS you are familiar with.
Uses free or affordable tools.

Not a high-performance firewall.
Not a high-reliability firewall.
Not a maximum-security firewall.
Not a no-cost firewall.
Not a plug-and-play firewall.

Good for:
a departmental network.
a lab network.  Things that might leak.
a small business.
a home.
a personal domain.

Agenda:
Ingredients.
Service providers.
Hardware and OS
filtering and services
architecture
administration
tips for building
experiences
Q&A

Ingredients:
know what you want t orun on or pass through your firewall
old or cheap hardware
a suitable and FAMILIAR operating system
free or affordable tools
your time

Know what you want to do:
who do you want to let in?
who do you want to try to keep out?
is it in alignment with your security policy?
what services will be offered?

Architectures:
[picture with a dual-homed host, between the internal network and the Internet]
[picture of a perimeter network, with a firewall host between them]

Selecting a Broadband ISP:
Landon Curt Noll <chongo@certive.com> speaks:
Determine your requirements.
ISP pre-selection questions
ISP selection
ISP quality questions

Determine Your Requirements:
Home, home office, or business user?   Home = someone who just wants to 
 surf the Web.  Home office = always-on needs such as e-mail.  Business
 user = has specific quality-of-service needs.
Minimum speed / % bandwidth
Number of IP addresses:  remember that 3 go to overhead
What external services do I need?   Is ISP providing DNS, pine, news?
How much hand-holding do I need?  This isn't just ability; it might 
 be inclination:  Do you want to also perform your job at home?

ISP Pre-selection Questions:
Is broadband service available?
What speeds are available?
How much can I afford per month?
Consumer or business service?  You get what you pay for:  Consumers; hidden
 provision where you can really use only 5-10% of theoretically available
 bandwidth.  Business has guaranteed rates of service, no limit on usage.
 Business will have some priority routing on packets, eventually.  This
 already happens at the ATM level.  Consumer service also oversells 
 bandwidth, typically by a factor of 30.  384 kbps is _not_ guaranteed
 to be good to anywhere useful, just to the NOC.

ISP Selection:
Does the ISP understand the product?  Ask them to differentiate aDSL from
 sDSL.
Is the ISP small or large.  Large ISPs have advantage of larger staff, 
 which however will be less clueful.  
Is the ISP full-service or self-service?  Some want to sell you Web design,
 e-commerce consulting, other services.  Others sell basic bandwidth.
Max %age of the bandwidth allowd
Where is the ISP located?  When the ISP cuts your line, can you drive 
 down and talk to them?
How much do they oversell their bandwidth?  Don't except "not at all".
How much does it cost?
Who provides the physical network?  
Am I the right customer for the ISP?

ISP Quality Questions:
Hours of support
Is the support staff clueful?
Does the ISP support my OS?  Mac-supporting ISPs will probably 
How will my issues be tracked?  Get back to you?  Tracking number?
How well connected is the ISP?  Size of pipe.  Where geographically
 are they connected to elsewhere?  If your ISP is connected only in
 Boston, all your IP traffic will go through Boston first.  Run
 traceroutes.
How will network problems be fixed?   What will they do if your line
 is slow?
Ask your friends about their experiences with quality of service?

Hardware:
Use what you have:  Suns, PCs, SGIs.
Laptops: Quiet, compact, built-in UPS.
Last-generation hardware.
Has (at least) two network interfaces.

Hardware issues:
Know which is the inside interface.  With PCI slots, you might
 find the interfaces renumbered. Choose the primary interface to
 be on the inside.
CD-ROM drive is important.  Put firewall config on CDR/CDRW.
Check to verify that the CD-ROM drive can read CD-R and CDRW.
 This is worth a small investment.
Power supplies, disks, and fans wear out.  Make sure the power supply
 doesn't smell funny, no spiderwebs in the disk drives, no clogged fan
 bearings.  Burn in the machine.  Vacuum-clean it (gently).

Operating system:
The operating system you use will need
 packet filtering
 free or affordable software for what you want to do
 to be FAMILIAR to you
 continued and active support
 an active security community

Operating System Examples
Linux:  IP chains in 2.2, Netfilter in 2.3
NT / Win2k:  Microsoft Proxy Server
A BSD variant:  ifpw
IRIX: ipfilterd
Solaris: ipfilter
AIX: ipfilterd

Hardening the OS
Philosophy:  disable or remove everything that is not needed
Secure "distributions" exist
 freefire pointers:  http://www.freefire.org/  Free firewall information site.
   Not much NT stuff, but otherwise lots of information for firewalling.
   Links to router projects, hardening scripts.
 Linux Router Project: http://www.linuxrouter.org/  Goes on a floppy.  
   At least two derived offshoots.
 picoBSD:  http://www.freebsd.org/picobsd/

Hardening the OS:
Can do it yourself, if you're experienced
Keep a written log.  Or run script when you're doing it.  You might
 want to construct a script that can [re-] build your firewall.
Don't build your firewall on the network you are going to protect!
There are cheet sheets on the Web for many OSes.  Search for keywords
 and combination like
   hardening, securing, bastion, <OS name>
Sites with particular OS information seems to be on the increase -- try
 searching there, first.  E.g., securityportal.com.
Some securiyt news sites carry articles on securing as specific OS.
Check the OS release with the information you find -- don't rely 
 completely on one information source unless you trust it!

The Kernel (for Unixes):
Things to watch out for and protect against:
 IP DoS attacks
 IP forwarding OFF when the system boots (i.e., not wide open until
  the rule script runs).
 Default deny rules when the system boots
 Packet filtering failure mode:  If the packet filtering fails to
  start, how does it default?
 IP fragmentation:  Don't let them through; use re-assembly.  Information
  needed for filtering is available only in the first fragment.  Must
  allow through only complete packets.  Allowing fragments through
  might allow arbitrary content through; covert information channels.
  There have been successful attacks that relied on fragmentation.
  There are some IP stacks that aren't very good:  Put NT Web server 
  behind firewall, attacker sends small packet through, sends second
  overlapping fragment that overwrites header field.  Does the Web 
  server deliver the 2nd packet to port 80, or to the apparent address 
  in the header?   (IPv6 deprecates fragmentation.)

Remove OS Logging
For Unix:
  syslog
  some syslogs can be made send-only -- does not listen on syslog
   port to other hosts
  can sendencrypted packets
  can use TCP instead of UDP
  Linux syslogd listens only by default
For NT:
 A free syslog-like too, but simulates the behaviour with problem.


Checklist:
Turn off all services you won't be using.  
Secure the filesystem.
 update file permissions
 remove pieces you won't be using
Service packs.  Kernel changes.  Patches.
Run your initial integrity check now!  E.g., tripwire. (GPLed equivalent
 is "AIDE".)  Make sure
 you include the tripwire binary on the CDR.  Build a static binary,
 or include all other pieces including libs.  Commercial tripwire
 ships with dynamic libs

Filtering topics:
Desired features
What is available
ipfilterd, ipfilter
ipchains, netfilter
filtering issues
examples

Filtering: Desired features
Wish list:
 input and output rules for each interface:  Three-legged firewall 
  is nice, to support service network.  Usually apply rules on in and out, 
  with forwarding allowed to be generic, except for specific blocks.  Complex
  rules could be applied everywhere, but then they become difficult to maintain
  and debug. 
 interface forwarding rules.
 ability to rewrite packets (masquerading / NAT)
 Knowledge of ICMP, ability to rewrite ICMP response packets
 logging of rejected or flagged packets.  Nice to have log indicate
  which rule rejected the packet.
 hierarchical (user defined) rules.  Optimise by putting side-conditions
  in, thereby shortening the path to acceptance or rejection.
 handling of idle TCP sessions:  This is a policy issue
 configurable handling of UDP.  Nasty issue.  Works for NTP.
 detailed knowledge aobut some protocols, e.g., matching of return
  packets for DNS, traceroute
 configurable default policy

 Filtering
 NT
 ipfilterd (IRIX, AIX), ipfilter (Solaris).  Very easy to allow things
  through by accident.  Very mature system otherwise.
 ipfw (FreeBSD)
 ipchains (Linux 2.2)
 netfilter (LInux 2.3)
 Currently, no single operating system is "perfect".

 Ipchains (Linux 2.2)
 in/out filters for each interface
 by protocol, port, addresses
 separate formwarding fules
 user-defined rules
 support for packet masquarding
 configurable default policy

IPchains weaknesses
weak on logging:  Records the index number into the rule.  
 only logs a packet synopsis
Rules are build incrementally
 things can leak through
TCP is not stateful (no ACK/SEQ checking)
Cannot reference interfaces unless they are "up" (complicates startup).
 Ports must be up first, in which case they're initially open.
Masquerading uses a limited port range.  NAT-portion is 4000 tcp
 connections outgoing.  TCP and UDP come out of that.  Could recompile
 for a different limit.  Fixed in netfilter.  IP port range is rather
 high; might want to move it.

 Filtering issues
 icmp path MITU discovery
 auth/identd - reject but allow a response.  Dropping on the floor
  isn't good, as services will wait for a timeout.
 REJECT or DROP?  ipchains can reject and send a response, or send
  packets to a black hole
 protect yourself from mishaps, such as switching the interfaces
  accidentally. Filtering rules can protect you from that.
 Don't assume that the inside is always inside.  Cleaning lady might
  knock both connections out and "put them back".
 Do source routing.  Drop wrong packets and log them.
 If you don't trust some of the things that you have inside
  your firewall, filtering rules can partition the network.  E.g.,
  first 16 addresses for trusted machines, put filtering rules 
  that say 16-32 cannot go straight out, must use proxy or forwarder.

Example (input)
ipchains -F input
ipchains -P input reject
#protect against IP address spoofing
ipchains -A input -i eth0 -s $inet -d $any -j ACCEPT
ipchains -A input -i eth1 -s $inet -d $any -l -j REJECT
#allow incoming SMTP
ipchains -A input -i eth1 -p tcp -s any -d $ne 25 -j ACCEPT
#catch all rule
ipchains -A input -s $any -d $any -l -j REJECT

Example (output)
#protect against spoofing or routing errors
ipchains -F output
ipchains -P output REJECT
ipchains -A output -i eth0 -a $any -d $inet -j ACCEPT
ipchains -A output -i eth1 -a $any -d $inet -l -j REJECT
#allow SMTP-responses out
ipchains -A output -i eth1 -p tcp -s $ne 25 -d $any -j ACCEPT
$catch everything else
ipchains -A output -s $any -d $any -l -j REJECT

Resources for Creating Filters
 Simon Cooper, D. Brent Chapman, Elizabeth D. Zwicky's
 Building Internet Firewalls, 2nd ed. coming out in June 2000
 Thicker than the sendmail book.  Suitable for throwing at managers
 who need to be convinced you need a firewall:  850 pages.
 Includes information for Linux and NT.
Linux HOWTOs for ipchains and masquerading.

Services
Unix:
 Mail - postfix recommended.  easy to set up.
 Web proxy server / Apache
 DNS (internal/external)
 Proxy - SOCKS
 Transparent masquerading
NT
 Mail - sendmail for NT (not free)
 Web server - Apache for NT
 Proxy - Microsoft Proxy Server