<section><title>Security issues</title>

<para>It almost seems strange that we are discussing security issues in
the context of Usenet news servers. Usenet news has been one of the most
open and free-for-all network services traditionally. However, with the
exponential growth of the Internet, all services are becoming aware of
potential threats. The community of Internet intruders too has acquired
new profiles: a lot of Internet intrusion attempts are program-driven,
and exploit a set of ``well known'' vulnerabilities,
<emphasis>i.e.</emphasis> vulnerabilities which have been identified by
the computer security and intrusion community and published in their
reports and advisories. Thus, the question of ``Why will someone attack
my harmless Usenet server?'' is no longer valid. It will be attacked if
it can be attacked, merely because its IP address falls in a range of
addresses being targeted, perhaps.</para>

<para>Security issues for Usenet news servers fall into two categories.
First come vulnerabilities which will allow an attacker to bring down
your server or run code of his choice on it. Second come vulnerabilities
which can distort or corrupt your Usenet article hierarchy, either by
junk postings, unsolicited commercial messages, or forged control
messages. The second category of threats is specific to Usenet news and
needs Usenet-specific protection mechanisms, some of which require
tapping into defence mechanisms designed by the Usenet administrator
community.</para>

<section><title>Intrusion threats</title>

<para>Here we discuss the vulnerabilities which will allow an intruder
to ``gain control'' of your Usenet server, or ``bring it down,'' either
of which may be irritating, embarassing, or downright disastrous for your
business or occupation.</para>

<section><title>Generic server vulnerabilities</title>

<para>Foremost among these vulnerabilities are those which render
<emphasis>any</emphasis> 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.</para>

<para>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.</para>

<para>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.</para>

</section>

<section><title>Vulnerabilities in Usenet software</title>

<para>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.</para>

<para>Any server which accepts a text string as input from a
client is open to the buffer overrun class of attacks, if the
<literal>gets()</literal> C library function has been used in its code
instead of the <literal>fgets()</literal> 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
<literal>nntpd</literal> 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 <literal>root</literal>. In
fact, they would begin to cause malfunctioning of the underlying Usenet
software if they ran as <literal>root</literal>. 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
<literal>news</literal>, which means that she can play havoc with the
Usenet installation, but no further. A daemon which runs as
<literal>root</literal>, if compromised, can allow an intruder to take
control of the operating system itself.</para>

<para>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.</para>

<para>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 <literal>POST</literal> 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 <literal>in.coming</literal> 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.</para>

<para>While this possibility exists, it appears that neither the C-News
<literal>newsrun</literal> 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.</para>

</section>

</section>

<section><title>Vulnerabilities unique to the Usenet service</title>

<para>There are certain security precautions that a Usenet server
administrator has to take to ensure that her servers are not swamped by
irritating junk or configured out of shape by spurious control messages.
These vulnerabilities do not allow an intruder to run her software on
your servers, but allows her to mess up your server, causing you to lose
a precious weekend (or week) straightening out the mess.</para>

<section><title>Unsolicited commercial messages</title>

<para>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.</para>

<para>There are many tools that Usenet administrators use in their
battle against SPAM. The most important of these is the NoCeM suite. See
<literal>http://www.cm.org/</literal> for details of NoCeM, and the
newsgroup <literal>alt.nocem.misc</literal> for the SPAM cancel messages
which NoCeM reads to identify which articles to discard. Your server
will need a feed of <literal>alt.nocem.misc</literal> 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.</para>

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

<para>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.</para>

</section>

<section><title>Spurious control messages</title>

<para>Control messages, discussed in detail earlier in <xref
linkend="controlmsg"/>, 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) <literal>newgroup</literal> control
messages, which rapidly taught us the danger of unprotected control
messages and the protection against them.</para>

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

<para><literal>pgpverify</literal> 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 <literal>pgpverify</literal>
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.</para>

<para>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
<literal>pgpverify</literal> protection.</para>

</section>

</section>

</section>
