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.
