Re: smtpserver message-rate-counter (ratelimitmsgs policy)

[Matti Aarnio <mea@nic.funet.fi>]

On Fri, Apr 09, 2004 at 11:42:05AM +0400, Eugene Crosser wrote:
> Too bad that this approach is not cluster-ready...

It is next thing to add to the present subdaemon.
(After writing router and contentfilter subdaemons..
or before; who knows..)

On the other hand..  If a flooder switches regularly in between,
say, 5 cluster nodes, then it will get just 5 times as much messages
thru as with fully clustered approach.

If your L4-aware switch directs same source IP to same cluster node,
then this approach and cluster-approach are no different.

Yes, I have given it some thought, and do think that this approach
is "good enough" for starters.  :-)


About the cluster communication choices:

 - UDP datagrams unicast to each peer
 - UDP datagram sent to a locally defined multicast group

Using unicast is .. simple.  Configuration needs one entry for each node.
(As is done with ETRN-cluster that speaks with TCP..)

Use of UDP has inherent "data loss", but in this application it would
mean that the flooder is able to send some percent of more messages,
than with perfect lossless networking.  (Definitely not 400% extra..)

Configuration needs also "listen-socket" specification for each peer.
(Peer entry list can serve as that too, needs just recognition of which
address is in the system, tools do exist.)   To me, having _same_
configuration file at each node is highly valuable.


Using multicast would be nice, a bit less network load, and in both cases
"send-to-self" must be detected/avoided and ignored.

What about communication security ?
Can we accept that Mallory sends fake counter increments producing denial
of service to somebody that way ?   (Enclosing the server cluster within
a firewalled network segment does prevent that, of course.)
(Preventing Ivan the Insider from attacking is a lot harder, of course..)
Adding a cryptographic signature to the UDP packet can be used to verify
authenticity, of course.

  /Matti Aarnio

> On Thu, 2004-04-08 at 23:08, Matti Aarnio wrote:
> > Now IF your system support command line mungling (in BSDish way), you
> > might see following kind of things:   ( Linux system with: "ps axf" )
> > 
> >   879 ?        S      0:00 smtpserver -s strict -h -s ve -l /var/log/mai..
> >   882 ?        S      0:00  \_  [smtpserver ratetracker subsystem]         
> >   883 ?        S      0:00  \_  [smtpserver router subsystem]              
> >   884 ?        S      0:00  \_  [smtpserver contentfilter subsystem]       
> >   885 ?        Z      0:00      \_ [smtp-contentfil <defunct>]
> > 
> > For systems where this nice textform thing isn't possible,
> > the  'mailq -M' command lists PIDs for those processes:
> >   SYS.SmtpServerMasterPID                879
> >   SS.SubsysRateTrackerPID                882
> >   SS.SubsysRouterMasterPID               883
> >   SS.SubsysContentfilterMasterPID        884
> > 
> > 
> > Of those subsystems, only 'ratetracker' really works at the moment.
> > It keeps everything in memory, so when I ask it to dump internal
> > memory content, I get something like this:  (Filename is fixed.)
> > 
> > # kill -USR1 31800
> > # sort /var/tmp/smtpserver-ratetracker.dump |uniq -c
> >     999 0.0.0.0
> >       1 67.72.78.212    0     9     21    0     0     0     0     0     
> > 
> > Data slots are allocated in slabs of 1000, therefore this dump has
> > 999 examples of '0.0.0.0'.  When first 1000 are in use, next slab
> > gets allocated, etc.
> > 
> > The numbers above after the IP address (oh yes, only IPv4 is
> > supported with the code at present, IPv6 needs some further
> > thought..) are number of messages received from that address.
> > The message count is kept in 8 rotating timeslots, about 510-520
> > seconds each giving total time around  1.00 - 1.14 hours which
> > the message count exists for given sender IP address.
> > 
> > The tracking idea here is, that each message accepted into the
> > system does get counted as one, and when there are too many messages,
> > the system is replying following for MAIL FROM:
> >    450 4.7.1 Hello [67.72.78.212], for your MAIL FROM address <****@*****>
> >        policy analysis reported: You are sending too much mail per time
> >        interval.  Try again latter.
> > 
> > 
> > The count is tracked only for those message senders, that have in the
> > initial contact IP address lookup an attribute pair of:
> >       ratelimitmsgs 60
> > 
> > When the number is NEGATIVE, limit excess will result in 550 code
> > for MAIL FROM, otherwise a 450 code reply is given.
> > (The example number above is "60", meaning about 1 message per minute
> > over whole 1.0-1.2 hour period..  or 60 in first minute, and none
> > for next hour...)
> > 
> > The smtpserver policy boilerplate file  (smtp-policy.src)  does not
> > have any nicely compartementalized way to handle the rate limiting
> > parameter entry.  I had to add that pair into  _full_rights  macro
> > values in my tests.
> > 
> > The overall idea in here is that you can give blanket rate limit to
> > all users for whom you are doing outbound relaying without those
> > users needing to authenticate.  (Autenticated users bypass these
> > tests.)
> > 
> > If you want to rate-limit ALL incoming email, then you want probably
> > to put this attribute both on _default_ipaddr,  and _full_rights
> > macroes.  (The 'default-ipaddr' thing was formerly the smtp-policy.src
> > source line with:  [0.0.0.0]/0  )
> > 
> > For incoming traffic rate tracking also the recipient address is
> > important to track.  Otherwise you may get nasty surprises with
> > large volume (and subscriber population in your system) lists.
> > Present system does not support that operational mode.



-- 
/Matti Aarnio	<mea@nic.funet.fi>
-
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to majordomo@nic.funet.fi