s1.doc
TRANSCRIPT
Constructing Firewalls For Network Security
Tina Darmohray [email protected] Ranum [email protected]
Copyright (C) 1995 Darmohray
*Internet Security Problem Definition
*Security Policies
*Firewall Design
*Firewalls: Routers
*Firewalls: GatewayHosts
*Firewalls: ProxyApplications
*Firewalls: DNS
*Firewalls: Mail
*Firewalls: TISImplementation
Firewalls: Introduction
The Problem
*Connecting to the Internet carries with it inherent security risks
Anyone can connect to your machine
They may not all be trustworthy
*Preventing security problems at each server and client is extremely difficult
Might be impossible
The Morris worm certainly opened some eyes
A Solution: Firewalls
*One way to eliminate complex host and client security monitoring is ``Firewalls''
The Firewall guards a site at its front door
Only packets ``approved''by the firewall make it through
Security is dramatically enhanced
Perimeter protection vs. Protection in depth
Is a good solution for large sites
Flames and Firewalls
*The Internet is getting really large
Not everyone has good intentions
Unprotected computing isn't advisable
*Firewalls impede some traffic
It's not clear you want all traffic
Some argue "idle cycles" belong to the masses
What are the ethics surrounding/monitoring/filtering?
Safe computing is advisable
Firewall Approach
*Purpose - set up a configuration that puts up a wall between your local installation and the outside world
*Should be configured to allow certain functionality (ftp,telnet,mail)
*But, in general, make it difficult for an attacker on the outside to penetrate the firewall and gain access to your local nets
Firewalls: Policies
Creating a Site Security Policy
*Must be your first step in implementing any site security
*Must address security concerns
*Must identify risks
*Results in site-specific solution
Ask Yourself These Questions
*What are you protecting?
*How important is it to protect it?
*How likely is someone to try to attack/steal/corrupt it?
*How hard are they likely to try?
*How likely are they to succeed?
*How much will it hurt you if they do succeed?
What is "Safe"?
*What constitutes "safe" at your site?
*What are the answers to the preceeding questions?
*You'll find that "safe" == "acceptable risk"
What Resources Are WeTrying to Protect?
*Government secrets
*Trade secrets
*Personnel files
*CPU usage/downtime
*Abuse of network connections
*Particularly sensitive area of internal net
How important is it to protect it?
*Loss of trade secrets/competitive information
*Lawsuits
*Missed deadlines
*Loss of reputation
Against whom must the systems be defended?
*Who (how sophisticated) is your "enemy"?
*Thrill seekers just poking around
*Braggers
*Industrial spies
*Avoiding charges/quotas
*Outsiders vs. Insiders
Acceptable Risk Analysis
*Cost of implementation
*Cost of the failure of the firewall
*Designers' estimate of that likelihood
How Much Security can you Afford?
*Hardware/software/administration
*Convenience/productivity/morale
There Are No Absolutes
*When all is said and done, disconnection may be the right choice
*The decision should be made by weighing the risks against the benefits
*The design should be based on the preceeding analysis
If You're Sounding the Alarm
*You may be researching firewalls *for* your organization
*You may be researching them *despite* your organization
*If you're sounding the alarm and no one is listening document your warning post the next overhead on your office door hold on for the ride
Hi-Ho, Hi-Ho, It'sOff toWork WeGo
We're deeply concerned about security, what, oh, what should we do? But we have no budget, or even staff time, and our security guy was laid off, too.
So, please, we'd like you to tell us, how to solve our security blues, as long as it costs not a penny, and causes no changes in how the system is used.
Site Policy Examples
*Site Security Policy Handbook Working Group,"Site Security Handbook", RFC 1244, Internet Engineering Task Force, July 1991.
*gopher://gopher.eff.org/11/CAF/policies
*http://musie.phlab.missouri.edu/Policy/copies/tamu/collection1.html
Ethics of Computer Security
*Sensitive data
*Leave others' computers alone
*Integrity of data
*Counterintelligence?
*Counter attacks?
*Monitoring your own machine
*How about innocent probing?
*Lures; are they entrapment?
Firewalls:
Design
It'sall Trade Offs!
*There are variations on this theme
*Based on the security and functionality requirements identified for your site
*Implement the firewall design that best suits your site
Design Goals
*All traffic from inside to outside and visa versa must pass through the firewall
*Only authorized traffic, as defined by the local security policy,will be allowed to pass
*The firewall itself is immune to penetration
Stance Of Firewall
*That which is not expressly permitted is prohibited,or
*"Show me that it'sboth safe and necessary; otherwise we won't run it"
Identify necessary services
Address the security of those services
Block *all* other services and traffic
Enable all selected services only once they have been tested and believed to be secure
Stance Of Firewall, cont.
*That which is not expressly prohibited is permitted,or
*"We'll run it unless you can show me that it's broken"
Identify all the services that are believed to present risks; disable/secure them
Some design considerations
*The larger the program, the more difficult to verify
*Ifyou do not run a program, you can't be affected by bugs in it
*Everything is guilty until proven innocent
*The theme here is "bigger is *not* better" == run minimal configurations
*A firewall is not a general-purpose host (i.e. needn't run lots of software or have lots of users)
Some Firewall Nomenclature
*Screening Router/Choke - have the ability to filter traffic on an IP port level
*Bastion Host - a system with extra security,auditing, and modified software
*Packet-Filtering Gateways - a router used as a firewall
*Circuit-Level Gateways - relay UDP/TCP level connections
*Application Gateway - a forwarding service that runs across a firewall, usually run on a bastion host
Some Firewall Nomenclature, cont.
*Dual Homed Gateway - a single system with two network connections and routing disabled between them
*Screened Host Gateway - a screening router and a bastion host combination
*Screened Subnet - an isolated subnet situated between the Internet and the private network; also called the demilitarized zone (DMZ)
Selective Filtering Approach
*Uses the router to screen traffic
*Need not involve a bastion host
*Can avoid addition of proxy application software on clients
*Cheap, simple, and open to attacks
Dual-Homed Gateway Example
Internet
internal subnet client
dual homed host
external subnet
Dual-Homed Gateway is Appealing
*Simple to implement
*Requires minimum hardware
*Easy to verify
*(But) can'tweaken with flexible filtering
Common Screened Host Firewall Design
*Consists of two parts which separate the outside network from the internal one:
*Choke (Router) blocks all packets from the outside network destined for the inside network, unless they are destined for the gateway
blocks all packets from the inside network destined for the outside, unless they originated from the gateway
*Circuit/Application Gateway software passes data between the two networks
Screened Host Firewall Example
Internet
LAN
Gateway Router/ Choke Router/ Choke
Screened Host Firewall
*More expensive to implement
*More flexible for configuration
*Two systems to manage
*Can seletively weaken stance
Screened Subnet Example
Internet
internal subnet
external/ screened subnet
router
router bastion host
client
Screened Subnet
*Dual-homed gateway applied to an entire network
*Permits multiple hosts to exist on the "outside" network
*Can configure network routing not to advertise routes to the private network
Another DMZ Example
Internet
internal subnet
external/ screened subnet
router
router
bastion host
client
Choices, Choices, Choices!
*Security is the reciprocal of convenience
*Begin with a clear understanding of the site security policy and goals
*Each application function should be evaluated for design feasibility,potential risks, and user benefits
*The challenge becomes designing for the functionality which still provides the appropriate security
*Choose the right mix for your site!
Implementing the Firewall Design
*Lock the front door:choking-router restricts
routing (as above)
*Secure and empower the gateway machine
Standard host security on the gateway
Proxy commands to re-implement functionality
Configure DNS
Configuresendmail
Firewalls:
Routers
Packet Filtering Firewalls
*Provide a cheap and useful level of security
*Filtering abilities come with the router software
*Probably need the router to connect to the Internet anyway
*Public domain software packages available to roll your own router
Roll Your Own Routers
*Purchasing a router is easiest
*Anumber of host-based alternatives exist: screend,(anon ftp) gatekeeper.dec.com:/pub/misc/vixie/screend
TAMU drawbridge (anon ftp)
net.tamu.edu:pub/security/TAMU
ipfilterd (SGI)
How They Work
*Router/Choke
Can parse the headers of a packet and then apply rules and decide whether to route or drop the packet
*Drop packets based on
Source/destination addresses
Ports
Protocols
TCP/IP Layers
application application application
TCPUDP
IP ICMP
hardware interface
Protocol Layers and Addressing Schemes
*IPdatagram contains 32-bit host source/destination addresses
*TCP/IP employs a hierarchical addressing scheme
*Protocol identifier (e.g. TCP,UDP)
*TCP/UDP headers contain the source/destination port number
Defined Association
*Protocol (TCP/UDP)
*Local host's32-bit Internet address
*16-bit local port number
*Foreign host'sInternet address
*Foreign host'sport number
e.g. {tcp, 128.10.0.3, 1500, 128.10.0.2, 21}
TCP Encapsulation Example
ethernet header I P header TCP header data ethernet trailer
TCP 16-bit source/destination port address
ethernet 48-bit source/destination address
Internet 32-bit source/destination address
TCP and Virtual Circuits
*TCP provides reliable virtual circuits to processes
*Lost/damaged packets are retransmitted
*The ordering is maintained by sequence numbering of the packets
Configuring Packet Filtering Gateway
*Know what should/should not be permitted (based on your security policy)
*Translated into allowable packets
*Re-written into vendor-specific syntax
IP Access Lists
*Anaccess list is a sequential collection of permit and deny conditions for Internet addresses
Match: appropriatepermit/deny
No match:deny
*To specify an access condition an access list configuration command is used: access-list list {permit|deny} address wildcard-mask no access-list list
Router Configuration Warm-up
Address MaskAction
X1 Ignore (so address is allowed)
0.0.0.0 255.255.255.255Any address allowed
199.12.1.1 0.0.0.0Only 199.12.1.1
Exploiting a Convention
*UNIX supports the concept of reserved ports
Ports in the range 1-1023 are reserved
*Aprocess is not allowed tobindto a reserved port unless its effective UID is zero (the superuser)
*Ports 1024-5000 are automatically ("randomly") assigned by the system
*Ports >5000 are for user-developed, nonprivileged servers
Convention Example
CLIENTSERVER
TELNET TELNET
128,115,32.618.72.2.1
1026 23
23 1026
telnet mit.edu
source destination
Filtering Telnet Example
router
Internet
restricted telnet access
unrestricted telnet access
port 23
port >1023 port >1023
ethernet 0
ethernet 1
0 1
Router Configuration for Telnet Access
interface ether 0 ip address 128.115.32.0 255.255.255.0 ip access-group 102
ip access-list 102 permit tcp0.0.0.0 255.255.255.255 128.115.32.0 0.0.0.255eq 23 ip access-list 102 permit tcp0.0.0.0 255.255.255.255 128.115.32.0 0.0.0.255gt 1023
interface ether 1 ip address 128.115.0.0 255.255.255.0 ip access-group 103
ip access-list 103 permit tcp0.0.0.0 255.255.255.255 128.115.0.0 0.0.0.255gt 1023
Telnet Configuration Alternatives
*Suggesttelnetoutbound only
*Acompromise might be: telnetinbound from static addresses only
Use a non-UNIX based terminal server
Use smart card technology (more on this later)
Additional Router Configuration
*telnet from static address only ip access-list 102 permit tcp192.25.36.1 0.0.0.0 128.115.32.0 0.0.0.255eq 23 ip access-list 102 permit tcp0.0.0.0 255.255.255.255 128.115.32.0 0.0.0.255gt 1023
*Forcing telnet through a bastion host ip access-list 103 permit tcp128.115.32.6 0.0.0.0 128.115.0.0 0.0.0.255eq 23 ip access-list 103 permit tcp128.115.32.6 0.0.0.0 128.115.0.0 0.0.0.255gt 1023
Filtering FTP Sessions
*Normal operation requires an incoming call
*Acontrol channel uses port 21
*Transfers occur on port 20
*The server initiates the transfer call
Standard FTP Connection Example
CLIEN TSERVER 1.2.3.4 5.6.7.8
listen port 21 random port initiate call
331 Enter Password
230 Guest Login OK
STOR myfile
150 Connection Established
(file contents)
226 Transfer done
local port 20 listen on 5*256+6
create random port 5*256+6
PORT 1,2,3,4,5,6
200 Port OK
(open port 5*256+6)
PASS [email protected]
USER anonymous
FTP and PASV Command
*Modify ftp to issue a PASV command to the server
*But you must distribute the modified clients to all inside machines
*Not all servers understand the PASV command
PASV Example
CLIEN TSERVER 1.2.3.4 5.6.7.8
listen port 21
create random port
listen on random port random port
random port initiate call
331 Enter Password
230 Guest Login OK
PASV
227 Passive(5,6,7,8,9,10)
STOR myfile
150 Connection Established
(file contents)
226 Transfer done
open port (9*256+10)
USER anonymous
PASS [email protected]
Sample TCP Session
SYN(2000), ACK(1001)
ACK(2001)
ACK, data
ACK(2300), FIN(1500)
ACK(1501), FIN(2400)
ACK(2401)
SYN(1000)
ACK(1501)
CLIEN TSERVER
connection established
connection closed
server close
client close
passive open active open
SYN/FIN/ACKConclusions
*Packets with SYN represent the first packets traveling in either direction
*Packets with ACK set are part of an on going conversation
*Good idea to restrict connnection establishment to internal hosts only
*Aninside kernel should reject a continuation packet for a connection that has not been initated
Trusting Trusted Ports
*We can't control a foreign host'sport numbers
*Better to permit outgoing calls to trusted ports
Filtering X
*Xis "backwards"
*Users' display (monitor,keyboard, mouse ) is a server
*The result is that use requires an incoming call
XThreats
*Intruders can:
Dump data from screens
Monitor keystrokes
Generate bogus input
*Recommend blocking all inbound calls to ports
6000-6100
ICMP
*ICMP provides useful information (ping/traceroute)
*ICMP can be used for denial of service attacks
*Outsiders can map your network with ICMP
*Becareful ofRedirectmessages
UDP
*Is a datagram protocol - not a virtual circuit
*Has no SYN/ACK bit to aid in filtering
*The source port is subject to forgery
*RPC services pose problems
*Maybe just block all UDP,with some fortunate exceptions
Portmapper Problems
*Portmapper maps an RPC service to the UDP/TCP port where that server is currently listening
*Blocking access to Portmapper (port 111)is not enough as intruders can just try all possible ports
DNS (UDP) Filtering
*Uses UDP for most lookups
*Servers always use port 53, on both ends of the connection
*Uses TCP for zone transfers, port 53 for sending end of zone transfer
NTP (UDP) Filtering
*Similar to DNS, except uses port 123
About Screening Routers
*Inbound and Outbound filtering capability
Allows the router itself to appear behind the firewall
Some sites want to monitor outbound (ftp) traffic
Allows you to recognize address spoofing attempts
Convenience of configuration/administration
*Use different vendors for routers in a DMZ set-up
Source Port Example
*Some routers don'thave source port filtering capability
Src Addr.Dest. Addr.Src PortDest. Port
external internal>= 102423
internal external23 >=1024
internal external>= 102423
external internal23 >=1024
*"Start of Connection" packets can help pin things down
Routing Information
*Do not advertise routes to "unavailable" internal nets
*Do not trust routes learned from the outside
*Bogus IP numbering on internal nets is a messy security strategy
Selective Filtering Approach
*Uses the router to screen traffic
*Need not involve a bastion host
Screening router example
*Can avoid addition of proxy application software on clients
Selective Filtering Problems
*Router configuration can get to be a hit/miss proposition
*Can leave you wide open above port 1023
Monitoring Selectively Filtering Firewalls
*Servers can run on your net without your knowledge
*probe_tcp_ports is a tool to look for services on the net
Run it via cron to monitor your net
Available (anon ftp) greatcircle.com:
pub/archive/firewalls/firewalls.9210.Z
*Output gives port numbers and service names: Host gateway.com, Port 23 ("telnet" service) connection ... open. Host gateway.com, Port 25 ("smtp" service) connection ... open.
Packet Filtering and Performance
*Filtering does cause a performance hit
*Claimed numbers vary
*T1line is 1.544 Mb/sec; will typically be the bottleneck
*Pay attention to number and order of rules
*Watch that routers between internal nets aren't affected by filtering rules
Firewalls:
Gateway Hosts
Implementing the Gateway Host
*Continuing on our present path:
Install standard security precautions on the host
Then proxy commands to build functionality back into network connection
Then fixDNS
Finallysendmailto hide hosts
About Intrusions
*Afew seconds of su access blows the whole thing
*Smart intruders cover their tracks; logs help
*Imported programs can be a problem
*Threats come from inside and outside
Common Types of Attacks
*Denial of Service:consuming a resource in order to render it useless
*Spoof: Programwhich tricks a user into believing it'ssomething else (e.g., fake login program)
*Address Spoofing:Pretending to be someone you are not
More Common Types of Attacks
*Virus: copiesitself into other program; runs when that program runs
*Worm: Independentprogram which copies itself; usually nondestructive
*Trojan Horse:code living inside another program (disguise for the perpetrating code)
*Trap door:Undocumented means of access to a program
Gateway Choices
*Nothing set in stone
*More software available for common platforms
*Don't select based on security advisories
*Choose the "devil you know"
Make a Bookmark
*Before you modify the system, make a "bookmark" date > /etc/installdate find / -newer /etc/installdate -print
*When modifying system files: cp /etc/mumble /etc/mumble.orig vi /etc/mumble
Server Processes
*Network service processes are generally started at boot time or from service listeners (i.e.inetd)
Disable boot time servers (/etc/rc*)
Disable servers in/etc/inetd.conf(list of assigned numbers in RFC 1340)
Usepsto check the process table
Usenetstatto check network sockets
Server Processes, cont.
*If a server process is running, find out what it does
Check the manual
Determine if it is necessary
If it is not necessary to the operation of the firewall system, disable it
*Remember,the firewall is a dedicated system
Boot Time Servers
*Servers started in/etc/rc
NFS lpd
Accounting inetd
Boot Time Servers, cont.
*Servers started in/etc/rc.local biod nfsd mountd portmapper
syslogd sendmail
inetd.confServers
*Listen on specified ports and start server as needed
*Not uncommon forinetd.confto have > 700 lines as shipped
*You'd be wise to strip this down to a lot less
Exampleinetd.confFile
#Time service is used for clock syncronization. # time streamtcp nowaitroot internal time dgramudp waitroot internal # #The following are used primarily for testing. # echo streamtcp nowaitroot internal echo dgramudp waitroot internal discard streamtcp nowaitroot internal discard dgramudp waitroot internal daytime streamtcp nowaitroot internal daytime dgramudp waitroot internal chargen streamtcp nowaitroot internal chargen dgramudp waitroot internal
More Example inetd.conf File
# #The following are candidates for "wrappers". # # ftp streamtcp nowait root/wrapper in.ftpd telnet "tcp nowait root/wrapper in.telnetd login "tcp nowait root/wrapper in.rlogind finger "tcp "nobody "in.fingerd smtp "tcp nowait root/c_wrapper smap nntp "tcp """plug-gw nntp #
ABare System'sProcess Table
#ps-ax
PID TT STATTIME COMMAND
0? D0:29 swapper 1? IW0:08 /sbin/init - 2? D0:00 pagedaemon 85 ?IW 0:36syslogd 111 ?IW 330:01update 114 ?IW 0:08cron 120 ?IW 0:34inetd 23485 co IW0:00 -sh 87 pd IW0:00 -std.19200 ttyb (getty) 5603 p0 R0:00 ps -ax
*Asopposed to >70 on an "idle" user's workstation
Spoofing Servers
*Reading across the network is not like reading from afile
*The UDP protocol is much easier to spoof
Protocol simpler
No virtual connection
*Discovery-based servers are open for spoofing
*Can'trun NFS/NIS
Spoofing Example
Client Server
Intruder
Fake Reply
Request
Reply
Some Spoofing Attacks
*Denial of service with incorrect password response
*Creating new users with fake /etc/passwd response
*Gain access with incorrect hosts.byaddr response
*Read more about this in (anon ftp: net.tamu.edu/pub/security) NIS_paper
File System Security
*Remove or rename the binaries of all unnecessary commands
*chmodall system directories to 711
*Programs in general should be --x not r-x (doesn't work for shell scripts)
*Mount all possible disks read only
Vulnerable Files
*Several files are particularly vulnerable and should be protected appropriately: /vmunix /dev/kmem/ dev/drum /etc/passwd
Any setuid program
Any program EVER run by root
RBK - f.gahost.19 Aug11, 1995
File System Auditors
*TRIPWIRE: a file system integrity checker (anon ftp) coast.cs.purdue.edu:pub/spaf/COAST/Tripwire
*COPS: another popular auditing package (anon ftp) ftp.cert.org:pub/security/cops
Kernel Configuration
*Build a kernel that does not include uneeded services
NFS
ip for warding
SNMP
*Ability to do this varies with vendors
Accounts/Password Security
*The gateway machine cannot play the trusted host game
*Minimum number of user accounts
*Restrict root logins
To the console only
sudo
op
Checking for "Trust"
*Quick.rhostsfinder: #/bin/perl open(P, "/etc/passwd") || die "Can't open passwd"; or open(P, "ypcat passwd|") || die "Can't open passwd"; while(<P>) { $home = (split(/:/))[5]; if (-e "$home/.rhosts") {print "$home/.rhosts\n"; } }
RBK - f.gahost.23 Aug11, 1995
It'sEasy to Steal Network Data
*Theetherfindandtcpdumpprograms do it
*Kolstad modifiedtcpdumpto watch NFS file accesses to catch an NFS mail intruder
*Other people might steal clear-text passwords, e-mail, or keystrokes (like passwords)
RBK - f.gahost.24 Aug11, 1995
Securing Offsite Logins
*The only way to beat password crackers is to get out of the game
*One-time passwords/challenge-response systems is your only defense
*One-time password systems provide authentication over networks
*Often employ "smart-card" technology
How It Works
*The user's secret password never crosses the network in the clear
*The user is challeged at login
*The response is generated locally and sent back
*The response is encrypted and is only good one time
Some Available Solutions
*Security Dynamics' SecurID
*Enigma Logics' Silver Card
*Digital Pathways' Secure Net Key
*S/Key package, developed at Bellcore, available (anon ftp) from crimelab.com
Modems - Part of Your Perimeter
*Modems allow people off-site into your environment
Scanning finds modems
Logging detects this kind of breakin
Call back modems help a lot!
Ensure your modems hang up when people disconnect
Ensure user is logged out when modem is disconnected
RBK - f.gahost.28 Aug11, 1995
More Modems
*Challenge-response boxes can help lots
*Root on disconnected terminal/modem is trouble
*Only ``console''labeled as ``secure''inttytab
*Noterminals labeled as ``secure''inttytab
RBK - f.gahost.29 Aug11, 1995
Logging and Gateway Security
*Turn on system logging
Add the tcp_wrappers package available (anon ftp) from cert.org in pub/tools
Create a system drop-log
More ontcp_wrappers
*AKA log_tcp, tcpd
*Well-accepted technique for protecting individual computers (gateway hosts or single internal machines)
*Can monitorsystat,finger,ftp,telnet, rlogin,rsh,exec,tftp,talk,etc.
*Advertised availability on SunOS, Ultrix, DEC/OSF,
HP-UX, AIX, Apollo, Sony,NeXT,SCO, Cray,and more
*Doesn'trequire any changes to existing software
How it Works
*Normally,inetdpasses an open network connection to a network server program using the execsystem call
*Thetcpdprogram is substituted for the normal network server program (ininetd.confor by moving/linking)
*tcpdverifies the remote host connection, logs the connection, andexecsthe real server
Paranoia and Protection
*The default configuration oftcpdrejects connections when the host name does not match the host address or the host name cannot be verified
withgethostbyname()
*tcpdguards against source route attacks
Source Route Realization
*"Source Routing" is specified as one of the IP options in RFC 791
*RFC 791 states that, "What is optional is their transmission in any particular datagram, not their implementation."
*Source Routing is used to route the internet datagram based on information supplied by the source
*Destination hosts which receive source routed packets are required to reverse the route back to the source!
Example Source Routing
*Source routing overrides the normal routing tables
source routing
routing tables
proxy applications
IP
TCP
Example Access Control
*Optionallytcpdcan provide access control on a daemon or client basis
#cat /etc/hosts.allow ALL: LOCAL, .our.domain, our.domain in.telnetd: outsidews.other.domain
#cat /etc/hosts.deny in.fingerd, in.telnetd: ALL
*Can use IP address, subdomain or network addresses, as well
Example Access Monitoring
#grep tftp /etc/hosts.deny in.tftpd: ALL
#grep tftp /etc/hosts.allow ALL EXCEPT in.tftpd: cracker.latest.host: echo "%d from %c" | mail root
tcpdOutput
Jan 13 17:59:51in.ftpd fromVAX1.Winona.MSUS.EDU [VAX1.Winona.MSUS.EDU] 13-JAN-1992 20:02:00.76Uptime: 6 04:33:47
User NameTerm StateImage Location ------------------------------------------------------------------- CHRISPY Placce,Christophe NVA248 LEFEDT UnknownServer Down SHANGHAI Ke-Min, ZhouTWA315 LEFUnknown Server Down WNRODELA Larson, Ronald DTXH6: LEFUnknown Server Down
Jan 13 18:04:03in.telnetd fromVAX1.Winona.MSUS.EDU [VAX1.Winona.MSUS.EDU] 13-JAN-1992 20:06:12.37Uptime: 6 04:37:58
User NameTerm StateImage Location ------------------------------------------------------------------ CHRISPY Placce,Christophe NVA248 LEFEDT UnknownServer Down JKENNEY Kenney,Jason T.LTA116 LEFEDT UnknownServer Down
Creating a Drop-log
*Usesyslogin UNIX
Messages of typeauthare probably most important, e.g.login,su,date
*Log interesting events to a hard-copy console, or a dedicated printer
*Use one secure machine on the network to log events from many machines
*You might want to log failed login attempts, but not the password that was used
Routing and Gateway Security
*Turn offsource routing
*Turn off IP forwarding in the kernel
*Adaptive routing protocols should only trust routes from local routers or routers belonging to your service provider
Checking for Source Routing
*One easy way to tell if you can get source-routing through a firewall is to try it
*The version of telnet on ftp.uu.net:/systems/unix/bsd-sources/usr.bin/telnet supports it via the command line telnet @router:targetto telnet to target via router
*Bear in mind, though, that many hosts don't do the right thing with source routing; in particular,some of them crash...
RBK - f.gahost.41 Aug11, 1995
Join the Security Community
*Get on the security alert list by writing to the CERT (Computer Emergency Response Team); details on next slide
*Join a mailing list about security risks: risks
[email protected] (or,equivalently,read the newsgroup comp.risks)
*Designate a person to get all reports about security
RBK - f.gahost.42 Aug11, 1995
Computer Emergency Response Team (CERT)
*Founded by DARPAinthe wake of the Internet worm
*Monitors computer security and break-in activities
*Acts as an information clearinghouse and resource center; sends out notices to alert users to potential security problems
*Has no law enforcement or regulatory authority
*Reach them:
Be prepared to verify your identity cert.org is also the anon ftp repository of previous bugs
+1 412 268-7090 (24 hours/day)
Computer Incident Advisory Capability (CIAC)
*Department of Energy'steam located at Lawrence Livermore National Laboratory
*Develops guidelines for incident handling and software for responding to events
*Conducts training and awareness activities
*Alert/assist sites with vulnerabilities and attacks
*Reach them:
+1 510 422-8193
NIST - National Institute of Standards and Technology
*Charged with the development of computer security standards
*Has some informational pamphlets
*Contact them at:
NIST Computer Security
Division A-216
Gaithersburg, MD 20899
+1 301 975-3359
FBI
*Have law enforcement authority in the computer crime area
*Contact your local office (and you'll probably wind up with one of the 2 folks the FBI has in this area)
Current Information and General Discussion
*Read the USENET news groups:
alt.security
comp.security.announce
*Join the Mailing Lists:
Firewalls:
Proxy Applications
``Proxy''Functionality
*Desire to maintain functionality in a firewall
network design
*"Proxy" - the authority to act for another
*Desired functionality: ftp:file transfer protocol telnet:user interface to a remote system gopher:distributed information delivery
system DNS mail news X
World Wide Web
Firewall Progression
*Packet filtering
*Public domain, modified-code, proxy solution
*Freely available toolkit, no code modifications required
*Dynamic packet filtering
*Transparent proxies
*Solutions are converging
ASimple Proxy; Housework
#include <stdio.h> #include <unistd.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <sys/stat.h> #include <fcntl.h> #include <bstring.h> #include <sys/time.h> #include <errno.h>
ASimple Proxy
main(int argc, char **argv) { int sock, s; int fd; struct sockaddr_in sa; pid_t pid; int x; fd_set fdset; int len, ret, salen; char buf[256]; int bufsize = 256;
if (argc != 4) { fprintf (stderr, "Usage: proxy localport remoteaddr remoteport0); exit (1); }
if ((sock = socket (AF_INET, SOCK_STREAM, 0)) < 0) { perror ("socket"); exit (2); } sa.sin_family = AF_INET; bzero ((char *)&sa.sin_addr, sizeof (sa.sin_addr)); sa.sin_port = htons(atoi(argv[1]));
More Simple Proxy
if (bind (sock, (struct sockaddr *)&sa, sizeof(sa)) < 0) { perror ("bind"); exit (2); }
if (listen(sock, 5) < 0) { perror ("listen"); exit (2); }
while (1) { salen = sizeof (sa); if ((s = accept(sock, (struct sockaddr *)&sa, &salen)) <0){ if (errno == EINTR) { continue; }else { perror ("accept"); exit (2); } } if ((pid = fork()) < 0) { perror ("fork"); exit (2); }else if ( pid == 0) { break; /*child */ } close (s); } close(sock);
Still More Simple Proxy
/* *** Do authentication *** */ fprintf (stdout, "Received connection from %s.0, inet_ntoa (sa.sin_addr));
if ((fd = socket (AF_INET, SOCK_STREAM, 0)) < 0) { perror ("child: socket"); exit (2); }
sa.sin_addr.s_addr = inet_addr (argv[2]); sa.sin_port = htons(atoi(argv[3])); if (connect (fd, (struct sockaddr *)&sa, sizeof(sa)) < 0) { perror ("child: connect"); exit (2); }
while (1) { FD_ZERO(&fdset); FD_SET (s, &fdset); FD_SET (fd, &fdset); if (select (32, &fdset, NULL, NULL, NULL) < 0) { perror ("select"); exit (2); }
Last of Simple Proxy
if (FD_ISSET (s, &fdset)) { if ((len = read (s, buf, bufsize)) < 0) { perror ("child: read"); exit (2); }else if (len == 0) { exit (0); } if ((ret = write(fd, buf, len)) < 0) { perror ("child: write"); exit (2); }else if (ret == 0) { exit (0); } } if (FD_ISSET (fd, &fdset)) { if ((len = read (fd, buf, bufsize)) < 0) { perror ("child: read"); exit (2); }else if (len == 0) { exit (0); } if ((ret = write(s, buf, len)) < 0) { perror ("child: write"); exit (2); }else if (ret == 0) { exit (0); } } } }
Multi-client Proxy
*socksis a publically available proxy server, sockd,available (anon ftp) from ftp.inoc.dl.nec.com in pub/security
*Itcomes with client programs corresponding to finger, whois, ftp, telnet,and xmosaic(for WWW/Gopher/Hytelnet/ftp)
There is also a library module for adapting other applications
SOCKS Access
*Alist of users can be included along with other fields (source address, destination address,service/port) for permission/denial of access
*Identd is used in the SOCKS server to try to verify the actual user-ids
*Ashell command can optionally be specified which is executed if the conditions of that line are satisfied
ExampleSOCKSConfiguration
#telnet access for root/joe on net 18.2.2 from 12.1.7.1 permit *=joe,root 12.1.7.1 0.0.0.0 18.2.2.0 0.0.0.255 eq telnet # #Permit all users on network 129.101 ftp access permit 129.101.0.0 0.0.255.255 eq ftp # #Deny everything else. #Upon an attempt, finger the client host and pipe the #result to root's mail with appropriate Subject: line. deny 0.0.0.0255.255.255.255 : finger @%A | /usr/ucb/mail -s 'SOCKD: rejected -- from %u@%A to host %Z (service %S)' root
*Thetest_sockd_confprogram can be used to test the access control file
XProxy Service
*xforwardprovides a user-level X11forwarding service, available (anon ftp) from crl.dec.com as /pub/DEC/xforward.tar.Z
CERN WWW (httpd) Server
*Thecern_httpdcan be configured to run as a proxy
*Run on the firewall machine, it provides access to the outside
*Additionally it performs caching of documents for faster response times
WWW and Security
*Operation generally involves a host querying a server and receiving a response
*The queries, documents, and pointers all all potentials for danger
Returned documents include format tags
Servers that blindly accept pointers are at risk
Queries that are in fact scripts/servers themselves are a particualar problem
SecureftpInstallation
*Ifyou desire to enableftpfor others, do this:
*Create /ftp directory with copies of executables and system files; protect them
*Create /etc/ftpusers to restrict accounts which are not allowed to use ftp
*Create ./ftp account with disabled password and unwritable home directory
*Create ./bin subdirectory containing ls, unwritable by anyone
*Create ./etc subdirectory with copies of passwd and group files; delete unnecessary lines
*Create ./pub subdirectory,ifworld writable, anyone can put, otherwise they can just get
SpecializedftpServers
*wuarchiveftpd
*Has some security features built in
Works with S/Key
Can selectively apply restrictions
*TIS' Firewall Toolkit FTP-Gw
MBone
*Encapsulated multicast packets hides the ultimate destination of the packet
*Network audio sessions use random ports
*Anyone is allowed to register new sessions on ports above 3456
Firewalls:
DNS
TMD - fire.dns.00Aug 11, 1995
DNS' Firewall Role
*Help hide internal network structure
*Replace functionality through mail gateway interaction
our.domain Master DNS Servers
Internet
LAN
gateway2 gateway1 choke router/ choke router/
BIND hosts Data File
*/etc/named.bootspecifies the location of this file
*Use MX records to accept mail on behalf of the domain, e.g., our.domain
*Sample: Configuration information for our.domain @INSOA gw1.our.domain.postmaster.gw1.our.domain. ( 296 ;Serial 3600 ;Refresh 300 ;Retry 86400 ;Expire 3600 );Minimum IN NS gw2.our.domain. IN NS gw1.our.domain. IN MX 0gw2.our.domain. IN MX 10gw1.our.domain. IN A128.115.32.7 ;forold mailers
Additional DNS Possibilities
*Some sites don'twant internal machine information available
*With MX records and properly configured supporting applications, internal machine information is not needed
DNS Possibilities (cont.)
*Can run 2 sets of domain name servers for the site, internal and external servers
External servers keep data for just the machines which are reachable from the outside world
External servers' resolv.conf points to the internal servers
Internal servers contain all the information for the internal nets
Internal servers forward request for outside data to the external servers, which proxies the question
DNS Proxy/Forwarding
*Ifyou designate the external DNS servers as site forwarders, all the off-site queries are sent to the forwarders first
*You must restrict the internal name server further, stopping them from trying to contact an off-site server,bydesignating it as a slave server
*Add the following lines in the named.boot file forwarders 128.115.32.1 128.115.32.2 slave
Dual-DNS Example
Internet
internal subnet
external/ screened subnet
router external dns server
internal dns server
client
Firewalls:
TMD - fire.mail.00Aug 11, 1995
Mail Gateways
*Gateway sometimes describes software that performs specific conversions at layers above the network layer
*Mail gateways convert electronic mail from one format to another
*Our gateway is an application level electronic mail gateway that:
Routes mail between the internal LAN and the Internet and then
Rewrites outbound mail headers appropriately
Where WeAre Going
*First we'll discuss site-wide mail topology
Proposed scheme
What the benefits are
*Then we'll cover how to modify the sendmail.cf file to support our mail topology
Firewall Mail Topology
Internet
LAN
gateway2 gateway1 choke router/ choke router/ /relay1/relay2
Security Benefits of Electronic Mail Design
*Limited access tosendmailfrom the Internet
*Hide the local structure of internal organization by rewriting, thus: [email protected]
becomes: [email protected]
Security andsendmail
*sendmailis the prevalent implementation of the SMTP protocol
*Itcertainly got a lot of press in regards to network security!
Read about the worm in: anonymous ftp cs.purdue.edu, pub/spaf/security
*sendmailis NOT a trivial piece of code, easily submitted to a code review
*Itruns setuid as root
SMTP Mitigations
*Create a simple program that implements the minimum functionality required by the SMTP protocol
*Limit the permissions it requires
*smrshlimits sendmail'sscope of program execution
MD - fire.mail.06Aug 11, 1995
Administrative Benefits toMail Design Philosophy
*The configuration file on the master mail machine(s) must be able to handle connections to external networks
*The rest of the machines on site can have a simple configuration file that forwards mail to the master(s)
*Built in redundancy gives you robustness and load balancing (costs more, but avoids network bottleneck and single point of failure)
*With header rewriting, users' email addresses never have to be relearned or re-distributed
*The master machine(s) can be replaced and the site email addresses can remain unchanged
More Mail Design
Source OnMailer DeliveredTo Destination
Relay tcpInternet HostInternet
local tcp FS/SALocalnet
Standalone tcpRelay Internet
localtcp FS/SALocalnet
local SALocal
FS tcpRelay Internet
localtcp FS/SALocalnet
local FSLocal
Client tcpRelay Internet
nfs FS/SALocalnet
*Source machine and destination address will determine the mailer/machine combination involved in the mail delivery
Designing a sendmail.cf For Your Site
*Don'tstart from scratch - modify an existing sendmail.cf
*Design the sendmail.cf to support your site's mail topology
*Don'tpanic; you can do this!
Design Goals
*Rewrite all headers to appear as though they originated from fileservers rather than clients - reply headers point to servers
*Route all outbound mail through mail gateways
*Hide internal LAN structure by rewriting all outbound mail headers to appear as if the mail originated from the gateways
*Accept all inbound mail on GATEWAYs
Route Outbound Mail Through Gateways
*Defining a Macro DR/**/RELAY
*Ruleset 0 R$*<@$+>$* $#tcp$@$R$:$1<@$2>$3
Rewrite Outbound Addresses
Mtcp, P=[IPC],F=MSDFMUEXL, S=15, R=14, A=IPC $H, E=sp 0.5 S14 R$- R<@$+>$@<@$1>$2 resolve<ROUTE-ADDR> R$*<@$+.UUCP $:$2!$1<@$J>put local name on UUCP R$*:$* $1.$2map colons to dots
S15 R$- $@$?D$1@$D$|$1@$J$.local sender R$* $:$>14$1normal rewriting R$*<@$*> $:$1@$Da@ourhost => a@ourdomain
Accept Inbound Mail ToDomain Name
*Remember the BIND MX Record!
*Ruleset 0 R$*<@$D>$* $#local$:$1 user@ourdomain
*Maintain a global ``aliases''file
Aliases
*For forwarding mail from the gateway to the internal mail server machines
*For forwarding between internal mail server machines
*The new aliases command is send mail -bi and must be run when aliases file changes
Recognizing Mail Subdomains
*Set the MX record to match the subdomain(s)
*Ruleset 0 R$*<@$D> $#local$:$1user@ourdomain R$*<@$=L.$D> $#ether$@$L$:$1 [email protected]
*S15 R$*<@$=L.$D> $:$1@[email protected] R$*<@$*> $:$1@$Da@ourhost => a@ourdomain
Firewalls:
TIS Solution
The TIS Firewall Toolkit
*Aset of components for building firewalls
*Available (anonymous ftp) from ftp.tis.com:pub/firewalls/toolkit
*Does not enforce or mandate any particular policy
Firewall Toolkit, cont.
*Provides a minimum functionality for services that can be implemented with high security
telnet
ftp
rlogin
smtp
*Will work with other firewall or security software (e.g. COPS, SOCKS, Tripwire)
Blocking Traffic Between Networks
*Toolkit software "doesn'tcare" how network traffic is blocked
*May be a mixture of:
Screening router
Complete traffic blocking via disabling routing
Netacl: a TCP Wrapper
*Front end TCP wrapper to control access to TCP based services
*Process started byinetdreplaces real server process
*Checks to see if source of connection is permitted service
*Includes ability to chroot or change user-id of server process prior to invoking it
Available Proxies
*TN-Gw: Telnet proxy
*Rlogin-Gw: Rlogin proxy
*FTP-Gw: FTP Proxy
*Plug-Gw,X,WWW,and Gopher
*Donot require client-side software
Smap - SMTP queuer
*Toprevent outsiders from communicating directly with large privileged processes (like sendmail)
*Mail is gathered to disk under chroot as unprivileged user
*Daemon process (smapd) sweeps spool directory and hands mail offtosendmail for delivery
*smapdmay perform additional scanning of message before handing offtosendmail
Current version performs some minimal checks for addresses in the envelope that contain pipe commands
Authentication Server: Authsrv
*Can be compiled with support for multiple forms of authentication
Many of the common smart-cards are supported S/Key is supported
*New options may be added without harming existing database
*Has an administrative interface
portscanLists Active TCP Ports
#portscan localhost
localhost: trying stream ports between 0 & 30000 echo discard daytime chargen ftp telnet time finger
netscanProbes Nodes on Network for Reachability
#netscan -v 128.115.29
trying subnet 128.115.29
128.115.29.1 w33public.mitre.org (128.115.29.2) 128.115.29.3 128.115.29.4 bkillam-pc.mitre.org (128.115.29.5) wv3100.mitre.org (128.115.29.6) ccelwamci.mitre.org (128.115.29.7) ccelwam2.mitre.org (128.115.29.8) cderose-mac.mitre.org (128.115.29.9)