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.
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).
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.
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».
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.
