ROS 3.16
RB230
Current Routerboard Firmware 1.3.8

The Only configuration is nat, Public IP and a gateway and Queues. The router is a test machine for a inhouse bandwidth management system using the ROS API.

Problem: The router goes under a SSH attack and we experience a symptom where we cannot get into the router anymore using normal username and passwords, SHH and Winbox are both affected. At this point, the router accepts admin and no password. Issuing a reboot from ssh/winbox locks the router up and it must be manually power cycled. At this point everything returns to 'normal'. I do not have a console output yet of the reboot lockup at this point.

I have since put on firewall rules for SSH to see if it happens again, but I"m concerned about a huge security flaw in ROS concerning SSH in that our experience with this problem leaves a router open. I have few other routerboards I would like to specifically test this issue with to provide Mikrotik with more ammo, but if they haven't already seen the issue, I've had it happen now four times on me. I'll send a supout once i get the chance but it has been interfering with the development of the project.

how about this?
http://wiki.mikrotik.com/wiki/Bruteforc ... prevention

properly configure the firewall and there will be no issues like this

i can confirm this loss of user database on x86. i have had one specific x86 box that every once in a while all credentials get lost and admin/blank are the only ones that work. a simply reboot (not locked up like posters was) and its back to working. i took some supouts and even a screen video, i will see if i can post it. i assumed it was bad flash (yet again). at this point I am not sure if replacing the flash fixed it or not. will report back when i know for sure.

I 100% whole heartedly agree that proper firewall setup and maintenance is necessary to protecting our routers and network. I will never argue you that on that point. Even the best firewalls can be compromised though, and having a brute force attack simply render the most basic of unauthorized access prevention useless even without the attack itself being successful in finding a username/password combination can be a huge problem and is a big concern. It is our last line of defense, it should not our first.

I am going to see if I can't setup a SSH attack with some 3.xx versions, protected and unprotected and see if I can't pin down the problem. This is the only 3.16 box I have, and the only machine that I've had the problem with.

i can tell you in my situation it has nothing to do with an ssh attack. . . i have mine totally closed and i still saw the problem. and i've seen it on all versions of 3.x, not just .16. it is only happening on one router out of 20 that i maintain which is weird.

Sam