firewall block all new incoming traffic by default #1346

adrelanos · Oct 19, 2015

I noticed, Qubes replies to ping requests and so forth.

As a follow up task of #1344... Perhaps a "drop ICMP timestamps" ticket can be avoided by implementing this ticket.

Essentially something like this...

## Set secure defaults.
$iptables_cmd -P INPUT DROP

## Traffic on the loopback interface is accepted.
$iptables_cmd -A INPUT -i lo -j ACCEPT

## Established incoming connections are accepted.
$iptables_cmd -A INPUT -m state --state ESTABLISHED -j ACCEPT

## Reject anything not explicitly allowed above.
$iptables_cmd -A INPUT -j DROP

(+ same for ipv6)

Doing this in NetVM?
And also FirewallVM?
Or every VM?

Dropping ICMP at all would make diagnostic somehow harder (for example
checking if AppVM can reach NetVM). We have explicit "-p icmp -j ACCEPT"
rule for that. But maybe it would be better to change it to handle ICMP
only from downstream VMs ("-i vif+"), not the upstream (including the
outside world). What do you think?

Independently indeed it would be better to replace terminating rule "-j
REJECT --reject-with icmp-host-prohibited" with just "DROP".

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 · Oct 19, 2015

Dropping ICMP at all would make diagnostic somehow harder (for example
checking if AppVM can reach NetVM). We have explicit "-p icmp -j ACCEPT"
rule for that. But maybe it would be better to change it to handle ICMP
only from downstream VMs ("-i vif+"), not the upstream (including the
outside world). What do you think?

Independently indeed it would be better to replace terminating rule "-j
REJECT --reject-with icmp-host-prohibited" with just "DROP".

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?

Marek Marczykowski-Górecki:

Dropping ICMP at all would make diagnostic somehow harder (for example
checking if AppVM can reach NetVM).

Agreed. Makes diagnostic harder. Depends what weights more here. Ease of
debugging or difficult to quantity(?) security benefits.

I think for this reason fewer people technically understand Whonix,
since they cannot ping if they experiment with something. Maybe this is
something useful in an advanced users security guide, but not as a
default configuration.

I don't know. Unless someone has a good argument to add here, I am happy
with whatever decision the Qubes Council makes.

But maybe it would be better to change it to handle ICMP
only from downstream VMs ("-i vif+"), not the upstream (including the
outside world). What do you think?

Not sure I understand.

Are you suggesting to only block ICMP from the LAN / outside world? I.e.
to only block ICMP on network interfaces directly connected to a [wifi]
router or modem?

If so... That would be a tradeoff. Not a bad one, I think. Better
protection from outside attackers (ddos, ICMP timestamp analysis) but
not from compromised VMs. However, I don't know if blocking ICMP from
compromised VMs is worthwhile at all due to other side channel attacks,
you tell me.

Independently indeed it would be better to replace terminating rule "-j
REJECT --reject-with icmp-host-prohibited" with just "DROP".

That is more correct, easier to debug, but also easier to ddos. Kinda a
personal decision.

adrelanos · Oct 19, 2015

Marek Marczykowski-Górecki:

Dropping ICMP at all would make diagnostic somehow harder (for example
checking if AppVM can reach NetVM).

Agreed. Makes diagnostic harder. Depends what weights more here. Ease of
debugging or difficult to quantity(?) security benefits.

I think for this reason fewer people technically understand Whonix,
since they cannot ping if they experiment with something. Maybe this is
something useful in an advanced users security guide, but not as a
default configuration.

I don't know. Unless someone has a good argument to add here, I am happy
with whatever decision the Qubes Council makes.

But maybe it would be better to change it to handle ICMP
only from downstream VMs ("-i vif+"), not the upstream (including the
outside world). What do you think?

Not sure I understand.

Are you suggesting to only block ICMP from the LAN / outside world? I.e.
to only block ICMP on network interfaces directly connected to a [wifi]
router or modem?

If so... That would be a tradeoff. Not a bad one, I think. Better
protection from outside attackers (ddos, ICMP timestamp analysis) but
not from compromised VMs. However, I don't know if blocking ICMP from
compromised VMs is worthwhile at all due to other side channel attacks,
you tell me.

Independently indeed it would be better to replace terminating rule "-j
REJECT --reject-with icmp-host-prohibited" with just "DROP".

That is more correct, easier to debug, but also easier to ddos. Kinda a
personal decision.

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-3.1.10-1.fc21 has been pushed to the r3.1 testing repository for the Fedora fc21 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r3.1-current-testing

QubesOS/qubes-issues

Join GitHub today

firewall block all new incoming traffic by default #1346

Comments

adrelanos commented Oct 19, 2015

This comment has been minimized.

marmarek commented Oct 19, 2015

This comment has been minimized.

adrelanos commented Oct 19, 2015

adrelanos referenced this issue Nov 2, 2015

marmarek added enhancement C: core C: templates P: major labels Nov 2, 2015

marmarek added this to the Release 3.1 milestone Nov 2, 2015

marmarek closed this in marmarek/old-qubes-core-agent-linux@b9e51f9 Dec 30, 2015

This comment has been minimized.

marmarek commented Dec 31, 2015

marmarek added the r3.1-fc21-cur-test label Dec 31, 2015

This comment has been minimized.

marmarek commented Dec 31, 2015

marmarek added the r3.1-fc22-cur-test label Dec 31, 2015

This comment has been minimized.

marmarek commented Dec 31, 2015

marmarek added the r3.1-fc23-cur-test label Dec 31, 2015

This comment has been minimized.

marmarek commented Dec 31, 2015

marmarek added the r3.1-jessie-cur-test label Dec 31, 2015

This comment has been minimized.

marmarek commented Dec 31, 2015

marmarek added the r3.1-stretch-cur-test label Dec 31, 2015

This comment has been minimized.

marmarek commented Dec 31, 2015

marmarek added the r3.1-wheezy-cur-test label Dec 31, 2015

This comment has been minimized.

marmarek commented Jan 12, 2016

marmarek added r3.1-fc21-stable and removed r3.1-fc21-cur-test labels Jan 12, 2016

This comment has been minimized.

marmarek commented Jan 12, 2016

marmarek added r3.1-fc22-stable and removed r3.1-fc22-cur-test labels Jan 12, 2016

This comment has been minimized.

marmarek commented Jan 12, 2016

marmarek added r3.1-fc23-stable and removed r3.1-fc23-cur-test labels Jan 12, 2016

This comment has been minimized.

marmarek commented Jan 13, 2016

marmarek added r3.1-jessie-stable and removed r3.1-jessie-cur-test labels Jan 13, 2016

This comment has been minimized.

marmarek commented Jan 13, 2016

marmarek added r3.1-wheezy-stable and removed r3.1-wheezy-cur-test labels Jan 13, 2016

marmarek closed this in `marmarek/old-qubes-core-agent-linux@b9e51f9` Dec 30, 2015