Page 1 of 1

Bruteforce prevention Issue

Posted: Thu Sep 06, 2018 6:04 pm
by earcaesar1
Hello,

I have a working brute force to block winbox access. It sort of works, the timers don't seem to fully work. For some reason when stage1 timer is say at 30 secs down from 1 minute and you log in again stage 2 timer starts and stage 1 timer refreshes back to 1 minute. Not sure if that is how it is suppose to or if I am doing something wrong.

Code: Select all

add chain=input protocol=tcp dst-port=8291 src-address-list=winbox_blacklist action=drop \
comment="drop winbox brute forcers" disabled=no
add chain=input protocol=tcp dst-port=8291 connection-state=new \
src-address-list=winbox_stage3 action=add-src-to-address-list address-list=winbox_blacklist \
address-list-timeout=10d comment="Winbox 10 day Ban" disabled=no
add chain=input protocol=tcp dst-port=8291 connection-state=new \
src-address-list=winbox_stage2 action=add-src-to-address-list address-list=winbox_stage3 \
address-list-timeout=1m comment="Winbox Stage 3" disabled=no
add chain=input protocol=tcp dst-port=8291 connection-state=new src-address-list=winbox_stage1 \
action=add-src-to-address-list address-list=winbox_stage2 address-list-timeout=1m comment="Winbox Stage 2" disabled=no
add chain=input protocol=tcp dst-port=8291 connection-state=new action=add-src-to-address-list \
address-list=winbox_stage1 address-list-timeout=1m comment="Winbox Stage 1" disabled=no
add chain=forward protocol=tcp dst-port=8291 src-address-list=winbox_blacklist action=drop \
comment="drop winbox brute downstream" disabled=no
The Main issue I am having is due to the nature of how we setup some things I need to keep access to www enabled. I have changed the format of the ports to match port 8080 but for some reason when I try and test this and browse to the webfig login page, it auto turns on stage 1, stage 2, stage 3 and blacklist for the www service. I am not sure why it is doing this. I am assuming that the webfig login page opens multiple sessions at the start, but I am unable to find out how many it is opening. Any feedback or suggestions to make this work would be appreciated.

Code: Select all

add chain=input protocol=tcp dst-port=8080 src-address-list=www_blacklist action=drop \
comment="drop www brute forcers" disabled=no
add chain=input protocol=tcp dst-port=8080 connection-state=new \
src-address-list=www_stage3 action=add-src-to-address-list address-list=www_blacklist \
address-list-timeout=10d comment="WWW 10 day Ban" disabled=no
add chain=input protocol=tcp dst-port=8080 connection-state=new \
src-address-list=www_stage2 action=add-src-to-address-list address-list=www_stage3 \
address-list-timeout=1m comment="WWW Stage 3" disabled=no
add chain=input protocol=tcp dst-port=8080 connection-state=new src-address-list=www_stage1 \
action=add-src-to-address-list address-list=www_stage2 address-list-timeout=1m comment="WWW Stage 2" disabled=no
add chain=input protocol=tcp dst-port=8080 connection-state=new action=add-src-to-address-list \
address-list=www_stage1 address-list-timeout=1m comment="WWW Stage 1" disabled=no
add chain=forward protocol=tcp dst-port=8080 src-address-list=www_blacklist action=drop \
comment="drop WWW brute downstream" disabled=no

Re: Bruteforce prevention Issue

Posted: Thu Sep 06, 2018 6:46 pm
by Sob
Bad news, all this is almost useless.

You can block stuff on network level only for services that use single connection (WinBox, ssh, ...). Even there it's far from perfect, because you can't know if login succeeded for given connection or not. You're just counting connections. Even successful login will be counted by this method. So try to use it from some location with unstable internet connection, get disconnected few times and you might end up blocked too. It's not good.

With WebFig it's even worse, it's regular http service, browser can and probably will open many connections, so you either need to have very generous limit, or you'll end up blocked all the time.

There's also another problem. If you set strong password, then even if bruteforcers would work 24/7, they have near zero chance to find it. It's not like bruteforcing passwords locally, where you can try millions of them every second, network slows it down significantly. Even if they could try hundered or thousand passwords every second (it will be way less in reality), they won't get anywhere.

But all this provides zero protection against something even more dangerous, like the recent WinBox exploit. In case you missed it, WinBox was happy to tell full list of usernames and passwords to anyone who asked. And all it needed was single tcp connection. As you can imagine, what you're trying to do would not help at all.

Re: Bruteforce prevention Issue

Posted: Thu Sep 06, 2018 7:28 pm
by k6ccc
As Sob said, what you're doing is not overly helpful. At first I thought you were doing a port knock until I read it. You would do better with a port knock.
add action=add-src-to-address-list address-list="Long Knock-1" \
    address-list-timeout=15s chain=input comment=\
    "Long Port Knock setup step 1" dst-address=aaa.bbb.ccc.ddd dst-port=zzzzz \
    log=yes log-prefix="Long Port Knock step 1" protocol=tcp
add action=add-src-to-address-list address-list="Long Knock-2" \
    address-list-timeout=15s chain=input comment=\
    "Long Port Knock setup step 2" dst-address=aaa.bbb.ccc.ddd dst-port=yyyyy \
    log=yes log-prefix="Long Port Knock step 2" protocol=tcp \
    src-address-list="Long Knock-1"
add action=add-src-to-address-list address-list="Long Knock-3" \
    address-list-timeout=15s chain=input comment=\
    "Long Port Knock setup step 3" dst-address=aaa.bbb.ccc.ddd dst-port=xxxxx \
    log=yes log-prefix="Long Port Knock step 3" protocol=tcp \
    src-address-list="Long Knock-2"
add action=add-src-to-address-list address-list=Safe address-list-timeout=1m \
    chain=input comment="Long Port Knock setup step 4" dst-address=\
    aaa.bbb.ccc.ddd dst-port=wwwww log=yes log-prefix="Long Port Knock step 4" \
    protocol=tcp src-address-list="Long Knock-3"
This is a four step port knock. Once a source IP is on the "Safe" list, you have one minute to establish whatever connection is allowed by the safe list. Then depending on how you set things up, you can have established connections allowed, or have rules that reset the "Safe" list timer as long as you keep doing stuff. You can also only allow specific addresses for the various port knock stages - only works if you know what they are. For example, if I'm connecting from a known address at work, I can get in with a shorter port knock than is required from the internet. You note that the rules also log the entries, and there is a script that sends me an E-Mail if the last step of the port known is activated. Note that there is zero response from the router when a port knock step is triggered, so a port scanner would not know that it accomplished anything.

I would also recommend using non-standard ports (and 8080 for www access hardly qualifies). It adds one more layer of obscurity. Keep in mind that security through obscurity once broken is nothing, so this should NOT be the only method used.

As for port scanners, there are lots of references on the Wiki.

Re: Bruteforce prevention Issue

Posted: Thu Sep 06, 2018 8:07 pm
by earcaesar1
Thank you for your all responses,

I have a couple simple questions at first. One when you select code to add in what option are you picking ?

Other than that. I understand of the recent hacking for winbox. That is one of the reasons I am trying to increase some of this stuff to keep the people out that hacked or at least stop them.

I do know its not perfect. I don't use port 8080 as our www port I just was using that as a reference. I was going to try the port knocking method but it does not really work very well for our application for the most part. I have over 500 different routers out in the field and they are being managed by a different location for tech support. Now I could whitelist some ip addresses to the "safe" list to bypass the port knock

but my question is really about the session count and it seems like the only option I have is I guess to do a port knock and just make a secure list to avoid people getting in to the www service. I was trying to avoid the port knock for ease of access through a phone while being mobile without having to do a port knock to get into a system

Any other suggestions to basically block people that try and brute force in.

Re: Bruteforce prevention Issue

Posted: Thu Sep 06, 2018 8:22 pm
by k6ccc
Thank you for your all responses,

I have a couple simple questions at first. One when you select code to add in what option are you picking ?

I assume you mean where I included my code extract. It's the symbol to the left of the quotation marks.

You can also just type "[ c o d e ]" and "[ / c o d e ]" (without the quotation marks and spaces).
Note that you have to leave a blank line before it...

but my question is really about the session count and it seems like the only option I have is I guess to do a port knock and just make a secure list to avoid people getting in to the www service. I was trying to avoid the port knock for ease of access through a phone while being mobile without having to do a port knock to get into a system

Here's what I do to make a port knock easier. I have bookmarks in my browser for each one. Click the first one, wait a second, click the second on, etc. Takes seconds.

Re: Bruteforce prevention Issue

Posted: Thu Sep 06, 2018 8:29 pm
by earcaesar1
Here's what I do to make a port knock easier. I have bookmarks in my browser for each one. Click the first one, wait a second, click the second on, etc. Takes seconds.
This works if we are only managing 1 or 2 devices, but I am managing 500 routers in the field and increasing. This bookmark feature would not work.

Re: Bruteforce prevention Issue

Posted: Thu Sep 06, 2018 8:38 pm
by k6ccc
Here's what I do to make a port knock easier. I have bookmarks in my browser for each one. Click the first one, wait a second, click the second on, etc. Takes seconds.
This works if we are only managing 1 or 2 devices, but I am managing 500 routers in the field and increasing. This bookmark feature would not work.
Yea, I only have three - and no expectation of that growing very much (if at all).

Re: Bruteforce prevention Issue

Posted: Thu Sep 06, 2018 10:32 pm
by earcaesar1
I was thinking of adding a series of safe ip addresses to a list, than having a brute force rules to stop the winbox stuff and also do a port knock like we were talking about.

My question is 1 will this work for this setup and if so if the ip address gets banned will it also be cleared through the safe list?

Not sure 100% how to set that part up

Re: Bruteforce prevention Issue

Posted: Fri Sep 07, 2018 2:04 am
by Van9018
How about a Mikrotik as a VPN server. Techs VPN into that router. Then all client routers allow winbox, RDP, etc from the VPN Servers IP.
It also gives the ability to cancel the tech's access to all client sites by deleting his login on the VPN server.
iPhone, Android, Windows and Mac all support L2TP/IPSec.
Could that work?

Detecting brute force may work if your service disconnects a connection after 1 failed login. Then you can count how many connections per few seconds and ban the IP after too many connections per 10 seconds.

Re: Bruteforce prevention Issue

Posted: Wed Sep 19, 2018 12:01 am
by earcaesar1
Sorry for the delay on this. This method works for the most part, we are already doing this, but I am trying to allow people not having to do a VPN tunnel into then network to restrict it. This is more so for people that are on the road traveling and need quick access to Troubleshoot and get access real quick without having to do an extra step.

I don't need anything like 100% blocking. I can do that but it is not the best solution for our stuff.

Is there any suggestions on how to set it up so that there is a "safe" list of common IP addresses we use to always be good and than to do the brute force blocking for port 80 and port 8291. This would only block or cause the login attempts to start if it is not part of the safe list.

Also I was looking at maybe adding a port knock for say SSH so that way if there is an issue I can always login via SSH to unblock the issue remotely

Re: Bruteforce prevention Issue

Posted: Wed Sep 19, 2018 12:47 am
by gerakon
You should be able to add a firewall filter rule with the safe addresses above the brute force blocking rules, then they shouldn't every make it to the blocking rules.

Though I agree with Sob and Van9018, VPN is safer.

Re: Bruteforce prevention Issue

Posted: Wed Sep 19, 2018 2:01 am
by Sob
Actually, I'm not sure if I agree with Sob about VPN being safer. ;) And I never wrote it was. If MikroTik made an ugly mistake in WinBox server, they could as well make similar mistake in VPN server. But the prevailing opinion seems to be that VPN should be safer than direct WinBox access.

IMHO dealing with bruteforcers is near useless from security perspective. Use a twenty-characters password and they won't get in anyway, because they won't be able to try all combinations. They would need really lucky guess to get in. Only annoying thing, if you let them connect, is that they will fill up the log. But if you want to also protect against bugs, you can't let them connect at all, not even once.

If VPN is too difficult, then go with port knocking. It's not real security either, but it's good enough to prevent random remote addresses accessing your services. It's up to you what you use, it can be connections to different ports, different sized icmp packets, anything. You can make it in way that no special tools will be required for the knocking. Ping is available on every computer, telnet (to make tcp connections) on most, or you can just use web browser and open http://<router>:<port> to make tcp connection to <port>.

Re: Bruteforce prevention Issue

Posted: Wed Sep 19, 2018 5:26 pm
by gerakon
Eh... so you didn't. :?
I guess it was more that you didn't think brute force mitigation was very useful, but I didn't take the time to go back and look at what you said after reading the rest of the posts....

Yes there could be an unknown vulnerability in the VPN server.

On some of my routers I have setup port knocking for the VPN services as well, then nobody should get a response from my routers except me..... Or someone would have to go through the effort of running a packet analyzer somewhere along the route between me and my router and know what they were looking for....

If you wanted to get really creative, you could setup an auto changing port knock with a script on the router and a port knock application on your computer with the same algorithm you use in the router.... but that might be more effort than the little bit of extra security you'd get out of it....

Re: Bruteforce prevention Issue

Posted: Wed Sep 19, 2018 6:17 pm
by Sob
I wouldn't get too creative with port knocking on RouterOS.

If it should work as basic protection against random bots, even single port/ping knocking is enough to get rid of >99% of them. Make it two or three and their chance to get through is near zero. Most don't even bother with port scanning, they just go for open well known ports (ftp, ssh, ...) and try their luck.

If you want port knocking resembling a real security layer, something that can't be simply replayed, you'd need some one-time codes. I've seen something that uses regular SYN packets to target port and embeds data in sequence number and other fields. There was some cryptography involved and it looked really nice. But you can't do that with RouterOS alone. Something simpler is probably possible, but there's only so much you can do with address lists and simple scripting, so it will be closer to security through obscurity and I'm not sure if it's worth it.

Re: Bruteforce prevention Issue

Posted: Wed Sep 19, 2018 7:08 pm
by k6ccc
I do use port knocking (among other things), and log any connection attempts. Of course for step one I see hits somewhat regularly due to random scans. I have NEVER seen a hit on step two if it was not me. As sob said, most of the attackers are simply going after the commonly used ports. I do also have rules that will stop (or at least slow down) port scanners. Somewhat unexpectedly, those rules really don't show many counts. I don't use the standard ports for any access into my routers, but I do have firewall rules that allows me to see packet counts on the standard ports. Interesting to see the counts sometimes.