OT: Control message abuse: stemming the flood

Sylvain Robitaille syl at alcor.concordia.ca
Mon Mar 25 17:49:49 UTC 2002

(My apologies for the off-topic message, but I hope this will be of
interest to at least enough people on the list that it won't seem like a
major disaster...)

I know this may not be a concern for most of you, but I'm interested in
knowing what you think...

The recent flood of netnews control messages (more HipCrime) caused
me some grief, though not actually on the news server.  My server is
configured to email me all newgroup/rmgroup control messages, except
those from a select few known senders, which it processes automatically
and notifies me that the action has been done.

On the account where I receive email, I have procmail filter through
those and put them into mail folders based on whether I should ignore
them entirely, or have a look and consider adding them (ultimately here,
since I don't have time to really track this type of stuff, the groups
are never added until a user requests one, but the *idea* is that I
would watch some of the control messages, and act on them if the group
creation seems to be "correct".)

The trouble is, I also get a very large amount of spam mail (>36 per
day average, so far this month), so procmail on my account tends to
run rather slowly (I even moved my news processing to the start, but
the frequency of messages coming through last week was still too high).
What happens is my userid becomes unable to start any new processes and
I'm unable to work.  Messages get queued up, and the cycle goes on far
too long.  I decided to retake control...

Strangely enough, the hipcrime abusers haven't really changed their
tactics since I started seeing these several years ago:  a flood of
messages to create parallel news hierarchies with groups containing
"hipcrime" in their name.  That's actually pretty simple to detect
automatically, and process differently than other control messages.

My first approach was to simply configure control.ctl to log and
otherwise ignore these messages for newsgroups matching "*hipcrime*".
They were still being stored on the spool, though, and therefore still
being sent on to my news peers (who probably would otherwise get them
from their other peers anyway, but my concern is whether or not my own
system is forwarding these...)

As it's done so well in the past, Cleanfeed provided the solution.
If any of you folks are also using Cleanfeed, you might find this useful.
If you're not using Cleanfeed, this may help you consider using it...

I added the following to cleanfeed.local, and I no longer have to deal
with these particular control message abuse floods.  They're silently

  # local_filter_newrmgroup - called for each newgroup and
  #  rmgroup control message
  sub local_filter_newrmgroup {
     # We want to check the Control: header and reject the message if it's
     # for a group matching \.?hipcrime\.?
     if( $hdr{'Control'} =~ /\.?hipcrime\.?/ ) {
        # writeheaders "cleanfeed.log.$$";
        $result = "Local: Hipcrime control message";
     } else {
        # No match, we can let it through...
        $result = "";
     return $result;

I checked the results this morning (the filter was writing headers to
log files over the weekend), and it filtered out 3474 hipcrime control
messages since late Friday afternoon.  This, in my view, is good, and the
fact that I'm not feeding these messages back out is even better...  :-)

If the abusers decide to alter their tactic slightly, by say changing
the string to "hopcrime", or whatever, it'll be easy enough to adapt
this filter.  I'm really not too worried about that.

I've grepped the Control: lines out of the rejected message log,
and counted each.  I append the results below my signature, in case
anyone's interested.  I'll probably post a similar message to one of
the news.admin.* newsgroups, so I apologize in advance to any folks
who'll see multiple copies of this...

Sylvain Robitaille                              syl at alcor.concordia.ca

Systems analyst / Newsmaster                      Concordia University
Instructional & Information Technology        Montreal, Quebec, Canada

 465 Control: newgroup us.hipcrime
 135 Control: newgroup free.hipcrime
 104 Control: newgroup alt.0000.hipcrime
 103 Control: newgroup alt.hipcrime
 103 Control: newgroup alt.abg.hipcrime
 102 Control: newgroup alt.de.hipcrime
 101 Control: newgroup alt.dur.hipcrime
 101 Control: newgroup alt.config.hipcrime
 101 Control: newgroup alt.cc.hipcrime
 101 Control: newgroup alt.awelch.hipcrime
 100 Control: newgroup alt.this.is.yet.another.hipcrime
 100 Control: newgroup alt.iglou.hipcrime
 100 Control: newgroup alt.atl.hipcrime
  99 Control: newgroup alt.altopia.hipcrime
  98 Control: newgroup alt.nocem.hipcrime
  98 Control: newgroup alt.monique.hipcrime
  98 Control: newgroup alt.conspiracy.hipcrime
  97 Control: newgroup alt.current-events.net-abuse.hipcrime
  97 Control: newgroup alt.control.hipcrime
  96 Control: newgroup alt.moja.hipcrime
  94 Control: newgroup alt.usenet.legends.hipcrime
  94 Control: newgroup alt.trippy.hipcrime
  94 Control: newgroup alt.penpals.hipcrime
  92 Control: newgroup alt.spam.hipcrime
  69 Control: newgroup alt.sex.net-abuse.hipcrime
  65 Control: newgroup alt.alt.hipcrime
  63 Control: newgroup alt.2600.hackers.hipcrime
  62 Control: newgroup alt.fan.hipcrime
  62 Control: newgroup alt.bonehead.self-immolation.hipcrime
  45 Control: newgroup free.binaries.hipcrime
  42 Control: newgroup biz.hipcrime
  41 Control: newgroup control.hipcrime
  40 Control: newgroup hipcrime.general
  40 Control: newgroup hipcrime.config
  40 Control: newgroup hipcrime
  40 Control: newgroup de.alt.hipcrime
  39 Control: newgroup hipcrime.control
   9 Control: newgroup comp.hipcrime
   7 Control: newgroup talk.hipcrime
   7 Control: newgroup soc.hipcrime
   7 Control: newgroup sci.hipcrime
   7 Control: newgroup rec.hipcrime
   7 Control: newgroup news.hipcrime
   7 Control: newgroup misc.hipcrime
   2 Control: rmgroup de.alt.hipcrime

More information about the inn-workers mailing list