Re: News DoS using sendsys

[rra () STANFORD EDU (Russ Allbery)]

Walter Hafner <hafner () INFORMATIK TU-MUENCHEN DE> writes:

> Our newsserver (INN) all of a sudden gets several 100 'sendsys' requests
> per day. The addresses of the people requesting the sendsys seem to be
> completely random. They all seem to be normal user-accounts. We see
> these sendsys requests for about a week now.

Just today, the same folks switched to using newgroups.  Unfortunately,
the control message handling in INN is still implemented using shell
scripts that are spawned directly from the news server, making it fairly
easy for a large batch of these to drive the load average of a news server
through the roof and hurt its normal functioning.  This is particularly
true if, rather than receiving a real-time feed, you're receiving news in
batches, because then your upstream will happily batch all the control
messages for you and you'll get several hundred at once.

There are several possible solutions at different levels of complexity.

First, please make sure that your control.ctl file or the equivalent has a
line like:

        sendsys:*:*:drop

Otherwise, not only are you processing these, but you're also replying to
them, and hence mailbombing the targets of this attack (myself included).
This is a harassment attack aimed at anyone who posts to news.admin.*.

Second, if you're running a recent version of INN with a Perl spam filter,
add something like the following to your filter_innd.pl:

        return 'Supersede in control message'
            if (defined $hdr{Supersede} && defined $hdr{Control});
        return 'sendsys'
            if ($hdr{Control} =~ /^\s*sendsys/);

or grab the latest version of Jeremy Nixon's Cleanfeed spam filter from
<URL:http://www.exit109.com/~jeremy/news/cleanfeed.html>.

Finally, patches to turn INN's control message handling into a channel
feed have finally been written, and are in the current INN CVS tree.
These send control messages through a channel feed to a separate program
for processing, rather than having INN handle them, and that separate
program does serialization to reduce the load impact.

This whole section of INN is being reworked, which is good; it's long
overdue for a complete rethink.

--
Russ Allbery (rra () stanford edu)         <URL:http://www.eyrie.org/~eagle/>