Not sure about the question, but next features will be very useful:
a)IP Sevices: make access more then from “one place”.
b)DNS: make access restrictions via IP (or ip list).
It’s possible to make restriction via firewall, but this feature could be very “handy”.
both of those can be done with firewall …
If it is traditional DNS rebinding you would need layer 7 inspection of DNS traffic to ensure that either records stick (no records are added to a reply that has been seen before), or that no reply ever contains an IP address behind the router.
Considering the admin interface for RouterOS is accessible on all router IP addresses by default, I’d say the Onus is on the user to firewall off their own system.
Asking mikrotik to fix it would be akin to asking them to preinstall a random password on each new router shipped.
I’ve always thought it odd that RouterOS allows null passwords for users, Rather than ship them with random passwords alter ROS to not allow blank passwords, Its good basic security practice
So if I have the www service disabled this solves the problem for this attack as long as they are not specifically after my routerOS and target Winbox and discovered it on my non standard port ?
The only service I run is winbox on a non standard port.
I dont think this will effect me.
I just figured I would bring the issue to everybody’s attention.
if you don’t know the password, an empty password is as hard/easy to guess as a five letter password. we could use a predefined 7 symbol password, but if it’s all the same on all units, it will be known and posted on the first day of release.
password based on the serial number would be the only way I can imagine, but I suspect there will be more complaints about this, as many people want to preconfigure their routers in their own way before using or selling them, and they use automated systems (like Flashfig) to do this, and nobody wants to read and type the password manually in an automated system
Fewi:
If it is traditional DNS rebinding you would need layer 7 inspection of DNS traffic to ensure that either records stick (no records are added to a reply that has been seen before), or that no reply ever contains an IP address behind the router.
These would be a handy rules to block all sorts of rebinding.. Do you happen to have these rules you could share with the forum ?
I’m sorry but sniff some botnet traffic, Null passwords are the first thing tried on brute force bot scans. I dont think you need serial based passwords on each unit but atleast not allowing null passwords would be a better and safer way to start
four-five letter passwords can be bruteforced just as quickly.
I do not. I don’t think you can do the former on RouterOS at all, but the latter should be possible. If I have time this week I’ll try to write them.
Turns out I can’t figure out how to make that work. Can’t match on content reliably because the class and type are in binary and not in string form, and just searching for numbers would cause false positives.
I can’t write a layer 7 protocol matcher because what you’re looking for is at least \x00\x01 (type A) followed by \x00\x01 (class IN) followed by 4 bytes (TTL) followed by two bytes (data length) followed by the IP address, where you’d want to match either \x0a (starts with a 10), \xac (172) followed by [\x10-\x1f] (16-31) or \xc0\xa8 (192.168) to match all replies that resolve to RFC1918 addresses. That regex would be “\x00\x01\x00\x01…(\x0a|\xac[\x10-\x1f]|\xc0\xa8)”, but you can’t enter that because null bytes terminate regular expressions. I don’t see how you can work around that because without the type and class anchor you’d get quiet a few false positives.
If anyone else better at writing these has any ideas I’m curious how this would be solved.
EeEee that is obviously way harder then it seemed. Interesting tho. Like a fun puzzle..
On the password thing… Anyone who has a default password should be owned. Its so stupid they really need to be taught a lesson. Smart people should not try and figure out a way to save stupid people from themselves. Let natural selection take its course. I think Mikrotik should keep blank default passwords. Someone who does not have the skills or experence to set a real password should not be using Mikrotik.
Why not break it into two separate expressions to lower the number of false positives, or use a combination of firewall filter rules to help you along.
I’m terrible at regex’s sorry.