can you please help?
We have public IP on RB 3011
I disable all interfaces except WAN ... and I have all the time some TX bandwidth around 6-15Mbps
Here is short video:
https://1drv.ms/v/s!AjA-Ktm4yR9FkrVy6F1BuAXLMA89sg
DDOS suspect ?
Hello everybody...
can you please help?
We have public IP on RB 3011
I disable all interfaces except WAN ... and I have all the time some TX bandwidth around 6-15Mbps
Here is short video:
https://1drv.ms/v/s!AjA-Ktm4yR9FkrVy6F1BuAXLMA89sg
can you please help?
We have public IP on RB 3011
I disable all interfaces except WAN ... and I have all the time some TX bandwidth around 6-15Mbps
Here is short video:
https://1drv.ms/v/s!AjA-Ktm4yR9FkrVy6F1BuAXLMA89sg
Re: DDOS suspect ?
Your screenshot shows a good deal of the traffic comes to UDP port 53 of your router.
This typically happens when you let the router process and respond DNS queries coming from the WAN - most often this is a consequence of missing or incorrect firewall rules.
The attacker sends a small DNS query packet known to get resolved to a large response, and it sends it with the source address of the attack target (most ISPs don't waste their resources on filtering packets with forged source addresses). So your router resolves that query and sends the large response packet to the attack target. So the attacker "invests" a relatively small bandwidth to make your router create a 10-20 times higher one towards the target.
This typically happens when you let the router process and respond DNS queries coming from the WAN - most often this is a consequence of missing or incorrect firewall rules.
The attacker sends a small DNS query packet known to get resolved to a large response, and it sends it with the source address of the attack target (most ISPs don't waste their resources on filtering packets with forged source addresses). So your router resolves that query and sends the large response packet to the attack target. So the attacker "invests" a relatively small bandwidth to make your router create a 10-20 times higher one towards the target.
Re: DDOS suspect ?
Thank you for your fast answer ...Your screenshot shows a good deal of the traffic comes to UDP port 53 of your router.
This typically happens when you let the router process and respond DNS queries coming from the WAN - most often this is a consequence of missing or incorrect firewall rules.
The attacker sends a small DNS query packet known to get resolved to a large response, and it sends it with the source address of the attack target (most ISPs don't waste their resources on filtering packets with forged source addresses). So your router resolves that query and sends the large response packet to the attack target. So the attacker "invests" a relatively small bandwidth to make your router create a 10-20 times higher one towards the target.
My rules looks like:
Re: DDOS suspect ?
And these drop rules have been always there? Since they are placed even before the "accept established" one, they should be sufficient to prevent such an attack even if it started before the rules have been added.
Can you export your configuration and anonymize it as per my automatic signature below and post it?
Can you export your configuration and anonymize it as per my automatic signature below and post it?
Re: DDOS suspect ?
Yep ... these rules was in firewall from beginning ... but on other place ... after I notice this strange behave, I put it on beginning .And these drop rules have been always there? Since they are placed even before the "accept established" one, they should be sufficient to prevent such an attack even if it started before the rules have been added.
Can you export your configuration and anonymize it as per my automatic signature below and post it?
All configuration... or is enough just firewall ?
Code: Select all
add action=drop chain=input comment="Block DNS Request on INCOMING WAN INTERFACE port 53" connection-state=new dst-port=53 in-interface-list=WAN protocol=tcp
add action=drop chain=forward connection-state=new dst-port=53 in-interface-list=WAN protocol=tcp
add action=drop chain=input connection-state=new dst-port=53 in-interface-list=WAN protocol=udp
add action=drop chain=forward connection-state=new dst-port=53 in-interface-list=WAN protocol=udp
add action=accept chain=input comment="Accept established connections" connection-state=established
add action=accept chain=input comment="Accept related connections" connection-state=related
add action=accept chain=output dst-port=123 protocol=udp
add action=drop chain=input comment="Invalid connections" connection-state=invalid
add action=drop chain=forward comment="Invalid connections" connection-state=invalid
add action=add-src-to-address-list address-list="Port scanners" address-list-timeout=2w chain=input comment="Port scanners to list" protocol=tcp psd=21,3s,3,1
add action=add-src-to-address-list address-list="Port scanners" address-list-timeout=2w chain=input comment="NMAP FIN Stealth scan" protocol=tcp tcp-flags=fin,!syn,!rst,!psh,!ack,!urg
add action=add-src-to-address-list address-list="Port scanners" address-list-timeout=2w chain=input comment="SYN/FIN scan" protocol=tcp tcp-flags=fin,syn
add action=add-src-to-address-list address-list="Port scanners" address-list-timeout=2w chain=input comment="SYN/RST scan" protocol=tcp tcp-flags=syn,rst
add action=add-src-to-address-list address-list="Port scanners" address-list-timeout=2w chain=input comment="FIN/PSH/URG scan" protocol=tcp tcp-flags=fin,psh,urg,!syn,!rst,!ack
add action=add-src-to-address-list address-list-timeout=2w chain=input comment="ALL/ALL scan" protocol=tcp src-address-list="Port scanners" tcp-flags=fin,syn,rst,psh,ack,urg
add action=add-src-to-address-list address-list="Port scanners" address-list-timeout=2w chain=input comment="NMAP NULL scan" protocol=tcp tcp-flags=!fin,!syn,!rst,!psh,!ack,!urg
add action=drop chain=input comment="Dropping port scanners" log=yes log-prefix="Drop port scanners" src-address-list="Port scanners"
add action=drop chain=input comment="ftp brute forcers" dst-port=21 protocol=tcp src-address-list=ftp_blacklist
add action=accept chain=output comment="530 Login incorrect" content="530 Login incorrect" dst-limit=1/1m,9,dst-address/1m protocol=tcp
add action=add-dst-to-address-list address-list=ftp_blacklist address-list-timeout=3h chain=output comment="530 Login incorrect" content="530 Login incorrect" protocol=tcp
add action=drop chain=input comment="ssh brute forcers" dst-port=22 protocol=tcp src-address-list=ssh_blacklist
add action=add-src-to-address-list address-list=ssh_blacklist address-list-timeout=1w3d chain=input connection-state=new dst-port=22 protocol=tcp src-address-list=ssh_stage3
add action=add-src-to-address-list address-list=ssh_stage3 address-list-timeout=10m chain=input connection-state=new dst-port=22 protocol=tcp src-address-list=ssh_stage2
add action=add-src-to-address-list address-list=ssh_stage2 address-list-timeout=10m chain=input connection-state=new dst-port=22 protocol=tcp src-address-list=ssh_stage1
add action=add-src-to-address-list address-list=ssh_stage1 address-list-timeout=1m chain=input connection-state=new dst-port=22 protocol=tcp
add action=drop chain=input comment="drop Black_list" disabled=yes protocol=tcp src-address-list=Black_list
add action=drop chain=input comment="drop telnet brute forcers" dst-port=23 protocol=tcp src-address-list=telnet_black_list
add action=add-src-to-address-list address-list=telnet_black_list address-list-timeout=1d chain=input connection-state=new dst-port=23 protocol=tcp src-address-list=telnet_stage3
add action=add-src-to-address-list address-list=telnet_stage3 address-list-timeout=1m chain=input connection-state=new dst-port=23 protocol=tcp src-address-list=telnet_stage2
add action=add-src-to-address-list address-list=telnet_stage2 address-list-timeout=1m chain=input connection-state=new dst-port=23 protocol=tcp src-address-list=telnet_stage1
add action=add-src-to-address-list address-list=telnet_stage1 address-list-timeout=1m chain=input connection-state=new dst-port=23 protocol=tcp
add action=accept chain=input comment="PPTP VPN" dst-port=1723 protocol=tcp
add action=accept chain=input comment="L2TP VPN" dst-port=500,1701,4500 protocol=udp
add action=accept chain=input comment=IPSec-ESP protocol=ipsec-esp
add action=accept chain=output comment=IPSec-ESP protocol=ipsec-espRe: DDOS suspect ?
That's one of the many drawbacks of posting screenshots rather than text export. The drop rules you've moved match specifically on connection-state=new, so if such a stream already exists, they cannot break it even if placed before the "accept established" one. Remove that match condition and see whether it helps. But before you do that, what does /ip firewall connection print detail where dst-address~"your.pub.lic.ip:53" show?
The thing is that even when these rules were placed anywhere else, they should have prevented new incoming DNS connections from establishing - I cannot see any action=accept rule overriding them.
The thing is that even when these rules were placed anywhere else, they should have prevented new incoming DNS connections from establishing - I cannot see any action=accept rule overriding them.
Re: DDOS suspect ?
When I was notice this ... I move rules at beginning and reboot router.That's one of the many drawbacks of posting screenshots rather than text export. The drop rules you've moved match specifically on connection-state=new, so if such a stream already exists, they cannot break it even if placed before the "accept established" one. Remove that match condition and see whether it helps. But before you do that, what does /ip firewall connection print detail where dst-address~"your.pub.lic.ip:53" show?
The thing is that even when these rules were placed anywhere else, they should have prevented new incoming DNS connections from establishing - I cannot see any action=accept rule overriding them.
So, rules must check connection from new state ... right?
Everything was fine for short time and start again.
Then I decide to ask for help.
Now print detail show this:
Code: Select all
/ip firewall connection print
Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying, F - fasttrack, s - srcnat, d - dstnat
# PROTOCOL SRC-ADDRESS DST-ADDRESS TCP-STATE TIMEOUT ORIG-RATE REPL-RATE ORIG-PACKETS REPL-PACKETS ORIG-BYTES REPL-BYTES
0 C s tcp 10.170.180.30:40256 8.131.101.191:443 established 3h49m5s 0bps 0bps 2 0 168 0
1 SAC udp 144.43.243.208:24397 MyPublicIP:53 4s 0bps 0bps 11 11 638 43 450
2 C s tcp 10.170.180.30:38418 8.131.101.191:443 established 20m21s 0bps 0bps 3 0 231 0
3 C s tcp 10.170.180.30:37310 65.55.44.109:443 established 5h3m38s 0bps 0bps 3 0 3 514 0
4 C s tcp 10.170.180.30:39421 8.131.101.191:443 established 2h13m24s 0bps 0bps 2 0 191 0
5 C s tcp 10.170.180.30:40807 8.131.101.191:443 established 5h1m23s 0bps 0bps 1 0 139 0
6 SAC udp 86.135.23.148:443 MyPublicIP:53 1m31s 0bps 0bps 279 279 16 182 1 102 050
7 C s tcp 10.170.180.30:38804 8.131.101.191:443 established 1h4m3s 0bps 0bps 2 0 190 0
8 SAC s tcp MyLAN_ip.50:55863 20.199.120.85:443 established 9h12m27s 0bps 0bps 30 19 4 155 7 003
9 C s tcp 10.170.180.30:38698 8.131.101.191:443 established 52m6s 0bps 0bps 2 0 167 0
10 C s tcp 10.170.180.30:45432 40.126.31.137:443 established 3h58m27s 0bps 0bps 2 0 92 0
11 C s tcp 10.170.180.30:40181 8.131.101.191:443 established 3h44m55s 0bps 0bps 1 0 52 0
12 C s tcp 10.170.180.30:38678 8.131.101.191:443 established 49m47s 0bps 0bps 2 0 190 0
13 C s tcp 10.170.180.30:49802 52.177.138.113:443 established 5h23m42s 0bps 0bps 3 0 168 0
14 SAC udp 144.43.243.208:53352 MyPublicIP:53 4s 0bps 0bps 54 54 3 132 213 300
15 S C icmp MyLAN_ip.1 MyLAN_ip.2 9s 896bps 0bps 182 011 163 907 10 192 616 9 178 792
16 C s tcp 10.170.180.30:38376 8.131.101.191:443 established 17m23s 0bps 0bps 1 0 64 0
17 C s tcp 10.170.180.30:38756 8.131.101.191:443 established 58m36s 0bps 0bps 4 0 346 0
18 C s tcp 10.170.180.30:38411 8.131.101.191:443 established 22m51s 0bps 0bps 1 0 52 0
19 C s tcp 10.170.180.30:38480 8.131.101.191:443 established 28m19s 0bps 0bps 1 0 52 0
20 C s tcp 10.170.180.30:38573 8.131.101.191:443 established 39m14s 0bps 0bps 1 0 64 0
21 SAC udp 144.43.243.208:45238 MyPublicIP:53 5s 0bps 0bps 54 54 3 132 213 300
22 SAC udp 144.43.243.208:856 MyPublicIP:53 5s 0bps 0bps 56 56 3 248 221 200
23 C s tcp 10.170.180.30:40460 8.131.101.191:443 established 4h15m3s 0bps 0bps 2 0 191 0
24 C s tcp 10.170.180.30:40089 8.131.101.191:443 established 3h29m49s 0bps 0bps 2 0 168 0
25 C s tcp 10.170.180.30:38960 8.131.101.191:443 established 1h21m43s 0bps 0bps 3 0 232 0
26 C s tcp 10.170.180.30:40403 8.131.101.191:443 established 4h12m13s 0bps 0bps 1 0 52 0
27 C s tcp 10.170.180.30:39821 8.131.101.191:443 established 2h59m7s 0bps 0bps 2 0 191 0
28 SAC udp 144.43.243.208:8042 MyPublicIP:53 3s 0bps 0bps 12 12 696 47 400
29 C s tcp 10.170.180.30:40487 8.131.101.191:443 established 4h18m41s 0bps 0bps 2 0 168 0
30 C s tcp 10.170.180.30:40966 8.131.101.191:443 established 5h17m46s 0bps 0bps 1 0 52 0
31 C s tcp 10.170.180.30:38297 8.131.101.191:443 established 11m56s 0bps 0bps 1 0 52 0
32 SAC udp 174.137.7.117:80 MyPublicIP:53 2m59s 1392bps 94.8kbps 1 526 1 526 88 508 6 027 700
33 SAC udp 144.43.243.208:19821 MyPublicIP:53 4s 0bps 0bps 13 13 754 51 350
34 C s tcp 10.170.180.30:39982 8.131.101.191:443 established 3h23m4s 0bps 0bps 1 0 52 0
35 C s tcp 10.170.180.30:40676 8.131.101.191:443 established 4h45m 0bps 0bps 1 0 139 0
36 SAC s tcp MyLAN_ip.50:57222 40.101.137.34:443 established 13h10m36s 0bps 0bps 7 5 2 019 1 789
37 C s tcp 10.170.180.30:47368 195.29.178.18:587 established 1h33m51s 0bps 0bps 1 0 87 0
38 C s tcp 10.170.180.30:39655 8.131.101.191:443 established 2h40m9s 0bps 0bps 2 0 168 0
39 C s tcp 10.170.180.30:40458 8.131.101.191:443 established 4h14m48s 0bps 0bps 2 0 191 0
40 C s tcp 10.170.180.30:41105 8.131.101.191:443 established 5h32m48s 0bps 0bps 2 0 191 0
41 C s tcp 10.170.180.30:41298 8.131.101.191:443 established 6h1m27s 0bps 0bps 1 0 64 0
42 C s tcp 10.170.180.30:40419 8.131.101.191:443 established 4h9m5s 0bps 0bps 2 0 168 0
43 C s tcp 10.170.180.30:57622 207.244.91.50:993 established 6h16m25s 0bps 0bps 5 0 317 0
44 C s tcp 10.170.180.30:39903 8.131.101.191:443 established 3h8m44s 0bps 0bps 2 0 191 0
45 SAC s tcp MyLAN_ip.25:52038 20.199.120.182:443 established 17h15s 0bps 0bps 5 424 2 730 501 575 585 889
46 C s tcp 10.170.180.30:39456 8.131.101.191:443 established 2h17m35s 0bps 0bps 2 0 191 0
47 C s tcp 10.170.180.30:38466 8.131.101.191:443 established 28m19s 0bps 0bps 1 0 52 0
48 C udp 149.56.106.222:5261 MyPublicIP:5060 9m53s 0bps 0bps 1 0 443 0
49 C s tcp 10.170.180.30:40452 8.131.101.191:443 established 4h17m41s 0bps 0bps 1 0 139 0
50 C s tcp 10.170.180.30:39083 8.131.101.191:443 established 1h35m31s 0bps 0bps 2 0 191 0
51 C s tcp 10.170.180.30:40572 8.131.101.191:443 established 4h29m37s 0bps 0bps 2 0 191 0
52 C s tcp 10.170.180.30:38242 8.131.101.191:443 established 1m 0bps 0bps 1 0 52 0
53 C s tcp 10.170.180.30:40080 8.131.101.191:443 established 3h28m47s 0bps 0bps 2 0 191 0
54 C s tcp 10.170.180.30:40377 8.131.101.191:443 established 4h3m24s 0bps 0bps 2 0 168 0
55 C s tcp 10.170.180.30:40809 8.131.101.191:443 established 4h59m13s 0bps 0bps 2 0 191 0
56 C s tcp 10.170.180.30:39689 8.131.101.191:443 established 2h44m3s 0bps 0bps 2 0 191 0
57 C s tcp 10.170.180.30:41003 8.131.101.191:443 established 5h21m21s 0bps 0bps 2 0 168 0
58 C s tcp 10.170.180.30:41213 8.131.101.191:443 established 5h50m32s 0bps 0bps 1 0 52 0
59 C s tcp 10.170.180.30:38251 8.131.101.191:443 established 6m28s 0bps 0bps 1 0 52 0
60 C s tcp 10.170.180.30:41308 8.131.101.191:443 established 5h58m15s 0bps 0bps 3 0 232 0
-- [Q quit|D dump|down]
Re: DDOS suspect ?
Part of the problem of adding all these bloatware rules to a perfectly tight default firewall ruleset!! Self-inflicted damage.
Re: DDOS suspect ?
Part of the problem of adding all these bloatware rules to a perfectly tight default firewall ruleset!! Self-inflicted damage.
It would be nice if you do not know the answer or you are a person who does not know how to help someone ...
you'd rather get in line with the others who just lurking.
If that were true about the ten rows of "a perfectly tight default firewall ruleset", then people would no longer be educated and upgraded.
I follow your advice and disable all rules in my firewall ... put only ten default rows:
Code: Select all
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=drop chain=input comment="defconf: drop all not coming from LAN" disabled=yes in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WANProblem still remain.
Re: DDOS suspect ? [SOLVED]
As the problem persists even though you have restarted the router with just the default firewall rules you've shown above, and even though the WAN interface is not by mistake a member of the /interface list LAN, I'm afraid your router may have been infected by malware due to the fact that you previously used the "permit everything but a few exceptions" firewall concept; as you took the effort to build the state automaton that was blacklisting brute force attacks to SSH (and FTP), I suppose your SSH was open to the world. And from how your firewall rules looked before you followed @anav's advice *), it is quite clear that you've created the firewall while running a much older RouterOS version. And in older RouterOS versions, user credentials used to be stored in plaintext, and vulnerabilities existed allowing the attackers to download them without knowing any of them in advance. So the complexity of the username and password didn't matter at all, and RouterOS upgrade also doesn't matter at all unless you've changed all of the passwords since they've harvested them.
Now if the malware is really able to inactivate firewall rules while still showing them as working (essentially by making "drop" ones act like just "passthrough" ones so they would count matches but not actually drop the packets), I'm quite sure Mikrotik security team would be interested in that. But I don't know how quickly they would respond to a support ticket and whether you can wait for days for them to come into contact with you. So I'd like to be sure that it's really that bad before asking you to do so.
Please post the complete export, not just the firewall rules, anonymized as before, and confirm that with exactly that configuration, the problem still exists.
Also, do not omit the where ... part in the /ip firewall connection print detail command - in your previous post you've omited that, and therefore the list contained all connections, not just those DNS ones, so it was unneccessarily huge and at the same incomplete as you've only posted the first part.
Since there may be the malware and there is more than one way it can act to circumvent the firewall, here's a modified version of the command (copy it, paste it into an editor, replace MyPublicIP by your actual public IP before copy-pasting it to the command line, then substitute it back in the output before posting it):
/ip firewall connection print detail where dst-address~"MyPublicIP:53" or src-address~":53"
If the [Q quit|D dump|down] row appears, keep pressing the space bar until the prompt appears again, and then post the complete list.
*) @anav is a minimalist, and it's a fact that the default firewall rules of recent RouterOS versions are very good except protection against attacks from the LAN side conducted by cross-platform malware (which first infects a PC in LAN and from there it attacks the router as 99% of home routers do not block management access from the LAN), and that many popular extensions to them posted on the Wiki and here on the forum are effectively useless for a home router (ISP routers are a different point).
However, even with the contemporary default firewall, as soon as you decide to re-enable the remote SSH access via WAN and you modify the rules accordingly, you'll fall back to the same rabbit hole like before - the state automaton will not score because the very first SSH login attempt will be correct if the credentials have been harvested in the past.
And if the malware has indeed already squatted on your router, it may have rendered any firewall rules useless, either by modifying their behavior or by initiating outgoing connections on its own - the default firewall doesn't restrict where the router itself can initiate connections.
Now if the malware is really able to inactivate firewall rules while still showing them as working (essentially by making "drop" ones act like just "passthrough" ones so they would count matches but not actually drop the packets), I'm quite sure Mikrotik security team would be interested in that. But I don't know how quickly they would respond to a support ticket and whether you can wait for days for them to come into contact with you. So I'd like to be sure that it's really that bad before asking you to do so.
Please post the complete export, not just the firewall rules, anonymized as before, and confirm that with exactly that configuration, the problem still exists.
Also, do not omit the where ... part in the /ip firewall connection print detail command - in your previous post you've omited that, and therefore the list contained all connections, not just those DNS ones, so it was unneccessarily huge and at the same incomplete as you've only posted the first part.
Since there may be the malware and there is more than one way it can act to circumvent the firewall, here's a modified version of the command (copy it, paste it into an editor, replace MyPublicIP by your actual public IP before copy-pasting it to the command line, then substitute it back in the output before posting it):
/ip firewall connection print detail where dst-address~"MyPublicIP:53" or src-address~":53"
If the [Q quit|D dump|down] row appears, keep pressing the space bar until the prompt appears again, and then post the complete list.
*) @anav is a minimalist, and it's a fact that the default firewall rules of recent RouterOS versions are very good except protection against attacks from the LAN side conducted by cross-platform malware (which first infects a PC in LAN and from there it attacks the router as 99% of home routers do not block management access from the LAN), and that many popular extensions to them posted on the Wiki and here on the forum are effectively useless for a home router (ISP routers are a different point).
However, even with the contemporary default firewall, as soon as you decide to re-enable the remote SSH access via WAN and you modify the rules accordingly, you'll fall back to the same rabbit hole like before - the state automaton will not score because the very first SSH login attempt will be correct if the credentials have been harvested in the past.
And if the malware has indeed already squatted on your router, it may have rendered any firewall rules useless, either by modifying their behavior or by initiating outgoing connections on its own - the default firewall doesn't restrict where the router itself can initiate connections.
Re: DDOS suspect ?
Sorry I can be blunt, especially after seeing the same issue with 100s of people!!
In short, you need to neinstall the latest long term firmware onto the router.
I wouldnt bother trying to discern where the problem is and simply be safe and cautious and assume there has been a compromise
and then you will be back up and running soonest.
The export suggested is still a great idea as you will still a template or example if you will, of the parts of the config you do need to recreate.
Note: All usernames and passwords have to be different from before!
Start with the default firewall rules and then we can review the config and try to tighten it down according to the requirements you have, vice what youtube suggests etc..
In short, you need to neinstall the latest long term firmware onto the router.
I wouldnt bother trying to discern where the problem is and simply be safe and cautious and assume there has been a compromise
and then you will be back up and running soonest.
The export suggested is still a great idea as you will still a template or example if you will, of the parts of the config you do need to recreate.
Note: All usernames and passwords have to be different from before!
Start with the default firewall rules and then we can review the config and try to tighten it down according to the requirements you have, vice what youtube suggests etc..
Re: DDOS suspect ?
Accept...thanks ... now we can go on.Sorry I can be blunt, especially after seeing the same issue with 100s of people!!
In short, you need to neinstall the latest long term firmware onto the router.
I wouldnt bother trying to discern where the problem is and simply be safe and cautious and assume there has been a compromise
and then you will be back up and running soonest.
The export suggested is still a great idea as you will still a template or example if you will, of the parts of the config you do need to recreate.
Note: All usernames and passwords have to be different from before!
Start with the default firewall rules and then we can review the config and try to tighten it down according to the requirements you have, vice what youtube suggests etc..
Your advice In this situation, a very reasonable.
But if that device is potentially compromised whether it might be reasonable to set it aside for further analysis?
Re: DDOS suspect ?
My advice is no, the sooner its scrubbed the better. There is no need to analyze.Sorry I can be blunt, especially after seeing the same issue with 100s of people!!
In short, you need to neinstall the latest long term firmware onto the router.
I wouldnt bother trying to discern where the problem is and simply be safe and cautious and assume there has been a compromise
and then you will be back up and running soonest.
The export suggested is still a great idea as you will still a template or example if you will, of the parts of the config you do need to recreate.
Note: All usernames and passwords have to be different from before!
Start with the default firewall rules and then we can review the config and try to tighten it down according to the requirements you have, vice what youtube suggests etc..
Accept...thanks ... now we can go on.
Your advice In this situation, a very reasonable.
But if that device is potentially compromised whether it might be reasonable to set it aside for further analysis?
Re: DDOS suspect ?
If you can afford that because you've got another router you can use in the meantime, it might be helpful - it's up to Mikrotik support to say whether they are interested. If you cannot, proceed with the netinstall as suggested by @anav.But if that device is potentially compromised whether it might be reasonable to set it aside for further analysis?
Who is online
Users browsing this forum: erlinden, Gomo, GoogleOther [Bot], Guntis, NetworqAndy, patrikg, Techsystem, thompsontech, zdiv and 60 guests