On Wed, 26 Aug 1998, Russ Allbery wrote: > Walter Hafner <hafnerat_private-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.*. The worst thing about these attacks is that they all contain Supersedes headers, which amounts to a very subtle way of cancelling articles. Even if you have entries in your control.ctl file, it's too late to prevent the cancel because the Supersedes takes effect right in INN's main loop, far before the control scripts kick in. The only way to prevent the cancels is to "alias" out the site using excludes in the newsfeeds file. For instance, change this ME\ :!control,!junk/!local\ :: to this ME/a.site.which.is.sending.bad.sendsys.messages\ :!control,!junk/!local\ :: The only problem is identifying which site is actually sending the control messages, because the beginning of the Path is usually forged. One clue is that the server is usually wide open, allowing connections from anyone. ps. Thanks to Bossman for teaching me how all this stuff works. > 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 (rraat_private) <URL:http://www.eyrie.org/~eagle/> >
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:13:47 PDT