Constructing Firewalls For Network Security Tina Darmohray tmd@iwi.com Marcus Ranum mjr@iwi.com Copyright (C) 1995 Darmohray Today'sTopics *Today'sSchedule *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 user@my.host 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 me@my.host 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(

) { $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 request@csl.sri.com (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: cert-advisory-request@cert.org 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 ciac@llnl.gov 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@greatcircle.com academic-firewalls@net.tamu.edu 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 #include #include #include #include #include #include #include #include #include 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: Mail 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: user@machine.our.domain becomes: user@gateway.our.domain or user@our.domain 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 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 user@sub.ourdomain *S15 R$*<@$=L.$D> $:$1@$L.$Da@sub.ourdomain 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)