I would like to respond in a generic and sweeping way - having not read in the detail Bob layed out for us required to fully analyze the situation - to the notion that circuit level access or prior topological knowledge is required to exploit this or any other spoofing attack. On a corporation or education network, I could generate such malformed packets with almost no effort as long as i had my Mac or a similarly not-windows device, or access to one. I estimate it'd take less than 5 minutes for me to do for the majority of targets - which means any motivated party could within an hour or two. I'm not warranting I would succeed - hopefully there would be a real firewall SOMEWHERE in the path from the open internet to a real physical host.
IP routers are, by design, completely disinterested in source information and the additional overhead of becoming aware and meaningfully acting on it is significant - hence multimillion dollar price tags on single linecards in most Internet-scale devices. Additionally, the amount of knowledge required to effectively benefit from it while avoiding massive architectural issues is frequently impractical if not to distribute to the necessary infrastructure devices. Long story short: this sort of processing is only practical at the very.ingress interfaces to a network. In the case of a Level 3 sized carrier that would mean the number of interfaces that are not protected from such a packet would number literally in the millions. Level 3 is a poor example of an vulnerable path - i would be hard pressed to circumvent their security strategies due to effective onion-like layering - but AT&T's? No problem. All I need is one host that is willing to play and is on a segment without reverse path forwarding - which is all of them, in my experience. Once i am past the first hop I can get the rest of the way there. The network should not *ever be the solution *to a host vulnerability. It can provide a break-fix level of response but as I believe it was PHK said - the only effective mitigation strategy starts with a real firewall followed by a very aggressively managed host. The level of protection offered by standard anti-spoofing ACLs or advanced RPF detection is merely insurance. Other effective strategies include NEVER allowing the internet to connect directly to a host. A simple reverse proxy or server load balancer combined with a RFC 1918 numbering scheme on host networks is a VERY powerful tool. Such L4-7 inspection engines are just the ticket to foiling an evil exploit. NS i Sun, Oct 25, 2015 at 2:01 PM Paul <[email protected]> wrote: > [This is my final contribution to this topic since real time-nuts using NTP > run their own S1 servers driven by their Thunderbolts (et.seq.) and don't > need to worry about this] > > On Sun, Oct 25, 2015 at 11:27 AM, Florian Teply <[email protected]> wrote: > > > > > > > >But if I read that article on ars technica correctly, it looks like > > > >it is something inherent to the ntp protocol itself and the > > > >definitions it makes. > > > > Only loosely. It might appear that RFC5095 admits certain attacks using > the 'debug' interface however the 'source'* document says (referring to the > 'nonce' check) > > "While it seems reasonable to expect this check to be performed on the KoD > packet as well, RFC 5905 [41, Sec. 7.4] does not seem to explicitly require > this." > > I believe this is an incorrect interpretation but in any case I think it's > clear the RFC is ambiguous and the published "fix" is to explicitly > validate the nonce. Other fixes include completely disabling the 'debug' > interface. Implicit in this is the need to update the NTPv4 RFC. > > I advise those concerned to read RFC5095, the BU paper* (don't worry about > the 68 references) and check the NTP security notice** to draw your own > conclusions about this problem keeping in mind Wojciech's recent comments. > > *http://www.cs.bu.edu/~goldbe/papers/NTPattack.pdf > **http://support.ntp.org/bin/view/Main/SecurityNotice > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
