Intranet vs. Internet: Firewalls

Presented at MacWorld/Expo San Francisco '99, as part of the MacWorld/Pro conference.

Notes to Self
1. Segue to TidBits?
2. Research before buying firewall
  1. Cisco is good, but nothing's good unconfigured.
  2. Medscape got a firewall router, but never configured it.
  3. Look for sample configs from the vendor before purchase.
Once upon a Time
1. AOL didn't identify itself as the Internet.
2. Servers were used for private networks.
3. WANs were rare, expensive, and used highly restricted.
4. Security was simpler -- physical blocked most attackers completely.
5. A locked door is the best protection in such a situation.
Now
1. Many things are decentralized.
2. Internet makes access from outside the server room available and increases demand for access to services / servers.
3. A library or coffee shop is now a valid access point for computer resources. This provides increased flexibility for users, and additional workload for administrators.
4. Firewalls can restore much of the presence-based security lost when connecting to the Internet, through restrictions placed on people not 'on the premises'....
Passwords
1. After presence (physhsical) security, the next best option is strong passwords.
2. Any admin password should be at least 6 characters and very strong.
3. General user passwords should also be strong, but this is less important.
4. Admins should keep a list of accounts and change passwords at least yearly (if this is an option on servers, use it!).
5. Assume that any password may be attacked a few thousand times by someone with vague personal knowledge of the owner -- this may not be likely, but it's what you must defend against / prepare for. If your password is guessable, 'crack'-able, or weak, it's useless.
Hackers
1. Tabloids (which covers most news reportage for purposes of this discussion) are happy to tell you that the Internet contains about a thousand real business users and trillions of sociopathic teen hackers.
2. This is of course absurd (but still widely reported), but there is a germ of truth.
3. There are lots of hackers on the Internet (think about it -- free or flat-rate connectivity to lots of machines, with no centralized admins and lots of documented weaknesses is hacker hog heaven).
4. Motivations may include: challenge, money, ego, destructiveness.
5. Remember -- while an employee might be able to physically shut down your server, this is fairly obvious; also, they generally have a stake in your success. You don't have this commonality with most Internet users, and even if you can figure out who attacked your servers, you can't fire 'em.
Firewalls
1. Firewalls can be a valuable barrier to interpose between yourself and this mass of anonymous and unpoliced humanity.
2. Principles
  1. Firewalls work by preventing certain 'dangerous' activities -- realize ahead of time that you are likely to be restricting or preventing legitimate activities in order to forestall malicious activities.
  2. Since each organization has different servers and services, a generic firewall configuration would be useless -- you must be prepared to carefully consider what services you offer and who should have access, and build this knowledge into your firewall.
  3. Firewalls work by making a distinction between here (generally called the 'Intranet') and there (the Internet) -- or us and them, and restricting traffic between the two.
  4. A firewall configuration is basically a list of IP address blocks, and the services those IP addresses are allowed to access. This will become clearer when we talk about ports, which identify services on the Internet.
3. Protection from outsiders
  1. Think of a firewall as a military checkpoint -- people with legitimate business are allowed in, but anyone without authorization is turned away.
  2. Most types of crashing-server-type network attacks are documented and recognizable within a few weeks after their first appearance, and can be blocked completely by properly-configured firewalls.
  3. Generally speaking, firewalls have a short list of things they (Internet users) are allowed to do to computers on the Intranet.
  4. A firewall can limit the number of ways an Internet user can access Intranet services, bringing the possibilities down from from effectively infinite to a manageable handful, which you can focus on securing and monitoring.
4. Control over insiders
  1. Firewalls can also log suspicious and normal activities across your Internet link, and block certain activities (most often connections to certain websites) -- for an example, see http://www.dilbert.com/comics/dilbert/financial/tphbx.html.
  2. Financial institutions often block outgoing FTP (File Transfer Protocol) transfers, in an effort to keep proprietary data private.
Intranets
1. Generally speaking, an Intranet is a LAN with a firewall-controlled Internet connection which places severe restrictions on external->internal connections and minor restrictions on internal->external connections.
2. There are lots of other ways to create an "Intranet"!!
  1. You may not need a real Intranet at all, if your confidence in passwords is strong enough relative to your exposure (often the case if money isn't involved).
  2. Using VPN (encrypted IP) technology, you can get strong security without basing it around physical access to a LAN. This may work with or instead of a firewall-based solution, and is beyond the scope of this discussion.
  3. Your web server (for example) may be able to restrict access to certain areas of your site to local users, by recognizing local IP addresses.
TCP, UDP, and Ports
1. Internet traffic uses 'port numbers' to identify the sending and receiving services.
2. The higher-level protocols run on top of two more fundamental protocols: TCP (Transmission Control Protocol) and UDP (Universal Datagram Protocol).
  1. Each of these protocols uses port numbers from 0 to 65,535; some services use UDP (such as SNMP), some use both (DNS and ping, for example), and most use TCP (HTTP and FTP, among others).
  2. TCP and UDP are effectively equivalent for our purposes today.
  3. To talk to a service, you connect to the appropriate port, and the receiving computer knows who to pass the traffic to (like preceding every sentence with a person's first name in a crowded room).
3. If you connect to a computer on (TCP) port 80, you get a connection to its web server (if one is running); port 443 provides you a connection encrypted with SSL (Secure Sockets Layer).
4. If you connect to port 25, you're talking to the SMTP server, which will accept E*Mail messages for delivery to local users or other servers.
5. DNS servers answer on port 53, and FTP servers answer on port 21 for initial connections.
6. Once you've enumerated the services (and their ports) you want to offer, and what machines offer them, you're ready to start considering rules for your firewall.
7. Compatible Systems includes a useful list of port numbers under 'port' on this page about firewall configuration http://flash.compatible.com/ini-html/ini_ip_filter.html.
8. Well-established TCP/IP protocols generally use ports below 1024 -- those above 1024 are mostly left unspecified for client computers to use.
Specific Suggestions
1. Basic suggestions
  1. Set up the standard your firewall's packet-forgery and bad-packet filters (I'm thinking specifically of source routed packets -- those which come from the Internet but falsely identify themselves as originating on the inside of your firewall. Firewalls are the logical place to catching such forged packets.
  2. Think carefully about what should be outside your firewall, and what should be inside -- in many cases, it makes sense to put public webservers outside, since their primary purpose is to serve people on the Intranet. Depending on your Internet connection and Internet provider, this may also make your webserver faster for Internet visitors (and access from your office correspondingly slower).
  3. Consider putting your FTP site outside the firewall -- possibly on your Internet provider's machine. Web and FTP servers are prime targets.
  4. Consider having a separate external DNS server, with a minimum set of hosts defined. In this case, you can prevent DNS requests to any of your other DNS servers completely. It is also fairly simple to configure internal DNS servers to block access to certain websites (thanks to Compatible for this tip, and ask me directly if you're interested).
  5. If you have trusted users at another site (such as an office which connects to you via the Internet), consider relaxing all firewall-based restrictions for them. Generally, you'll want such people to have the same access as people on the inside of the firewall. Extranets work this way.
  6. Log rejected packets. Reading such logs may let you identify people who are attacking your network, before they succeed. If you find such attackers, you might block all traffic from their IP block, complain to their Internet provider (who you can generally find through ARIN, the American Registry of Internet Numbers http://www.arin.net/whois/arinwhois.html), or possibly take legal action.
2. Protection from outsiders
  1. You generally want outsiders to be able to connect to port 25 on your mail server, ports 80 and 443 on your web server, port 21 on your FTP server (actually FTP is a bit more complicated, described later), and port 53 on your DNS server; this covers the major legitimate uses of computer resources by outsiders, and is a manageable set.
  2. Block any inbound traffic that isn't specifically allowed.
  3. A special consideration: FTP
    1. Normal FTP (file transfer protocol) works by having the client open a connection to a server and then use the PORT command, which causes the server to open a new connection back to the client machine and transfer files over it.
    2. This is a security issue because a user outside the firewall might ask an FTP server behind the firewall to transfer files to/from other internal servers, and the firewall wouldn't be in the way to prevent this.
    3. Also, this procedure requires any FTP server on the Internet to be able to connect to ports on any client on the Intranet, which is what firewalls generally prevent.
    4. Passive mode FTP (which web browsers generally use, and many firewall configurations require) asks the server to opens an additional port above 1024 which the client then connects to for the actual file transfer.
    5. PASV is easier on firewalls, as internal users are often allowed to connect to any high port on external servers so they can use new services, and PASV looks like this.
3. Control over insiders
  1. In most situations, you'll want to allow clients to connect to most or all external servers and ports. Also, you'll probably want to permit external hosts to reply to requests from your Intranet (fortunately, TCP packets include an establishing flag that makes this possible).
  2. Many businesses log visited sites by internal requesting IP address (local user). Obviously, this is a major privacy issue, but management may want to know if the newest employee's computer downloads 300 pages from www.playboy.com in a typical week, or may be more interested in what pages employees visit on competitors' sites (job listings, for example).
  3. As mentioned previously, many financial institutions are very concerned about what information leaves the company -- they configure their firewalls to block or log outgoing FTP transfers (or just FTP PUTs), in an attempt to safeguard proprietary data.
  4. If you log sent mail, don't allow anything but the official mail servers to connect to port 25 on the outside, which will force people to go through your mail servers. To accomplish the same thing for received mail, block port 110 for POP and 143 for IMAP.
4. Network Address Translation (NAT)
  1. Network Address Translation for outbound packets rewrites outbound packets to look like they're coming from the firewall itself -- to prevent outsiders from learning about the IP addresses of internal -- and reverses the conversion when responses come back, rewriting the packets and putting them back on the internal network, destined for the right hosts. NAT is described at http://www.cisco.com/warp/public/732/nat/.
  2. NAT for *inbound* packets is most useful for people with a single-IP (cheaper) Internet connection, who want to use multiple servers (web, mail, etc.). Effectively, all users talk to the firewall, which is able to use port numbers to redirect traffic to the appropriate server on the local network.
Proxy Servers
1. Proxy servers come in several types, often tied in with firewall functionality. The basic concept is that internal users connect to the proxy server, which then makes another connection to the desired external service.
2. The proxy server then has precise control over what transfers are permitted and what is blocked.
3. The proxy can also keep detailed logs of connections made and data transferred.
4. Proxy servers can speed up Internet access by providing a centralized cache.
5. To use a proxy server for security, you would block all outbound web and/or FTP traffic except that coming from the server, thus forcing people through the proxy.
Buying a Firewall
1. Firewall functionality may be built into a dedicated firewall box, or come as a feature of a general-purpose router, or may be a software module that runs on a general-purpose server.
2. When comparing firewalls, think about what would happen if someone attacks the firewall (since the purpose of the firewall is to interpose it between hackers and your resources, anyone interested in attacking you is likely to target your firewall to start with).
3. Ask the vendor what the firewall's speed impact is likely to be.
  1. Will it making things faster by cutting down on the traffic that reaches your critical resources?
  2. Will a critical resource spend a great deal of time deciding whether to pass or throw away individual packets?
Categories of Attacks
1. It's worth categorizing the most common types of attacks. Some attacks fall into multiple categories.
2. Finding and capitalizing on weak security
3. Guessing passwords (a subcategory of weak security)
4. Using known bugs to trigger useful misbehaviors: Several UNIX attacks, for instance, are based upon known ways to get sendmail to crash and execute hostile code in the process.
5. Social Engineering -- tricking people into providing information to unauthorized parties
6. Forgery (either of packets or of documents)
7. Leeching off someone else's services (such as using someone else's SMTP server to deliver spam -- a very big problem in 1998)
8. Denial of service: either making a system so busy that it can't perform its function, or making so many fraudulent attempts that the service must be shut down.
Reminders
1. Firewalls are useless without careful configuration, taking into consideration your network services, users, and vulnerabilities.
2. Firewalls are effective, but in the process of blocking attacks you generally lose some flexibility -- users working from home, specifically, are generally quite restricted.
3. Before spending money on a firewall or router, carefully consider what you're protecting, and whether there's a better way (if there's no money involved, a firewall may not be necessary, and a VPN may be either a useful adjunct to a firewall system, or even a superior alternative).
4. If you can, take advantage of SSL, which offers 40-bit (export version) or 128-bit (non-export version) encryption of web connections.
  1. Using a web browser as a generic client has many advantages, and SSL is a pretty effective barrier to hackers.
  2. If you're thinking of going this route, remember that POP and FTP generally transmit passwords in plain text. You can get around this by using APOP for encrypted password negotiation and SSL for file transfer over port 443 .
Closing Comments
1. Hopefully we've made it clear to you being connected to the Internet does pose a security risk, but it's one you can address. Securing your 'Intranet' is really a question of weighing comfort and simplicity versus security and decide on an appropriate balance.
2. You will be able to find the outline for this talk at http://www.reppep.com/expo/ as of next week.
3. A longer version of this talk might become a TidBits article.