project - mtcna m6 firewall en v1

7/23/2019 Project - Mtcna m6 Firewall en v1

1/59

Module 6

FIREWALL

TrainerVEACESLAV SAMBURSKI


2/59

Firewall Principles


3/59

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).


4/59

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 amatch

Firewall principles


5/59

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

And more

Firewall principles


6/59

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


7/59

Packet flows

Overall diagrams


8/59

Packet flows


9/59

Packet flows


10/59

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 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


11/59

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 60Filter-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


12/59

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


13/59

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 DST-ADDRESS TCP-STATE TIMEOUT

0 SA tcp 172.16.2.140:52010 17.172.232.126:5223 established 23h42m6s

1 ospf 172.16.0.6 224.0.0.5 5m49s




5 SA gre 172.16.0.254 172.16.0.1 4h44m11s6 SA udp 172.16.0.254:4569 209.217.98.158:4569 13m9s





11 ospf 172.16.0.5 224.0.0.5 5m49s






14/59


Should you disable tracking for any reason, the

following features will not work:

NAT

Firewall connection-bytes connection-mark

connection-type connection-state

connection-limit connection-rate

layer7-protocol p2p

new-connection-mark tarpit

p2p matching in simple queues

Before disabling connection tracking, be certain of the

goal that you want to achieve!


15/59


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

exchangedTime-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


16/59

The use of connection tracking allows

tracking of UDP connections, even if

UDP is stateless. As such, MikroTik'sfirewall can filter on UDP "states".



17/59

Structure : chains and actions

A chain is a grouping of rules based on

the same criteria. There are three

default chains based on predefinedcriteria.

Input : Traffic going to the router

Forward : Traffic going through the router

Output : Traffic originating from the router


18/59


You can have user chains based on custom criteria. For

example :

All icmp traffic

Traffic coming in from Ether2 and going to bridgeinterface "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.


19/59


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 matchoccurs. 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.


20/59

Firewall filters in action


21/59

Basic security philosophy

You can approach security in various

ways

We trust the inside, the rules will affectwhat's coming from the outside

We block everything and permit that which

we agree upon

We permit everything and block that whichwe know is problematic


22/59

Basic tips and tricks

Before configuring or changing rules,

activate "safe mode".

After configuring or changing rules, testyour rules using a tool like ShieldsUP(https://www.grc.com/x/ne.dll?bh0bkyd2)

It'll give you a weaknesses report


23/59

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, inputthem 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 alldirections. 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.



24/59


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.


25/59

Filter Matchers

Before taking "action" on a packet, it

must be identified.

Matchers are many!


26/59

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.


27/59

Protecting your router (input)

The input chain looks at traffic aimed at

the router.

The rules you add in the input chainmust prevent hackers from reaching the

router without stopping it from doing it's

job.


28/59

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.

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!)


29/59

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.


30/59

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. Accept all "established" and "related" forward traffic

(You'll want the replies to whatever you asked for, like

HTTP and E-mail 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!)


31/59

What it looks like in the end


32/59

Firewall filter syntax

View existing filter rules

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

/ip firewall filter export (shows completesyntax)


33/59

Create various rules (from /ip firewall filter)

add chain=input comment="Established-Related (in)" connection-

state=established in-interface=ether01

add chain=forward comment="Established-Related (fwd)"

connection-state=established in-interface=ether01

add action=log chain=input comment="===CATCH-ALL==" in-

interface=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-list-timeout=3d1h1m1s chain=input protocol=tcp src-

address=172.16.2.0/24

Firewall filter syntax


34/59

Basic address-list


35/59

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


36/59

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-address-listactions 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-listaddress-list=BLACKLIST chain=input

comment=psd in-interface=ether1-Internet

psd=21,3s,3,1

Basic address-list


37/59

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 address-

list=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 address-list=NAT-AL chain=srcnat

/ip firewall mangle add action=add-dst-to-address-list

address-list=DST-AL address-list-timeout=10m

chain=prerouting protocol=tcp


38/59

Source NAT


39/59

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.


40/59

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".


41/59

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

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 totallydifferent address space as a buffer and

both networks will require src-nat and dst-

nat rules.


42/59

Destination NAT


43/59

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

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'saddress.


44/59

"Redirect" changes the destination port

to the specified "to-ports" port of the

router.

Usage example : All http (TCP, port 80)

traffic is to be sent to the web proxy service

at TCP port 8080.

Dst-nat and redirection action


45/59

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 to-addresses=10.5.8.200

Destination NAT

Redirect all web traffic (TCP, port 80) to the

router's web proxy on port 8080

add action=redirect chain=dstnat dst-port=80

protocol=tcp to-ports=8080


46/59

Practical exercise


47/59

Laboratory

Goals of the lab

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


48/59

Laboratory : Setup


49/59

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 trackconnections. Check the results.

Enable the masquerade NAT rule and check connection

tracking again.

Laboratory: Step 1


50/59

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.

Laboratory: Step 2


51/59

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?

Laboratory: Step 3


52/59

Create Address Lists representing all

pods

Use the following format: Name : Pod1

Address : of the LAN

Name : Pod1

Address : of the WAN interface

Do so for all pods, even your own

Laboratory: Step 4


53/59

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!

Laboratory: Step 5


54/59

To test port redirection, we'll need to

make a small change to the IP

SERVICES of your pod.

In the IP Services section, change the

WinBox port to 8111.

Laboratory: Step 6


55/59

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 afterthe IP address. Does it work now?

Log into you peer pod's router. What's

happening?

Laboratory: Step 7


56/59

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'srouter normally.

Laboratory: Step 8


57/59

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.

Laboratory: Step 9


58/59

Do an export AND a binary backup

under the file name module6-podx.

Laboratory: Step 10


59/59

Thank you!

project - mtcna m6 firewall en v1

Documents