Bonjour,
souvent quand je suis amen� � utiliser les machines Linux des autres, je
suis d�pays�. Pas forc�ment � cause du clavier, ou de l'interface
graphique diff�rente ou le manque des outils auxquels je suis habitu�,
mais souvent pour le manque de s�curisation.
Une machine qui se trouve sur Internet (m�me sur r�seau commut�, ie par
dialup) ne devrait r�ellement tourner que les services minimaux: en
r�alit�, sur un poste de travail, pas grand chose. En particulier ni
BIND/named, ni portmapper, rpc.mountd, ni sendmail (�coutant sur le port
25: sans option -bd c'est ok).
Rappelons qu'une machine pirat�e doit �tre r�install�e compl�tement, et
seulement ses *donn�es* � l'exclusion de tout script, configuration et
ex�cutables, peuvent �tre restaur�es. On peut aussi d�marrer sur un medium
read-only pr�par� � l'avance et v�rifier un backup consid�r� comme s�r,
p.ex.
Mais quand le piratage a eu lieu ? Pour faire peur, rappelons que sous
AmigaOS, il existait un virus silencieux qui commen�ait par encrypter le
contenu du disque, ajoutant un boot-block de d�cryptage. Enlever le virus
plusieurs mois plus tard lorsque celui-ci devenait visible amenait � la
perte des donn�es.
Rappelons aussi que la possibilit� existe, une fois le worm/virus devenu
root, de modifier le BIOS (si celui-ci est flashable et que le jumper de
programmation est mis (cartes-m�res modernes: plus de jumper) ou pire, sur
disque (anciens Compaq!)), voire de modifier le microcode du processeur
(Intel). Personne ne l'a fait encore, bien s�r. Un tel piratage � large
�chelle, comme le probl�me avec BIND et Red Hat, pourrait faire mal
(rappelons que ce probl�me n'aurait pas exist� si 1. BIND n'�tait pas
lanc� 2. les machines �taient maintenues � jour).
Apr�s tout, si une machine n'�coute aucun port ou que sur quelques ports,
cela diminue d'autant le risque: en effet, m�me si certains protocoles
sont authentifi�s (p.ex. les magic cookies MIT du serveur X), des bugs
peuvent tout de m�me exister dans le traitement de la connexion initiale.
Pour X, utiliser l'option -nolisten tcp au lancement du serveur X,
p.ex. dans /etc/X11/kdm/Xservers.
Par exemple, sans poss�der l'authentification X, on pouvait faire coincer
(Denial-of-Service) le serveur X. Certains d�mons, comme POP, ont eu, eux,
leurs probl�mes de s�curit�: une simple connexion non authentifi�e et vous
aviez acc�s root. Enfin, citons le grand probl�me des paquets UDP: un
simple paquet UDP, envoy� m�me d'une adresse invalide, pouvait ex�cuter du
code � travers BIND. C'est ce qui a �t� utilis� pour le vers/worm qui
attaquait notamment les machines Red Hat en avril de cette ann�e.
Aucune raison de tourner un serveur POP ou BIND sur un client.
Ce probl�me d'UDP est une des raisons pourquoi un firewall IP Masquerading
devrait �tre �valu� avant d'�tre mis en oeuvre. Une solution �
proxy-application est probablement plus s�re dans le cas g�n�ral, vu
qu'elle ne permet pas de faire du tunneling d'UDP.
Un proxy application, en g�n�ral, ne permettra plus l'utilisation
d'ICQ ou d'autres protocoles bas�s sur UDP. Le resolving de noms
ne sera plus fait par les clients mais par le proxy.
Comment s'en pr�munir ? On peut bien s�r surveiller les annonces de
s�curit� ou utiliser des syst�mes de mise � jour automatis�es (apt-get
update && apt-get -u dist-upgrade) de la Debian. Mais m�me les autorit�s
de s�curisation des distributions font parfois des erreurs, et certains
patches ne sont disponibles que quelques heures apr�s.
En limitant le nombre de services accessibles sur votre serveur sur
Internet et sur votre poste de travail, vous limitez l'�tendue du risque
et vous vous donnez la possibilit� de vous abonner � la mailing-list de
s�curit� d'un logiciel particulier, sans �tre noy� sous des annonces
ne vous concernant pas.
Rappelons que la plupart des distributions ont une mailing-list de
s�curit�. Rappelons aussi qu'en particulier les distributions les
moins `populaires' ont parfois des probl�mes � sortir des patches
� temps. Et certaines distributions ont parfois, ponctuellement,
des lenteurs.
Comment savoir quels sont les ports ouverts ?
Exemple:
schaefer@truc:~$ netstat -an | egrep 'tcp.*LISTEN|udp'
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:5432 0.0.0.0:* LISTEN
Cette machine semble relativement s�curis�e, si l'on suppose que l'acc�s
SSH et HTTP sont utiles. Rappelons que le mot de passe root (si login SSH
possible) et des utilisateurs doivent �tre bien choisis, et les logs
d'authentification surveill�s. Un outil comme logdog (qui envoie un mail
lors d'entr�es de logs non usuelles) peut �tre utile. Rien que pour
d�tecter quand votre disque fait des erreurs. Ou alors lancez dmesg et des
tails r�guliers!
Malheureusement, pourquoi le port 5432 est-il ouvert?
truc:/home/schaefer# fuser -v -n tcp 5432
USER PID ACCESS COMMAND
5432/tcp postgres 164 f.... postmaster
ah, c'est Postgres. Sur la Debian, pour fermer ce port (qui est ferm� par
d�faut!), changer PGALLOWTCPIP � no, dans /etc/postgresql/postmaster.init,
et faire un /etc/init.d/postgresql restart. Si cette machine n'a pas
besoin de PostgreSQL, on peut aussi le d�sinstaller.
Si vous en avez besoin p.ex. pour l'acc�s local via TCP/IP, vous pouvez
demander au daemon de n'�couter que sur l'interface local, ou le
firewaller, en supposant que eth0 est l'interface Internet:
/sbin/ipchains -I input -j REJECT -l -y -p tcp -s 0.0.0.0/0 \
-d 0.0.0.0/0 5432 -i eth0 # 2.2.x
N'importe quel paquet en provenance de eth0 demandant l'ouverture (-y ==
--syn) d'une connexion TCP sur le port 5432 sera rejet� comme si aucun
service n'�tait en �coute sur ce port. La r�jection sera suivie d'un log
kernel.
Pour tester:
telnet truc 5432
telnet: Unable to connect to remote host: Connection refused
kernel:
Packet log: input REJECT eth0 PROTO=6 194.38.85.209:19578
194.38.85.206:5432 L=44 S=0x10 I=57676 F=0x0000 T=55 SYN (#1)
Il existe �galement des programmes de scanning actifs, qui peuvent
�tre utile si on suppose un piratage pr�alable ayant modifi� la
commande netstat et/ou le kernel.
Cette commande doit �tre lanc�e apr�s la configuration r�seau, mais avant
le lancement des daemons. Alternativement, quand vous voulez, mais
seulement si la `policy' par d�faut de l'input firewall est DENY.
Notons que si les num�ros de s�quence sont pr�dictibles (pas le cas sous
Linux normalement) ET que le firewalling n'est pas configur� pour refuser
des paquets d'adresses internes venant de l'ext�rieur (spoofing, en
g�n�ral configur� par d�faut sur la Debian notamment), une attaque
d'insertion est possible m�me avec les r�gles ci-dessus. Dans ce cas
enlever le -y (== --syn), ou configurer ce qui pr�c�de.
(dans le cas de dialup, on peut lancer de telles commandes de firewalling,
et effacer les entr�es dans les scripts lanc�s par pppd � la configuration
d'interface, v�rifier que pppd appelle le script avant de configurer
l'interface, ou alors utiliser une politique de deny par d�faut).
L'option de log est pour �tre averti, l'acc�s � ce port peut indiquer un
scan, voire un piratage.
Bien s�r par d�faut PostgreSQL ne laisse pas n'importe qui entrer. Mais le
jour o� un bug de s�curit� dans le protocole d'authentification est
d�couvert, vous serez content d'avoir prot�g� ce port.
PS: ne pas h�siter � faire r�guli�rement un tel netstat, en particulier
quand des applications comme Star Office, ou d'autres trucs complexes
comme KDE ou GNOME sont lanc�s. On peut faire un crontab qui annonce des
changements par rapport � une version `connue correcte'.
Exemple:
netstat.user | grep LISTEN | egrep -v "^unix" | sort -u | diff \
/root/reference/netstat - | egrep '^>'
Pour kxmlrpcd, un service non n�cessaire de KDE mais qui �coute
globalement, lire:
http://archives.neohapsis.com/archives/linux/suse/2001-q1/1190.html
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se d�sabonner aussi.
