Firewall

Module 6

2013-01-01

Firewall Principles

2013-01-01

Firewall principles
A Firewall is a service that allows or
blocks data packets going to or through
it based on user-defined rules.
The firewall acts as a barrier between
two networks.
A common example is your LAN
(trusted) and the Internet (not trusted).

2013-01-01

Firewall principles
How the firewall works

The firewall operates using rules. These have two parts

The matcher : The conditions that I need to have a match

The Action : What I'll do once I have a match

The matcher looks at parameters such as :

Source MAC address

IP addresses (network or list) and address types (broadcast, local, multicast,

unicast)

Port or port range

Protocol

Protocol options (ICMP type and code fields, TCP flags, IP options)

Interface the packet arrives from or leaves through

DSCP byte

2013-01-01

And more

Packet flows
MikroTik created the packet flow
diagrams to help us in the creation of
more advanced configurations
It's good to be familiar with them to
know what's happening with packets
and in which order
For this course, we'll keep it simple

2013-01-01

Packet flows
Overall diagrams

2013-01-01

Packet flows

2013-01-01

Packet flows

2013-01-01

Packet flows, example

Complicated? Welcome to the club!
This next example might help to
illustrate a simple flow of packets :
Pinging a (non-existent node) on a
router's LAN interface through it's WAN
interface

2013-01-01

IP of node doing the pinging : 172.16.2.100

IP of node being pinged : 192.168.3.2
IP of router's WAN (ether1) : 192.168.0.3
9

Packet flows, example

Ping in
===PREROUTING===
Mangle-prerouting prerouting: in:ether1 out:(none), src-mac d4:ca:6d:33:b5:ef, proto ICMP (type 8, code 0),
172.16.2.100->192.168.3.2, len 60
dstnat dstnat: in:ether1 out:(none), src-mac d4:ca:6d:33:b5:ef, proto ICMP (type 8, code 0), 172.16.2.100>192.168.3.2, len 60
===FORWARD===
Mangle-forward forward: in:ether1 out:Bridge-PC, src-mac d4:ca:6d:33:b5:ef, proto ICMP (type 8, code 0),
172.16.2.100->192.168.3.2, len 60
Filter-forward forward: in:ether1 out:Bridge-PC, src-mac d4:ca:6d:33:b5:ef, proto ICMP (type 8, code 0),
172.16.2.100->192.168.3.2, len 60
===POSTROUTING===
Mangle-postrouting postrouting: in:(none) out:Bridge-PC, src-mac d4:ca:6d:33:b5:ef, proto ICMP (type 8, code 0),
172.16.2.100->192.168.3.2, len 60
srcnat srcnat: in:(none) out:Bridge-PC, src-mac d4:ca:6d:33:b5:ef, proto ICMP (type 8, code 0), 172.16.2.100>192.168.3.2, len 60

Reply out
===OUTPUT===
Mangle-output output: in:(none) out:ether1, proto ICMP (type 3, code 1), 192.168.0.3->172.16.2.100, len 88
Filter-output output: in:(none) out:ether1, proto ICMP (type 3, code 1), 192.168.0.3->172.16.2.100, len 88
===POSTROUTING===
Mangle-postrouting postrouting: in:(none) out:ether1, proto ICMP (type 3, code 1), 192.168.0.3->172.16.2.100, len 88

2013-01-01

10

Packet flows, example explained

/ip firewall filter
add action=log chain=input log-prefix=Filter-input protocol=icmp
add action=log chain=output log-prefix=Filter-output protocol=icmp
add action=log chain=forward log-prefix=Filter-forward protocol=icmp
/ip firewall mangle
add action=log chain=prerouting log-prefix=Mangle-prerouting protocol=icmp
add action=log chain=output log-prefix=Mangle-output protocol=icmp
add action=log chain=input log-prefix=Mangle-input protocol=icmp
add action=log chain=forward log-prefix=Mangle-forward protocol=icmp
add action=log chain=postrouting log-prefix=Mangle-postrouting protocol=icmp
/ip firewall nat
add action=log chain=srcnat log-prefix=srcnat protocol=icmp
add action=log chain=dstnat log-prefix=dstnat protocol=icmp
2013-01-01

11

Connection tracking and states

Connection tracking manages information about all
active connections.
Before creating your firewall filters (or rules), it's good
to know what kind of traffic goes through your router.
Connection tracking show you just that.
Flags: S - seen reply, A - assured
#
PROTOCOL SRC-ADDRESS
0 SA tcp
172.16.2.140:52010
1
ospf
172.16.0.6
2 SA tcp
172.16.2.100:49164
3 SA tcp
172.16.2.122:61739
4 SA tcp
172.16.2.130:58171
5 SA gre
172.16.0.254
6 SA udp
172.16.0.254:4569
7 SA tcp
172.16.2.130:58174
8 SA tcp
172.16.2.140:52032
9 SA tcp
172.16.2.107:47318
10 SA tcp
172.16.2.102:57632
11
ospf
172.16.0.5
12 SA tcp
172.16.2.102:56774
13 SA tcp
172.16.2.102:56960
14 SA tcp
172.16.0.254:37467
15 SA tcp
172.16.2.107:39374

2013-01-01

DST-ADDRESS
17.172.232.126:5223
224.0.0.5
172.16.9.254:445
206.53.159.211:443
17.149.36.108:443
172.16.0.1
209.217.98.158:4569
173.252.103.16:443
69.171.235.48:443
173.252.79.23:443
173.252.102.241:443
224.0.0.5
65.54.167.16:12350
173.194.76.125:5222
172.16.0.1:1723
79.125.114.47:5223

TCP-STATE
TIMEOUT
established 23h42m6s
5m49s
established 23h42m51s
established 23h44m8s
established 23h43m41s
4h44m11s
13m9s
established 23h42m40s
established 23h43m27s
established 23h43m26s
established 23h44m15s
5m49s
established 23h35m28s
established 23h43m57s
established 4h44m11s
established 23h29m1s

12

Connection tracking and states

Should you disable tracking for any reason, the
following features will not work:

NAT
Firewall

connection-bytes
connection-type
connection-limit
layer7-protocol p2p
new-connection-mark

connection-mark
connection-state
connection-rate
tarpit

p2p matching in simple queues

Before disabling connection tracking, be certain of

the goal that you want to achieve!
2013-01-01

13

Connection tracking and states

Connection states are

(assuming client-A is initiating a connection to client-B):

Established

A TCP session to the remote host is established, providing an

open connection where data can be exchanged
Time-wait
Time spent waiting to insure that remote host has received an
acknowledgment of his connection termination request (after
"close")
Close
Represents waiting for a connection termination request from
the remote
Syn-sent
Client-A is waiting for a matching connection request after
having sent one
Syn-received Client-B is waiting for a confirming connection request
acknowledgement after having both received and sent a
connection request
2013-01-01

14

Connection tracking and states

The use of connection tracking allows
tracking of UDP connections, even if
UDP is stateless. As such, MikroTik's
firewall can filter on UDP "states".
First packet will be "new", the rest can
be accepted as established if UDPtimeout value is not reached.

2013-01-01

15

Firewall connection states

New first packet of UDP, TCP syn
packet
Established The rest of UDP, the rest
of TCP
Related a connection created by
already existing connection
Invalid TCP packet without connection
tracking entry

Connection states - new

First packet that can establish
connection tracking entry
First TCP SYN packet
First UDP packet

Connection states - established

Packets from already knoewn connections
The rest of UDP communication, if packet rate
can keep entry from timeout
It is good idea to accept them

Connection states - realted

Connection that is created by other,
already established connection.
For example, TFP data connection is
created by FTP management connection.
It is essential to accepted them

Connection states - invalid

Any packet with unknown state
It is good idea to drop them

Structure : chains and actions

A chain is a grouping of rules based on the same criteria. There
are three default chains based on predefined criteria.

Input : Traffic going to the router

Forward : Traffic going through the router
Output : Traffic originating from the router

You can have user chains based on custom criteria. For example :

All icmp traffic

Traffic coming in from Ether2 and going to bridge interface "LAN

User defined chains are created by selecting the desired

matchers and choosing the jump action. You will give your
user-defined chain a name in the jump target field.

After that, you can start creating filter rules using the new chain by
inputting it in the Chain field of the new firewall filter.

2013-01-01

21

Structure : chains and actions

An action dictates what the filter will do when
packets are matched to it.
Packets are checked sequentially against existing
rules in the current firewall chain until a match
occurs. When it does, that rule is applied.
Know that certain actions may or may not require
that the packet be further processed.
Other actions may demand that the packet be
further processed in a different chain. We'll see
this in later pages.
2013-01-01

22

Firewall filters in action

2013-01-01

23

Basic security philosophy

You can approach security in various
ways

2013-01-01

We trust the inside, the rules will affect

what's coming from the outside
We block everything and permit that which
we agree upon
We permit everything and block that which
we know is problematic

24

Basic tips and tricks

Before configuring or changing rules,
activate "safe mode".
After configuring or changing rules, test
your rules using a tool like ShieldsUP
(https://www.grc.com/x/ne.dll?bh0bkyd2)
It'll give you a weaknesses report

2013-01-01

25

Basic tips and tricks

Before you begin, establish a policy.
Write down, in plain text, in your language, the basic
rules that you want.

Once you understand them and agree with them, input them
in the router.

Add other rules progressively, once you're satisfied with

the basic ones.

If you're new to security, it won't help you to shoot in all

directions. Do the basics, but do them well.
Just don't wait too long to add the following rules. It's one
thing to work well, but it's another to leave holes open
because you want to test the first rules out.

2013-01-01

26

Basic tips and tricks

It's a good idea to end your chains with the
"catch-all" rules and see what you may have
missed.
You'll need two "catch-all" rules, one to "log" and
one to "drop" unmatched traffic. Both must be
based on the same matchers to be helpful to you.
Once you see what reaches the "catch-all" rules,
you can add new rules based on the firewalls
desired behavior.
2013-01-01

27

Filter Matchers
Before taking "action" on a packet, it
must be identified.
Matchers are many!

2013-01-01

28

Filter actions
Once a packet has been matched to a rule, an action will
be applied to it.
MikroTik's firewall filters have 10 actions.
Accept

Accept the packet. Packet is not passed to next firewall rule.

Add-dst-to-address-list

Add destination address to address list specified by address-list parameter. Packet is passed to next firewall
rule.

Add-src-to-address-list

Add source address to address list specified by address-list parameter. Packet is passed to next firewall rule.

Drop

Silently drop the packet. Packet is not passed to next firewall rule.

Jump

Jump to the user defined chain specified by the value of jump-target parameter. Packet is passed to next
firewall rule (in the user-defined chain).

Log

Add a message to the system log containing following data: in-interface, out-interface, src-mac, protocol,
src-ip:port->dst-ip:port and length of the packet. Packet is passed to next firewall rule.

Passthrough

Ignore this rule and go to next one (useful for statistics).

Reject

Drop the packet and send an ICMP reject message. Packet is not passed to next firewall rule.

Return

Pass control back to the chain from where the jump took place. Packet is passed to next firewall rule (in
originating chain, if there was no previous match to stop packet analysis).

Tarpit

Capture and hold TCP connections (replies with SYN/ACK to the inbound TCP SYN packet). Packet is not
passed to next firewall rule.

2013-01-01

29

Protecting your router (input)

The input chain looks at traffic aimed at
the router.
The rules you add in the input chain
must prevent hackers from reaching the
router without stopping it from doing it's
job.

2013-01-01

30

Protecting your router (example)

The following are suggestions!

Assume that ether01 is connected to the WAN (untrusted
network) and we're using the "trust the inside" policy.

2013-01-01

Accept icmp echo replies (You may want to ping a server on the
Internet. It would be useful for you to get the replies!)
Drop icmp echo requests (You don't want others pinging you.
Stay under the radar!)
Accept all "established" and "related" input traffic (You'll want
the replies to whatever the router asked for, like NTP and DNS
requests)
Drop all "invalid" input traffic (Whatever the router gets that it
didn't ask for)
Log the rest of input traffic (Have I missed anything
important?)
Drop the rest of input traffic (I want to be safe!)

31

Protecting your customers (forward)

As stated before, the forward chain looks
at traffic going through the router.
The rules you add in the forward chain
must prevent hackers from reaching
your "safe" network without stopping
you from doing your job.

2013-01-01

32

Protecting your customers (example)

The following are suggestions!

Again, assume that ether01 is connected to the WAN
(untrusted network) and we're using the "trust the inside"
policy.

2013-01-01

Accept all "established" and "related" forward traffic (You'll

want the replies to whatever you asked for, like HTTP and Email requests)
Drop all "invalid" forward traffic (Whatever you get that you
didn't ask for)
Log the rest of forward traffic (Have I missed anything
important?)
Drop the rest of forward traffic (I want to be safe!)

33

What it looks like in the end

2013-01-01

34

Firewall filter syntax

View existing filter rules

/ip firewall filter print (produces a clearer, readable output)

/ip firewall filter export (shows complete syntax)

Create various rules (from /ip firewall filter)

add chain=input comment="Established-Related (in)" connectionstate=established in-interface=ether01

add chain=forward comment="Established-Related (fwd)" connectionstate=established in-interface=ether01
add action=log chain=input comment="===CATCH-ALL==" ininterface=ether01 log-prefix="CATCH-ALL(in)"
add action=drop chain=input in-interface=ether01
add action=add-dst-to-address-list address-list=temp-list address-listtimeout=3d1h1m1s chain=input protocol=tcp src-address=172.16.2.0/24

2013-01-01

35

Basic address-list

2013-01-01

36

Basic address-list
Address lists are groups of IP addresses
They can be used to simplify filter rules

For example, you could create 100 rules to block

100 addresses, or!!
You could create one group with those 100
addresses and create only one filter rule.

The groups (address lists) can represent

IT Admins with special rights

Hackers
Anything else you can think of

2013-01-01

37

Basic address-list
They can be used in firewall filters, mangle and
NAT facilities.
Creation of address lists can be automated by using
add-src-to-address-list or add-dst-to-addresslist actions in the firewall filter, mangle or NAT
facilities.

This is a great way of automatically blocking IP

addresses without having to enter them one by one
Example : add action=add-src-to-address-list addresslist=BLACKLIST chain=input comment=psd ininterface=ether1-Internet psd=21,3s,3,1

2013-01-01

38

Address list syntax

View existing address lists

/ip firewall address-list print

Create a permanent address list

/ip firewall address-list add address=1.2.3.4 list=hackers

Create an address list through a firewall filter rule

/ip firewall filter add action=add-dst-to-address-list addresslist=temp-list address-list-timeout=3d1h1m1s chain=input

protocol=tcp src-address=172.16.2.0/24
/ip firewall nat add action=add-src-to-address-list addresslist=NAT-AL chain=srcnat
/ip firewall mangle add action=add-dst-to-address-list addresslist=DST-AL address-list-timeout=10m chain=prerouting
protocol=tcp

2013-01-01

39

Source NAT

2013-01-01

40

NAT
Network Address Translation (NAT) allows
hosts to use one set of IP addresses on the LAN
side and an other set of IP addresses when
accessing external networks.
Source NAT translates private IP addresses (on
the LAN) to public IP addresses when accessing
the Internet. The reverse is done for return
traffic. It's sometimes referred to as "hiding"
your address space (your network) behind the
ISP supplied address.
2013-01-01

41

Masquerade and src-nat action

The first chain for NATing is "srcnat". It's used by traffic
leaving the router.
Much like firewall filters, NAT rules have many
properties and actions (13 actions!).
The first, and most basic of NAT rules, only uses the
"masquerade" action.
Masquerade replaces the source IP address in packets by
one determined by the routing facility.

Typically, the source IP address of packets going to the

Internet will be replaced by the address of the outside (WAN)
interface. This is required for return traffic to "find it's way
home".

2013-01-01

42

Masquerade and src-nat action

The "src-nat" action changes the source IP
address and port of packets to those
specified by the network administrator

2013-01-01

Usage example : Two companies (Alpha and

Beta) have merged and they both use the
same address space (ex. 172.16.0.0/16). They
will set up a segment using a totally different
address space as a buffer and both networks
will require src-nat and dst-nat rules.
43

Destination NAT

2013-01-01

44

Dst-nat and redirection action

"Dst-nat" is an action used with the
"dstnat" chain to redirect incoming
traffic to a different IP address or port

2013-01-01

Usage example : In our previous Alpha

and Beta example, we see that dst-nat
rules will be required to reconvert the
"buffer IP address" to Beta's server's
address.

45

Dst-nat and redirection action

"Redirect" changes the destination port
to the specified "to-ports" port of the
router.

2013-01-01

Usage example : All http (TCP, port 80)

traffic is to be sent to the web proxy service
at TCP port 8080.

46

NAT Syntax
Source NAT (from /ip firewall nat)

Add the masquerade rule

add action=masquerade chain=srcnat

Change the source IP address

add chain=srcnat src-address=192.168.0.109 action=src-nat toaddresses=10.5.8.200

Destination NAT

Redirect all web traffic (TCP, port 80) to the router's web proxy on port 8080

2013-01-01

add action=redirect chain=dstnat dst-port=80 protocol=tcp toports=8080

47

Time for a practical exercise

End of module 6

2013-01-01

48

Laboratory
Goals of the lab

2013-01-01

Setup basic firewall rules

Configure a basic address-list
Apply basic source NAT rules and test
them out
Apply basic destination NAT rules and test
them out

49

Laboratory : Setup

2013-01-01

50

Laboratory : step 1
Before going ahead with firewall rules, we'll test a NAT
rule : Masquerading

Look into your settings to see if you have a "masquerading"

NAT rule. Create one if you don't BUT leave it disabled. If
you have one make sure that it's disabled
Launch Winbox and connect to a neighbour pod.
In the IP FIREWALL CONNECTION section, look at active
connections. What do you see? Why?
Set the configuration option that will let you track
connections. Check the results.
Enable the masquerade NAT rule and check connection
tracking again.

2013-01-01

51

Laboratory : step 2
Let's make things more interesting by adding filter rules.
Apply the following rules to incoming traffic on your
WAN interface.

Accept icmp echo replies

Drop icmp echo requests
Accept all "established" and "related" input and forward traffic
Drop all "invalid" input and forward traffic
Log the rest of input and forward traffic
Drop the rest of input and forward traffic
Add meaningful comments to all rules.
Do the same for the "log" rules' prefixes.

2013-01-01

52

Laboratory : step 3
Now that you have rules, check your
logs. Look at the messages and their
format
Seeing what you see now, do you think
troubleshooting connection problems
would be easier? Why?

2013-01-01

53

Laboratory : step 4
Create Address Lists representing all
pods
Use the following format:

Name : Pod1
Address : <network/mask> of the LAN
Name : Pod1
Address : <IP> of the WAN interface

Do so for all pods, even your own

2013-01-01

54

Laboratory : step 5
Pods should be matched in pairs for the
following tests
Close your WinBox window and reopen it,
connecting to your peer pod. What's happening?
With one filter rule ONLY, allow all IP
addresses from you peer pod to connect to your
router with WinBox (TCP, 8291)

Make sure that it's in the right spot so that it works

And DON'T forget comments!

2013-01-01

55

Laboratory : step 6
To test port redirection, we'll need to
make a small change to the IP
SERVICES of your pod.

2013-01-01

In the IP Services section, change the

WinBox port to 8111.

56

Laboratory : step 7
Close and reopen the WinBox interface without
adding any special parameters. What result do
you get?
Log into the WinBox using port 8111.
Create a dst-nat rule with a redirect action to port
8111 on all TCP port 8291 traffic.
Close and reopen WinBox without the port after
the IP address. Does it work now?
Log into you peer pod's router. What's happening?
2013-01-01

57

Laboratory : step 8
Return the WinBox port to it's normal
value of 8291.
Disable (don't delete) the dstnat rule of
"redirect".
Close WinBox and validate that you can
log into your router and your peer's
router normally.

2013-01-01

58

Laboratory : step 9
Create a dst-nat rule with a redirect
action to port 8291 on all TCP port 1313
traffic coming into the WAN port.
Open WinBox and log into your router
using port 1313.
Open WinBox and log into your peer's
router using port 1313.
Explain the different results.
2013-01-01

59

Laboratory : step 10
Do an export AND a binary backup
under the file name module6-podx.

2013-01-01

60

End of Laboratory 6

2013-01-01

61