I’ve been using MikroTiks for years, but I’d be happy to be proven ignorant on this if there is such a feature. What I’m wanting is the ability in Winbox to specify an example packet details (ie. any option in a Firewall rule) and get a report of which rules–including NAT–would match that packet if it passed through the router. This would be a killer feature for tracking down security holes and just explaining why something isn’t working when I think it should be.
So, is there anything like this available for RouterOS?
There are enough tools already to do this work, least of which is putting logging rules before rules to see what packets are hitting the rule in question.
As for security holes, plug them for the most part by putting a drop all rule at the end of the forward chain and input chain and thus traffic getting through will limited to what you have allowed or nefarious users on your network using your internet connection for ‘bad’ reasons. PS> I think I saw some sort of packet inspector like what you described once, could have been on a Crisco router.
I do not see any need for this.
All of this “Filter, NAT, Mangle…” has logging capability, and as anav writs, if you are not sure what packets reaches the rule, add a rule in front if rule to examine and log all traffic. You will then see what will hit the rule and the rule will tell you what it filter/nat/mangle.
Sending data to external syslog server like Splunk, gives you a good view of what is going on. See my signature for example.
PS I do have a drawing on how my rules are setup to help me out.
@tangent Thanks for your thoughts. That is an interesting idea, albeit pretty involved to set up and test.
@Jotne Thanks for your flowchart. Something like that would be very helpful, especially if it’s kept up to date. I get the idea of logging statements throughout, but you’re still having to poke around to figure it out. What I’m asking for would not require adding any (log) rules and would work across all chains and areas (Filter, NAT, Mangle). I still see something like I’m asking for as being very useful. In addition to being very helpful at troubleshooting, it would also be useful in training and learning.
When your firewall is so complex that you no longer understand it, you should redesign it to be more managable.
In may cases you can make things a lot clearer using the “jump” action (which is a misnomer, it really should have been named “call”).
In the main “forward” and “input” chains, usually after the initial “accept established/related” that you normally want to have, add a number of rules that match on in-interface(-list) and jump to a dedicated chain for that. So you will have a different dedicated chain for internet, LAN, guest network, VPN, etc.
That way you can keep the different sections easier to understand.
Also, keep all the rules grouped by chain name. And, between the groups, add a rule for chain ----- with action “log” and comment -------------
These serve as a separator line for each section.
Of course, end each section with a “drop” or “reject” without any match (default drop). Make sure you “accept” all traffic you want in the rules above that.
With such standard practices, you keep everything much easier to understand and usually safer.
I disagree with that. "raw" rules, when not fully understood, cause nasty problems that you do not see in "filter" rules with connection tracking.
Only use "raw" rules when necessary, e.g. to exclude some traffic from connection tracking, or to drop traffic of broad categories that you are sure you do not want to see (e.g. IP protocol 41).
Concur with pe1chl, raw is not to be trifled with… mind you I dont yet see the need to use jump either on my small config.
(would jump chain be a good candidate for knock rules on the input chain?)
Also allergic to mangling!
One example over all for raw: all incoming IPs presents on blacklist or from DDoS attack.
Why bother with those? In case of attack it also consumes less CPU …
No argument, identify in input chain, block in raw makes sense to me.......
Just not convinced
a. a homeowner is going to get singled out and DDOS attacked.
b. the router will actually prevent loss of internet
My sense is its the responsibility and possibly within the capabilities of the ISP provider..............
where you want to group some traffic (e.g. coming from a certain interface, going out to some interface) for ease of maintenance
where you have many rules that share the same matching criteria except some detail different on all of them (the above actually is a special case of that)
In routers I manage I e.g. have a different chain for all the traffic that is leaving the router towards local servers. In the typical NAT router that would be “port forwards”, but the main network I manage generally does not use NAT but still you want to have protection of the connected systems similar to what you would have with “port forwards”. So I use a chain “openports” that allows certain dst.address/protocol/port combinations and is called for traffic outgoing on the interface where the local servers are connected. This keeps everything nicely organized, and it avoids the situation where a long list of rules is present in the forward chain that are all to be evaluated also for traffic that is just being forwarded to another router and not to the local servers.
But in the typical home NAT router this would be overkill, and in fact unnecessary because you would put these rules in as dst-nat and have a rule in the forward table that matches on “dst-natted traffic” (as it is done in the default firewall).
And the same is for mark route on mangle, when is not evitable better use routes rules
When you make vlan you create more vlan interface in /interface vlan and put all together on bridge,
or you directly use bridge/vlan settings (or orther function depending on hardware) ???
Is the same with firewall filters and firewall raw, until connection tracking or some advanced features are needed, better use raw.
I do that for all my user dropping directly the route on my BGP router, and on case of attack I can send directly a BGP blackhole route on my “provider”
Well I use bridges and vlans and keep firewall rules to the firewall settings. More specifically, each vlan has its own subnet.
Understood, I am just not comfortable enough with my knowledge of raw and connection tracking to know when or not to use RAW.
For my basic home setup of two wans, about 15 vlans and WLANs, I dont think I really need raw but am open to suggestions.
At least all user must enable IP Spoofing block, near all DDoS attack use that vulnerability.
Today I discover that what I took for sure (set loose), for my disbelief for default are disabled…
/ip settings rp-filter default is no
Must be set at least to loose http://forum.mikrotik.com/t/cant-reach-winbox-if-dual-wan-in-failover-mode/150556/1
the strict option must be necessary only on ISP border router
The default firewall, if not set for drop spoofing, permit crafted packet from LAN to WAN…
No, infected PC (or DVR, or any IoT device, etc.) than send out packet to Internet,
like fake ping from 8.8.8.8 to ip like 1.1.1.1…
the simply rule “LAN to WAN allowed” if not integrated with some other settings or rules,
accept that packet and send it out on internet (if rp-filter=no)
if rp-filter is loose, the software see than the packet coming from “8.8.8.8” come from wrong port (LAN), because “8.8.8.8” are reachable on WAN, not LAN, and discard the packet.
(for precision: check if the IP can be reached from any internal interface, if not the packet are discarded)
lan to wan traffic with dst address of private IPs
What you say, leak private internal LAN address to internet (obviously not one already used on own internal router),
really is not a problem, ISP border router drop it because are unroutable on Internet
Instead some NAT do not translate TCP ACK or TCP RST packet on out (TP-Link), this is wanted, and I do not full understand why, just some suppositions,
and the packet go out with for example 192.168.x.x as source
