Firewalls and Security

1
Firewalls and Security

• Eric Rostetter
• Physics Computer Group
• April, 2001

2
Everything is Relative

• There are few absolute answers.
• Being secure is a matter of identifying threats,
  identifying the value of what you are protecting,
  and then implementing appropriate mechanisms to
  reduce the risk to an acceptable level
• What's appropriate for one situation may be
  insane for another
• How paranoid do you really need to be???
• If you make things too restrictive, people either
  won't use it or will circumvent it. To be
  effective, it must also be usable
• You can't achieve absolute security

3
Who's at Risk?

• Computer Intrusions are like Drive-By Shootings
  -- They'll hit anyone who is available! It
  doesn't matter who you are.
• If you're on the network, you are at risk!
• In the last month, we've seen at least 2 port
  scans of our network per day
• This year, we've had 3 major intrusions resulting
  in network shutdowns, and 3 desktop intrusions
• It's only going to get worse!

4
Common Myths

• No one would break into my computer...
• It isn't important enough
• It isn't registered in the DNS
• It's running... (MacOS, Windows, Solaris, etc)
• I don't care, there's nothing important here...
• Are you sure? Do you have backups? Source
  media?
• If it isn't important, then why do you have it?
  (What is UT paying you for anyway?)
• Your compromised box DOES affect the rest of UT
  (sniffers, bandwidth, reputation, reprisals,
  liability, etc)
• Recently UT was blocked from the LANL archives
  because of one user. One person or machine
  really can affect the whole institution!

5
Common Myths (Cont)

• I'll do it later...
• If you get hit, you may be removed from the
  network until you are secured
• Might as well do it now, rather than be forced to
  do it later
• If it isn't convenient now, will it really be
  convenient when you are forced to do it? Hackers
  rarely time things to your schedule...
• How important is your data? Can you afford to
  lose it if you don't get around to it in time?

6
Policy

• Firewall and network security should be based on
  a security and usage policy. This policy should
  define
• Acceptable use
• Minimal security requirements for users
  (passwords, type of connections allowed, privacy,
  etc)
• Minimal security requirements for machines (patch
  policy, shares/exports policy, services
  allowed/banned, etc)
• How to handle an incident
• How to request services and approval process for
  requests
• The firewall becomes the implementation of parts
  of the policy (not the other way around)

7
What is a Firewall?

• A hardware or software solution which restricts
  access between your network and an outside
  network.
• Firewall can be uni-directional or bi-directional
• Usually at perimeter (where the two networks
  meet)
• Like a Military Checkpoint
• Stops all traffic in and/or out of your network
• Inspects the traffic to see if it meets the
  security policy
• Allows or denies the traffic based on the
  security policy
• Like a real checkpoint, it will slow down
  traffic!!!

8
The Role of the Firewall

• Firewalls restrict access to services you don't
  want to make available to the outside
• This includes services and machines that you
  don't know about (Web servers on desktops,
  laptops using public ports, etc)
• Firewalls scale well and centralize management
• As the number of hosts increases, the ability to
  fully secure and monitor each host decreases.
  Firewalls help solve this problem by allowing
  some amount of centralization.
• It can not protect against everything!!!

9
Possible benefits of Firewalls

• Controlled access to networks, machines or
  services
• Centralization of some aspects of security
• Enhanced logging and auditing of traffic
• Enforcement of policy
• Can enhance privacy (encryption, NAT, etc)
• Ability to track network use, locate network
  abuse, spy on people )

10
What can't a Firewall do?

• Protect you from Denial of Service (DoS) attacks
• Protect you from inside attacks
• Protect you from inside networks, modems, etc.
• Protect you from natural disasters )
• Protect you from yourself (or stupidity)

11
Why not use a Firewall?

• Can interfere with legitimate traffic
• May block un-anticipated network traffic
• May modify the way things are done (e.g. passive
  vs active ftp, proxy server configuration, etc.)
• Can give a false sense of security
• Ignores internal threats
• Potential "Single Point of Failure" for your
  entire network or application
• Can be circumvented or bypassed!

12
The Role of the Host Machine

• The host machine must accept some responsibility
  for security itself
• Keep up with patches
• Eliminate unnecessary services
• Security through depth protect the host with
  multiple levels of defense (firewall,
  tcp_wrappers, access control, passwords, etc)
• Run services (and logins) with reduced privileges
• Don't be root/administrator/system unless you
  must be
• Eliminate Unix SUID programs when possible
• Don't run Unix services as root, chroot jail them
  if possible, etc.

13
The Role of PCG

• Things we could do to help
• Vulnerability scans of the physics network
• Service outsourcing for groups (web, e-mail,
  etc.)
• Incident and information "Point of Contact" for
  department
• Aid in recovery or analysis after an attack
• Consulting, education, etc?
• What would you like to see PCG do for you???

14
Types of Firewalls

• Bastion Hosts
• Packet Filtering firewalls
• Application-layer and Proxy Server firewalls
• Stateful Inspection firewalls
• Commercial "Kitchen Sink" firewalls
• Any or all of the above can be combined

15
Bastion Host Firewall

• Dual Homed Host Machine
• Machine is connected to both networks as
  non-routing host
• Users must login to this machine or proxy via
  this machine
• Very hard to manage and secure
• One user can compromise entire network!
• Very resource intensive
• Most connections will require a login on the
  machine
• Very inconvenient
• User's must login to yet another machine to do
  anything

16
Packet Filtering Firewall

• Operate at network level, not application level
• No state, no context, little awareness of what a
  packet does
• Fast, efficient, scale well
• Very easy to implement and maintain
• Mostly transparent
• Less secure and flexible than others because they
  have no context or content information.
• E.g. You can't allow ftp get's but block ftp
  put's

17
Application-Layer / Proxies

• Stronger security
• Can consider application design, context, etc.
• Can implement user-level authentication and
  authorization
• Can provide extensive contextual logging of
  traffic
• Harder to implement and maintain
• May require client software configuration or
  changes
• Requires writing new or custom rules/proxies as
  applications and protocols change or are
  introduced
• Slower performance, less scalable
• Generally requires more resources, and hence is
  more expensive

18
Stateful Inspection

• Provides some application-level awareness but
  doesn't break the client-server model
• Can still include proxy support if desired
• Fast, efficient, scalable, but requires more
  resources than a Packet Filtering system
• Mostly transparent
• Hard to develop content-aware rules (Limited
  content understanding)
• This is probably the "future of firewalls"

19
Commercial "Kitchen Sinks"

• Normal firewalls, with added bells and whistles.
• Virtual Private Networks (VPNs)
• IP address hiding/masquerading (NAT)
• Remote (web based) monitoring and control
• Content filtering and logging
• Virus protection software
• Encryption accelerators
• and almost anything else you can think of...

20
How to Implement a Firewall?

• Software Solution
• Pros Can run on existing hardware, easier to
  upgrade
• Cons Slower, may be hardware dependent
• Hardware Solution
• Pros Faster, no worries about software/hardware
  compatibility
• Cons More expensive, less flexible, harder to
  upgrade in box
• Commercial Solution
• Pros "Best of Breed", well tested, outside
  support
• Cons Expensive, dependent on supplier
• "Homespun" Solution
• Pros Can be cheaper, easily customized, not
  dependent on others
• Cons May not be well tested, no outside support

21
Default Firewall Policies

• Default to deny all
• If we don't explicitly enable it, then it is
  blocked
• May block unintended items
• Most secure implementation
• Often implemented by a refinement process...
• Default to allow all
• If we aren't explicitly blocking it, then it is
  allowed
• May miss things you want to block
• Least secure implementation
• Hard to refine, hard to audit. Can you really
  trust it???

22
Our Firewall Proposal

• Our general recommendations
• Either Packet Filtering (preferred) or Stateful
  Inspection
• Buy commercial version or create our own
• Must be a "highly available" system
• Restrict SMTP at firewall to Physics Department
  SMTP server (see next slide for details)
• Configure via "Default to deny all" policy.
• Start by allowing most services, and slowly close
  services over time, so as to make troubleshooting
  easy, and minimize problems
• No DMZ -- Protect everything!

23
NFS and E-Mail Server

• Non-stop, reliable NFS and E-Mail services!
• Proposing a Compaq AlphaServer Tru64 Cluster
• Pros Secure, manageable, improved uptime
• On-line OS upgrades, patches, disk
  reconfiguration, etc.
• Cons Initial cost high (but cheaper than cost of
  downtime?)
• Could interface with firewall to protect E-Mail
• No external SMTP allowed into the network except
  via this cluster (via firewall blocking and DNS
  MX records)
• Can stop relaying, viruses, SMTP exploits, etc.
  (from the outside)