mirror of https://github.com/tLDP/LDP
219 lines
11 KiB
Plaintext
219 lines
11 KiB
Plaintext
<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>
|