WEBVTT 00:01.690 --> 00:05.650 Hello, guys, in this video, I'll cover the lock target. 00:06.100 --> 00:13.330 We've seen a lot of terminating targets like accept, drop or reject will shift our focus to a commonly 00:13.330 --> 00:16.540 used non terminating target named Lock. 00:17.560 --> 00:24.840 If a packet is matched against a wall with the lock target, the packet headers are locked and then 00:24.850 --> 00:32.380 the packet continues to traverse the chain rules until it is accepted, dropped or rejected by a goal 00:32.380 --> 00:35.380 or by the default policy lock. 00:35.380 --> 00:41.550 Target is specially designed for logging detailed information about packet headers. 00:42.040 --> 00:45.730 It does this via the kernel logging facility. 00:47.250 --> 00:54.300 This information can then be read directly with the message or from the sea slug demon looks. 00:56.590 --> 01:03.100 Note as well that it could be a really great idea to use the lock target instead of drop while you are 01:03.100 --> 01:10.990 testing a rule and you are not 100 percent sure about it on a production final or a syntax error in 01:10.990 --> 01:15.670 the rule, six could cause severe connectivity problems for your users. 01:17.490 --> 01:25.280 The target takes two options that could be of interest, minus minus, minus level and minus minus and 01:25.470 --> 01:26.520 minus prefix. 01:27.670 --> 01:37.000 Low level indicates the priority or severity of the message and the prefix Baylis IP tables to prefix 01:37.000 --> 01:44.740 all log messages with a specific prefix or string, which can then be combined with the group to track 01:44.740 --> 01:48.170 specific problems and output from different rules. 01:50.210 --> 01:57.470 Let's see an example in our testing environment, I want to look and then drop the first bucket of any 01:57.470 --> 02:05.000 incoming SNH connection, the packet that establishes a new connection by initializing the DCP a three 02:05.000 --> 02:08.900 way handshake of the packet that has the same flag set. 02:11.400 --> 02:15.390 Table is minus eight in both minus P DCP. 02:16.860 --> 02:25.440 Minus minus deport 22, minus minus seven, that's the first packet of the connection, minus J lock 02:26.550 --> 02:34.890 and minus minus log, minus prefix equals between double quotes, incoming SSX traffic. 02:39.090 --> 02:44.190 And the other option, minus minus log, minus the level info. 02:45.860 --> 02:53.780 Lock target is a non terminating target, and that means that the Mixtepec, it continues to traverse 02:53.780 --> 02:54.380 the chain. 02:54.890 --> 03:02.810 My second rule will drop the packet IP table minus a inverter, minus BTP. 03:05.050 --> 03:13.720 Minus minus deport 22 minus J drop from Lenox to I'll try to connect using SSX to Linux one. 03:16.790 --> 03:24.260 The connection is not working because the packet that initializes the connection is locked and then 03:24.260 --> 03:24.710 dropped. 03:28.440 --> 03:33.260 On the firewall, I'll execute the message to see the colonel logs. 03:37.870 --> 03:39.940 These are the camel lagus. 03:43.180 --> 03:51.130 Among these logs, we noticed the logged packs, we see the log prefix, which is the string incoming 03:51.130 --> 03:52.420 SSX traffic. 03:53.880 --> 04:00.780 There are a lot of messages, so it could be a good idea to select only the messages we are interested 04:00.780 --> 04:04.920 in and we can do that by using a pipe and the grape comment. 04:06.010 --> 04:15.700 The message pipe group and I want to see only the lines that contain incoming SSX traffic, SSX traffic 04:15.730 --> 04:16.330 is enough. 04:18.840 --> 04:21.480 And we are seeing only of those rules. 04:23.060 --> 04:29.870 If I want, I can also direct these lines to a text file for later inspection. 04:32.370 --> 04:34.800 I'm using the output right direction. 04:36.330 --> 04:38.020 I said that the. 04:40.480 --> 04:42.970 And cut SSX that texte. 04:45.930 --> 04:47.700 We see the logs in the file. 04:49.490 --> 04:56.900 The message is only displaying a buffer in the RAM memory, if you want to see the logs after the computer 04:56.900 --> 05:04.670 restarts or at a later moment, you should read from a specific log file based on the Linux distribution 05:04.680 --> 05:05.450 you are using. 05:05.450 --> 05:13.780 The logs are saved in a specific file on your file system on Ubuntu, the kernel logs are saved in isolation. 05:14.630 --> 05:26.270 Log Cabin that look let's see the file using the tale comment detail minus f var log cabin that log. 05:27.560 --> 05:35.030 Minus F option means that it will display the tail of the file in real time as data is appended to the 05:35.030 --> 05:35.420 file. 05:37.130 --> 05:42.380 By the way, Dale is displaying the last 10 airlines by default. 05:49.980 --> 05:53.700 I'm connecting to Port 22 on Linux one again. 05:57.680 --> 06:02.690 And we noticed how the contents of the log file is updated in real time. 06:05.200 --> 06:12.490 Note that the lock target doesn't save the packet it contains, it only saves the packet headers. 06:13.030 --> 06:19.390 If you want to save the pack it contains, you should use a packet sniffer like DCP Dump or Wireshark.