[syslinux] TFTP forking thousands of processes

[Vanush Paturyan]

On 13 Nov 2012, at 22:34, H. Peter Anvin wrote:

> On 11/13/2012 04:49 AM, Nikola Ciprich wrote:
>> 
>> Which I'd undetstand that no more then 500 in.tftpd processes
>> should be spawned. I guess tftp is forking on it's own, right? Is
>> it possible it could block somewhere unable to send replis, but
>> forking on (repeated) requests?
>> 
> 
> This comes up every so often.  The way to fix this is for in.tftpd to
> keep track of its clients in a hash database so it can filter out
> repeated RRQs or WRQs, but since the design of the protocol is still
> such that repeated RRQs or WRQs cannot always be detected it is still
> not always going to work.
> 

Can this not be tracked by iptables with "-m state"? Something like this:
"-A INPUT -p udp --dport 69 -m recent --set --name TFTP --rsource"
"-A INPUT -p udp --dport 69 -m recent --rcheck --seconds 5 --hitcount 3 --name TFTP --rsource -j LOG"
"-A INPUT -p udp --dport 69 -m recent --update --seconds 5 --hitcount 3 --name TFTP --rsource -j DROP"

(i've enclosed lines in quotes in case mail clients wrap them). This should (in theory) rate-limit connections to 3 per 5 second for each individual client.

Not sure if adding -m state --state NEW will limit it to only NEW connections, as udp don't really have "new" state (but I've heard Linux conntraker is doing a good job of figuring out RELATED udp packets, which don't make sense from the protocol standard point of view either. Maybe it can track new connections as well?) 

Misha.

---
Vanush "Misha" Paturyan
Senior Technical Officer
Computer Science Department
NUI Maynooth