2014-12-01 05:19:02 -0500, Alfred M. Szmidt: [...] > Though, after thinking, I am partially keen to breaking the protocol > in a documented fashion, and submitting new RFCs for these protocols. > It would make things more useful, and the changes simply mean that a > very special case stops working. > > Would you like to submit a patch to amend these issues? That in > itself would be useful for those who do want to explicitly break the > protocol for whatever reason. [...]
Actually, thinking more about it, ignoring packets with source ports of 7, 13, 19, 37 (and 17 (qotd) as well I suppose) or anything <= 1024 for all of echo, time, daytime, chargen services may not even be enough in cases where NAT is involved as the source port we're seeing in the incoming packet is not necessarily the one that the client or attacker originally used when the packet was sent, and our reply to 54321 for instance may eventually be translated back to a port 7/13/19/37... by a genuine NATing device.. So probably the best thing to do for now is just documenting or deprecating. > I think a good step further would be to clearly document that > enabling those services have security implications and that they > should not be exposed to the internet. > > This is a good idea, would you like to submit a piece of text for the > manual? [...] Will do. Cheers, Stephane
