Lab 06-04 · Firewall logging: the bouncer's notebook¶
MTCNA
Module 6 · Firewall of the MikroTik MTCNA course, official slides p258–260 (firewall logging, log prefixes, and the LAB "Registro de Firewall").
Monday morning, the club manager asks the bouncer: "Did anybody try to get into the office this weekend?" If the bouncer only shrugs, the manager learns nothing. If he kept a notebook with the time, the face and what each person wanted, the manager can spot the same troublemaker coming back every night.
Your router can keep that notebook. In this lab you switch on logging for the two WinBox rules from the previous lab, knock on the door as a guest and as a stranger, and read the notes: the time, the address, the port, and even a detail that gives away that the "stranger" was really your own laptop in disguise.
What you will learn
- Turn on logging for any firewall rule and give it a log prefix.
- Find firewall lines in the router's Log and filter them by prefix.
- Read a firewall log line: chain, interfaces, connection state, MAC, protocol, addresses and ports.
- Explain why logging a busy rule can flood the log.
- Use a log to answer "who tried to get in, when, and from where?".
What logging does¶
Logging makes a rule write a line in the router's log every time a packet matches it.
Slide 258: every firewall rule can be logged when it matches, and you can add a prefix, a short tag of your own, so you can find those lines later. In WinBox both options are on the rule's Action tab (Log checkbox and Log Prefix), slide 259.
Logging does not change what the rule does. An accept rule with logging still accepts; a drop rule still drops. The bouncer just writes it down as well.
A firewall log line looks like this (one line, split here for reading):
WINBOX-DENY input: in:bridge1 out:(unknown 0), connection-state:new
src-mac 02:00:00:00:00:C8, proto TCP (SYN), 192.168.88.199:36951->192.168.88.1:8291, len 60
| Part | Meaning |
|---|---|
WINBOX-DENY |
your prefix: which rule wrote this |
input: |
the chain |
in:bridge1 out:(unknown 0) |
arrived on bridge1; no output interface because it was for the router itself |
connection-state:new |
the first packet of a new conversation (you will study states in lab 06-08) |
src-mac 02:00:00:00:00:C8 |
the sender's MAC address, its network card's hardware address |
proto TCP (SYN) |
TCP, and the SYN flag: "hello, may I open a connection?" |
192.168.88.199:36951->192.168.88.1:8291 |
source address:port → destination address:port |
len 60 |
packet size in bytes |
Do not log everything
Every matching packet writes a line. Logging an accept rule for normal web traffic would write thousands of lines a minute, push the useful ones out of the log (RouterOS keeps the most recent lines in memory) and cost CPU. Log the rare, interesting events: denied attempts, admin logins.
The scenario¶
The router starts exactly where lab 06-03 ended: list allowed with your laptop, WinBox accepted from the
list and dropped for everybody else, plus the black-book rules for telnet.
On a real hAP the Internet port is ether1; in the virtual lab ether1 is reserved for the lab itself, so the Internet port is ether2 and the LAN ports start at ether3.
flowchart LR
PC1["<b>pc1</b> (your laptop)<br>192.168.88.200<br>+ stranger .199 for tests"] -- "LAN" --- R1["<b>r1</b> (your router = the club)<br>bridge1 = ether3: 192.168.88.1/24<br>WinBox 8291 guarded by list <i>allowed</i>"]
R1 -- "ether2 = WAN<br>10.0.0.x" --- AP["<b>class-ap</b><br>10.0.0.1"]
AP --- NET["<b>internet</b><br>198.51.100.10"]| Node | Role | Address |
|---|---|---|
pc1 |
your laptop; also plays the stranger | 192.168.88.200 (DHCP) and, temporarily, 192.168.88.199 |
r1 |
your router with the WinBox rules of lab 06-03 | LAN 192.168.88.1/24 · WAN ether2 10.0.0.x |
class-ap |
trainer's router | 10.0.0.1 |
internet |
"the Internet" | 198.51.100.10 |
As in lab 06-03, pc1 has the helper knock IP PORT [FROM-IP], which opens a TCP connection the way WinBox
does and prints OPEN or NO ANSWER.
Start the lab¶
Download the lab files and unzip them: 06-04-firewall-logging.zip. Open a terminal inside the 06-04-firewall-logging folder.
From the lab folder guions/tema-3/lab/mtcna/06-04-firewall-logging/:
After about two minutes:
ssh admin@clab-mtcna-06-04-r1 # the router (password: admin)
docker exec -it clab-mtcna-06-04-pc1 bash # the laptop
Step 1 · Check the starting rules¶
IP → Firewall → Filter Rules and IP → Firewall → Address Lists
You should see the four rules and the list from lab 06-03. Open the log too: Log in WinBox, or
Nothing from the firewall yet: the bouncer has no notebook.
Check yourself
Which of the four rules would you log first if you wanted to know who tries to sneak into WinBox? Why that one?
Done when: you can name which rule accepts WinBox and which one drops it.
Step 2 · Give both WinBox rules a notebook¶
Slide 260: enable logging on both rules of the address-list lab, with prefixes that tell them apart.
IP → Firewall → Filter Rules → double-click WinBox: only guests on the allowed list → Action tab →
tick Log, Log Prefix WINBOX-OK → OK. Then the same for WinBox: everybody else with Log Prefix WINBOX-DENY.
/ip firewall filter set [find comment="WinBox: only guests on the allowed list"] log=yes log-prefix="WINBOX-OK"
/ip firewall filter set [find comment="WinBox: everybody else"] log=yes log-prefix="WINBOX-DENY"
/ip firewall filter print
set [find comment="..."] changes the rule you find by its comment, so you do not need its number.
Check yourself
Logging is now on. Has the router started dropping or accepting anything differently? Explain.
Done when: both rules show log=yes and their prefix.
Step 3 · Visit as a guest¶
On pc1, connect to WinBox from your allowed address:
Expect several lines: the first with connection-state:new and (SYN), then a few established ones. The
accept rule matches every packet of your visit, so it writes a line for each.
Check yourself
One short visit produced several log lines. Imagine logging the accept rule while an admin uses WinBox for an hour. What would happen to your log?
Done when: you see WINBOX-OK lines with 192.168.88.200.
Step 4 · Visit as a stranger¶
Slide 260: change the laptop's IP to one not on the list and try again. On pc1:
ip addr add 192.168.88.199/24 dev eth1
knock 192.168.88.1 8291 192.168.88.199 # NO ANSWER
ip addr del 192.168.88.199/24 dev eth1 # back to normal
Log, or:
Expect around three WINBOX-DENY lines, all connection-state:new and (SYN), a second or two apart: the
stranger's laptop retried because it got no answer (drop is silent).
Check yourself
Look at the src-mac of a WINBOX-OK line and of a WINBOX-DENY line. What do you notice, and what
does it tell an investigator about the "stranger" .199?
Done when: you see WINBOX-DENY lines from 192.168.88.199 to port 8291.
Step 5 · Run the checker¶
From the lab folder on your PC:
It knocks as both addresses and looks for the new log lines. It must end with RESULT: lab 06-04 solved.
Check yourself
Name one real situation (school, company, home) where these log lines would help you, and what you would look for.
Done when: check.sh passes.
If something goes wrong¶
| Symptom | Likely cause | Fix |
|---|---|---|
| No firewall lines in the log | Log not ticked, or you set it on another rule | /ip firewall filter print and look for log=yes |
| Lines appear but without your prefix | Log Prefix left empty | set log-prefix= on the rule |
WINBOX-OK lines for .199 |
.199 is in list allowed |
remove it from the list |
No WINBOX-DENY lines, but .199 gets NO ANSWER |
.199 is in the black book (lab 06-03), so rule 0 drops it before the WinBox rules | /ip firewall address-list remove [find list=blocked] |
| The log is flooded | logging on a busy rule | set ... log=no on that rule |
Clean up¶
Key takeaways¶
- Logging makes a rule write a line every time it matches; it does not change the rule's action.
- Turn it on in the rule's Action tab (Log, Log Prefix), or with
log=yes log-prefix=.... - A log prefix tags the lines of one rule so you can filter them later (
/log print where message~"PREFIX"). - A log line shows chain, interfaces, connection state, MAC, protocol, addresses and ports.
- Log rare events such as denied attempts; logging busy rules floods the log.
Quick check¶
1. What happens to a packet that matches a drop rule with logging enabled?
- It is accepted, because logged rules only observe
- It is dropped and a line is written in the log
- It is logged and sent back to the sender
- It is logged only if it is the first packet
Logging is extra: the rule still does its action (drop) and also writes a log line.
2. What is a log prefix for?
- It encrypts the log line
- It decides which chain the rule belongs to
- It tags the log lines of a rule so you can find them later
- It limits how many lines the rule may write
The prefix is your own label at the start of each line written by that rule, e.g. WINBOX-DENY.
3. In WinBox, where do you enable logging for a rule?
- General tab
- Advanced tab
- Extra tab
- Action tab
The Log checkbox and the Log Prefix field are on the rule's Action tab (slide 259).
4. A log line contains proto TCP (SYN), 192.168.88.199:36951->192.168.88.1:8291. What was the sender trying to do?
- Open a new connection to WinBox on the router
- Send an email from the router
- Ask the router for a DNS answer
- Reply to a web page the router requested
SYN means "may I open a connection?", and 8291/tcp is WinBox. The destination 192.168.88.1 is the router.
5. Why is logging the accept rule for all web traffic a bad idea?
- Because accept rules cannot be logged
- Because every matching packet writes a line and floods the log
- Because it makes the rule drop the traffic
- Because logs are deleted after each line
Every packet that matches writes a line. Normal traffic matches constantly: the useful lines get pushed out and the router spends CPU writing.
6. The log shows WINBOX-DENY lines from 192.168.88.199 and WINBOX-OK lines from 192.168.88.200, both with the same src-mac. Which two conclusions are reasonable?
- Both attempts probably came from the same network card
- Two different laptops share one IP address
- Someone changed their IP address to test the rules
- The router's MAC address was spoofed
The MAC address belongs to the network card. Same MAC, two IPs: one device changed its IP, exactly what you did in step 4. Logs let you notice that kind of disguise.
So far the bouncer has decided who gets in. In 06-05 · Destination NAT: port forwarding he starts escorting visitors: someone knocks at the club's front door and he walks them to the right room inside.