-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Mike O'Connor Sent: Wednesday, 3 April 2019 2:32 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au>; Karl Auer <kauer@nullarbor.com.au> Subject: Re: [MT-AU Public] UKNOF 43 CVE
On 3/4/19 1:29 pm, Karl Auer wrote:
On Wed, 2019-04-03 at 12:41 +1100, Mike Everest wrote:
MikroTik have released an effective patch for this issue [...] It is important to note that this problem affects routing function of ipv6, so packets with final destination of any host forwarded by a router will make that router vulnerable (i.e. input chain is no use for above rules) Sorry, Mike, I don't understand that paragraph at all. Can you clarify, please?
Regards, K.
Mike E is saying that simply seeing a ipv6 packet is a problem.
I have no idea if he is correct because I've not seen the details behind
Mike, Karl, Yes, that's an accurate translation of my clumsily worded statement! :-} To clarify further, the particularly nasty issue (the one from this recent discussion that has caused the most angst) is related to the ipv6 routing engine. Essentially, an attack on a specific router can be made by sending 'specially crafted' IPv6 packet to any IPv6 host on any network via the target router. So such malicious packets could have destination address of another router server, host, client on your network. The structure/content of such malicious packets are not matchable by any of the available packet attributes of MikroTik firewall, and therefore, the only way to effectively limit excess dodgy packets is to limit ALL ipv6 connections to a limited rate. Typically, attacks that target a specific device by sending packets with destination address OF THAT device which can be mitigated using input chain of firewall. For reasons outlined above, input chain can not be used for this case. Therfore, until the bugfix/longterm and stable versions include this recent fix, core routers processing significant (more than 2 new connections per sec, burst of 5) we recommend to run the 6.45beta23 software release, and firewall filters for all other routers. Of course if you do not really *need* ipv6 right now, it is also worth considering to just temporarily turn off IPv6 in the interim (by disabling IPv6 package, disable all public ipv6 addresses, or just remove network advertisement from your BGP) For us, ipv6 is mostly experimental since it is only inside our WAN and across one upstream peer, so we'll be disabling for a couple of weeks at least. <sigh> I suppose IPv6 can still be considered 'new' for most of us (even though it *shouldn't* be!) and that this sort of event can be welcomed as just another step toward efficient and effective universal IPv6 for everyone. I suspect that it won't be the last time it happens (and not just MikroTik I'm sure ;) and we should all be thankful for guys like the fellow who discovered this one and made some concerted effort to make sure it was addressed! Hope it clarifies the situation better :-} Cheers! Mike. the
issue.
Mike
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au