RELATED,ESTABLISHED -> ESTABLISHED linux kernel hardening

[adrelanos]

grep -r RELATED

qubes-core-agent-linux/network/iptables:-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
qubes-core-agent-linux/network/iptables:-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
qubes-app-linux-tor/start_tor_proxy.sh:    /sbin/iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
qubes-core-admin/core-modules/006QubesProxyVm.py:        iptables += "-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED " \
qubes-core-admin/core-modules/006QubesProxyVm.py:        iptables += "-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED " \

Is the RELATED really needed?

Source of inspiration:
[Tails-dev] Reducing attack surface of kernel and tightening firewall/sysctls
https://www.mail-archive.com/tails-dev@boum.org/msg07483.html
http://comments.gmane.org/gmane.linux.distributions.tails.devel/10264

(Was done in Whonix long time ago and did not cause any issues. - https://phabricator.whonix.org/T28)

[Zrubi]

man iptables-extensions

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.

So removing those are not a good idea in general. Only if you (the user) are fully aware of the consequences. I would recommend to not remove them by default.

[Zrubi]

man iptables-extensions

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.

So removing those are not a good idea in general. Only if you (the user) are fully aware of the consequences. I would recommend to not remove them by default.

[marmarek]

But disabling/not loading complex parsers (like ftp or others) into kernel is a good thing.
I'm wondering what would be useful here - ICMP is somehow useful (ease debugging of network issues, required for traceroute etc). Anything else?

[marmarek]

But disabling/not loading complex parsers (like ftp or others) into kernel is a good thing.
I'm wondering what would be useful here - ICMP is somehow useful (ease debugging of network issues, required for traceroute etc). Anything else?

[Zrubi]

On 05/07/2016 12:39 AM, Marek Marczykowski-Górecki wrote:

But disabling/not loading complex parsers (like ftp or others) into
kernel is a good thing.

Yes, until the user do not want to use FTP at all.
Not sure about UDP protocols but I guess they not even work without
allowing RELATED packages.

I'm wondering what would be useful here - ICMP is somehow useful (ease
debugging of network issues, required for traceroute etc). Anything else?

ICMP is not only for debugging but for general networking

ICMP net/host unreachable, admin prohibited, etc.

and if you drop/not allow "ICMP Fragmentation Needed" packets you
probably will face mysterious network errors.

But let's turn it around:
What harm can be used by allowing RELATED packages???

As I see this thing is just the same when some ppl think that
dropping/not allowing udp 67/68 will stop dhcp. While dhcp actually
using raw sockets. So they are not affected by the packetfilter at all.

Zrubi

[Zrubi]

On 05/07/2016 12:39 AM, Marek Marczykowski-Górecki wrote:

But disabling/not loading complex parsers (like ftp or others) into
kernel is a good thing.

Yes, until the user do not want to use FTP at all.
Not sure about UDP protocols but I guess they not even work without
allowing RELATED packages.

I'm wondering what would be useful here - ICMP is somehow useful (ease
debugging of network issues, required for traceroute etc). Anything else?

ICMP is not only for debugging but for general networking

ICMP net/host unreachable, admin prohibited, etc.

and if you drop/not allow "ICMP Fragmentation Needed" packets you
probably will face mysterious network errors.

But let's turn it around:
What harm can be used by allowing RELATED packages???

As I see this thing is just the same when some ppl think that
dropping/not allowing udp 67/68 will stop dhcp. While dhcp actually
using raw sockets. So they are not affected by the packetfilter at all.

Zrubi

[marmarek]

On Fri, May 06, 2016 at 11:20:56PM -0700, Zrubi wrote:

But let's turn it around:
What harm can be used by allowing RELATED packages???

As I see this thing is just the same when some ppl think that
dropping/not allowing udp 67/68 will stop dhcp. While dhcp actually
using raw sockets. So they are not affected by the packetfilter at all.

It's about avoiding parsing every packet payload by miscellaneous kernel
modules:

• nf_conntrack_amanda.ko
• nf_conntrack_broadcast.ko
• nf_conntrack_ftp.ko
• nf_conntrack_h323.ko
• nf_conntrack_irc.ko
• nf_conntrack_netbios_ns.ko
• nf_conntrack_netlink.ko
• nf_conntrack_pptp.ko
• nf_conntrack_proto_dccp.ko
• nf_conntrack_proto_gre.ko
• nf_conntrack_proto_sctp.ko
• nf_conntrack_proto_udplite.ko
• nf_conntrack_sane.ko
• nf_conntrack_sip.ko
• nf_conntrack_snmp.ko
• nf_conntrack_tftp.ko

But blacklisting those modules should be equally good for this purpose.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

On Fri, May 06, 2016 at 11:20:56PM -0700, Zrubi wrote:

But let's turn it around:
What harm can be used by allowing RELATED packages???

As I see this thing is just the same when some ppl think that
dropping/not allowing udp 67/68 will stop dhcp. While dhcp actually
using raw sockets. So they are not affected by the packetfilter at all.

It's about avoiding parsing every packet payload by miscellaneous kernel
modules:

• nf_conntrack_amanda.ko
• nf_conntrack_broadcast.ko
• nf_conntrack_ftp.ko
• nf_conntrack_h323.ko
• nf_conntrack_irc.ko
• nf_conntrack_netbios_ns.ko
• nf_conntrack_netlink.ko
• nf_conntrack_pptp.ko
• nf_conntrack_proto_dccp.ko
• nf_conntrack_proto_gre.ko
• nf_conntrack_proto_sctp.ko
• nf_conntrack_proto_udplite.ko
• nf_conntrack_sane.ko
• nf_conntrack_sip.ko
• nf_conntrack_snmp.ko
• nf_conntrack_tftp.ko

But blacklisting those modules should be equally good for this purpose.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Zrubi]

On 05/07/2016 09:01 AM, Marek Marczykowski-Górecki wrote:

It's about avoiding parsing every packet payload by miscellaneous kernel
modules:

• nf_conntrack_amanda.ko
• nf_conntrack_broadcast.ko
• nf_conntrack_ftp.ko
• nf_conntrack_h323.ko
• nf_conntrack_irc.ko
• nf_conntrack_netbios_ns.ko
• nf_conntrack_netlink.ko
• nf_conntrack_pptp.ko
• nf_conntrack_proto_dccp.ko
• nf_conntrack_proto_gre.ko
• nf_conntrack_proto_sctp.ko
• nf_conntrack_proto_udplite.ko
• nf_conntrack_sane.ko
• nf_conntrack_sip.ko
• nf_conntrack_snmp.ko
• nf_conntrack_tftp.ko

But blacklisting those modules should be equally good for this purpose.

Well I see.
However not every packets are parsed thanks to the conntrack in general.
But that's sounds more like a good direction for me anyway :)

Just do not forget to write a big fat warning that those blacklisted
protocols will not work by default.

Zrubi

[Zrubi]

On 05/07/2016 09:01 AM, Marek Marczykowski-Górecki wrote:

It's about avoiding parsing every packet payload by miscellaneous kernel
modules:

• nf_conntrack_amanda.ko
• nf_conntrack_broadcast.ko
• nf_conntrack_ftp.ko
• nf_conntrack_h323.ko
• nf_conntrack_irc.ko
• nf_conntrack_netbios_ns.ko
• nf_conntrack_netlink.ko
• nf_conntrack_pptp.ko
• nf_conntrack_proto_dccp.ko
• nf_conntrack_proto_gre.ko
• nf_conntrack_proto_sctp.ko
• nf_conntrack_proto_udplite.ko
• nf_conntrack_sane.ko
• nf_conntrack_sip.ko
• nf_conntrack_snmp.ko
• nf_conntrack_tftp.ko

But blacklisting those modules should be equally good for this purpose.

Well I see.
However not every packets are parsed thanks to the conntrack in general.
But that's sounds more like a good direction for me anyway :)

Just do not forget to write a big fat warning that those blacklisted
protocols will not work by default.

Zrubi