Community discussions

 
sindy
Forum Guru
Forum Guru
Posts: 2399
Joined: Mon Dec 04, 2017 9:19 pm

Re: Dual wan

Sun Feb 11, 2018 8:35 pm

if I change that rule and place that ip the previous consiguration is not damaged
Correct, everything that works will continue working, that change will only extend the exception from the WAN restriction also to devices connected to 192.168.8.0/24 (like your LTE modem) and devices connected to 192.168.20.0/24.

After checking that everything works the way you want, come back for the audit of your security rules. It seems you've missed a point in how the firewall filter works, as @CZFan has pointed out. On the other hand, as both your WANs are via private subnets, I assume both the LTE modem and the WAN 1 modem have their own security policies, so it is probably not urgent.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
wireles1234
newbie
Topic Author
Posts: 29
Joined: Sun Feb 04, 2018 2:35 pm

Re: Dual wan

Sun Feb 11, 2018 8:53 pm

I changed the rule but after doing so I can not enter the devices of the lan-3 but I can enter the LTE modem
/ip firewall mangle
add action=mark-routing chain=prerouting dst-address=!192.168.8.0/24 \
 in-interface=LAN-3 new-routing-mark=wan1-only passthrough=yes
security is very important for me since my two connections to the internet have public ip and this router will be my main since my wan1 is a SXT LITE5

to refresh one thing
WAN1: 192.168.20.1
WAN2: 192.168.8.1
Bridge-lan: 192.168.50.1
Lan-3: 192.168.40.1
 
sindy
Forum Guru
Forum Guru
Posts: 2399
Joined: Mon Dec 04, 2017 9:19 pm

Re: Dual wan

Sun Feb 11, 2018 9:01 pm

Read again what I wrote - I've told you to change 192.168.50.0/24 to 192.168.0.0/16 in the mangle rule and you have instead changed it to 192.168.8.0/24.

No wonder that it behaves different than what I've said.

As for security - of course security is important, no question about that. But all your public adresses are currently outside the Mikrotik we are twisting so most attacks cannot reach it unless you have some DMZ rules on the boxes closer to the internet. If you plan to have a public address directly on this Mikrotik, or if you have DMZ rules forwarding everyting that comes to their public IP address further to this Mikrotik without any filtering, then you need to fix your security rules on this Mikrotik urgently.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
wireles1234
newbie
Topic Author
Posts: 29
Joined: Sun Feb 04, 2018 2:35 pm

Re: Dual wan

Sun Feb 11, 2018 9:12 pm

sorry I had not read well and it works all

about security I tell you that my sxt has done DDoS attacks and 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 for this I want to have it the safest prosibleme because it is the one that will support everything from outside
 
sindy
Forum Guru
Forum Guru
Posts: 2399
Joined: Mon Dec 04, 2017 9:19 pm

Re: Dual wan

Sun Feb 11, 2018 10:36 pm

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).
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
wireles1234
newbie
Topic Author
Posts: 29
Joined: Sun Feb 04, 2018 2:35 pm

Re: Dual wan

Mon Feb 12, 2018 1:21 am

the attacks I received was through my public ip were by dns and DDoS
then how would all the rules be that I copied it from the post that you passed me to make the dual wan
 
sindy
Forum Guru
Forum Guru
Posts: 2399
Joined: Mon Dec 04, 2017 9:19 pm

Re: Dual wan

Mon Feb 12, 2018 11:32 am

I have to paraphrase a wise man's statement as I wasn't able to find the original link: "there is no security without understanding; if someone offers to care about your security instead of you, he's in the best position to take it away from you".

So look through the manual and my example on blocking DNS from WAN again, there is everything you need to know to create your firewall.

Basically:
  • you want to block any packet initiating a connection coming from the internet, i.e. via any internet-facing interface, except thoroughly thought cases (like icmp). The key here is "connection-state=new" for the exceptions and the last rule in each chain to be "action=drop" without any conditions.
  • you want to permit any packet belonging to an already established connection. The key here is "connection-state=established,related"
The above applies for both "input" and "forward" chains.
Specifically for security of the Mikrotik itself (chain "input"):
  • you want to block access to the mikrotik's own IP addresses also for generic devices in your LANs, with the exceptions listed earlier (ICMP, DHCP, DNS, NTP)
  • you want to enable only secure management protocols on your Mikrotik (ssh, https, winbox) with non-default usernames and passwords; under such conditions, these protocols can be left open for all LAN devices on the firewall
  • if you cannot avoid use of insecure protocols (http, telnet, ftp), access to them must be permitted only to a handful of IP addresses assigned to devices under your direct control and it is still not secure enough (IP address can be spoofed, communication between the authorized device and your mikrotik can be intercepted; telnet and ftp send passwords in plaintext, http sends using an encryption algorithm which provides no real protection given the computing power available today)
The firewall rules from the default configuration do not permit DNS requests coming from the internet to be processed. So if your SXT could be used in the past to DDoS someone using the DNS attack, it means the default firewall rules were not active on it.

No firewall rules can protect you from losing the internet connectivity if you are a target of a DDoS attack. A DDoS attack will exhaust all your downlink bandwidth or all the packet forwarding capacity of your firewall device, whichever is lower. But the firewall can protect you from unintentionally participating in a DDoS attack against someone else using your Mikrotik. It cannot protect you from one of the devices in your network getting infected due to application vulnerabilities and then participating in any kind of malicious activity you can imagine.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
wireles1234
newbie
Topic Author
Posts: 29
Joined: Sun Feb 04, 2018 2:35 pm

Re: Dual wan

Tue Feb 13, 2018 4:18 pm

hi
these are the only rules that my SXT has any more?
/ip firewall filter
add chain=input comment="default configuration" protocol=icmp
add chain=input comment="default configuration" connection-state=established
add chain=input comment="default configuration" connection-state=related
add chain=input comment="default configuration" log=yes src-address-list=\
    admis
add action=drop chain=input dst-port=123 log=yes protocol=udp \
    src-address-list=!ntp-servers
add action=drop chain=input comment="default configuration" in-interface=\
    wlan1-gateway
add action=drop chain=input comment="default configuration" dst-port=53 \
    in-interface=all-ppp log=yes protocol=udp
add chain=forward comment="default configuration" connection-state=\
    established
add chain=forward comment="default configuration" connection-state=related
add action=drop chain=forward comment="default configuration" \
    connection-state=invalid
 
sindy
Forum Guru
Forum Guru
Posts: 2399
Joined: Mon Dec 04, 2017 9:19 pm

Re: Dual wan

Tue Feb 13, 2018 6:01 pm

hi
these are the only rules that my SXT has any more?
The interface configurations are missing but I suppose that wlan1-gateway has no IP address at all and there is some pppoe-out1 which uses wlan1-gateway as transport interface and gets the IP address from the ISP.
If the above is true, the firewall actually permits anything that comes in towards the SXT itself via the pppoe interface, because each of the three "action=drop" rules has some additional conditions:
  • the first one doesn't care abouut the interface but only drops NTP packets from other sources than on the ntp-servers address-list
  • the second one drops "everything" but only if it gets in via wlan1-gateway (which I assume is actually nothing as wlan1-gateway supposingly has no IP address associated
  • the third one drops packets which come in via any ppp interface (which includes your pppoe interface), but only the DNS ones.
    So e.g. the http and ssh interface of this SXT are open for public access at firewall level; it is not clear whether they are limited to some source subnets at service level (see "/ip service print" output, if there are some subnets other than 0.0.0.0/0, the se services are secured there, otherwise they are open to the world).
The forward chain is similarly broken, it only drops "invalid" packets, but permits opening of new connections. This is more or less fine if there are no dst-nat rules in "/ip firewall nat" part of the configuration, but if there are, anything matching those rules can get in and establish a new connection. Of course it is possible that the dst-nat rules check the source but something is telling me that it is not the case.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
wireles1234
newbie
Topic Author
Posts: 29
Joined: Sun Feb 04, 2018 2:35 pm

Re: Dual wan

Tue Feb 13, 2018 9:05 pm

Well I'll have to finish all the settings so that you help me with the rules is my first mikrotik device and I do not know much about them the sxt is managed by my internet service provider
 
sindy
Forum Guru
Forum Guru
Posts: 2399
Joined: Mon Dec 04, 2017 9:19 pm

Re: Dual wan

Tue Feb 13, 2018 10:54 pm

@wireles1234, have you read the manual link I've sent you, and do you understand how the firewall (at least the filter part) works?

If you do not understand, can you quote the part which is incomprehensible there?

The point is that the logic of the firewall filter is nothing Mikrotik-specific, you can see the same one not only in linux netfilter (better known as iptables) but also in other vendors' products - it would actually be hard to do that in any other way with the same flexibility. It is in fact an algorithmic programming like any other.

So one more time:
  • first, you choose the action which should be applied for most of the traffic, and set it as the last rule in its chain (input or forward), without any conditions. Usually it is "drop", so add it with "disabled=yes" so that you don't cut yourself. If the intended defaut handling is "accept", you don't need to set a rule for it, because "accept" is the default action for the predefined chains if no rule matches.
  • then, you put in front of that last rule a list of exceptions from it, which usually mean accepting packets which match some conditions (permitted source address, permitted inbound interface).
  • in front of each exception, you may put "exceptions from that exception" if that makes sense.
  • finally, when you check by rule statistics that your management connection is handled by the exception rules, you set "disabled=no" for the final "drop everything" rule.
A quickly (and therefore not optimally) modified real life example is the following:
1. add chain=input connection-state=established,related action=accept
2. add chain=input connection-state=invalid action=drop
...
3. add chain=input dst-address=195.x.x.x protocol=tcp dst-port=443 in-interface=ether1 action=accept
4. add chain=input dst-address=195.x.x.x protocol=tcp dst-port=22 in-interface=ether1 action=jump jump-target=ssh-in
5. add chain=input action=drop
...
6. add chain=ssh-in src-address-list=ssh-clients action=accept
7. add chain=ssh-in src-address-list=shadowserver-scan action=drop
8. add chain=ssh-in action=add-src-to-address-list address-list=ssh-attacks address-list-timeout=none-static
9. add chain=ssh-in action=drop
Rule 1 matches all packets belonging to already established tracked connections.
After that rule has done its job, this type of packets is not inspected by any following rule. So only packets which did not match that rule get further in the chain.

Rule 2 matches all packets which match already established tracked connections by source and destination sockets but they do not fit to current state of such connection.
After that rule has done its job, only packets whose connection state is none of (related, established, invalid), which means it must be one of (new, untracked), get further in the chain.

So Rules 3 and 4 only get this kind of packets (new or untracked) for inspection, and checks whether they came in through a particular interface and are intended for a particular IP address and TCP port. Rule 3 accepts its matching packets straight away, but Rule 4 sends its matching packets to a new chain, created for that purpose, for a more detailed inspection and sort-out.

Rule 5 receives all the rest, which means packets which are new or untracked and came in through other interface than ether1 or towards other IP address than 195.x.x.x or are not TCP ones or are not towards ports 22 or 443. And drops them.

So Rule 5 is the most generic one, Rules 3 and 4 are exceptions from it, and Rule 2 is a common exception from both Rule 3 and Rule 4 as it filters away "invalid" packets which Rule 3 or Rule 4 would otherwise accept as they do not care about "connection-state" themselves. Rule 1 is an exception from Rules 3 to 5 - it doesn't allow Rule 5 to drop "established" or "related" packets, and it does not allow rules 3 and 4 to inspect them. Rule 1 cannot be deemed an exception from Rule 2 because both check the same attribute of the packet (connection-state) but each of them matches a different set of values of that attribute.

Rules in the chain "ssh-in" only receive for inspection packets which matched Rule 4 - initial packets of TCP sessions on local port 22 (i.e. SSH ones) on address 195.x.x.x which came in via ether1.

Rule 6 accepts such packets from a list of permitted clients. What remains are initial TCP packets to port 22 etc. but from other sources than those on the ssh-clients list

Rule 7 silently drops packets as above (TCP/22 etc.) coming from known sources which we do not need to note down (the shadowserver foundation presents themselves as good guys who care about security so we don't let them in but we don't record that attempt as a security incident).

Rule 8 adds the remaining packets as above (TCP/22 etc.) from any other sources than those on the two lists. We record each such not-yet-known source to a list named ssh-attacks. If an attempt comes twice from the same source, I think the existing item on the list is overwritten so the timestamp of the last occurrence is recorded. To keep the timestamp of the first occurrence in the record, I would have to use the same address list like in Rule 7 (so that once an address would be recorded, any subsequent packet from it would be dropped already by Rule 7), but as the address list would be growing, processing Rule 7 would take more and more time as the packets' source address is compared to the whole address list item by item.
However, packets which have matched Rule 8 are inspected also by Rule 9, because adding a packet to address list is not a final verdict.

Rule 9 drops the packets which made it up to it as they did match Rule 4 and didn't match Rule 6 (which would have accepted them) nor Rule 7 (which would have dropped them). So again, Rule 6 and Rule 7 are in a way exceptions from Rule 9.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.

Who is online

Users browsing this forum: elico, nomatter, sindy and 44 guests