Rate limiting Kerberos Requests

Jack Neely jjneely at ncsu.edu
Wed Sep 26 10:53:59 EDT 2012


On Tue, Sep 25, 2012 at 09:55:21PM -0700, Frank Cusack wrote:
> On Tue, Sep 25, 2012 at 2:02 PM, Jack Neely <jjneely at ncsu.edu> wrote:
> 
> > My network engineers tell me that the firewall in one DC had 8000
> > concurrent connections from the offending IP address to the KDCs and
> > 4000 in the second DC.  (Oddly, the DC with only 1 slave.)  The KDCs
> > weren't able to handle other requests until the spike settled.
> >
> 
> Well then, that's the place where you should apply a limit.
> 
>    iptables -A INPUT -p tcp --dport 88 -m limit --limit 4/min --limit-burst
> > 6 -j ACCEPT
> >     iptables -A INPUT p tcp --dport 88 -j DROP
> >
> 
> The problem with a rule like that is that the attack succeeds: you are
> dropping arbitrary requests from arbitrary users.  It's the exact same
> effect as just letting the server get overwhelmed.
> 
> Another problem is that you are limiting TCP whereas Kerberos will use
> UDP.  UDP plays havoc with firewalls, and as Russ points out, that's where
> the problem is likely to really lie.  8000 concurrent "connections" from
> one host is symptomatic of a firewall problem.

Wow, I did write that badly.  I blame the stress.  Let's use the
"recent" module in iptables as its more powerful.

    iptables -A INPUT -p udp --dport 88 -m recent --set --name KRB 
    iptables -A INPUT -m recent --rcheck --name KRB --seconds 60 --hitcount 10 -j DROP

Granted, before I do something that will probably make my performance
issues worse, I'm waiting to hear back from my network engineers about
Russ's comments.

Jack

-- 
Jack Neely <jjneely at ncsu.edu>
Linux Czar, OIT Campus Linux Services
Office of Information Technology, NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89


More information about the Kerberos mailing list