443 lines
13 KiB
HTML
443 lines
13 KiB
HTML
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Security issues</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
|
|
"><LINK
|
|
REL="HOME"
|
|
TITLE="Usenet News HOWTO "
|
|
HREF="index.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="Connecting email with Usenet news"
|
|
HREF="x714.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="Access control in NNTPd"
|
|
HREF="x818.html"></HEAD
|
|
><BODY
|
|
CLASS="SECTION"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
SUMMARY="Header navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>Usenet News HOWTO</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="x714.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
></TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="x818.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="SECTION"
|
|
><H1
|
|
CLASS="SECTION"
|
|
><A
|
|
NAME="AEN758">7. Security issues</H1
|
|
><P
|
|
>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,
|
|
<EM
|
|
>i.e.</EM
|
|
> 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.</P
|
|
><P
|
|
>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.</P
|
|
><DIV
|
|
CLASS="SECTION"
|
|
><H2
|
|
CLASS="SECTION"
|
|
><A
|
|
NAME="AEN763">7.1. Intrusion threats</H2
|
|
><P
|
|
>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.</P
|
|
><DIV
|
|
CLASS="SECTION"
|
|
><H3
|
|
CLASS="SECTION"
|
|
><A
|
|
NAME="AEN766">7.1.1. Generic server vulnerabilities</H3
|
|
><P
|
|
>Foremost among these vulnerabilities are those which render
|
|
<EM
|
|
>any</EM
|
|
> 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.</P
|
|
><P
|
|
>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.</P
|
|
><P
|
|
>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.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECTION"
|
|
><H3
|
|
CLASS="SECTION"
|
|
><A
|
|
NAME="AEN772">7.1.2. Vulnerabilities in Usenet software</H3
|
|
><P
|
|
>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.</P
|
|
><P
|
|
>Any server which accepts a text string as input from a
|
|
client is open to the buffer overrun class of attacks, if the
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>gets()</TT
|
|
> C library function has been used in its code
|
|
instead of the <TT
|
|
CLASS="LITERAL"
|
|
>fgets()</TT
|
|
> 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
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>nntpd</TT
|
|
> 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 <TT
|
|
CLASS="LITERAL"
|
|
>root</TT
|
|
>. In
|
|
fact, they would begin to cause malfunctioning of the underlying Usenet
|
|
software if they ran as <TT
|
|
CLASS="LITERAL"
|
|
>root</TT
|
|
>. 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
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>news</TT
|
|
>, which means that she can play havoc with the
|
|
Usenet installation, but no further. A daemon which runs as
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>root</TT
|
|
>, if compromised, can allow an intruder to take
|
|
control of the operating system itself.</P
|
|
><P
|
|
>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.</P
|
|
><P
|
|
>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 <TT
|
|
CLASS="LITERAL"
|
|
>POST</TT
|
|
> 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 <TT
|
|
CLASS="LITERAL"
|
|
>in.coming</TT
|
|
> 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.</P
|
|
><P
|
|
>While this possibility exists, it appears that neither the C-News
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>newsrun</TT
|
|
> 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.</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECTION"
|
|
><H2
|
|
CLASS="SECTION"
|
|
><A
|
|
NAME="AEN789">7.2. Vulnerabilities unique to the Usenet service</H2
|
|
><P
|
|
>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.</P
|
|
><DIV
|
|
CLASS="SECTION"
|
|
><H3
|
|
CLASS="SECTION"
|
|
><A
|
|
NAME="AEN792">7.2.1. Unsolicited commercial messages</H3
|
|
><P
|
|
>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.</P
|
|
><P
|
|
>There are many tools that Usenet administrators use in their
|
|
battle against SPAM. The most important of these is the NoCeM suite. See
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>http://www.cm.org/</TT
|
|
> for details of NoCeM, and the
|
|
newsgroup <TT
|
|
CLASS="LITERAL"
|
|
>alt.nocem.misc</TT
|
|
> for the SPAM cancel messages
|
|
which NoCeM reads to identify which articles to discard. Your server
|
|
will need a feed of <TT
|
|
CLASS="LITERAL"
|
|
>alt.nocem.misc</TT
|
|
> 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.</P
|
|
><P
|
|
>Other anti-spam tools for Usenet services are listed in the
|
|
Anti-SPAM Software Web page
|
|
(<TT
|
|
CLASS="LITERAL"
|
|
>http://www.exit109.com/~jeremy/news/antispam.html</TT
|
|
>).
|
|
The <TT
|
|
CLASS="LITERAL"
|
|
>Cleanfeed</TT
|
|
> software will clean out articles
|
|
identified as SPAM. There are many others.</P
|
|
><P
|
|
>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.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECTION"
|
|
><H3
|
|
CLASS="SECTION"
|
|
><A
|
|
NAME="AEN803">7.2.2. Spurious control messages</H3
|
|
><P
|
|
>Control messages, discussed in detail earlier in <A
|
|
HREF="x64.html#CONTROLMSG"
|
|
>Section 2.4</A
|
|
>>, 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) <TT
|
|
CLASS="LITERAL"
|
|
>newgroup</TT
|
|
> control
|
|
messages, which rapidly taught us the danger of unprotected control
|
|
messages and the protection against them.</P
|
|
><P
|
|
>The standard protection mechanism against this
|
|
vulnerability is <TT
|
|
CLASS="LITERAL"
|
|
>pgpverify</TT
|
|
>, which can be
|
|
downloaded from multiple Websites and FTP mirror sites by
|
|
searching for <TT
|
|
CLASS="LITERAL"
|
|
>pgpverify</TT
|
|
> (the program) or
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>pgpcontrol</TT
|
|
> (the total software package). We have
|
|
integrated this into our source distribution, so that our C-News works
|
|
in a tightly coupled manner with <TT
|
|
CLASS="LITERAL"
|
|
>pgpverify</TT
|
|
>.</P
|
|
><P
|
|
><TT
|
|
CLASS="LITERAL"
|
|
>pgpverify</TT
|
|
> 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 <TT
|
|
CLASS="LITERAL"
|
|
>pgpverify</TT
|
|
>
|
|
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.</P
|
|
><P
|
|
>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
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>pgpverify</TT
|
|
> protection.</P
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
SUMMARY="Footer navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x714.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
ACCESSKEY="H"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x818.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>Connecting email with Usenet news</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
> </TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>Access control in NNTPd</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |