Product SiteDocumentation Site

Capitolo 5. Rendere più sicuri i servizi che girano sul vostro sistema

5.1. Rendere sicuro ssh
5.1.1. Ssh in chroot
5.1.2. Client SSH
5.1.3. Non permettere il trasferimento di file
5.1.4. Limitare l'accesso al solo trasferimento di file
5.2. La sicurezza in Squid
5.3. Rendere sicuro FTP
5.4. Rendere sicuro l'accesso al sistema X Window
5.4.1. Controllare il display manager
5.5. Rendere sicuri gli accessi alla stampante (specifico per lpd ed lprng)
5.6. Rendere sicuro il servizio di posta
5.6.1. Configurare un nullmailer
5.6.2. Fornire un accesso sicuro alle mailbox
5.6.3. Ricevere posta in sicurezza
5.7. Rendere sicuro BIND
5.7.1. Configurazione di Bind per evitare abusi
5.7.2. Cambiare l'utente di BIND
5.7.3. Eseguire il name server in chroot
5.8. Proteggere Apache
5.8.1. Impedire agli utenti la divulgazione di contenuti di rete
5.8.2. Permessi sui file di log
5.8.3. Pubblicare file web
5.9. Rendere sicuro finger
5.10. Paranoie generiche riguardo chroot e suid
5.10.1. Creare ambienti chroot automaticamente
5.11. In generale, paranoia per le password in chiaro
5.12. Disabilitare NIS
5.13. Rendere sicuri i servizi RPC
5.13.1. Disabilitare completamente i servizi RPC
5.13.2. Limitare l'accesso ai servizi RPC
5.14. Aggiungere funzionalità al firewall
5.14.1. Proteggere il sistema locale con un firewall
5.14.2. Utilizzare un firewall per proteggere altri sistemi
5.14.3. Configurare il firewall
I servizi attivi su un sistema possono essere resi più sicuri in due modi:
  • Rendendoli accessibili solo dai punti di accesso (interfacce) per i quali sono necessari.
  • Configurandoli opportunamente cosicché possano essere usati solo dagli utenti legittimati con un metodo di autorizzazione.
Vincolare i servizi in maniera tale da renderli accessibili solo da un luogo definito può essere fatto limitando il loro accesso a livello di kernel (per es. i firewall), configurandoli in maniera tale da ascoltare solo da una data interfaccia (alcuni servizi potrebbero non fornire questa possibilità) o impiegando qualche altro metodo, per esempio la patch linux vserver (per il 2.4.16) può essere usata per obbligare i processi ad usare una sola interfaccia.
Regarding the services running from inetd (telnet, ftp, finger, pop3...) it is worth noting that inetd can be configured so that services only listen on a given interface (using service@ip syntax) but that's an undocumented feature. One of its substitutes, the xinetd meta-daemon includes a bind option just for this matter. See ixnetd.conf(5) manual page.
service nntp
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = news
        group           = news
        server          = /usr/bin/env
        server_args     = POSTING_OK=1 PATH=/usr/sbin/:/usr/bin:/sbin/:/bin
+/usr/sbin/snntpd logger -p news.info
        bind            = 127.0.0.1
}
Le sezioni seguenti forniscono dettagli su come configurare opportunamente singoli e specifici servizi in funzione dell'uso previsto.

5.1. Rendere sicuro ssh

Se state ancora usando telnet invece di ssh, è meglio che passiate a ssh prima di proseguire con la lettura di questo manuale. Sarebbe bene utilizzare ssh invece di telnet per tutti i login remoti. In un'epoca in cui è facile intercettare il traffico su Internet e ottenere le password trasmesse in chiaro, bisognerebbe usare solamente protocolli che utilizzano la crittografia; per questo motivo meglio eseguire subito apt-get install ssh sulla propria macchina.
Incoraggiate tutti gli utenti del vostro sistema ad usare ssh invece di telnet o, ancora meglio, disinstallare telnet/telnetd. Oltre a quanto detto bisognerebbe evitare di autenticarsi nel sistema come root con ssh e utilizzare invece dei metodi alternativi per diventare root, come su o sudo. Infine, meglio modificare anche il file sshd_config, in /etc/ssh, per aumentare la sicurezza:
  • ListenAddress 192.168.0.1 Have ssh listen only on a given interface, just in case you have more than one (and do not want ssh available on it) or in the future add a new network card (and don't want ssh connections from it).
  • PermitRootLogin no Try not to permit Root Login wherever possible. If anyone wants to become root via ssh, now two logins are needed and the root password cannot be brute forced via SSH.
  • Port 666 or ListenAddress 192.168.0.1:666 Change the listen port, so the intruder cannot be completely sure whether a sshd daemon runs (be forewarned, this is security by obscurity).
  • PermitEmptyPasswords no Empty passwords make a mockery of system security.
  • AllowUsers alex ref me@somewhere Allow only certain users to have access via ssh to this machine. user@host can also be used to restrict a given user from accessing only at a given host.
  • AllowGroups wheel admin Allow only certain group members to have access via ssh to this machine. AllowGroups and AllowUsers have equivalent directives for denying access to a machine. Not surprisingly they are called "DenyUsers" and "DenyGroups".
  • PasswordAuthentication yes It is completely your choice what you want to do. It is more secure to only allow access to the machine from users with ssh-keys placed in the ~/.ssh/authorized_keys file. If you want so, set this one to "no".
  • Disable any form of authentication you do not really need, if you do not use, for example RhostsRSAAuthentication, HostbasedAuthentication, KerberosAuthentication or RhostsAuthentication you should disable them, even if they are already by default (see the manpage sshd_config(5) manual page).
  • Protocol 2 Disable the protocol version 1, since it has some design flaws that make it easier to crack passwords. For more information read http://earthops.net/ssh-timing.pdf or the http://xforce.iss.net/static/6449.php.
  • Banner /etc/some_file Add a banner (it will be retrieved from the file) to users connecting to the ssh server. In some countries sending a warning before access to a given system about unauthorized access or user monitoring should be added to have legal protection.
Potete limitare l'accesso al server ssh anche utilizzando le direttive pam_listfile o pam_wheel nel file di configurazione PAM per ssh, in modo da limitare le autenticazioni ssh. Per esempio potreste escludere tutti gli utenti non elencati in /etc/loginusers aggiungendo questa riga a /etc/pam.d/ssh:
auth       required     pam_listfile.so sense=allow onerr=fail item=user file=/etc/loginusers
Come ultima osservazione dovreste considerare che queste direttive si riferiscono ad un file di configurazione di OpenSSH. Al momento vengono utilizzati comunemente tre demoni SSH: ssh1, ssh2 e l'OpenSSH degli sviluppatori di OpenBSD. ssh1 è stato il primo demone ssh disponibile ed è ancora il più utilizzato (ci sono voci che esista anche una versione per Windows). ssh2 ha molti vantaggi rispetto a ssh1 tranne per il fatto di essere rilasciato con una licenza closed-source. OpenSSH è un demone ssh rilasciato come software libero che supporta sia ssh1 che ssh2. OpenSSH è la versione che viene installata in Debian quando selezionate il pacchetto ssh.
You can read more information on how to set up SSH with PAM support in the http://lists.debian.org/debian-security/2001/11/msg00395.html.

5.1.1. Ssh in chroot

Per ora OpenSSH non fornisce un modo per poter ingabbiare automaticamente, con chroot, gli utenti dopo una connessione (la versione commerciale invece fornisce questa possibilità). Ad ogni modo esiste un progetto per dare questa funzionalità anche ad OpenSSH, vedete http://chrootssh.sourceforge.net, al momento credo non sia disponibile il pacchetto per Debian. Potreste usare al suo posto il modulo pam_chroot come descritto in Sezione 4.11.15, «Restrizioni agli utenti per l'accesso».
In Sezione B.7, «Chroot environment for SSH» potete trovare numerose opzioni per creare un ambiente chroot per SSH.

5.1.2. Client SSH

Se usate un client SSH con un server SSH dovreste assicurarvi che supporti gli stessi protocolli impostati sul server. Per esempio, se utilizzate il pacchetto mindterm, questo supporta solo il protocollo con versione 1. Mentre, il server sshd, in modo predefinito, viene configurato per accettare solo la versione 2 (per ragioni di sicurezza).

5.1.3. Non permettere il trasferimento di file

Se non volete che gli utenti trasferiscano file da e verso il server ssh dovete limitare l'accesso all'sftp-server e l'accesso a scp. Potete limitare l'sftp-server configurando il corretto Subsystem in /etc/ssh/sshd_config.
Potete anche ingabbiare in chroot gli utenti (usando libpam-chroot) cosicché, nonostante il trasferimento di file sia permesso, gli utenti siano costretti in un ambiente limitato che non comprende file di sistema.

5.1.4. Limitare l'accesso al solo trasferimento di file

Potreste desiderare di limitare l'accesso agli utenti al solo trasferimento di file e non concedere loro shell interattive. A questo scopo potete anche:
  • non permettere agli utenti il login per mezzo del server ssh (come descritto in precedenza, sia mediante il suo file di configurazione che tramite il file di configurazione di PAM).
  • concedere agli utenti una shell limitata come scponly o rssh. Queste shell limitano i comandi disponibili agli utenti in modo da non fornire alcun privilegio di esecuzione remota.