So, Normis and Janisk both post elaborate defenses, and simply ignore all the queries about a security list-serv or equivalent?
Seriously?! [With all due respect, can I have what you're smoking? It's got to be good stuff!]
-- First: I can show you scare mongering, and this isn't it. [The first post or two, who knows. I'm not going to get into analyzing the mindset of another poster. Perhaps they are people with ill will toward RB/MikroTik, perhaps not. But my posts, and my queries, they've been respectful and simply asking for more data. The other posts also have been asking for more data.]
-- Second: Scaremongering only works if you refuse to get out in front of the problem and actually address the issues in non-bunker mentality. Be open about the issue, it's cause and ramifications, remediation steps and time for a fix.
You've had to be led, screaming and kicking the whole way, to get the most minimal disclosures so far. So, in that environment, you are being your own worst enemy in allowing MikroTik to be a "victim" of scare-mongering, IMO.
When people think you're being evasive, not fully honest, hiding things - that's when fear-mongering works.
[And that's how it looks to me - and really, I'm no hostile audience. I really WANT MikroTik to succeed. I've just spent a very significant amount of time moving my clients to RB and writing scripts and doing a lot of bench-testing etc. I don't have lots of great alternatives. So, believe me when I say, I *really* want RB to succeed. At it's core, it looks like a really great product. If I didn't want your success, I wouldn't have spent the time, money and resources here.]
So, if you want to immunize yourself against fear-mongering, just be fully open and very up-front about the problems. If you don't, someone will fill up the vacuum with mis-information - intentional or not.
-- Third: Please stop with all the "firewall blocks on the WAN interface fix the problem." You act as though this isn't a problem because you shouldn't use WinBox on the WAN interface. You act as though this is just "normal" and any non-retarded non-moron wouldn't be complaining at all, that this is all a total freak-out over absolutely nothing.
Lets just, for the sake of argument, assume this is a reasonable/plausible suggestion. [That it's all a "freak-out" over nothing.]
If that is really so, and freaking-out over nothing, and there's really nothing there, there...then why bother fixing the problem at all?
Oh, that's right, because it really *is* a problem.
Any station that can communicate with WinBox can exploit this and DOS the Routerboard, including internal stations - or something infected with a virus etc. [And yes, it would have to be specially tailored etc - I fully understand this.]
And the attacks from a "fake" RB server are, from the minimal data I have, very serious.
So, it *IS* a real problem. You're admitting that by fixing it. But you can't have it both ways. Either it's not a problem and we're not going to bother fixing it, or it IS a real problem and that is WHY we're spending the resources to fix it.
The mitigation steps help for people who *can* practically implement them. However, some won't be able to implement them, and the thing is *still* vulnerable unless you disable all management except through the serial interface. Do you think Cisco would get away with claiming that "only people on the LAN could DOS Cisco routers" and thus it was all no real problem? [Answer: ABSOLUTELY NO!]
However, there are, essentially, NO mitigation steps for the fake RB server problem however. [Again, going from the extremely limited data that MikroTik has divulged so far.]
-- Fourth. You continue to avoid any time-frame of a fix. "We're working on it," doesn't mean a lot to me. Did you ever hear about Duke NukEm Forever? They're working on it. [Just to save you time, it was a FPS game that went through a 15 year development cycle, and still generally sucked when it finally rolled over the finish line. It received a "Lifetime achievement award" for being vaporware.]
So, "working on it" is nice, but not enough.
When, generally, do you expect to have resolution in place. I understand that dev cycles aren't solid guarantees, but rough estimates are good. Should we expect six days, six weeks, six months, six years, six decades or six millenia?
And again. Is there some plan to put in place a security announcement list-serv? I shouldn't need to check the forum. Every other Linux product: Postfix, sendmail, dovecot, apache etc all have security-announce lists.
If I subscribe to the announce list, I get notifications of security problems and links to fuller discussion and remediation steps. MikroTik REALLY, REALLY, needs to do the same. Don't expect people to check in here every day/month/year to see if there was a security vulnerability that was addressed and fixed. You need to proactively contact anyone who wishes for notification of a problem. A moderated list-serv is usually the time-honored way to handle this.
I'll leave it there - but really MikroTik, you can get in front of this and actually lead the way. If you refuse, there are those of us who will "help" you. You probably won't like it, and as the above shows, it sure seems you don't. But as the saying goes: "You can either lead or follow, but get the *** out of the way."
To Recap, here's what I and others are asking!:
-Answers about the problem and it's scope. [Would be nice, but I'm not holding my breath.]
-Time-frame on a working fix for this undefined set of security vulnerabilities/DOS attacks. [Must have!]
-Position on a security list-serv and when and how you plan to implement. [Must have!]
- If I helped you solve your problem ... Karma is an appropriate gift!