Configuration to block users that tries to access router on non open port(s)

If you add a nat rule to port 443 (https), you do not need an explicit filter rule, but I do have it.
And if you have a filter rule, it must be before the rule that starts to block stuff.

Filter rule:

add action=accept chain=forward dst-port=443 in-interface=ether1 log=yes log-prefix=FI_A_HTTPS protocol=tcp

Nat rule:

add action=dst-nat chain=dstnat comment="Web SSL -> Varg" dst-address-list=WAN-IP dst-port=443 log-prefix=ND_DE_SSL-Server protocol=tcp  to-addresses=192.168.3.4

ye even if i do that , still it puthing the ip on blacklist. something is not happy with the access list

Are this true?

@Jotne

i made this work ,can u explain more about TARPIT.

The question that i cant answer my self is what is the differences between TARPIT and drop.

If you put them sequentially (properly) without tarpit, just drop(everythings else) at the bottem , that will do all the job,

im assuming that tarpit above drop (everythings else)

if u can give us more info.

Thanks

Tarpit will cost more time and resources for the attacker.
You do not need this part.

A quick google search
https://en.wikipedia.org/wiki/Tarpit_(networking)
https://www.mtin.net/blog/use-tarpit-vs-drop-for-scripts-blocking-attackers/

and the last question i was playing around with your rules above,

I’ve noted something.

When i’m trying to get access from outsite with tarpit enabled, on the winbox i can see logging in and is gettign stack there. (the ip-add goes on blocked list)

If i disable tarpit and becouse of drop everythings else im seeying connecting to 1.2.3.4 (doesn’t know how to get there)

is that normal behavior?

if i read double what u have posted, what i’m experiencing is absolutely for expecting.
That is tarpit jobs

Thanks

Not convinced that there is any value in this approach.

how u mean?
according from the @Jones’s links and from what i’m experiencing , that completely match.

Lets say that you have a web server (443) and RDP (3389) open to all internett.

If some one with bad intention has a script that tests various ports, and if open ports are found trying to breake inn, this script for sure helps.
When the hackers script test port 10000 for any reason, he will be blocked for 24 hour on all ports, including 443 and 3389. Se his script can not try out anything to enter 443 or 3389, its blocked. Does not block a user trying only 443 or 3389.

You should not have 3389 open in any way (just as an example here).

@Jotne

that is absolutely clear.
What i was wandering is whether that behavior with the winbox (or any TCP connections, i have explained above ) is because of Tarpit job.

From what u have posted and from what i’m experiencing is completely match, can you confirm that. thanks

I do not use Winbox on outside. Not secure at all.
But to not look my self out I have a fixed white-list and a port knock that can add IP temporary to white-list.

me too, i have blocked everything from outside, and also i’m using port knock.

Even though i’m getting Logging… - and it’s stuck there, only if i play with Tarpit, otherwise, i’m getting Connecting to 1.2.3.4 if i disable Tarpit

I do not understand where your problem is:

When i’m trying to get access from outsite with tarpit enabled, on the winbox i can see logging in and is gettign stack there. (the ip-add goes on blocked list)

Are you not able to login? from where?
Do you get message that should not be there?
Are anything other broken?

im not able to log in , i can see only logging in…and it’s getting stuck there, doesn’t go further, with tarpit enabled

and according from the link:

When connections come in and are “tarpitted” they don’t go back out. The connection is accepted, but when data transfer begins to happen, the TCP window size is set to zero.

so , from what i’m experiencing is completely for expecting, am i right?

The tarpit rule:

add action=jump chain=input comment=“Drop user that has tried ports that are not open and has bin added to block list. Limit TARPIT to prevent DDOS CPU problems” in-interface=ether1 jump-target=TARPIT protocol=tcp src-address-list=FW_Block_unkown_port

It will only hit when you are coming in on interface ether1 (outside) and are in the address list FW_Block_unkown_port

So:

  1. You try to access router using winbox on outside interface???
  2. Your IP are in the block list.

So:

  1. You try to access router using winbox on outside interface???

yes,also on my router ether1 is wan

  1. Your IP are in the block list.

yes my ip-add goes on the block list,

i’ll repeat again , i can’t get access, the wnbox getting stuck on logging in..

that is only if tarpit is on , looks like this:

that remind me to:
nat
add action=dst-nat chain=dstnat dst-address=public-ip in-interface=wan protocol=tcp to-addresses=local to-ports=80

i dont have that one, that is only e.g.

Add a specific rule to allow Winbox to reach port 8291 on the input change as a rule above tarpit.

But as a long user here, you should know that you should never open Winbox on a public IP. Use VPN.

Add a specific rule to allow Winbox to reach port 8291 on the input change as a rule above tarpit.

i got that for the local lan

But as a long user here, you should know that you should never open Winbox on a public IP. Use VPN.

i’m not asking that , only i want to know, is that what i’m experiencing is Tarpit behavior?

I have not see this problem, nor has other posted about it before, so it may be a bug or some wrong with your configuration.