7. Security issues

7.1.1. Generic server vulnerabilities

Foremost among these vulnerabilities are those which render any server vulnerable to intrusion attempts. Most of these vulnerabilities are unrelated to Usenet news itself. For instance, if you have the Telnet service active on a server exposed to the Internet, then it is likely that systematic attempts by intruders to acquire usernames and passwords will bear fruit, using methods we will best leave to specialised texts on the subject. Once this is done, the intruder will merely ``walk into'' your server by Telnetting into it.

We will not discuss this class of vulnerabilities here any further; they belong in documents dedicated to general security issues. For further reading, check the ``Security HOWTO'', the ``Security Quickstart HOWTO'', the ``User Authentication HOWTO'', the ``VPN HOWTO'', and the ``VPN Masquerade HOWTO'' ... and that's just from the Linux HOWTO collection. As one can see, there is, if anything, a surfeit of material on this and related subjects.

There are vulnerabilities which allow an intruder to mount the so-called DoS attacks, which make your service inaccessible to legitimate users, even though it does not let the intruder in. The most publicised of these attacks were the SYNFlood and the Ping of Death attacks, both quite old and well-understood by now. A Linux server running a recent version of the kernel and properly configured, should be immune to both these attack methods. But network protocols being what they are, there are always new DoS methods being thought up, which can temporarily overload or slow down a server. Once again, the texts discussing generic security issues are the best place to study these vulnerabilities.

7.1.2. Vulnerabilities in Usenet software

Then come server vulnerabilities, if any, which are caused specifically by Usenet news software. For instance, if it was possible for an intruder to issue some string of bytes to your server's NNTP server and cause it to execute a command of the intruder's choice, then this vulnerability would be in this category.

Any server which accepts a text string as input from a client is open to the buffer overrun class of attacks, if the gets() C library function has been used in its code instead of the fgets() with a buffer size limit. This was a vulnerability made famous by the 1988 Morris Internet Worm, discussions on which can be found elsewhere. (Go Google for it if you're keen.) As far as we know, the INN NNTP server and the nntpd which forms part of the NNTP Reference Implementation both have no known buffer overrun vulnerabilities. This class of vulnerabilities is less significant in the case of NNTPd or INN because these daemons do not run as root. In fact, they would begin to cause malfunctioning of the underlying Usenet software if they ran as root. Therefore, even if an intrepid intruder could find some way of gaining control of these daemons, she would only be able to get into the server as user news, which means that she can play havoc with the Usenet installation, but no further. A daemon which runs as root, if compromised, can allow an intruder to take control of the operating system itself.

UUCP is generally believed to be insecure. We believe a careful configuration of Taylor UUCP plugs a lot of these vulnerabilities. One vulnerability with UUCP over TCP is that the username and password travel in plaintext form in TCP data streams, much like with Telnet or FTP. We therefore do not advise using UUCP over TCP in this manner if security is a concern at all. We recommend the use of UUCP through a SSH tunnel, with the SSH setup working only with a pre-installed public key. This way, there is no need for usernames and passwords for the SSH tunnel setup, and passwords cannot be leaked even intentionally. And the UUCP username and password then passes through this encrypted tunnel and is therefore totally superfluous for security; the preceding SSH tunnel provides a much stronger connection authentication than the UUCP username and password. And since we set up our SSH tunnels to demand key-based authentication only, it rejects any attempt to connect using usernames and passwords when the tunnel is being set up.

A third possible vulnerability is related to the back-end software which processes incoming Usenet articles. It is conceivable that an NNTP server will receive an incoming POST command, receive an article, and queue it for processing on the local spool; the NNTP server often does not perform any real-time processing on the incoming post. The post-processing software which periodically processes the incoming spool (the in.coming directory in C-News) will read this article and somehow be forced to run a command of the intruder's choice, either by buffer overrun vulnerabilities or any other means.

While this possibility exists, it appears that neither the C-News newsrun and family nor INN are vulnerable to this class of attempts. We base our comment on the solid evidence that both these systems have been around in an intrusion-prone world of public Usenet servers for more than a decade. INN, the newer of the two, completed one decade of life on 20 August 2002. And both these software systems had their source freely available to all, including intruders. We can be fairly certain that if vulnerabilities of this class have not been seen, it not for want of intrusion attempts.

7.2.1. Unsolicited commercial messages

Unsolicited commercial messages are called SPAM. There is a war against SPAM being fought in the Internet community. The biggest battlefront is in the world of email. Second to that is Usenet newsgroups.

There are many tools that Usenet administrators use in their battle against SPAM. The most important of these is the NoCeM suite. See http://www.cm.org/ for details of NoCeM, and the newsgroup alt.nocem.misc for the SPAM cancel messages which NoCeM reads to identify which articles to discard. Your server will need a feed of alt.nocem.misc to use the NoCeM facility. These special messages are signed by NoCeM volunteers whose job is to identify SPAM articles, list their message-IDs, and then issue these deletion instruction, digitally signed with special private keys, which tell all Usenet servers to delete the SPAM messages. Your server's NoCeM software will need public key software (typically PGP) and a keyring with the public key of each NoCeM volunteer you want to accept instructions from.

Other anti-spam tools for Usenet services are listed in the Anti-SPAM Software Web page (http://www.exit109.com/~jeremy/news/antispam.html). The Cleanfeed software will clean out articles identified as SPAM. There are many others.

SPAM is such a nuisance and a drain on organisational expense pockets (by wasting bandwidth you pay for) that it is almost imperative today that every Usenet server protects itself against it. We will integrate some selected anti-SPAM measures into our integrated source distribution soon.

7.2.2. Spurious control messages

Control messages, discussed in detail earlier in Section 2.4>, instruct a Usenet server to take certain actions, like delete a message or create a newsgroup. If this facility is ``open to the public'', anyone with half a brain can forge control messages to create twenty new newsgroups, and then post thousands of articles into those groups. In the mid-nineties, we were hit by a storm of over 2,000 (two thousand) newgroup control messages, which rapidly taught us the danger of unprotected control messages and the protection against them.

The standard protection mechanism against this vulnerability is pgpverify, which can be downloaded from multiple Websites and FTP mirror sites by searching for pgpverify (the program) or pgpcontrol (the total software package). We have integrated this into our source distribution, so that our C-News works in a tightly coupled manner with pgpverify.

pgpverify works using public key cryptography, much like NoCeM, and all the official maintainers of respective Usenet group hierarchies sign control messages using their private keys. Your server will carry their public keys, and pgpverify will check the sign on each control message to ensure that it's from the official maintainer of the hierarchy. It will then act upon legit control messages and discard the spurious ones.

In today's nuisance-ridden Usenet environment, no sane Usenet server administrator receiving a feed of ``public'' hierarchies and control messages will even dream of running her server without pgpverify protection.