Mikrotik

DoS attack Protection

DoS attack Protection

  • Limit incoming connections
Address with too much connections can be added to address list for blocking.
 
 
/ip firewall filter add chain=input protocol=tcp connection-limit=LIMIT,32 action=add-src-to-address-list  address-list=blocked-addr address-list-timeout=1d 
/ip firewall filter add chain=input protocol=tcp src-address-list=blocked-addr connection-limit=3,32 action=tarpit 
 
 

 

where LIMIT is max. number of connection per IP. LIMIT should be 100 or higher as many services use multiple connection (HTTP, Torrent, other P2P programs).
  • Action tarpit
Instead of simply droping attackers packets(action=drop) router can capture and hold connections and with enough powerfull router is can kill the attacker.

One to One NETMAP using Mikrotik Router


If we use private ip in our server and want to access that server from internet then we need to set 1 to 1 netmap bellow are the configuration of netmap, you just need to change the public IP, Private IP and WAN interface name as per your configuration.

say we have 4 public ip address 10.10.55.171 to 10.10.55.174
and we want to netmap private IP address 192.168.123.71 to 192.168.123.74


/ip address add address=10.10.55.171/32 interface=wan 
/ip address add address=10.10.55.172/32 interface=wan 
/ip address add address=10.10.55.173/32 interface=wan 
/ip address add address=10.10.55.174/32 interface=wan 

/ip firewall nat add chain=dstnat dst-address=103.10.55.171 action=dst-nat to-addresses=192.168.123.71
/ip firewall nat add chain=dstnat dst-address=103.10.55.172 action=dst-nat to-addresses=192.168.123.72
/ip firewall nat add chain=dstnat dst-address=103.10.55.173 action=dst-nat to-addresses=192.168.123.73
/ip firewall nat add chain=dstnat dst-address=103.10.55.174 action=dst-nat to-addresses=192.168.123.74

/ip firewall nat add chain=srcnat src-address=192.168.123.71 action=src-nat to-addresses=103.10.55.171
/ip firewall nat add chain=srcnat src-address=192.168.123.72 action=src-nat to-addresses=103.10.55.172
/ip firewall nat add chain=srcnat src-address=192.168.123.73 action=src-nat to-addresses=103.10.55.173
/ip firewall nat add chain=srcnat src-address=192.168.123.74 action=src-nat to-addresses=103.10.55.174

Improved CAPsMAN Wireless Client Roaming

CAPsMAN is a very useful method of setting up a large number of APs (CAPs) in a building, but how can you help a client to roam better?  The problem is that clients can get “sticky”. They refuse to disconnect themselves from an AP, even though they have actually moved their location and are now much closer to another AP.  The client software seems to hang in there for dear life, despite having a very poor and low speed of connection, but it seems to decide, “some connection, no matter how bad, is better than none at all, but I will not check to see if there are any other APs that are stronger”. So they remain “stuck” to that distant AP, even though there is a better one nearby.  So what’s the solution?

 

Add a couple of Access-List rules to the CAPsMAN controller and you can then make the AP forcibly disconnect the client once it has reached a certain signal level.  The client, now having been kicked from the AP will be forced to re-scan and (hopefully) find another AP much stronger and connect to that one instead.  The only downside is that if a client device is leaving the building, they will be forcibly kicked and have no other AP to connect to.  (But this can be used as a security feature as it now limits the receiving range of your Wireless System on the edge of your building, thus reducing the distance they can be connected from.)

 

Here is a config script which sets the level to kick a client at -80dBm. Run this on the CAPsMAN controller router, not on any of the CAPs. Obviously the exact level chosen is up to you, but I find that -80dBm is not a bad starting position for experimentation.

/caps-man access-list
add action=accept interface=all signal-range=-80..120
add action=reject interface=all signal-range=-120..-81

Mikrotik Hotspot Authentication for IPv6 dual-stacked clients

 

In preparation for some IPv6 testing of our hotspot systems, I’ve come up with the following temporary authentication method for dual-stacked users.

 

Seeing as the login redirect goes via an IPv4 webserver, if enabled IPv6 traffic passes by the hotspot unhindered. This is my work on enabling the IPv6 side of things when a user logs in or out of the hotspot with a dual stacked client.

 

This has been implemented on my demo v4.10 router and tested with both Mac OS X 10.6 and Windows 7 Ultimate x64

 

!!Please note this is an Alpha release an as such is not  recommended to be used on any production routers!!

 

Prerequisites

 

1. An IPv6 (public) address must be assigned to the hotspot interface

 

2. IPv6 transit must be working (can you reach ipv6 sites on the internet? try pinging 2404:6800:8004::68 aka ipv6.google.com … from Australia anyway)

 

3. ND (neighbour discovery) helps to be setup on the specific interface with the following options enabled:

 

1
reachable-time=30s retransmit-interval=1s managed-address-configuration=yes advertise-dns=yes

 

Admin note: as I’m not familiar with the reachable-time and retrans-time values I’ve copied default Cisco values, if anyone wants to correct me on this go ahead ^_^

 

Register to read more...

Improved Load Balancing over Multiple Gateways

Quick Start for Impatient

Configuration export from the gateway router:

/ ip address 
add address=1.1.1.50/24 network=1.1.1.0 broadcast=1.1.1.255 interface=Local comment="" \
disabled=no 
add address=10.111.0.2/24 network=10.111.0.0 broadcast=10.111.0.255 interface=wlan2 \
comment="" disabled=no 
add address=10.112.0.2/24 network=10.112.0.0 broadcast=10.112.0.255 interface=wlan1 \
comment="" disabled=no
/ ip firewall mangle
add chain=prerouting in-interface=Local connection-state=new nth=1,1,0 \
action=mark-connection new-connection-mark=odd passthrough=yes comment="" \
disabled=no 
add chain=prerouting in-interface=Local connection-mark=odd action=mark-routing \
new-routing-mark=odd passthrough=no comment="" disabled=no 
add chain=prerouting in-interface=Local connection-state=new nth=1,1,1 \
action=mark-connection new-connection-mark=even passthrough=yes comment="" \
disabled=no 
add chain=prerouting in-interface=Local connection-mark=even action=mark-routing \
new-routing-mark=even passthrough=no comment="" disabled=no 
/ ip firewall nat 
add chain=srcnat connection-mark=odd action=src-nat to-addresses=10.111.0.2 \
to-ports=0-65535 comment="" disabled=no 
add chain=srcnat connection-mark=even action=src-nat to-addresses=10.112.0.2 \
to-ports=0-65535 comment="" disabled=no 
/ ip route 
add dst-address=0.0.0.0/0 gateway=10.111.0.1 scope=255 target-scope=10 routing-mark=odd \
comment="" disabled=no 
add dst-address=0.0.0.0/0 gateway=10.112.0.1 scope=255 target-scope=10 routing-mark=even \
comment="" disabled=no 
add dst-address=0.0.0.0/0 gateway=10.112.0.1 scope=255 target-scope=10 comment="" \
disabled=no

Explanation

First we give a code snippet and then explain what it actually does.

Mangle

/ ip address 
add address=1.1.1.50/24 network=1.1.1.0 broadcast=1.1.1.255 interface=Local comment="" \
disabled=no 
add address=10.111.0.2/24 network=10.111.0.0 broadcast=10.111.0.255 interface=wlan2 \
comment="" disabled=no 
add address=10.112.0.2/24 network=10.112.0.0 broadcast=10.112.0.255 interface=wlan1 \
comment="" disabled=no

The router has two upstream (WAN) interfaces with the addresses of 10.111.0.2/24 and 10.112.0.2/24. The LAN interface has the name "Local" and IP address of 1.1.1.50/24.

/ ip firewall mangle
add chain=prerouting in-interface=Local connection-state=new nth=1,1,0 \
action=mark-connection new-connection-mark=odd passthrough=yes comment="" \
disabled=no 

First we take every second packet that establishes new session (note connection-state=new), and mark it with connection mark "odd". Consequently all successive packets belonging to the same session will carry the connection mark "odd". Note that we are passing these packets to the second rule (passthrough=yes) to place a routing mark on these packets in addition to the connection mark.

add chain=prerouting in-interface=Local connection-mark=odd action=mark-routing \
new-routing-mark=odd passthrough=no comment="" disabled=no 

The rule above places the routing mark "odd" on all packets that belong to the "odd" connection and stops processing all other mangle in prerouting chain rules for these packets.

add chain=prerouting in-interface=Local connection-state=new nth=1,1,1 \
action=mark-connection new-connection-mark=even passthrough=yes comment="" \
disabled=no 
add chain=prerouting in-interface=Local connection-mark=even action=mark-routing \
new-routing-mark=even passthrough=no comment="" disabled=no 

These rules do the same for the remaining half of the traffic as the first two rules for the first half of the traffic.

The code above effectively means that each new connection initiated through the router from the local network will be marked as either "odd" or "even" with both routing and connection marks.

NAT

/ ip firewall nat 
add chain=srcnat connection-mark=odd action=src-nat to-addresses=10.111.0.2 \
to-ports=0-65535 comment="" disabled=no 
add chain=srcnat connection-mark=even action=src-nat to-addresses=10.112.0.2 \
to-ports=0-65535 comment="" disabled=no 

All traffic marked "odd" is being NATted to source IP address of 10.111.0.2, while traffic marked "even" gets "10.112.0.2" source IP address.

Routing

/ ip route 
add dst-address=0.0.0.0/0 gateway=10.111.0.1 scope=255 target-scope=10 routing-mark=odd \
comment="" disabled=no 
add dst-address=0.0.0.0/0 gateway=10.112.0.1 scope=255 target-scope=10 routing-mark=even \
comment="" disabled=no 
add dst-address=0.0.0.0/0 gateway=10.112.0.1 scope=255 target-scope=10 comment="" \
disabled=no comment="gateway for the router itself"

For all traffic marked "odd" (consequently having 10.111.0.2 translated source address) we use 10.111.0.1 gateway. In the same manner all traffic marked "even" is routed through the 10.112.0.1 gateway. Finally, we have one additional entry specifying that traffic from the router itself (the traffic without any routing marks) should go to 10.112.0.1 gateway.