home *** CD-ROM | disk | FTP | other *** search
/ linuxmafia.com 2016 / linuxmafia.com.tar / linuxmafia.com / pub / linux / security / firewalls < prev    next >
Text File  |  2000-04-19  |  12KB  |  326 lines

  1. Inexpensive Firewalls, BayLISA, 2000-04-20
  2. Simon Cooper, sc@sgi.com
  3.  
  4.  
  5. A specific-use device.
  6. Filters, apps.  Not just a filtering router.
  7. Uses readily available hardware.
  8. Uses an OS you are familiar with.
  9. Uses free or affordable tools.
  10.  
  11. Not a high-performance firewall.
  12. Not a high-reliability firewall.
  13. Not a maximum-security firewall.
  14. Not a no-cost firewall.
  15. Not a plug-and-play firewall.
  16.  
  17. Good for:
  18. a departmental network.
  19. a lab network.  Things that might leak.
  20. a small business.
  21. a home.
  22. a personal domain.
  23.  
  24. Agenda:
  25. Ingredients.
  26. Service providers.
  27. Hardware and OS
  28. filtering and services
  29. architecture
  30. administration
  31. tips for building
  32. experiences
  33. Q&A
  34.  
  35. Ingredients:
  36. know what you want t orun on or pass through your firewall
  37. old or cheap hardware
  38. a suitable and FAMILIAR operating system
  39. free or affordable tools
  40. your time
  41.  
  42. Know what you want to do:
  43. who do you want to let in?
  44. who do you want to try to keep out?
  45. is it in alignment with your security policy?
  46. what services will be offered?
  47.  
  48. Architectures:
  49. [picture with a dual-homed host, between the internal network and the Internet]
  50. [picture of a perimeter network, with a firewall host between them]
  51.  
  52. Selecting a Broadband ISP:
  53. Landon Curt Noll <chongo@certive.com> speaks:
  54. Determine your requirements.
  55. ISP pre-selection questions
  56. ISP selection
  57. ISP quality questions
  58.  
  59. Determine Your Requirements:
  60. Home, home office, or business user?   Home = someone who just wants to 
  61.  surf the Web.  Home office = always-on needs such as e-mail.  Business
  62.  user = has specific quality-of-service needs.
  63. Minimum speed / % bandwidth
  64. Number of IP addresses:  remember that 3 go to overhead
  65. What external services do I need?   Is ISP providing DNS, pine, news?
  66. How much hand-holding do I need?  This isn't just ability; it might 
  67.  be inclination:  Do you want to also perform your job at home?
  68.  
  69. ISP Pre-selection Questions:
  70. Is broadband service available?
  71. What speeds are available?
  72. How much can I afford per month?
  73. Consumer or business service?  You get what you pay for:  Consumers; hidden
  74.  provision where you can really use only 5-10% of theoretically available
  75.  bandwidth.  Business has guaranteed rates of service, no limit on usage.
  76.  Business will have some priority routing on packets, eventually.  This
  77.  already happens at the ATM level.  Consumer service also oversells 
  78.  bandwidth, typically by a factor of 30.  384 kbps is _not_ guaranteed
  79.  to be good to anywhere useful, just to the NOC.
  80.  
  81. ISP Selection:
  82. Does the ISP understand the product?  Ask them to differentiate aDSL from
  83.  sDSL.
  84. Is the ISP small or large.  Large ISPs have advantage of larger staff, 
  85.  which however will be less clueful.  
  86. Is the ISP full-service or self-service?  Some want to sell you Web design,
  87.  e-commerce consulting, other services.  Others sell basic bandwidth.
  88. Max %age of the bandwidth allowd
  89. Where is the ISP located?  When the ISP cuts your line, can you drive 
  90.  down and talk to them?
  91. How much do they oversell their bandwidth?  Don't except "not at all".
  92. How much does it cost?
  93. Who provides the physical network?  
  94. Am I the right customer for the ISP?
  95.  
  96. ISP Quality Questions:
  97. Hours of support
  98. Is the support staff clueful?
  99. Does the ISP support my OS?  Mac-supporting ISPs will probably 
  100. How will my issues be tracked?  Get back to you?  Tracking number?
  101. How well connected is the ISP?  Size of pipe.  Where geographically
  102.  are they connected to elsewhere?  If your ISP is connected only in
  103.  Boston, all your IP traffic will go through Boston first.  Run
  104.  traceroutes.
  105. How will network problems be fixed?   What will they do if your line
  106.  is slow?
  107. Ask your friends about their experiences with quality of service?
  108.  
  109. Hardware:
  110. Use what you have:  Suns, PCs, SGIs.
  111. Laptops: Quiet, compact, built-in UPS.
  112. Last-generation hardware.
  113. Has (at least) two network interfaces.
  114.  
  115. Hardware issues:
  116. Know which is the inside interface.  With PCI slots, you might
  117.  find the interfaces renumbered. Choose the primary interface to
  118.  be on the inside.
  119. CD-ROM drive is important.  Put firewall config on CDR/CDRW.
  120. Check to verify that the CD-ROM drive can read CD-R and CDRW.
  121.  This is worth a small investment.
  122. Power supplies, disks, and fans wear out.  Make sure the power supply
  123.  doesn't smell funny, no spiderwebs in the disk drives, no clogged fan
  124.  bearings.  Burn in the machine.  Vacuum-clean it (gently).
  125.  
  126. Operating system:
  127. The operating system you use will need
  128.  packet filtering
  129.  free or affordable software for what you want to do
  130.  to be FAMILIAR to you
  131.  continued and active support
  132.  an active security community
  133.  
  134. Operating System Examples
  135. Linux:  IP chains in 2.2, Netfilter in 2.3
  136. NT / Win2k:  Microsoft Proxy Server
  137. A BSD variant:  ifpw
  138. IRIX: ipfilterd
  139. Solaris: ipfilter
  140. AIX: ipfilterd
  141.  
  142. Hardening the OS
  143. Philosophy:  disable or remove everything that is not needed
  144. Secure "distributions" exist
  145.  freefire pointers:  http://www.freefire.org/  Free firewall information site.
  146.    Not much NT stuff, but otherwise lots of information for firewalling.
  147.    Links to router projects, hardening scripts.
  148.  Linux Router Project: http://www.linuxrouter.org/  Goes on a floppy.  
  149.    At least two derived offshoots.
  150.  picoBSD:  http://www.freebsd.org/picobsd/
  151.  
  152. Hardening the OS:
  153. Can do it yourself, if you're experienced
  154. Keep a written log.  Or run script when you're doing it.  You might
  155.  want to construct a script that can [re-] build your firewall.
  156. Don't build your firewall on the network you are going to protect!
  157. There are cheet sheets on the Web for many OSes.  Search for keywords
  158.  and combination like
  159.    hardening, securing, bastion, <OS name>
  160. Sites with particular OS information seems to be on the increase -- try
  161.  searching there, first.  E.g., securityportal.com.
  162. Some securiyt news sites carry articles on securing as specific OS.
  163. Check the OS release with the information you find -- don't rely 
  164.  completely on one information source unless you trust it!
  165.  
  166. The Kernel (for Unixes):
  167. Things to watch out for and protect against:
  168.  IP DoS attacks
  169.  IP forwarding OFF when the system boots (i.e., not wide open until
  170.   the rule script runs).
  171.  Default deny rules when the system boots
  172.  Packet filtering failure mode:  If the packet filtering fails to
  173.   start, how does it default?
  174.  IP fragmentation:  Don't let them through; use re-assembly.  Information
  175.   needed for filtering is available only in the first fragment.  Must
  176.   allow through only complete packets.  Allowing fragments through
  177.   might allow arbitrary content through; covert information channels.
  178.   There have been successful attacks that relied on fragmentation.
  179.   There are some IP stacks that aren't very good:  Put NT Web server 
  180.   behind firewall, attacker sends small packet through, sends second
  181.   overlapping fragment that overwrites header field.  Does the Web 
  182.   server deliver the 2nd packet to port 80, or to the apparent address 
  183.   in the header?   (IPv6 deprecates fragmentation.)
  184.  
  185. Remove OS Logging
  186. For Unix:
  187.   syslog
  188.   some syslogs can be made send-only -- does not listen on syslog
  189.    port to other hosts
  190.   can sendencrypted packets
  191.   can use TCP instead of UDP
  192.   Linux syslogd listens only by default
  193. For NT:
  194.  A free syslog-like too, but simulates the behaviour with problem.
  195.  
  196.  
  197. Checklist:
  198. Turn off all services you won't be using.  
  199. Secure the filesystem.
  200.  update file permissions
  201.  remove pieces you won't be using
  202. Service packs.  Kernel changes.  Patches.
  203. Run your initial integrity check now!  E.g., tripwire. (GPLed equivalent
  204.  is "AIDE".)  Make sure
  205.  you include the tripwire binary on the CDR.  Build a static binary,
  206.  or include all other pieces including libs.  Commercial tripwire
  207.  ships with dynamic libs
  208.  
  209. Filtering topics:
  210. Desired features
  211. What is available
  212. ipfilterd, ipfilter
  213. ipchains, netfilter
  214. filtering issues
  215. examples
  216.  
  217. Filtering: Desired features
  218. Wish list:
  219.  input and output rules for each interface:  Three-legged firewall 
  220.   is nice, to support service network.  Usually apply rules on in and out, 
  221.   with forwarding allowed to be generic, except for specific blocks.  Complex
  222.   rules could be applied everywhere, but then they become difficult to maintain
  223.   and debug. 
  224.  interface forwarding rules.
  225.  ability to rewrite packets (masquerading / NAT)
  226.  Knowledge of ICMP, ability to rewrite ICMP response packets
  227.  logging of rejected or flagged packets.  Nice to have log indicate
  228.   which rule rejected the packet.
  229.  hierarchical (user defined) rules.  Optimise by putting side-conditions
  230.   in, thereby shortening the path to acceptance or rejection.
  231.  handling of idle TCP sessions:  This is a policy issue
  232.  configurable handling of UDP.  Nasty issue.  Works for NTP.
  233.  detailed knowledge aobut some protocols, e.g., matching of return
  234.   packets for DNS, traceroute
  235.  configurable default policy
  236.  
  237.  Filtering
  238.  NT
  239.  ipfilterd (IRIX, AIX), ipfilter (Solaris).  Very easy to allow things
  240.   through by accident.  Very mature system otherwise.
  241.  ipfw (FreeBSD)
  242.  ipchains (Linux 2.2)
  243.  netfilter (LInux 2.3)
  244.  Currently, no single operating system is "perfect".
  245.  
  246.  Ipchains (Linux 2.2)
  247.  in/out filters for each interface
  248.  by protocol, port, addresses
  249.  separate formwarding fules
  250.  user-defined rules
  251.  support for packet masquarding
  252.  configurable default policy
  253.  
  254. IPchains weaknesses
  255. weak on logging:  Records the index number into the rule.  
  256.  only logs a packet synopsis
  257. Rules are build incrementally
  258.  things can leak through
  259. TCP is not stateful (no ACK/SEQ checking)
  260. Cannot reference interfaces unless they are "up" (complicates startup).
  261.  Ports must be up first, in which case they're initially open.
  262. Masquerading uses a limited port range.  NAT-portion is 4000 tcp
  263.  connections outgoing.  TCP and UDP come out of that.  Could recompile
  264.  for a different limit.  Fixed in netfilter.  IP port range is rather
  265.  high; might want to move it.
  266.  
  267.  Filtering issues
  268.  icmp path MITU discovery
  269.  auth/identd - reject but allow a response.  Dropping on the floor
  270.   isn't good, as services will wait for a timeout.
  271.  REJECT or DROP?  ipchains can reject and send a response, or send
  272.   packets to a black hole
  273.  protect yourself from mishaps, such as switching the interfaces
  274.   accidentally. Filtering rules can protect you from that.
  275.  Don't assume that the inside is always inside.  Cleaning lady might
  276.   knock both connections out and "put them back".
  277.  Do source routing.  Drop wrong packets and log them.
  278.  If you don't trust some of the things that you have inside
  279.   your firewall, filtering rules can partition the network.  E.g.,
  280.   first 16 addresses for trusted machines, put filtering rules 
  281.   that say 16-32 cannot go straight out, must use proxy or forwarder.
  282.  
  283. Example (input)
  284. ipchains -F input
  285. ipchains -P input reject
  286. #protect against IP address spoofing
  287. ipchains -A input -i eth0 -s $inet -d $any -j ACCEPT
  288. ipchains -A input -i eth1 -s $inet -d $any -l -j REJECT
  289. #allow incoming SMTP
  290. ipchains -A input -i eth1 -p tcp -s any -d $ne 25 -j ACCEPT
  291. #catch all rule
  292. ipchains -A input -s $any -d $any -l -j REJECT
  293.  
  294. Example (output)
  295. #protect against spoofing or routing errors
  296. ipchains -F output
  297. ipchains -P output REJECT
  298. ipchains -A output -i eth0 -a $any -d $inet -j ACCEPT
  299. ipchains -A output -i eth1 -a $any -d $inet -l -j REJECT
  300. #allow SMTP-responses out
  301. ipchains -A output -i eth1 -p tcp -s $ne 25 -d $any -j ACCEPT
  302. $catch everything else
  303. ipchains -A output -s $any -d $any -l -j REJECT
  304.  
  305. Resources for Creating Filters
  306.  Simon Cooper, D. Brent Chapman, Elizabeth D. Zwicky's
  307.  Building Internet Firewalls, 2nd ed. coming out in June 2000
  308.  Thicker than the sendmail book.  Suitable for throwing at managers
  309.  who need to be convinced you need a firewall:  850 pages.
  310.  Includes information for Linux and NT.
  311. Linux HOWTOs for ipchains and masquerading.
  312.  
  313. Services
  314. Unix:
  315.  Mail - postfix recommended.  easy to set up.
  316.  Web proxy server / Apache
  317.  DNS (internal/external)
  318.  Proxy - SOCKS
  319.  Transparent masquerading
  320. NT
  321.  Mail - sendmail for NT (not free)
  322.  Web server - Apache for NT
  323.  Proxy - Microsoft Proxy Server
  324.  
  325.  
  326.