Depois de uma instalaçõa padrão, o sistema ainda poderá ter algumas vulnerabilidades de segurança. Ao menos que você baixe as atualizações para os pacotes vulneráveis em outro computador (ou você tenha espelhado security.debian.org para uso local), o sistema deverá ter acesso à Internet para os downloads.

Entretanto, na medida que você se conecta à Internet estará expondo seu sistema. Se um de seus serviços locais estiver vulnerável, poderá ser comprometido mesmo antes de finalizar as atualizações! Isso pode ser paranóico, mas as análises do http://www.honeynet.org têm mostrado que sistemas podem ser comprometidos em menos de três dias, mesmo que o sistema não seja conhecido publicamento (i.e., não está publicado nos registros DNS).

Quando estiver fazendo uma atualização em um sistema não protegido por um mecanismo externo como firewall, é possível configurar seu firewall local para restringir conexões envolvendo somente as próprias atualizações de segurança. O exemplo abaixo mostra como configurar estas capacidades de firewall, que permitem somente conexões do security.debian.org, registrando todas as outras que são negadas.

The following example can be use to setup a restricted firewall ruleset. Run this commands from a local console (not a remote one) to reduce the chances of locking yourself out of the system.

  # iptables -F
  # iptables -L
  Chain INPUT (policy ACCEPT)
  target     prot opt source               destination

  Chain FORWARD (policy ACCEPT)
  target     prot opt source               destination

  Chain OUTPUT (policy ACCEPT)
  target     prot opt source               destination
  # iptables -P INPUT DROP
  # iptables -P FORWARD DROP
  # iptables -P OUTPUT DROP
  # iptables -A OUTPUT -d security.debian.org --dport 80 -j ACCEPT
  # iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
  # iptables -A INPUT -p icmp -j ACCEPT
  # iptables -A INPUT -j LOG
  # iptables -A OUTPUT -j LOG
  # iptables -L
  Chain INPUT (policy DROP)
  target     prot opt source               destination
  ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          state RELATED,ESTABLISHED
  ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0
  LOG        all  --  anywhere             anywhere           LOG level warning

  Chain FORWARD (policy DROP)
  target     prot opt source               destination

  Chain OUTPUT (policy DROP)
  target     prot opt source               destination
  ACCEPT     80   --  anywhere             security.debian.org
  LOG        all  --  anywhere             anywhere           LOG level warning

Note: Using a DROP policy in the INPUT chain is the most correct thing to do, but be very careful when doing this after flushing the chain from a remote connection. When testing firewall rulesets from a remote location it is best if you run a script with the firewall ruleset (instead of introducing the ruleset line by line through the command line) and, as a precaution, keep a backdoor^[77]

Of course, you should disable any backdoors before getting the system into production. configured so that you can re-enable access to the system if you make a mistake. That way there would be no need to go to a remote location to fix a firewall ruleset that blocks you.

FIXME: This needs DNS to be working properly since it is required for security.debian.org to work. You can add security.debian.org to /etc/hosts but now it is a CNAME to several hosts (there is more than one security mirror)

FIXME: this will only work with HTTP URLs since ftp might need the ip_conntrack_ftp module, or use passive mode.

#!/bin/bash

while true; do
    read -n 1 -p "Are you there? " -t 30 ayt
    if [ -z "$ayt" ] ; then
        break
    fi
done

# Reset the firewall chain, user is not available
echo
echo "Resetting firewall chain!"
iptables -F
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
exit 1