Hi all,

DDOS. need i say more? crippled us over the last week. Had to have upstream isp blackhole the offending static route for 48 hours. Changing it didnt matter. Some LAN device is likely asking for it/report the IP.

Didnt have any filter rules before. 2 years of no problems. I learned my lesson.

Take alook at what ive got. I put some thought into input vs forward chains. As the DDOS we had was port 1900 udp to our router @ 5.1gbps, flooding the port and resulting in total packet loss for the duration. 48 hours later, we have enabled the route again, its been 2 hours, no attack yet, but likely the device that is asking for it is not online yet.

A few things i am looking for:
- feed back on the order of my filters. Do i need to re-org them?
- Im new to jump rules, I have DDOS ones on the input chain, and virus ones on the forward. Do i need to block those ports outbound too? keep the virus from being able to talk out? Would that be a third jump chain on the output? Should i make the virus+DDOS list the same list and make 3 jump chains? one for in, out, and forward? is too many jumps going to tank my router proc?
- i also put a simple queue at 230M Down 100M UP to see if that helps me still be able to get into the router during an attack, albeit likely maxing the proccessor when 5.1gbps is being sent to the ip router no matter what i do.

I have attached the current setup via screen shot. easier to read than script.

Any help would be awesome. Also wondering about making my DDOS chain bigger. I was watching the NORSE map on http://map.ipviking.com/ and wondering if i should just add ALL those ports to the input chain? in and out chain?

Thank you for the mentorship!

ps: 250mbps up/down fiber
RB1100AH (not x2) OS 6.12
with average usage @ 110mbps Down 10 Up and current filters/nat, cpu is at 35-45%

router screenshot

wondering if we can share popular DDOS ports to block, and if it should be input and forward, and if output would help too.

not even sure any of this filtering will help.

I think your going the wrong way.

Instead of blocking every known treat (meaning the unknown ones will still pass), try to allow only the known things.
e.g (adapt to your needs regarding the needed ports...):
input:
- Allow incoming ports and protocols (as needed, if needed - this catches new connection to your router)
- Allow incoming protocol 1 (icmp. if you want to respond to ping on WAN)
- Allow incoming from LAN (to be able to use services from LAN, including management - don't forget this)
- Allow incoming established
- Allow incoming related
- Drop everything else incoming.
forward:
- Allow forward outgoing (or restrict, as needed, allowing known destination ports)
- Allow forward established
- Allow forward related
- Drop any other forward
output:
- Allow all output (these are router requests or replies, so no worry on these)

If you need to access an internal server, use dst-nat. Replies will be allowed by the forward established/related filter.

Much easier to manage.

Wow. yes, you are right.
Im learning and new at this.

I had that queue in there and that was taking my routers performance had that in case it would help me hold access during an attack. RB1100AH i guess cant handle a queue of that size

As a way to understand, help me with this:

If say 20 users want to watch netflix from inside the lan, in a router like you setup, because they established the connection from inside, the router would allow those connections? I dont need to id all the ports things like streaming use?

This is an edge router for me, and inside i have about 200 access points, clustered into about 20 vlans. No servers, nothing interesting except it is natting, and is at the edge of the network, so im hopeful i can lock it down to sheild off some DDOS attacks.

If your very nicely made list of rules the main framework i need? And if i dont need any services or host any servers, I can just lock it down, except for winbox of course? And even then, i should prob VPN into it for that.

Thanks for the mentorship! Looking to get this puppy rinning smooth again as an edge router.

Hi Doc,

I hope you are watching this tread. Your post really helped me to change my point of view of firewaling and while trying to build it, i think i understand all the login needed to make an effective edge router firewall.

Here is the document i made for myself. I think it needs some editing and close examination. Can you take a look and provide me feedback to polish this up?

WARNING: DO NOT USE! FOR TESTING ONLY!

Locked Down Edge Router with no services short of (winbox to mgtips w/ antiabuse) + (ping on mgtips w/ antiabuse) + Port Forwards w/ antiabuse

/ip firewall address-list
add list=mgtips address=xxx.xxx.xxx.xxx/30 ##static ips
add list=mgtips address=xxx.xxx.xxx.xxx/30
add list=mgtips address=192.168.0.0/16 ##LANS (is this too wide? i use .70-.90 for now, should LAN ips be on a seperate list?)

/ip firewall filter

add chain=input connection-state=established comment="allow established connections"
add chain=input connection-state=related comment="allow related connections"
add chain=input connection-state=invalid action=drop comment="drop invalid connections" ##(is this one needed?)

####Allow Winbox for mgtips only / Prevent Winbox port flood attack/abuse
add chain=input action=accept protocol=tcp src-address-list=mgtips dst-port=8291 comment="Winbox"
add chain=input protocol=tcp connection-limit=5,32 action=add-src-to-address-list address-list=WINBOX-attack address-list-timeout=1d
add chain=input address-list=WINBOX-attack action=drop

- Allow incoming from LAN (to be able to use services from LAN, including management - don't forget this) (What does this rule look like? is it inherent in the list=mgtip in the rule above?)

####Add winbox login failures to ban list (1d) (need help to make this)

####ping only allowed on mgtips w/ antiabuse rules (not sure this rule works right, burst?)
add action=accept chain=input comment="PING ABUSE STOP 5 pings in 5 seconds" disabled=no limit=5,5 protocol=icmp src-address-list=mgtips
add action=add-src-to-address-list address-list=icmp-attack address-list-timeout=12h chain=input comment="add all other icmp input into icmp-attack address list." disabled=no protocol=icmp
add action=drop chain=input comment="drop excessive icmp traffic for 12 hours" disabled=no src-address-list=icmp-attack protocol=icmp
add action=drop chain=forward comment="drop excessive icmp traffic for 12 hours" disabled=yes src-address-list=icmp-attack protocol=icmp

add chain=forward connection-state=established comment="allow established connections"
add chain=forward connection-state=related comment="allow related connections"
add chain=forward connection-state=invalid action=drop comment="drop invalid connections" (is this one needed?)

####Allow MGTDevice Access w/ Antiabuse for MGTPorts
add chain=forward action=accept protocol=tcp src-address-list=mgtips dst-port=19000-19300 comment="MGTDEVICES" (access ports to our internal devices, is this a bad idea?)
add chain=forward protocol=tcp dst-port=19000-19300 connection-limit=20,32 action=add-src-to-address-list address-list=MGT-attack address-list-timeout=1d
add chain=forward address-list=MGT-attack action=drop

add chain=input action=drop comment="drop everything else"
add chain=forward action=drop comment="drop everything else"


how does this effect ssl/popular vpns?
how does this effect hulu+netflix on about 100 devices at once? (i am running about 15 NATs w/ vlans to make it a bit more elegant)
how does this effect other things im not thinking of?
anything else i should consider for a locked down edge router for about 1000 clients? 'residential type use'

Actually I never used lists, only ip/masks

Let me make a little theory on the access and let you work it out and tailor it to your needs.
First about NAT:
- src-nat happens LAST on the path of a packet, just before it is pushed to the ethernet interface. So any rules, filters and routes will not take this change in account.
- dst-nat happens FIRST in the chain, so any rules applied to destinations, outgoing ports and such stuff will work as if the incoming packet came in with its destination set as defined in the dst-nat rule.

Enough with this. Let's see the connection tracking and filtering...

The moment a connection is established (SYN TCP packet, a ALLOWED UDP or ICMP packet or other known packets like GRE), the router will track this connection, with a certain timeout and sensing the FIN packet for a TCP connection, remembering the source and destination interface, IP, protocol and port (if applicable) and forward all subsequent incoming and the corresponding replies for that connection using this known path. This will happen for every new connection and all packets belonging to this path will have the "established" attribute.
For certain protocols, like FTP, the protocol needs a helper application which for MT routers can be found under IP/Services, so that the router can associate other IP/port combination to that particular connection. These will get the "related" attribute.
And of course, packets that meet the interface/IP/protocol/port criteria but step out of line for a given connection will be "invalid".
(So yes, that rule kind of makes sense, but only if you don't drop it anyway by the general rule).

So the idea is that after the initial connection setup, everything else will work according to the established/related rule.
What is important here is that if you don't accept "new" packets, meaning those not "established" or "related", there is no way to punch a hole through the firewall.
So for connections which have to start on the inside (triggered e.g. by a machine on the LAN), you need to accept the "new" connections, and the "established", and the "related", mounting actually to ALL traffic from that machine (rule interface LAN accept).
On the external interface, if you accept only "established" and "related", no new connection will come to life, but all tracked replies will pass through.
The number of tracked connections can be very big (512k on a RB1100), so don't worry about some tens or 100 machines concurrently accessing the router.

Now except these basic rules, you need to take care of the exceptions on the WAN interface:
1. DST-NAT on the WAN interface for services which you want to offer to the internet (replies go the correct way tnx to connection tracking - no worry about them - but remember, forward filters affect them, because after dst-nat they go through the filters, with the original src and the dest as defined in the dst-nat rule).
2. Open ports for the services you want the router to offer to the internet: VPN server access, remote management (which I don't recommend this way), DNS and others.
Just remember, everything else gets dropped.

Now to the remote management: I strongly recommend a secure VPN connection, followed by using management access over that VPN. e.g. SSTP, even encrypted PPtP or L2TP (Windows client is available natively), or for added security OpenVPN. These will create a virtual interface on which you can apply specific firewall rules (e.g. limiting access to certain IPs), so you can hide the administrative interface and add an additional secutiy layer.

Have fun with your toy.
Marius

awesome. thanks!

i am working on my 3rd draft, but i have a quick question. my v2 firewall that was posted above does not have a hard drop rule (yet )

but i was wondering why the drop invalid connections count is so high? i feel like that should be before the allow established/related rules to work, but i am afraid to move them at this point. I thought that when an allow rule is hit, it will not care about any of the rules in the rest of that chain and thus, it should be 0 since the allow established/related is higher, and the invalid, which i understand simply means was not created from inside the lan, is below the accept rule.

thanks!

EDIT: PS. i just noticed my allow established/related were missing from my forward chain! i just disabled the rule to drop invalid and am afraid to mess with this as its a production network. In the screenshot below, was i dropping ALL traffic through the router that wasnt expressly allowed?

Each chain of rules works independent one from another.
The input chain affects traffic flowing to the router itself.
The forward chain manages traffic flowing through the router.
Some dropped traffic on forward will his the input rules because there are no connection tracked for forwarding.
Others will show up as invalid, for the same reason.

Most of your rules shall apply to an interface.
e.g. accept forward of established/related on WAN, and all traffic on LAN.
The same goes for the input chain (take care not to lock you out).
In your case applying a drop all on input will kill your connection to the router, because you have no rule stating that you shall be able to connect from LAN.

An example of complete minimal rules:

Thanks SO MUCH!

you are teaching me lots! here is my rough draft now. I have a few questions on there and hoping i have things in the right order. I have some pre-filters that i am thinking can help me until i learn about pppoe, but i want to get my semi-open router mostly secured. Im worried about tcp syn stuff ive been reading about. take a look, and again, THANK YOU (karma)


/ip firewall filter

##PROTECT THE ROUTER
add chain=input action=accept protocol=tcp dst-port=8291 comment="Winbox"
add chain=input action=drop src-address-list=badips comment="known bad ips" ##this is to prefilter out bad ips before they can do anything nasty? should this be first?
add chain=input action=accept protocol=icmp dst-address=99.99.99.99 comment="ping"
add chain=input action=accept connection-state=established comment="allow established connections"
add chain=input action=accept connection-state=related comment="allow related connections"
add chain=input action=accept src-address=192.168.0.0/16 in-interface=LAN1 comment="LAN1 networks" ##im not bridging the lans, hence the next rule
add chain=input action=accept src-address=192.168.0.0/16 in-interface=LAN6 comment="LAN6 networks"
add chain=input action=drop comment="drop everything else"

##PROTECT THE LAN
add chain=forward action=accept protocol=tcp dst-port=19000-19300 comment="MGTDEVICES" ##i know this is a bad idea, will need to learn about pppoe next. not sure if its more safe to enable pppoe service or just open the ports.
add chain=forward action=drop src-address=192.168.0.0/16 source-address-list=badips comment="known bad ips" ##(do i need to specify interfaces here? will it make it less proccessor intensive?) Im trying to stop LAN devices from communicating to botnet if they get activated
add chain=forward action=jump jump-target=BADTCP connection-state=new comment="BADTCP chain pre-filter" ##trying to stop malicious tcp to my open ports... will adding connection-state=new reduce processor load? does this need to go after?
add chain=forward action=jump jump-target=BADPORTS connection-state=new comment="bad ports chain"
add chain=forward action=accept connection-state=new src-address=192.168.0.0/16 out-interface=LAN1 comment="allow new connections from LAN1"
add chain=forward action=accept connection-state=new src-address=192.168.0.0/16 out-interface=LAN6 comment="allow new connections from LAN6"
add chain=forward action=accept connection-state=established in-interface=WAN1 comment="allow established connections"
add chain=forward action=accept connection-state=related in-interface=WAN1 comment="allow related connections"
add chain=forward action=drop comment="drop everything else"

##output
add chain=output action=accept comment="allow router to talk to lan"

##BADTCP pre-filter chain is this a good idea? see jump rule BADTCP above
add chain=BADTCP action=drop comment="TCP flags and Port 0 attacks" protocol=tcp tcp-flags=!fin,!syn,!rst,!ack
add chain=BADTCP action=drop protocol=tcp tcp-flags=fin,syn
add chain=BADTCP action=drop protocol=tcp tcp-flags=fin,rst
add chain=BADTCP action=drop protocol=tcp tcp-flags=fin,!ack
add chain=BADTCP action=drop protocol=tcp tcp-flags=fin,urg
add chain=BADTCP action=drop protocol=tcp tcp-flags=syn,rst
add chain=BADTCP action=drop protocol=tcp tcp-flags=rst,urg
add chain=BADTCP action=drop protocol=tcp src-port=0
add chain=BADTCP action=drop dst-port=0 protocol=tcp
add chain=BADTCP action=drop protocol=udp src-port=0
add chain=BADTCP action=drop dst-port=0 protocol=udp

You are right, I would put the bad-ip filtering as the first rule.
And I would drop the dst-addr from ICMP, since it could be a valuable debug tool.
Maybe drop ICMP on the WAN interface (making the router harder to discover on a ping sweep ), but not on LAN.

Adding specific accept rules for pppoe client connections is not necessary. Just don't put any rules for the physical WAN port and don't assign any IP to it and you are OK. Treat the pppoe interface as any WAN port and just ignore the physical interface. For safety you can add a "forward drop all" rule on the physical interface. And for a pppoe server, AFAIK it is enough to activate the server.

And if you drop the state=new evaluation on LAN ports and move the established/related rules to the top (just after specific drop rules), it will speed up processing without any side effect (this is not really necessary - just an idea - the RB1100 is fast enough not to notice any difference).

The rest seems ok to me.

what do you mean it could be a valuable debugging tool? how so?

i have about 20 outside facing public ips, so i added dst-address to the rule so only 1 of them would ping back and since it was specified to allow, the other 19 would get caught by the drop everything rule right?

??? like this?
add chain=input action=drop protocol=icmp comment="ping" in-interface=WAN1
add chain=input action=accept protocol=icmp comment="ping"
???
edit: oh, do you mean, i should leave it on the input chain so i can ping out of winbox terminal? i think the use of 'drop' in your first sentence threw me a bit...

also, you said on the LAN i should accept it? isnt it inherent in the accept established/related connections? and these rules? wont that allow icmp through the LAN?

add chain=forward action=accept src-address=192.168.0.0/16 out-interface=LAN1
add chain=forward action=accept src-address=192.168.0.0/16 out-interface=LAN6

"And if you drop the state=new evaluation on LAN ports" - you said 'drop' do you mean "drop", or move it down, or remove the state=new from the line?

should i remove the connection-state=new from the jump filters too? trying to be as processor sensitive i can on the forward rules. i dont know if more restrictions/specifications in the rule is more or less processor efficient.

add chain=forward action=drop source-address-list=badips comment="known bad ips" ##do i need to put src-address=192.168.0.0/16 on this rule to stop the LAN from starting a connection to these ips? Is having the rule on top inherently bi-directional?


Thanks! Im so close!

Ok... I meant to delete the state=new form the rules.

Regarding icmp: The forward rule will only forward icmp requests from the LAN to an external IP.
Maybe you would like to check if your router works from the LAN, Then you need an icmp accept from LAN on the input chain, not on the forward chain.

As I said, the input chain regulates the traffic terminating on an router interface, forward handles the traffic passing the router.

So if your router has 1.2.3.4 as its external IP, and 192.168.1.1 as its internal, then icmp input accept will allow 192.168.1.1 and 1.2.3.4 to respond to ping.
But this will not allow you to ping google.com from the LAN. For that you need accept icmp in the forward chain (and the other way around - first rule missing, no ping response from the router). This is why I suggested you to accept ping in the input chain on all interfaces.

Regarding the bad IPs, you could just drop them in both directions, no src IP check needed. They are BAD.

Excellent!

I studied your notes, and then ran a test on my RB450G at home. Had to play with it a bit, but i think i got it.

I am still a bit unclear of my order or operations on the icmp rules i have here. But what i want is the router to be stealth, but users on the lan, and the router itself to be allowed to ping out and get an ack.

I have 2 things in red below that i want to be sure of, and my general order of rules for efficiency.

THANKS! (karma:)


/ip firewall filter

##PROTECT THE ROUTER
add chain=input action=drop src-address-list=badips comment="known bad ips"
add chain=input action=jump jump-target=BADTCP comment="BADTCP chain pre-filter" ##added this here to protect open WINBOX from badTCP???
add chain=input action=accept protocol=tcp dst-port=8291 comment="Winbox"
add chain=input action=accept connection-state=established comment="allow established connections"
add chain=input action=accept connection-state=related comment="allow related connections"
add chain=input action=accept src-address=192.168.0.0/16 in-interface=LAN1 comment="LAN1 networks"
add chain=input action=accept src-address=192.168.0.0/16 in-interface=LAN6 comment="LAN6 networks"
add chain=input action=drop comment="drop everything else"

##PROTECT THE LAN
add chain=forward action=drop source-address-list=badips comment="known bad ips"
add chain=forward action=jump jump-target=BADTCP comment="BADTCP chain pre-filter"
add chain=forward action=jump jump-target=BADPORTS comment="bad ports chain"
add chain=forward action=accept src-address=192.168.0.0/16 out-interface=WAN1 comment="allow connections from LANStoWAN1" ##do i need to specify LAN interfaces since an RB1100AH has 2 Lans but im not bridging? Can the src-address specifyer grab from both interfaces?
add chain=forward action=accept connection-state=established dst-address=192.168.0.0/16 in-interface=WAN1 comment="allow established connections"
add chain=forward action=accept connection-state=related dst-address=192.168.0.0/16 in-interface=WAN1 comment="allow related connections"
add chain=forward action=accept protocol=tcp dst-port=19000-19300 comment="MGTDEVICES"
add chain=forward action=drop comment="drop everything else"

##output
add chain=output action=accept comment="allow router to talk to lan"


##BADTCP pre-filter chain Is this the right thing to do? is the jump rule above in the right stop to: How i understand it is that this is to stop the ESTABLISHED connections from attracking tcp syn stuff?
add chain=BADTCP action=drop comment="TCP flags and Port 0 attacks" protocol=tcp tcp-flags=!fin,!syn,!rst,!ack
add chain=BADTCP action=drop protocol=tcp tcp-flags=fin,syn
add chain=BADTCP action=drop protocol=tcp tcp-flags=fin,rst
add chain=BADTCP action=drop protocol=tcp tcp-flags=fin,!ack
add chain=BADTCP action=drop protocol=tcp tcp-flags=fin,urg
add chain=BADTCP action=drop protocol=tcp tcp-flags=syn,rst
add chain=BADTCP action=drop protocol=tcp tcp-flags=rst,urg
add chain=BADTCP action=drop protocol=tcp src-port=0
add chain=BADTCP action=drop dst-port=0 protocol=tcp
add chain=BADTCP action=drop protocol=udp src-port=0
add chain=BADTCP action=drop dst-port=0 protocol=udp

deleted

OK! so i got hit with DDOS before i was able to put get things finalized. Network went down.... came back in about 10 min.

i was desperate, so i started applying the rules, (in safe mode of course!)

Things were going well with my new rules!

Got hit with DDOS again, router could not handle it. its really not the routers fault, there was over 5gbps going from the upstream isp to our static ip, way over our quota and 1gbps port capacity, and i clocked 19million packets to udp 1900 within 2 minutes.

then DDOS stopped again. i was able to start playing with the new setup BUT for the life of me, i can not get my port forward to work for my Management port range.

I have:

add chain=forward action=accept protocol=tcp dst-port=19000-19300 comment="MGTDEVICES"
##this is the last rule on the forward chain before the drop rule. I tried it at the top of the forward chain too, no luck.

nat
action=dst-nat protocol=tcp dst-port=19020 dst-address=192.168.89.200 chain=dst-nat to-ports=443

tried with and without interface specified....

i can see packets hitting the nat rule but they are not going back to me. not sure why the forward chain is not letting it back through to me. Do i need a second nat rule for the way back? nothing hits my forward filter...


Answer to my own question (i think): I have to open ports 443+80 restricting with in-interface=WAN1

this makes it so it can talk back. i for some reason thought it would be bi-directional on the same port 190x0 but i was wrong. I guess before i had a drop rule it was just talking back on 80+443 anyway. (should i make a nat rule for the way back on the same dst-nat port? is that a thing?)

I GOT THERE. please take a look at the pic below to make sure i didnt just open a gaping hole or do something ignorant.

next step is to setup vpn, but i hope i am more invisible to ddos now. not totally, becuase i did get hit after putting in the rules.

PS. i think the jump rules on the forward chains are too heavy for the router when trying to pass 200mbps of traffic, that is why they are disabled. They count every packet that goes through the router, so its GBs per min piling up. is that right? should i do something to restrict them so they are less intenseive on the proc?

so i had to add an icmp rule so i could ping the gateway. in my tests, i think it was pinging without the rule becuase the connections were already established when i loaded the new rules.

then my watchdogs started rebooting when those connecttions were dropped and not allowed.

I used: chain=input src-address=192.168.0.0/16 protocol=icmp action=allow

I also can not pass traffic through the lan to other devices. In general this is ok becuase my customers all pass traffic directly to the net and do not need lan services. BUT to run manage devices while we are in the lan, or to run out mikrotik bandwidth servers are not going to work as is. I thought this rule will make the lan work and allow all traffic to talk, but it didnt, hence needing the icmp rule, but i thought icmp and lan communications are inherent in this rule:

add chain=forward action=accept src-address=192.168.0.0/16 out-interface=WAN1 comment="allow connections from LANStoWAN1"

do i need to add this?
add chain=forward action=accept src-address=192.168.0.0/16 in-interface=LAN1
add chain=forward action=accept src-address=192.168.0.0/16 out-interface=LAN1
add chain=forward action=accept src-address=192.168.0.0/16 in-interface=LAN6
add chain=forward action=accept src-address=192.168.0.0/16 out-interface=LAN6

(in-interface specified as without interfaces, it would attempt packets from the net with bogons?) with these, do i need icmp rule too?