To be pedantic there is technically no recent Mikrotik CVE WRT Meris. It was patched in 2018(?) shortly after discovery.
From their response to the Meris botnet[1]:
> As far as we have seen, these attacks use the same routers that were compromised in 2018, when MikroTik RouterOS had a vulnerability, that was quickly patched.
> Unfortunately, closing the vulnerability does not immediately protect these routers. If somebody got your password in 2018, just an upgrade will not help. You must also change password, re-check your firewall if it does not allow remote access to unknown parties, and look for scripts that you did not create.
It goes into more detail to further check/harden the device in the blog post. A lot of issues stem from having Winbox or other admin access not properly firewalled off and open to the world. Blessing and a curse of the power you have with these devices I guess.
I'm not a salesman nor do I care that much about the company, but seriously, let someone handle this stuff for you. There are at least a handful of us left, and we are good at what we do, generally.
Peace of mind is worth a lot. If this person were with my company for example, this wouldn't even be a comment.
I say my company meaning my employer. I have exactly zero stake in mentioning them by name or advertising them.
It’s probably a liability to go with anyone else, due to the lack of network resources.
TBF, I agree with the sentiment...cloudflare does seemed poised to own the world.
But they don't do everything well.. Not everyone wants a stupid landing page or captcha.
And Cloudflare will say... wait that's just free tier stuff, our enterprise stuff is X. Which is the whole problem, people associate free tier stuff with them, while they do offer better things. And those things compete directly with others who offer...those same things.
If Cloudflare is the endgame, why are companies like mine still getting customer acquisition?
Others have plenty of network capacity... that's not even a thing.
They definitely have brand recognition and are tip-of-the-tongue for people who have no prior experience.
"Best" in terms of actual product and protection is going to be F5, Akamai, Imperva, Voxility, etc.
I've ignored the first few mails. Still they kept coming.
I've told them curtly but politely we weren't interested. They tried to engage a sales conversation from that. Ignored them. Still they kept coming. Future outreach mails not even acknowledging the earlier conversation.
I told them they needed to learn when to let go and, literally, to "FUCK OFF". Still they kept coming.
I stopped their spamning with a custom SpamAssassin rule. That's what it took to get rid of them.
Don't support those spammy sales techniques. Don't do business with them.
I do think one day they'll squash everyone out, but not anytime immediately.
One big thing, to me. Call each as you would as a customer. Apparently some are easier to get ahold of than others.
Pick one where you can get a competent human on the phone quickly. Because when you're getting DDoS'ed and threatened by your bosses at 1AM, it's going to be a big peace of mind.
Second, if the response has to be larger than the request, send the requestor an address-specific value in a small initial response, e.g. HMAC of a secret and the sender IP. Then any request that incurs a large response has to contain that value. If the sender is spoofing the IP address and can't receive the small response sent to that address, they can't cause a large response to be sent there.
This can't be done with DNS because of "security" middleboxes. They ossify the protocol because they reject anything they don't understand, and they don't understand new versions of the protocol even if both of the endpoints do. So the protocol gets frozen in time and no security improvements can be made because of the things that claim to be there to improve security.
There is little actual reason for security middleware to not keep up.
This stuff is built on the foundation of puffing out EnTeRpRiSe ScAlE egos with "look at all this vast complexity that I made, I am a god". It's not built on a technical foundation of always moving the needle forward just because you can and because it's cool and the right thing to do.
Sooo, all the $$$ get spent on dashboards and analytics screens and front panel designs and logos and stuff. The actual DNS bits? Probably /r/programminghorror material.
Apart from human readability, how so?
The internet is IP. It is very robust. DNS is an application over the top of the Internet.
I don't think very many other applications will work without DNS either, although I never did much competitive testing.
Could you or someone else expand on this? How do you coordinate rtbh with your ISP? And how do you check for whether it's working? I'd love to learn more on this topic. Thanks!
How do you test it? Very simple. Announce an IP (or a few) as blackhole and test to make sure things don't work (from that IP).
Very simply could setup something to ping something on that provider's infrastructure from that IP and... if it starts to work, alert!
I imagine getting paged because of a DDOS is slightly easier when it's telling you it already null routed a few IPs so the rest of your network isn't screwed and you just have to identify how problematic those specific IPs being out of service is and whether you need to take action or wait for them to get bored.
There are, of course, proposals and protocols to make things better, but not caring is easier, and strict enforcement is hard, especially as the bandwidth goes up.
There's also enough ISPs that don't do egress filtering that name and shame isn't effective, and anyway, what am I going to do if I'm connected to an ISP that doesn't filter? I have exactly one meaningful offer of connectivity, so that's the one I've accepted, regardless of its merits. Many ISPs have a similar hold on customers.
> but once you get customers that can bring their own IPs (...)
You know these IPs though, since you route to your customer. So you could drop the offending packets. (I may be getting over my head here).
Also, the routing/BGP configuration is often separate from the filtering config, so making sure things are synchronized can cause problems.
It's far less time intensive as an ISP to just not filter once it starts getting complex. After all, you don't get a lot of customer service calls when you let ill-advised packets through, but you do get calls when you break things by dropping packets your clients were authorized to send.
It may be so, however my own need for clarification was the same as yours. If ISP xyz operates a /16 ip block, and only forwards source packets from its /16... Then, I guess, my question: how do spoofed packers usually travel past their first hops on their route to the target?
[edit] after-thought: I imagine attackers might easily spoof their source as any of their ISPs /16 or /8. Feels like that's not entire story here though.
No carrier will shut down an ISP paying them 100k/month just because of some spoofed traffic.
(Also, to people down-voting a genuine question ? wth..)
Who would then have to determine where it's coming into their network from, and go ask that ISP, who would have to do the same, ad nauseum. And all parties would have to be paying enough staff to handle that load in addition to, you know, making sure their services work.
- the DNS operator doesn’t care. These look like normal requests.
- if they did care, asking an ISP to packet trace ingress traffic is not trivial. At any large scale ISP there are hundreds to thousands of direct peers that could have originated that traffic.
I bought a mikrotik router recently, for my home network. How can I tell if I am impacted by this, and are there any mitigation strategies?
It's not really recent (2018) just that it's still being used after all this time. If you're using a default config on the home router you're basically already fine (save for changing the default login).
If your router is up-to-date and not previously compromised, you should be fine.
I asked around internally & Magic Transit is a solution the ISP should be able to leverage to protect themselves.
I think people who make this argument tend to forget that Cloudflare is an infrastructure provider that the website owner employs. It's not really MITM if the site owner explicitly asked them to terminate TLS so that CF can provide load balancing, tunneling, and a number of other services. It's the exact same as using an AWS ELB. Yeah it terminates TLS, but you can't really say its doing MITM since the site owner specifically configured it for that purpose.
Yeah, I just feel like people overreact to news.
Moms of 2021: this person in the news had a very bad case of X (covid, covid vaccine, hazelnuts, idk), I should avoid X preemptively
Nerds of 2021: this website in the news had a very bad DDoS attack, I should avoid DDoS attacks preemptively
The vast majority of people do not need to break the internet[1] for DDoS protection. It is really not that common. I know exactly nobody whose personal website got DDoS'ed. I do know people whose personal website is behind Cloudflare to preemptively avoid this problem.
I run a website myself where people can host all sorts of contents, I can totally imagine not everyone is happy with that. Never been on the receiving end of any kind of abuse though (people even ask me if I'm not afraid of that!). And if I were, I'd talk to my ISP -- they were previously involved in lawsuits for internet freedoms (i.e. on the good side), perhaps they are also happy to help me keep a site hosted with them before I need to consider moving to big brother corp for protection.
> It's not really MITM if the site owner explicitly asked them to terminate TLS
Nobody means MITM in the attacker sense when the service being MITM'd literally asked the proxy to proxy their traffic. Obviously. Saying that Cloudflare MITMs connections is a way to carry both meaning and judgement, similar to how I will talk about middleboxes on corporate networks that block evil haxxor tools that I need for my daily work (y'know, wireshark and such). I call those MITM boxes because that's what they do but also because I think they're more evil than good and the term reflects that (even if there are obviously pros and cons, same with Cloudflare).
> It's the exact same as using an AWS ELB
Hmm, if I understand what AWS does correctly, their load balancing service just routes traffic internally. It's not a transparent proxy where you think you're talking to one company but really you're talking to another. The manager at BigBank also understands intuitively that if they host their data at ExampleCorp, that ExampleCorp needs to not have data breaches. But if Cloudflare it just removing malicious traffic, it's not immediately obvious that they are in just as sensitive a position. The privacy policy rarely if ever mentions such proxying services.
I take your point though that it's not that different. This is also why I'd never host with Amazon or configure my email servers to be Google's, but yeah Cloudflare proxying gets more comments than hosting the whole thing at what some people perceive as an evilcorp. Not sure if that's for the aforementioned reasons or not.
In our case it was based on DNS reflection from a large number of hosts. I've contacted the top sources (ISPs hosting the largest number of attackers) and provided IPs and timestamps. I've received zero responses.
Geo-based approaches yielded no helpful reduction in source traffic.
Also, during this event we discovered an upstream of ours had misconfigured our realtime blackhole capability. As a result, I'm going to add recurring testing for this capability and burn a couple IPs to make sure upstreams are listening to our rtbh announcements.
Very concerned about the recent microtik CVE, as that is going to make for some very large botnets.
Personally this all is very disappointing because it creates an incentive to centralize / de-distribute applications to a few extremely large infrastructure providers who can survive an attack of these magnitudes.