WEBVTT

00:00.830 --> 00:02.490
Hello and welcome back.

00:02.780 --> 00:05.960
In this lecture, we'll dive into stateful firewall's.

00:07.450 --> 00:13.810
Net filter has a molecule called contract that permits us to inspect and restrict network connections

00:13.960 --> 00:16.720
using a method called connection tracking.

00:17.140 --> 00:24.670
Connection tracking refers to the ability of maintaining state information about the connection in memory

00:24.670 --> 00:25.300
Tabors.

00:25.960 --> 00:34.270
Firewalls that do this are known as stateful and are much more secure than they are stateless or packet

00:34.270 --> 00:35.500
based counterpart.

00:37.060 --> 00:44.680
The decision to drop or to accept al-Bakhit is not taken anymore based on the values in the packet headers

00:44.860 --> 00:52.250
like source or destination IP addresses or ports, but on the relationships it has with other Bishkek's.

00:53.860 --> 01:01.360
For a packet, there are the following states defined a new packet is the first packet of any connection.

01:02.200 --> 01:09.550
In fact, the packet requesting a new connection, such as a Tsipi packet with the SEAL Flex set or

01:09.550 --> 01:12.220
the first ICMP echo request packet.

01:13.370 --> 01:22.010
Back in the established state are those that are already part of an existing connection, all because

01:22.010 --> 01:29.450
of the connection starting with the second packet and until the last one are in the established state,

01:30.050 --> 01:37.820
related packets are those that are requesting a new connection but are already part of an existing connection,

01:38.060 --> 01:42.270
such as FTP data transfer or an ISP error.

01:42.980 --> 01:46.720
In general, it's good practice to accept these packets.

01:47.780 --> 01:55.640
An invalid packet is not part of any connection in the connection tracking table, these packets cannot

01:55.640 --> 01:57.990
be identified in any state.

01:58.720 --> 02:03.140
Generally, it is a good idea to drop everything in this state.

02:03.530 --> 02:08.540
In the last state is called untracked index and not so often used.

02:09.440 --> 02:17.240
Briefly, if a packet is marked within the right table with the no track target, then that packet will

02:17.240 --> 02:20.000
show up is entr'acte in the state machine?

02:22.200 --> 02:29.130
Note that you can use the stateful functionality of IP tables, connection tracking with any network

02:29.130 --> 02:35.520
protocol, even though the protocol itself is stateless, such as UDP or ICMP.

02:37.430 --> 02:45.980
To make Bishkek's based on their state use, minus M state, minus minus state, and then a comma separated

02:45.980 --> 02:50.720
values of Bishkek's states written in uppercase letters.

02:51.440 --> 02:59.150
In this example, we are accepting incoming Bishkek's if they are already part of an existing Conexion.

03:00.610 --> 03:07.570
Another rule or the policy of the input chain could drop the first packet of the connection, which

03:07.570 --> 03:08.590
is in the new state.

03:09.010 --> 03:16.360
This means that the host can connect to any destination using any protocol, but no one is allowed to

03:16.360 --> 03:19.300
connect to services running on the host.

03:20.780 --> 03:28.160
This was just an introduction to stateful fireballs in the next lecture will see a real example of how

03:28.160 --> 03:31.820
to configure a stateful firewall using IP tables.