Hello, guys, in this video, I'll cover the lock target.
We've seen a lot of terminating targets like accept, drop or reject will shift our focus to a commonly
used non terminating target named Lock.
If a packet is matched against a wall with the lock target, the packet headers are locked and then
the packet continues to traverse the chain rules until it is accepted, dropped or rejected by a goal
or by the default policy lock.
Target is specially designed for logging detailed information about packet headers.
It does this via the kernel logging facility.
This information can then be read directly with the message or from the sea slug demon looks.
Note as well that it could be a really great idea to use the lock target instead of drop while you are
testing a rule and you are not 100 percent sure about it on a production final or a syntax error in
the rule, six could cause severe connectivity problems for your users.
The target takes two options that could be of interest, minus minus, minus level and minus minus and
minus prefix.
Low level indicates the priority or severity of the message and the prefix Baylis IP tables to prefix
all log messages with a specific prefix or string, which can then be combined with the group to track
specific problems and output from different rules.
Let's see an example in our testing environment, I want to look and then drop the first bucket of any
incoming SNH connection, the packet that establishes a new connection by initializing the DCP a three
way handshake of the packet that has the same flag set.
Table is minus eight in both minus P DCP.
Minus minus deport 22, minus minus seven, that's the first packet of the connection, minus J lock
and minus minus log, minus prefix equals between double quotes, incoming SSX traffic.
And the other option, minus minus log, minus the level info.
Lock target is a non terminating target, and that means that the Mixtepec, it continues to traverse
the chain.
My second rule will drop the packet IP table minus a inverter, minus BTP.
Minus minus deport 22 minus J drop from Lenox to I'll try to connect using SSX to Linux one.
The connection is not working because the packet that initializes the connection is locked and then
dropped.
On the firewall, I'll execute the message to see the colonel logs.
These are the camel lagus.
Among these logs, we noticed the logged packs, we see the log prefix, which is the string incoming
SSX traffic.
There are a lot of messages, so it could be a good idea to select only the messages we are interested
in and we can do that by using a pipe and the grape comment.
The message pipe group and I want to see only the lines that contain incoming SSX traffic, SSX traffic
is enough.
And we are seeing only of those rules.
If I want, I can also direct these lines to a text file for later inspection.
I'm using the output right direction.
I said that the.
And cut SSX that texte.
We see the logs in the file.
The message is only displaying a buffer in the RAM memory, if you want to see the logs after the computer
restarts or at a later moment, you should read from a specific log file based on the Linux distribution
you are using.
The logs are saved in a specific file on your file system on Ubuntu, the kernel logs are saved in isolation.
Log Cabin that look let's see the file using the tale comment detail minus f var log cabin that log.
Minus F option means that it will display the tail of the file in real time as data is appended to the
file.
By the way, Dale is displaying the last 10 airlines by default.
I'm connecting to Port 22 on Linux one again.
And we noticed how the contents of the log file is updated in real time.
Note that the lock target doesn't save the packet it contains, it only saves the packet headers.
If you want to save the pack it contains, you should use a packet sniffer like DCP Dump or Wireshark.