Dopo un'installazione standard, la sicurezza di un sistema potrebbe presentare ancora delle vulnerabilità. A meno che voi non scarichiate gli aggiornamenti da un altro sistema (o abbiate fatto il mirror di security.debian.org per un uso locale), il sistema dovrà essere collegato ad internet per i download.

However, as soon as you connect to the Internet you are exposing this system. If one of your local services is vulnerable, you might be compromised even before the update is finished! This may seem paranoid but, in fact, analysis from the http://www.honeynet.org has shown that systems can be compromised in less than three days, even if the system is not publicly known (i.e., not published in DNS records).

Quando si esegue un aggiornamento, su di un sistema non protetto da un altro sistema esterno, come un firewall, è possibile configurare adeguatamente il vostro firewall locale per limitare le connessioni alle sole riguardanti gli aggiornamenti per la sicurezza. L'esempio qui di seguito mostra come configurare un tale firewall, per autorizzare solo le connessioni da security.debian.org e registrare tutte le altre.

Il seguente esempio può essere utilizzato per impostare un insieme di regole restrittive del firewall. Eseguite questi comandi da una console locale (non da remoto) per ridurre il rischio di rimanere tagliati fuori da un eventuale blocco del sistema.

  # 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 -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 -P INPUT DROP
  # iptables -P FORWARD DROP
  # iptables -P OUTPUT DROP
  # 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^[79]

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.

Questo richiede che il DNS funzioni correttamente, dato che serve per far funzionare security.debian.org. Potete aggiungere security.debian.org ad /etc/hosts ma attualmente è un CNAME a svariati host (c'è più di un mirror di sicurezza).

FIXME: ciò funzionerà solo con le URL HTTP poiché ftp potrebbe richiedere il modulo ip_conntrack_ftp module, oppure utilizzare la modalità passiva.

#!/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