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