|
Chapter 8 Configuring Internet Services |
|
|
|
Chapter 8 Configuring Internet Services |
|
NNTP is the service generally used to transfer Usenet news across the Internet (as we mentioned above, UUCP over TCP is sometimes used for this purpose). A news server is the place where Usenet news flows into and out of your organization, and which your users access (via news clients) to read and post news. There are a number of news servers available, including B-News, C-News, and INN , and they generally speak NNTP among themselves so they can transfer news between sites. In addition, many news clients use NNTP to access news servers for users reading news.
NNTP is a TCP -based service. NNTP servers use port 119. NNTP clients (including servers transferring news to other servers) use ports above 1023.
Figure 8.9 shows NNTP via packet filtering.
| Direc- | Source | Dest. | Pro- | Source | Dest. | ACK | |
|---|---|---|---|---|---|---|---|
| tion | Addr. | Addr. | tocol | Port | Port | Set | Notes |
|
In |
Ext |
Int |
TCP |
>1023 |
119 |
[16] |
Incoming news |
|
Out |
Int |
Ext |
TCP |
119 |
>1023 |
Yes |
Incoming news responses |
|
Out |
Int |
Ext |
TCP |
>1023 |
119 |
[16] |
Outgoing news |
|
In |
Ext |
Int |
TCP |
119 |
>1023 |
Yes |
Outgoing news responses |
|
[17] |
Int |
News Server |
TCP |
>1023 |
119 |
[16] |
Newsreader client reading news |
|
[17] |
News Server |
Int |
TCP |
119 |
>1023 |
Yes |
Server sending articles to newsreader client |
[16] ACK is not set on the first packet of this type (establishing connection) but will be set on the rest.
[17] Both ends are internal in most cases.
NNTP is a store-and-forward protocol, capable of doing its own proxying. It is also easy to proxy as a straightforward single-connection protocol. The TIS FWTK provides a generic proxy, plug-gw , which is frequently used with NNTP as well as modified user procedures (the NNTP connection is directed to the proxy server, which redirects the connection based on the client address). It would be easy to modify clients to use a generic modified-client proxy like SOCKS .
Figure 8.10 shows NNTP via proxy services.
It may seem obvious that the bastion host should be your site's Usenet news server. However, there are some subtle problems that can be caused by such a configuration.
First, it is advisable to dedicate a machine to news service; news has a tendency to absorb all available disk space and processing time, and does not coexist well with critical services. If you use a bastion host for news, you will probably need to have multiple bastion hosts, which is not in itself a bad thing, but does raise maintenance overhead. It may not be worth it to you to have multiple bastion hosts just so you can provide news service on one of them.
Second, if your news server is your bastion host, you can't have any private or proprietary newsgroups for internal discussions. You wouldn't want those newsgroups to be exposed if the bastion host gets broken into, or if some outsider manages to connect to your NNTP server and convinces it to show him your newsgroups.
Third, if your bastion host is your news server, you will have to choose one of four approaches to letting your users read news; each of these approaches, described in the sections below, has its own problems.
The most straightforward approach is to let users log into the bastion host and run a newsreader. This involves giving many users accounts on the bastion host, and will seriously compromise the bastion host's security. (See the discussions concerning user accounts on bastion hosts in Chapter 5, Bastion Hosts .)
This approach may not be very popular with the users, either, because it will require them all to use whichever UNIX newsreaders are available on the bastion host.
The second and somewhat safer approach is to make your users use only NNTP clients to read news from the bastion host. The main problem with this approach is that it requires your users to use NNTP -capable newsreaders. While many, perhaps even most, newsreaders are NNTP -capable, there are some that are still in common usage (such as certain versions of nn ) that are not NNTP -capable. Depending on the NNTP server you are using, it may be impossible to get popular newsreader features like article threading through NNTP . You may have difficulty finding a server that has all the features you want for both transferring news and serving newsreaders.
The third approach you could take to making your bastion host be your news server is to export the news to clients via NFS . This approach solves one of the problems we've identified: it allows you to use non- NNTP -capable newsreaders. However, it doesn't solve the other major problem, that of not being able to support any private or proprietary newsgroups for fear of exposure. If your users can use NFS to access your news server, chances are that an attacker can too, because the security of NFS is so weak. You're much better off disabling NFS altogether on your bastion host (see the section on NFS later in this chapter and Chapter 5 for further discussion of this point).
The fourth approach is to simply relay news through your bastion host, and make some internal system your "real" news server. The most obvious way to do this is to set up a news server on the bastion host that simply relays news to and from the internal news server.
The problem with this approach is that it requires a lot of maintenance. It takes a fair amount of ongoing attention to keep a news system functioning; ideally, you'd like to be able to set your bastion host up and leave it alone, maintenance free. Also, tightly coupled news systems like these are very susceptible to cascading problems. A problem on one causes news to stop flowing, stopping things up on the other system and causing problems there; when you fix the first problem, the other system floods the first, and the whole process starts over. However, if you have experienced news administrators and a large amount of disk space, you may find this approach acceptable, and it can be set up to allow for private newsgroups.
One of the key differences between NNTP and other protocols, such as SMTP , is in how they are used. You might get SMTP connections from all over the world, as folks from everywhere send electronic mail to your site. On the other hand, you'll only get legitimate NNTP connections from your news feed site (or sites).
The most convenient and reliable way to deal with news on a firewall is usually to arrange for the news to flow directly between your feed site(s) and your internal news server. This can be arranged either through packet filtering, or through a proxy system on the bastion host, as we describe in the following sections.
If you set up NNTP using either packet filtering or a proxy server, you'll greatly reduce your vulnerability to attacks via NNTP . With NNTP configured as we describe here, both of the following conditions would have to hold true in order for you to be attacked via NNTP :
Your NNTP server would have to have some bug or configuration error that could be exploited.
The attack would have to come from (or appear to come from) one of your feed sites, because the feed sites are the only sites that are allowed to open NNTP connections to your server.
NNTP is a relatively simple protocol. There have been no known attacks that use NNTP itself. There has been one known data-driven attack on UNIX news systems, which relied on the willingness of some news server software to create newsgroups automatically. It was possible to specify newsgroup names with semicolons (;) in them, so that when the news server went to create the group it also executed commands contained after the semicolon in the malformed group name. Because the control messages were malformed, they weren't recognized and propagated by all servers, and many sites were immune anyway because they didn't automatically create newsgroups. This bug is fixed in current releases of various news server software packages, but it highlights the importance of staying up to date, as we describe in Chapter 12, Maintaining Firewalls .
You may want to disable automated group creation in any case; it's a maintenance hassle to keep up with valid requests, but users can find it seriously annoying to deal with the side effects of automated group creation when somebody decides that it's amusing to send a few thousand creation requests overnight, most of them obscene.
If you've set up a packet filtering system between the internal news server and your news feed site, you can arrange to pass NNTP between them. Set up the packet filtering system to allow the following, as shown in the table below:
Incoming NNTP connections, so that you can receive news: that is, TCP packets from ports above 1023 on the remote system to port 119 on your news server, and TCP packets with the ACK bit set from port 119 on your news server to ports above 1023 on the remote system. (Rules A and B)
Outgoing NNTP connections, so that you can send news: that is, TCP packets from ports above 1023 on your news server to port 119 on the remote system, and TCP packets with the ACK bit set from port 119 on the remote system to ports above 1023 on your news server (Rules C and D).
| Direc- | Source | Dest. | Pro- | Source | Dest. | ACK | ||
|---|---|---|---|---|---|---|---|---|
| Rule | tion | Addr. | Addr. | tocol | Port | Port | Set | Action |
|
A |
In |
Service Provider |
Your Server |
TCP |
>1023 |
119 |
Any |
Permit |
|
B |
Out |
Your Server |
Service Provider |
TCP |
119 |
>1023 |
Yes |
Permit |
|
C |
Out |
Your Server |
Service Provider |
TCP |
>1023 |
119 |
Any |
Permit |
|
D |
In |
Service Provider |
Your Server |
TCP |
119 |
>1023 |
Yes |
Permit |
Don't use a bastion host as a news server.
Don't allow automated group creation.
Allow external NNTP connections only from the sites you exchange news with.
Use packet filtering or proxying to connect trusted external NNTP servers to an internal news server, and vice versa.
|
|
|
|
| 8.4 Remote Command Execution |
|
8.6 World Wide Web (WWW) and HTTP |