@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.