What kind of traffic do you filter using RAW. I cant find anything interesting except SSH block login users using RAW. Can you give me some idea? do you use it?
The biggest advantage of the raw table is that it happens prior to connection state tracking.
It’s a good place to drop packets from a blacklist because doing so in raw prevents the connection attempts from clogging up the connection tracking table.
Another thing to do is to make certain types of traffic go through the system “untracked” - which can improve performance. For this type of traffic, you would need to make sure that the filter table permits the traffic based on some heuristic other than connection state=established,related,new,invalid (note that “untracked” is a valid choice but tread lightly before allwing all untracked traffic), and generally these rules should come early in your filter chains for performance reasons.
One basic example of a good use of the raw table would be on core routers where you don’t do any kind of filtering / nat translation / etc - you may want to use connection tracking for the input/output chains, but just forward packets as quickly as possible. In raw, you could use the prerouting chain to perform an action of “notrack” for all packets whose dst-address-type=!local
This one rule would make all forwarded traffic skip the connection tracking engine, speeding things up for you, but w/o having to disable connection tracking system-wide. The input/output chains could still leverage this functionality.
I confirm the word of ZeroByte. We use raw table on our exchange routers to block some commond attack likes SSDP, LDAP, rate limiting DNS… We also fastrack other traffic and we can absorb some f large attacks.
If you need to drop some network, i suggest to using blackhole type routing
Black holing is not that effective as it seemed to be a while ago: http://forum.mikrotik.com/t/why-source-based-blackhole-instead-of-firewall-drop/103496/25
I tried the example of ZeroByte but did not manage to get it working and reverted to fasttracking.
yes i know that post, but the information on it was not correct. Read last reply of that thread.
I write here why blackholing is better:
###################
Blackholing is better because we can use it with fastpath active. Disabling route cache is not an option because this action disable fastpath
As DDoS Protected company we’re tuning ccr1072 mikrotik devices that we have on IXs and we have this configuration:
- Fastpath active (i see if we disable route cache fastpath is automaticaly disabled)
- Connection tracking disabled
- syncookie active and rp filter in loose
- Most know involved ip/networks in BH route
- Traffic divert setup in place
- If attack start our monitor will divert target ip to our filters
We experienced during TCP flood > 500k pps packet loss for around first 1-2 minutes, someone else experiencing the same?
With that configuration on CCR1072 we have about 10% CPU usage with 8Gbps troughput, so the issue shouldn’t be on cpu and i not understand why it happen only for 1-2 minutes (no matter the attack lengh)
###################
We also detected that you can use fasttrack with raw rules in place (see: http://forum.mikrotik.com/t/ip-raw-fasttrack-is-possible/110212/3 )
Thank and it seems that the solution to have an cascade of two devices. Only with Fastpath and the BGP routing for the blackhole.
The device behind that does the rest and is freed from the global filtering.
Fasttrack and RAW works together however if I want to filter out direct address requests to a webserver then I need all traffic on port 80/443 through RAW. Fasttrack will grab traffic as soon it is established and bypass RAW.
This is the same as with using layer 7 filtering.
I want to use some ip (it is in firewall as forward chain), Can I use raw with prerouting and it will do the same?
Hi.
I have a problem with RAW rule.
In the Mikrotik I mapping port 5060 on UDP protocol and I add rule on the RAW to drop all connection on this port from blacklist. But this rule not working and users try to connent throuth this port to my PhoneStation.
What am I doing wrong.
My question is simpler.
If my INPUT CHAIN RULES ARE basically.
Allow established, related
Drop invalid
Allow admin access (from lan side)
Allow access to port 53 from LAN
Drop All Else,
Then I should not need to have any other drop rules for the input chain.
However, if I want to take the load off the CPU to drop all the crappy in bound traffic,
Wouldnt it make sense to do this in raw prerouting.
/ip filter raw
add chain=prerouting in-interface-list=wan action=drop ???
Why do people want to add the incoming address list to a list and then drop the list
Seems like an extra step that saves nothing??
Would the above drop any legitimate return traffic?
Would the above negate interfere with legitimate inbound unsolicited traffic heading for servers behind the router for example?
If so, then I see the reason to add the source address list in prerouting and then in firewall filter rules apply the drop on input chain, which would stop access to router attempts but not legit attempts to reach server.
@Koman: are you sure you actually need to set in-interface-list? Use of src-address-list=blacklist should be enough.
Very near to the top of firewall raw wiki it is written:
RAW table does not have matchers that depend on connection tracking ( like connection-state, layer7 etc.).
So if you’d use a real straight rule (as written in quoted text), nothing at all would pass, not even return packets (which otherwise count as established).
When similar rule is used, but using blacklist
Why do people want to add the incoming address list to a list and then drop the list
Seems like an extra step that saves nothing??
The idea is: if someone tries wrong door, he should be banned from all doors (even those otherwise allowed). In your particular case nothing would change as you don’t offer any service to random internet host. But if you’d run your HTTPS service, DNS service for your domain, SMTP service, etc., you’d have a few (standard!) ports open to whole internet and every random internet host would be able to connect. In this case, if someone first tried winbox port and landed in blacklist, that host would not be able to connect HTTPS or DNS or … for duration of blacklist timeout.
Thanks MKX,
So here is what I would propose…
Tactic1:
Drop everything in raw prerouting for ports one knows will not be used outbound or inbound by the router or users behind the router or to services behind the router (in-interface WAN).
This will take the load off the CPU to do this in filter rule.
(for example 21, 23, 8291 etc…)
Tactic 2,
Keep everything in raw and this time simply get the source address for the standard port hackers routinely attempt to probe, (in-interface=wan)
(21,22,23, 53, etc…)
Create list
Still in raw, then drop all from source source addresses for 5 days or something.
What is the risk, downside of this approach…
I like your logic which lends itself to Tactic 2, in that bad guys will not just try the standard ports but perhaps many more or groups etc… and this method blocks them from all attempts.
A starting list of ports I do not use that could be effective in identifying bad guys and banning for 5 days.
0,11,20,21,22,23,79, 113, 119, 135, 139, 194, 389,445, 500, 1002, 1025, 1026, 1027, 1028, 1029, 1030, 1720, 5000
I dont expect any unsolicited incoming traffic on ports 25, 53, 80, 110, 143 or port 443 unsolicited but I should probably do these ones in firewall filter as I do not want to catch legitimate return traffic inbound to the WAN. Agreed?
Would look like so…(just before last rule of drop all input).
/ip firewall filter
add action=add-src-to-address-list address-list=DropPortProbes
address-list-timeout=5d chain=input comment=CaptureInputProbes_tcp
disabled=yes dst-port=25,53,80,443 in-interface-list=WAN protocol=tcp
add action=add-src-to-address-list address-list=DropPortProbes
address-list-timeout=5d chain=input comment=CaptureInputProbes_udp
disabled=yes dst-port=25,53,80,443 in-interface-list=WAN protocol=udp
/ip firewall raw (PREROUTING)
add action=add-src-to-address-list address-list=DropPortProbes
address-list-timeout=5d chain=prerouting comment=CaptureUnusedPorts_TCP
disabled=yes dst-port=0,11,20,21,22,23,79,113,119,135,139,194,389
in-interface-list=WAN protocol=tcp
add action=add-src-to-address-list address-list=DropPortProbes
address-list-timeout=5d chain=prerouting comment=CaptureUnusedPorts_TCP2
disabled=yes dst-port=445,500,1002,1025,1026,1027,1028,1029,1030,1720,5000
in-interface-list=WAN protocol=tcp
add action=add-src-to-address-list address-list=DropPortProbes
address-list-timeout=5d chain=prerouting comment=CaptureUnusedPortsUDP
disabled=yes dst-port=0,11,20,21,22,23,79,113,119,135,139,194,389
in-interface-list=WAN protocol=udp
add action=add-src-to-address-list address-list=DropPortProbes
address-list-timeout=5d chain=prerouting comment=CaptureUnusedPorts_UDP2
disabled=yes dst-port=445,500,1002,1025,1026,1027,1028,1029,1030,1720,5000
in-interface-list=WAN protocol=udp
add action=drop chain=prerouting disabled=yes in-interface-list=WAN
src-address-list=DropPortProbes
As you may have noticed I didnt have any firewall filter capture FORWARD probes on 25,53,80,443 etc.
Should I add those to the mix??
If one insits on blacklisting trespassers, I think easier would like this:
- In filter section accept whatever needs to be accepred in both input (ideally none) and forward chains. But be selective (see last paragraph)
- In filter section add pennultimate rule to add src-address to blacklist for all surviving packets … possibly this rule would be in both input and forward chain … and the ultimate rule drop all (possibly both input and forward chain).
Due to memory consumption issues it’s probably enough to set list member timeout to a few hours - add drop from blacklist in raw
Why both input and forward in the second bullet? If we DST-NAT some port and limit accessibility in nat section while accepting all nat-ed connections in filter section, then a trespasser knocking on DST-NATed port would not land in blacklist as it would get dropped in nat section (already left the filter section through accept due to dst-nat). If, on the other hand, we use filter rules to selectively allow access to those ports, trespassers not being accepted in particular forward rule would hit the “add to blacklist” filter rule …
So your saying that place the same rule in FORWARD that you do in INPUT
However, you also note the drop rule… WHY, if the remaining packets are matched to add to address list, none will hit last drop rule (now redundant)???
/ip firewall filter
{input chain}
…
allow admin access from lan
allow dns from lan
add all other traffic to address list name=stopProbes (timeout 6 hours)
drop all other traffic (no longer need this rule as no packet will reach here)???
{forward chain}..
..
allow lan to wan
allow dst-nat traffic → connection-nat-state=dstnat
add all other traffic to address list name=stopProbes (timeout 6 hours)
drop all other traffic (no longer need this rule as no packet will reach here)???
/ip firewall raw
prerouting chain drop source-address-list=stopProbes
You’re quite right. But having both doesn’t hurt while it helps to ease the mind of paranoid admins 
{forward chain}..
..
allow lan to wan
allow dst-nat traffic → connection-nat-state=dstnat
add all other traffic to address list name=stopProbes (timeout 6 hours)
drop all other traffic (no longer need this rule as no packet will reach here)???
Nope, the red should be quite selective as I wrote in my last post. Like this:
allow dst-nat where dst-port is that and src-address is that or that
allow dst-nat where dst-port is another one and src-address is another one
Only in this case trespasser trying “that” port will hit the green rule.
Okay MKX, just wanted to be sure, that what you are saying is that instead of placing the additional security info on the NAT rule, dont make a general rule for DSTNAT in filter, get specific!!
So If I have two port forwarding streams (4 in total, tcp and udp).
add action=dst-nat chain=dstnat comment=CompanyA_TCP dst-port=\
xx,yy,zz in-interface-list=WAN log=yes protocol=tcp \
src-address-list=TechniciansA to-addresses=192.168.u.u
add action=dst-nat chain=dstnat comment=CompanyA_UDP dst-port=\
xx,yy,zz in-interface-list=WAN log=yes protocol=udp \
src-address-list=TechniciansA to-addresses=192.168.u.u
and
add action=dst-nat chain=dstnat comment=CompanyB_TCP dst-port=ttttt \
in-interface-list=WAN log=yes protocol=tcp src-address-list=TechniciansB \
to-addresses=192.168.v.v
add action=dst-nat chain=dstnat comment=CompanyB_UDP dst-port=tttt \
in-interface-list=WAN log=yes protocol=udp src-address-list=TechniciansB \
to-addresses=192.168.v.v
You are recommending the following changes…
Obviously have to keep the nat rutes too
add action=dst-nat chain=dstnat comment=CompanyA_TCP dst-port=\
xx,yy,zz in-interface-list=WAN log=yes protocol=tcp \
to-addresses=192.168.u.u
add action=dst-nat chain=dstnat comment=CompanyA_UDP dst-port=\
xx,yy,zz in-interface-list=WAN log=yes protocol=udp \
to-addresses=192.168.u.u
and
add action=dst-nat chain=dstnat comment=CompanyB_TCP dst-port=ttttt \
in-interface-list=WAN log=yes protocol=tcp\
to-addresses=192.168.v.v
add action=dst-nat chain=dstnat comment=CompanyB_UDP dst-port=tttt \
in-interface-list=WAN log=yes protocol=udp\
to-addresses=192.168.v.v
and create the more specific filter rules and ports and protocol are not needed.
add action=accept chain=forward comment="CompanyA DST FILTER" \
connection-nat-state=dstnat in-interface-list=WAN \
src-address-list=CompanyA
add action=accept chain=forward comment="CompanyB DST FILTER" \
connection-nat-state=dstnat in-interface-list=WAN \
src-address-list=CompanyB
The rules in the last code block are too general … for example anyone from src-address-list=CompanyB will be able to connect to CompanyA services.
I think (and might to test as well some day) that filter rules for DST-NATed services should actually look very much alike rules for routed traffic (i.e. IPv6 filter rules) as if no NAT was necessary. According to Packet flow diagram DST NAT comes at the end of prerouting, so a filter rule should be like this:
action=accept chain=forward dst-port=xx,yy,zz protocol=tcp dst-address=192.168.u.u src-address-list=CompanyA
And here goes another dose of paranoia: one should drop in raw all packets with in-interface-list=WAN and dst-address anything remotely similar to used LAN addresses. Not that this paranoia has anything to do with the above firewall filter …
But now we are duplicating exactly the ip firewall nat rule??
That seems strange? I was trying to avoid duplication where possible LOL.
Okay well the quick answer is to put source address on both NAT rules and Filter rules??
BUt I have to ask…
what does the router look at first
NAT rule or
Filter rule??
Case1:
If its the NAT rule then we don’t have to worry about being to particular on the filter rule if we state the source address in the NAT rule…
Then the filter rule can be less specific and we dont care about port or protocol…
(where AuthorizedPortFowarders = all company IPs addresses (a+b))
The logic being, when the packet arrives at the NAT rule, is says okay Company A source address to port xx tcp that is going to local IP .yy FITS move on…
Is there a firewall rule to allow this traffic… yup there is a match
Thus when it hits the firewall it says, yup its a dst packet coming from the WAN and its coming from an authorized list. FITS move on…
(and there is no way company B can get to Company A ports)
Case2:
If the filter rule is applied FIRST, then concur
It has to be laid out detailed on the FILTER RULE.
I am not sure there is anyway to then shorten the NAT rule??
add chain=dstnat action=dst-nat in-interface=wan
source-address-list=AuthorizedPortFowarders
Fails as the firewall rule lets the traffic through but does not perform the public to private translation role etc…
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
After reviewing the packet flow diagrams was a tossup from the first diagram and second diagram where A is the flow to follow.
There appears to be a Firewall Choice before prerouting! and one after Bridge Forward so its not clear because firewall could be (filter, nat, mangle, raw for example).
Diagram 4 helps a bit as it insinuates that routing is done before forwarding and I am thinking that we are talking a forward filter rule!!
However diagram 5 helps in that it makes it clearer flow CHAINS, that pre-routing last step as you noted is dstnat AND filter forward is almost the last step of forward chain.
Therefore I think I am good to go with
add chain=forward action=accept in-interface=wan
connection-state=dst source-address-list=AuthorizedPortFowarders
The whole shebang of the last few oosts is because we want to use blacklists extensively, don’t we? So we really want techs from CompanyB trying to access server of CompanyA to hit that “add to blacklist” rule at the end …
If you had a look at link I pasted in my previous post, you’d know by now that NAT (the address rewriting) is done first, firewall comes later.
Thinking of it: perhaps using connection-nat-state=dst-nat in firewall filter really is enough. That it really is a shortcut instead if constructing all of rules twice.
I’ll let you conduct the trial
Hi MKX
The only thing I need to change on the filter rule is as follows
add chain=forward action=accept in-interface=wan
connection-state=dst source-address-list=AuthorizedPortFowarders
The NAT rules ensure company A goes to Company A port and associated local lan IP etc…