my sxt has done DDoS attacks
Do I get you right that the SXT was participating in DDoS attack against some other address in the internet? Or it was subject to a DDoS attack against its public IP address?
for dns I can not get the rules that that team has since I do not have the administrator password to enter their configuration
my idea is to make the pppoe mark that the sxt is doing and to do it from this router that we are configuring
These two statements somehow contradict to each other. WIthout modifying the SXT configuration, you cannot move the PPPoE termination point from the SXT to this Mikrotik.
However, let’s talk about the firewall rules.
1. add action=accept chain=input comment="Eliminar solicitudes de DNS de public" \
connection-state=new dst-port=53 in-interface=LAN-2 protocol=tcp
2. add action=accept chain=input comment="Eliminar solicitudes de DNS de public" \
connection-state=new dst-port=53 in-interface=LAN-2 protocol=udp
3. add action=accept chain=input comment="No permitir paquetes extra\F1os" \
connection-state=invalid
4. add action=accept chain=input comment=\
"Permitir el acceso LAN al enrutador y a Internet" connection-state=new \
in-interface=bridge-LAN
5. add action=accept chain=input comment=\
"Permitir el acceso LAN al enrutador y a Internet" connection-state=new \
in-interface=LAN-3
6. add action=accept chain=input comment=\
"Permitir conexiones que se originaron desde LAN" connection-state=\
established
7. add action=accept chain=input comment=\
"Permitir ping ICMP desde cualquier lugar" protocol=icmp
8. add action=accept chain=input comment=\
"No permitir nada desde cualquier lugar en cualquier interfaz"
9. add action=accept chain=forward comment="No permitir paquetes extra\F1os" \
connection-state=invalid
While the comment to rules 1 and 2 says “Eliminar solicitudes de DNS de public”, their action is “accept”, which means they do not eliminate the DNS requests coming in via LAN-2. To make them do what the comment says, you have to change action to “drop”.
Same case are rules 3 and 9 - the comment says “No permitir paquetes extraños” but the action is “accept”. So a change of action to “drop” is also needed.
Comment to rule 5 says “Permitir el acceso LAN al enrutador y a Internet”, but as the rule is in chain “input”, it only permits access to the router itself, not to internet.
Comment to rule 6 says “Permitir conexiones que se originaron desde LAN” but actually it permits any previously established connection to/from the router itself, regardless from where it has been originated.
Comment to rule 8 says “No permitir nada desde cualquier lugar en cualquier interfaz” but it actually permits everything, so you would need to replace “accept” with “drop” as action, but don’t do it now as you would cut access to the Mikrotik.
Now how the firewall filter actually works:
- each incoming packet with destination address matching any of the addresses which are up on the Mikrotik itself is tested against rules in the chain named “input”
- each incoming packet with destination address matching none of Mikrotik’s own addresses is tested against rules in the chain named “forward”
.
In each chain, the rules are tested against the packet one-by-one starting from the topmost one until one of the rules which do match the packet provides a final verdict (typically accept or drop, some other actions are final verdicts too, but e.g. “log” is not a final verdict so a packet matching such rule continues to be processed by the chain). If none of the rules in the chain provides a final verdict, the packet is accepted.
The above is true unless a rule with “action=fasttrack-connection” matches a packet; if it does, further packets belonging to the same connection are not processed by the filter, assuming that packets which have established that connection were been permitted by the filter.
So the current configuration of your firewall filter actually provides no security at all, because it explicitly or implicitly accepts (or forwards) whatever it receives.
I would recommend you to look at the firewall settings in the output of “system default-configuration print”, understand fully what each of them does, and then create your own rules based on that.
Interface lists are a handy tool - you can e.g. define a list named “WAN” and a list named “LAN” and refer to them in all rules which should match traffic coming from several different interfaces. Instead of in-interface, you use in-interface-list in the rule; such rule then matches if the packet comes in through any of the interfaces on the list.
An example would be that in order to ignore DNS queries coming in via WAN interfaces, you actually configure a rule to accept DNS requests coming in via any of the LAN interfaces in the “input” chain. The final “drop the rest” rule in the “input” chain, if present, will then take care of dropping DNS requests coming in via any other interface. So the first “accept” rule is an exception from the last “drop all” one.
Just a last remark, while “accept everything towards my own IPs which came in via any LAN interface” and “drop everything which came from outside, with several well-thought exceptions” may seem fine, some devices in your network may get infected by downloading some malware due to applications’ security holes and then attack your network from inside. So even if you have a working firewall, do not leave any account with administration privileges open without a password. The best thing is to create some other user than “admin” (not “root”, please), give it full access to configuration (and a password of course) and then disable the “admin” account. And if you provide internet access to some clients connected via LAN interfaces, better consider them potential threats too and do not permit them access to your management ports (ssh, http, https) at all. Actually, all they need to access on your Mikrotik itself is DNS (UDP/53), NTP (UDP/123) and DHCP (UDP/67).