Is -m conntrack --ctstate NEW,ESTABLISHED necessary?

I have this rule and it allows connection on three ports:

iptables -A INPUT -p tcp -m multiport --dports 22,80,443 -j ACCEPT

Then on internet I see examples including

-m conntrack --ctstate NEW,ESTABLISHED

I have then changed my current rule to:

iptables -A INPUT -p tcp -m multiport --dports 22,80,443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

I have read online about connection state but was wondering if -m conntrack --ctstate NEW,ESTABLISHED is necessary since it does its job without including it?

I was also wondering why some iptables drop OUTPUT like this?

iptables -P OUTPUT DROP

I keep it ACCEPT for OUTPUT while doing DROP to INPUT and FORWARD.

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

When I DROP output I can't get updates and can't download stuff from curl etc. Should I drop OUTPUT as well? What do you think?

This is essentially explained in the other answer, but I think another explanation still worth it.

In your setup, you often only explicitly enable some selected ports for known services, and for the rest you have -P INPUT DROP. But when computer itself creates some outgoing connections, it uses a random source port. Replies will be with that port as a destination. Do you have the explicit rule that will permit these replies? I guess no, because you don't even know in advance the source port it will use. So replies will be dropped and your server will be unable to establish any connections. For example, the DNS resolution will break.

When you use connection tracker, Linux observes the ports and addresses used in each your outgoing packet. It has special state table (viewable as /proc/net/nf_conntrack); it adds the record into that table, stating that it expects the packet with the addresses and ports reversed, as it will be in the reply. When such a packet arrives, it sets a flag on the packet, that is belongs to some "known" connection. Then, the -m conntrack --ctstate ESTABLISHED in the firewall uses that flag and it will match any of those "known" packets. This way, you can match precisely replies to your outgoing packets, without even knowing in advance what they are, at the expense of maintaining the state.

The RELATED is a related concept (pun intended); some protocols don't just answer the former connection, but also may create totally new connection, which better be enabled too. The examples of such protocols are FTP and SIP. With just the ESTABLISHED, those new connections will be rejected. But Linux has helpers for its connection tracker, which inspect the first connection more deeply and infer the properties of the additional connection from it; then the helper may install additional expect records into the state table, and sets another flag that corresponds to the --ctstate RELATED when packets of such a connection actually appear. So RELATED basically permits those tricky protocols to work.

As for dropping OUTPUT, it is for preventing the machine from misbehaving. With -P OUTPUT DROP and some explicit permitting rules you establish the tight policy where this server can actually connect, and this might be good for security. You might want to enable just DNS servers, time sync servers, some repo for updates, monitoring, backup servers and a few others. Now, for example, if the server gets intruded and infected with some botnet agent, that agent will not be able to connect to its control servers (unless it gains root privileges and removes the obstruction, which is not always the case).

Even if you don't want to forbid the whole OUTPUT, chances are your server must not send any mail directly, so it's worth to forbid it: -A OUTPUT -p tcp --dport 25 -j REJECT. This will not disable it to send mail through typical SMTP authenticated service, because it often uses ports 587 or 465; also if that's not the case, you can always add another rule above that allows the sending packets to the smarthost's port 25. That way, at least it won't be sending spam (that easily).

Simplified the Linux netfilter firewall "iptables" can operate in in two modes.

1. Mode one is as a simple packet filter.

That means that you create a bunch of rules in a specific order and every packet is checked against the full rule base, one rule after another until it triggers a rule that provides a dispositive match and the fate of that individual packet is determined.

Depending on your configuration that might result in packets needing to traverse dozens or more rules until they're allowed or rejected.

Once the packet reaches the last rule in your chain, and their fate still remains undecided, the policy of the chain is applied. (In most firewall configuration that scenario never happens because it is customary to set an explicit firewall rule accepting/rejecting/dropping all traffic that wasn't matched by the earlier rules, rather than relying on the policy.)

2. Mode two is a stateful firewall.

In a stateful firewall connections are tracked. That requires that some additional kernel modules are loaded and then the Linux kernel will (in memory) keep a connection state lookup table.

The assumption is that for most systems the majority of traffic, most packets, will belong to an existing connection.

Rather than checking the complete firewall rule base, in a stateful firewall only one check is needed for most packets: if the packet belongs to an existing connection, then it is allowed.
Done.
No more checks needed.

In a stateful firewall thus the first rule is something like

 # iptables-save
 -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
 ...

Only packets that don't belong to an existing connection require further evaluation. The subsequent rules then determine if the packet belongs to a connection that should be allowed or not.

The first rule:

 iptables -A INPUT -p tcp -m multiport --dports 22,80,443 -j ACCEPT

does not refer to the connection state and is the syntax that is valid for both a simple packet filter and a stateful firewall. It completely ignores any potential connection state information and simply allows any and all packets to TCP ports 22, 80 and 443.

The second rule:

 iptables -A INPUT -p tcp -m multiport --dports 22,80,443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT 

is only valid for a stateful firewall where connection tracking is enabled.

In a stateful firewall, both rules usually have the same end-result, a packet to either port 22, 80 or 443 is accepted and the firewall will allow connections to be established.

But the second rule is more precise, only packets with specific connection states are allowed and packets with for example a state "INVALID" or something else, will still be rejected.

States for --ctstate:

INVALID The packet is associated with no known connection.

NEW The packet has started a new connection or otherwise associated with a connection which has not seen packets in both directions.

ESTABLISHED The packet is associated with a connection which has seen packets in both directions.

RELATED The packet is starting a new connection, but is associated with an existing connection, such as an FTP data transfer or an ICMP error.

UNTRACKED
The packet is not tracked at all, which happens if you explicitly untrack it by using -j CT --notrack in the raw table.

SNAT
A virtual state, matching if the original source address differs from the reply destination.

DNAT
A virtual state, matching if the original destination differs from the reply source.