this is the first time in my life to see this.
I am sure that my router is closed from wan side.
Only from my network is accessible.

Only from my network is accessible.

In theory there are many ways to acomplish this, however some ways prooved to be vulnerable. If you want to share configuration (/export hide sensitive; redact any remaining sensitive data; post it here) we can comment on it ...

/interface bridge
add name=bridge-LAN

/interface ethernet
set [ find default-name=ether2 ] poe-out=off
set [ find default-name=ether3 ] poe-out=off
set [ find default-name=ether4 ] poe-out=off
set [ find default-name=ether5 ] poe-out=off

/interface pppoe-client
add add-default-route=yes allow=pap disabled=no interface=ether1 keepalive-timeout=2 name=pppoe-VDSL password=******* use-peer-dns=yes user=11111111@bbbbbbb.com

/ip pool
add name=dhcp_pool0 ranges=10.0.0.200-10.0.0.250

/ip dhcp-server
add address-pool=dhcp_pool0 disabled=no interface=bridge-LAN name=dhcp1

/interface bridge port
add bridge=bridge-LAN interface=ether2
add bridge=bridge-LAN interface=ether3
add bridge=bridge-LAN interface=ether4
add bridge=bridge-LAN interface=ether5

/interface pptp-server server
set authentication=mschap2 enabled=yes

/ip address
add address=10.0.0.1/24 interface=bridge-LAN network=10.0.0.0

/ip dhcp-server network
add address=10.0.0.0/24 dns-server=10.0.0.1 gateway=10.0.0.1

/ip dns
set allow-remote-requests=yes

/ip firewall address-list
add address=******** list=ADMIN
add address=10.0.0.0/24 list=ADMIN

/ip firewall filter
add action=drop chain=input dst-port=53 in-interface=pppoe-VDSL protocol=udp
add action=drop chain=input dst-port=53 in-interface=ether1 protocol=udp
add action=drop chain=input dst-port=53 in-interface=pppoe-VDSL protocol=tcp
add action=drop chain=input dst-port=53 in-interface=ether1 protocol=tcp
add action=drop chain=input comment="winbox_drop brute forcers" dst-port=8291 protocol=tcp src-address=!*********** src-address-list=winbox_login_blacklist
add action=add-src-to-address-list address-list=winbox_login_blacklist address-list-timeout=1w3d chain=input connection-state=new dst-port=8291 protocol=tcp src-address-list=!ADMIN
add action=drop chain=input comment="SSH_drop brute forcers" dst-port=22 protocol=tcp src-address=!************* src-address-list=SSH_login_blacklist
add action=add-src-to-address-list address-list=SSH_login_blacklist address-list-timeout=1w3d chain=input connection-state=new dst-port=22 protocol=tcp src-address-list=!ADMIN

/ip firewall nat
add action=masquerade chain=srcnat src-address=10.0.0.0/24
add action=masquerade chain=srcnat src-address=192.168.55.0/24
add action=dst-nat chain=dstnat dst-address=************* dst-port=22 protocol=tcp to-addresses=10.0.0.254 to-ports=22
add action=dst-nat chain=dstnat dst-address=************* dst-port=5038 protocol=tcp to-addresses=10.0.0.254 to-ports=5038
add action=dst-nat chain=dstnat dst-address=************* dst-port=81 protocol=tcp to-addresses=10.0.0.124 to-ports=81
add action=dst-nat chain=dstnat dst-address=************* dst-port=81 protocol=udp to-addresses=10.0.0.124 to-ports=81
add action=dst-nat chain=dstnat dst-address=************* dst-port=554 protocol=tcp to-addresses=10.0.0.124 to-ports=554
add action=dst-nat chain=dstnat dst-address=************* dst-port=554 protocol=udp to-addresses=10.0.0.124 to-ports=554
add action=dst-nat chain=dstnat dst-address=************* dst-port=8000 protocol=tcp to-addresses=10.0.0.124 to-ports=8000
add action=dst-nat chain=dstnat dst-address=************* dst-port=8000 protocol=udp to-addresses=10.0.0.124 to-ports=8000
add action=dst-nat chain=dstnat dst-address=************* dst-port=4233 protocol=tcp to-addresses=10.0.0.11 to-ports=4233
add action=dst-nat chain=dstnat dst-address=************* dst-port=4233 protocol=udp to-addresses=10.0.0.11 to-ports=4233

/ip service
set telnet address=10.0.0.0/24
set ftp disabled=yes
set www disabled=yes
set ssh disabled=yes
set api disabled=yes
set winbox address=10.0.0.0/24
set api-ssl disabled=yes

/ip ssh
set allow-none-crypto=yes forwarding-enabled=remote

/ppp secret
add local-address=192.168.55.254 name=********* password=********* remote-address=192.168.55.1 service=pptp

/system identity
set name=LLLLLLLL

/system note
set note="******************************** Your router was open to attack. The\
\_script in automatic mode restricted access to it only from your local ne\
twork. Please, be more attentive to the security of network equipment.****\
**********************************************"

The firewall is quite ineffective due to the concept of "drop forbidden, allow everything else". For example: telnet service is not protected with firewall ... indeed there is filter at service definition, but so has winbox and yet winbox firewall config hints that you're able to access it from address ******** ... I can't quickly think of a way for whitehat attacker to enter via winbox (or SSH... unless he came in from the whitelisted remote address), but that doesn't mean it's not possible.

The contemporary default firewall on SOHO routerboards has the logic inverse: explicit drop of any connections at the end of each firewall filter chain with explicit allows before that. You didn't indicate which routerboard is in question and which ROS version (there have been vulnerabilities in some services allowing un-authenticated remote user to gain access or information).

My advice to you: save the ASCII configuration export to your PC. Then netinstall routerboard with recent ROS and allow default config. Then add necessary config (PPPoE, ...) including NAT rules - but don't remove default firewall config, instead study it, understand it and ammend it minimally if needed.

Sorry, but this is so wrong.
It will drop connections to WinBox port, if the source address is in winbox_login_blacklist, except when source address is ***********. And the way how the address can get in winbox_login_blacklist list, is just by connecting to WinBox port once, except when you're coming from address listed in ADMIN list. So you're giving everyone a single chance to connect to your router using WinBox. Why? Even if it was you connecting from somewhere else, you'd have exactly one chance. If your connection accidentally broke, you wouldn't be able to connect again.

So it can be actually very simple, if you have (or had) old version with the famous WinBox bug (it told usernames and passwords to anyone who asked), one connection would be enough to get them, and another from different address to get in. Or from same one after ten days. Or earlier, if the router was rebooted.

Well, you could've had that there since a long time and you didn't even know about it, but recently you might have updated WinBox to 3.20, which in the changelog, reads:
*) show system note at login;
So....
You should start with a fresh install using netinstall just to be sure, as @mkx suggested. /export file=backupxx, save the file on PC, reinstall, remove config and reset, no default config, upload config to router, /import file=backupxx, done.

Code: Select all

/ip firewall filter
add action=drop chain=input comment="winbox_drop brute forcers" dst-port=8291 protocol=tcp src-address=!*********** src-address-list=winbox_login_blacklist
add action=add-src-to-address-list address-list=winbox_login_blacklist address-list-timeout=1w3d chain=input connection-state=new dst-port=8291 protocol=tcp src-address-list=!ADMIN

It will drop connections to WinBox port, if the source address is in winbox_login_blacklist, except when source address is ***********. And the way how the address can get in winbox_login_blacklist list, is just by connecting to WinBox port once, except when you're coming from address listed in ADMIN list. So you're giving everyone a single chance to connect to your router using WinBox.

Is it really that bad? The way I'm interpreting is this: a remote host starts winbox connection. It's not in black list. Its SYN packet will thus pass first rule, trigger the second (so remote address gets added to black list) but proceeds. SYN-ACK gets returned and remote host tries to finish the initial TCP handshake with ACK packet ... which will trigger the first rule because the address is on the black list. Note the absence of connection-state property which means filter rules get evaluated for just all packets regardless the state of connection they belong to...

Or am I utterly wrong?

... reinstall, remove config and reset, no default config, upload config to router, /import file=backupxx, done.

I think this is bad advice ... current firewall setup is much worse than default ... who knows how's the rest. I stick to my advice to go with default setup and perform only minor changes ... using ASCII export of current config only as reminder what was done before (and how not to do things again) ...

We don't know that's all he's got in the firewall (didn't reply yet), if he does, oh my , yes, he should redo his setup following defaults atleast. AFTER reinstall

We don't know that's all he's got in the firewall (didn't reply yet) ...

Check post #3 in this thread ... it's response to my plea for current config, do I'll go with assumption that that's whole config.

@mkx: No, you're right, I was wrong. Sob -1 point, mkx +1 point. I guess I'm too used to "accept established & related" always present. So correction, it's actually safe. But also completely pointless. If you're going to block everyone after first syn packet, except one address, then just directly block everyone except that one address.

Edit: Ok, I should really go to bed. There's also the ADMIN list. But it's still not good reason to have two confusing rules instead of just one simple rule.

There's added value: list of script kiddies who tried to connect during last 10 days. Not that I'd know what to do with that value though

Considering we're same timezone you reminded me to go to bed as well ... to get some poor substitute for caffeine