Comme chacun le sait, Linux est un système fiable, sur, sans virus, sans trojan, etc, etc....
 
Seul problem, mais tout petit, la chose entre la chaise et l'écran reste identique sous Linux que sous Windows. Donc la sécurité n'est pas toujours optimale.
 
je vous propose donc de lister sur ce topic toute les mise en oeuvre (évidente ou non) pour sécuriser à mort sa machine (bureau ou serveur).
 
J'organiserais des section quand j'aurais plus d'info.
 
 
règle numero 1) :  
Toujours se logguer en single user. Eviter autant que possible le mode Admistrateur/Root. Ca permet d'éviter beaucoup de probleme et de restreindre les droits d'acces.

Rasthor, pour les topics utiles y'a pas mieux que tes initiatives ! Longue vie à celui-ci !
 
Tiens, je mets mon drapo !
 
règle numéro 2):
Lire les logs de temps en temps (plutôt souvent) pour voir s'ils contiennent des "spécialités douteuses".
 
Question :
Quels appz pour auditer et tester la sécurité (sniffers, scannners, scripts d'exploits connus, etc.) de postes de travail, serveurs web, etc. ?

scanlogd pour surveiller les scans qui passent sur la machine

 
ouai mais ca c'est des virus écrits par Symantec pour remplir leur section Linux    
 
(je pense pas que tu ai compris l'humour du 1er poste)

shadow, iptables bien réglé, ...

oue enfin ca suffit pas
 
t as bo avoir un bo iptables, si les services ki tournent sont pas "securises" ou a jour, DTC

chkrootkit... c'est pas mal aussi de temps en temps, quand on pense  
s'être fait eu..

Les points de suspension etait là pour ça ...

attention, il peut dire des conneries avec certains softs comme snort je crois
j ai eu un pb avec nfs je crois sur un mauvais port

il faut aussi se tenir au courant des failles de sécurité signalées et d'appliquer les correctifs
on en a signale notament dans  
Xfree X.4.x.x  
apache 1.3.26
ftp : pro-ftp et wu-ftp
etc... , je ne les connaits pas tous.
 
bien paramétrer son samba
utiliser postix plutot que sendmail , bien le parametrer
(attention à son utilisation comme relay)
 
 

 
c bien pour ca k on rabache tjs ici k il fo jms lancer X en root

un bon truc : grsec
 
surtout avec des chroot, ca evitera les mauvaises surprises

romf ??  

 
Juste pour rectifier, ma phrase était un beau troll qui justifie le topic    
virus, trojan, worm, y'en a sur tous les systèmes.

Mais nan...
 
allez  : www.netfilter.org

grsecurity powaaa

 
Je me pose la question , finalement , chkrootkit , c'est pas un anti-virus (manuel) pour linux ?

bah..ça vérifie juste si certains de tes programmes systèmes importants sont pas corrompues..
C'est pas vraiment un virus, ils sont corrompus si un gars à hacké ta machine et qu'il les as remplacé afin d'avoir une backdoor

nan, pas du tout
 
c est un anti rootkit comme son nom l indique pas du tout

Ma contribution en vrac, en plus de ce qui a déja été dit :

• Utiliser des protocoles sécurisés : ssh au lieu de telnet, ftp, rcp...
• Couper tous les services inutiles : identd, ftp, X... Si un service ne sert qu'en local (par exemple SMTP chez moi, pour envoyer les mails et les recevoir de fetchmail), ne pas le binder sur les interfaces publiques
• Sécuriser l'accès à la machine en local (mot de pass au boot...)
• Choisir des mots de passes sûrs. Si on est admin, tourner un crackeur de mot de passes régulièrement.
• Sur les systèmes sensibles (firewall en particulier), monter /etc, /bin, /sbin, /usr, /opt en read-only. Ne pas monter /boot.
• Quand c'est possible, configurer les entrées ARP de manière statique, pour se protéger de l'ARP spoofing
• Si ça se justifie, envoyer les logs sur une machine distante ou sur un imprimante
• Utiliser la cible LOG/ULOG d'iptables

 
C'est un detecteur de rootkits comme son nom l'indique.
chk = check

Je me pose la question suivante :
pour être certain que personne ne touche à mon système, je voudrais le passer en "lecture seule".
Solution 1: liveCD. Pas très souple, même avec un /etc sur disquette.
Solution 2: démarrer sur un cramfs, qui n'a pas de fonction d'écriture (à moins de reconstruire tout le système). Même problème, et en plus un intrus peut éventuellement modifier astucieusement le périphérique pour faire ses modifications
Solution 3: lufs ou NFS monté en lecture seule. Mais est-ce vraiment sûr ?
Solution 4 (celle que j'ai implémentée): root en NFS sur un serveur distant qui n'exporte qu'en lecture seule. Je fais les modifications sur l'autre machine avec le chroot de son système.
Le système exporté n'a ni chroot, ni su, ni mount, bref rien de util-linux. Pas de lockd (inutile en lecture seule), ce qui permet de fermer le port.
 
La solution 4 a nettement ma préférence. Pourtant une rumeur insistante assure que "NFS, c'est mal" (en sécurité).
Quel est votre avis ?

glacote> en te servant des acl de grsecurity par exemple tu as le moyen de rendre tout ton systeme en lecture seule sauf évidement pour les applications que tu veux , en ayant restreint bien évidement les possibilités pour chaque application , c'est un peu lourd a mettre en place au départ mais apres c'est pas mal je pense

En effet, les Acls, c bien puissant, et en plus tu peux restreindre au niveau des utilisateurs et tout, ça peut le faire.
 
Sinon glacote: une autre solution serait peut être le boot depuis une interface réseau... avec une requête bootp et un mini linux chargé en mémoire... mais je sais pas si ça répond exactement à ce que tu veux...
 
Et pour le problème de sécurité de NFS je crois que c'est lié au fait qu'il soit sur UDP et non sur TCP.

> grosminet
Oui mais pas réussi. Pour l'instant je charge un kernel+initrd, lequel dans son /linuxrc monte une partition NFS et pivot_root/chroot dessus. Le boot direct avec les paramères NFS sur le kernel à voir
 
Pour NFS security UDP/TCP, je vois deux solutions: utiliser Coda (jamais utilisé), ou NFS over TCP.
A priori Coda est supérieur, à voir.

Si je dis pas de conneries, NFS over TCP est encore en développement.

bon
ca passionne pas des masses    
 
allez un tit truc pour la route :
 
se logguer (avec ssh evidemment ) mais par cle + pass phrase uniquement, et interdire les connexions pas mot de passe uniquement
 
 
c est tres simple :
 
generer sa paire de cles privee/publique :

rentrer une passphrase NON VIDE !
(cle de 1024 bits par defaut)
 
copier sa cle publique sur la machine ou l on veut pouvoir se loguer

 
sur la machine sécurisée : mettre l option

ds /etc/ssh/sshd_config et relancer sshd
 
voila, ca marche
 
ps : pour les nomades avec cle usb par exmple : copier sa cle privee (id_dsa) sur la machine d ou vous voudrez vous connecter
 
ps : vous pouvez faire l inverse bien sur : rajouter une cle + passphrase sur la machine securisee

interresant ce tomik !

Rasthor, il serai bien de refaire ton 1er post

exact  
 

 
et j'ajouterai même pam et tripwire

1 - on monte le strict minimum en service,
2 - on consolide au Maximum la pile IP (patch secu , noyau etc ..)
3 - on verrouille totalement le firewall,
4 - on ouvre uniquement les services à offrir au wan (web),
5 - on blinde aussi bien les regles coté WAN que coté LAN, (en clair on protége le Firewall des attaques internes aussi ...)
6 - on croise OBLIGATOIREMENT les technos ...
7 - on filtre impérativement les flux autorisés par le firewall (voir trend micro virus wall pour le filtrage ftp, http, smtp ...) et on met à jour SYSTéMATIQUEMENT les serveurs ftp, smtp, web etc ... qui vont forcément encaissé les premiers les failles de sécu (attaquer le service web, smtp ou ftp c bcp plus simple que la pile ip du firewall ... ca s'appelle un Dos et y'en a des milliers par produit ... securityfocus.com => N-stealth peut torpiller bcp de serveur web eb 10 mn ...si si)
8 - on verfie les log,
9 - un chkrootkit c trés bon,
10 - verfication obligatoire des fichiers .diff sur mandrake.
11 - mise a l'abris du certificat ssh si génération sur la gateway elle même (dites pas non y'en combien qui install ssh sur leur firewall puis l'administre a distance et .. c tout !!!)
12 - l'inévitable DMZ, pour le relay smtp, le serveur web, le proxy ...
 
le firewall doit être non pas une boite noire mais plutot une boite de crystal , totalement transparente pour qui tente d'en deceler la présence ....
 
13 - la régle d'or : la sécu à 100 % n'existe pas ... il faut donc une mutlitude de couches de sécurité pour obtenir le meilleur resultat.

 
ca veut dire quoi ca?

ex: de conf.
                                 
                                EXT (web)
                                   |
                                   |
        Fw1 (cisco Pix ou FW 1 checkpoint)
                                   |
                                   |
Filtrage appli(viruswall)--[Interco]--DMZ*
                                   |
                                   |
        Fw2 (iptables, pf , ipchains ou watchguard)
                                   |
                                   |
                                  LAN
 
* : --(web,smtp,proxy,concent. vpn,vmware : honeypot)
 
 
avec ca, ca fait trés mal au hacker ... c pas les ptits qui passent ...
 
l'interco dispose de vlan bien sure ...
 
en fait avec ce schema tu as un croisement de, minimum, 5 marques differentes et donc a connaitre avant de passer ..bon courage )

Ce que je propose sur ce sujet, c que chacun enonce des types d'attaques qu'il connait ET SURTOUT propose la parade au niveau codage de regles pour un firewall.
 
(evidemment sur des fw commercial , ce sont les ingé. secu. responsables du produit qui font de la recherche active et intensif pour inclure ds les maj de leur firewall les parades et donc les regles uptodate.
 
 
Mais pour les plus pauvres ... il faut les coder soit meme , pas forcement en ligne de commande (cf fwbuilder <=> interface de fW1 ou watchguard)
 
Je pense que cela peut être trés enrichissant et permet un reel echange de compétence en terme de sécurité , ca interesse du monde ?
 

j'ouvre la danse :
 
- IP Spoofing:
  injection, sur le firewall et en provenance de l'attaquant web donc), de paquets ayant pour adresse source le Lan ou la DMZ
 
=> parade : bloquage sur l'interface EXT (relié au web , pppo en gal) des paquets ayant pour adresse sources le lan (en gal 192.168., 172.16., 10.) ou la dmz
 
... to be continued ...

 
Heu tomate tu m'exliques comment tu fais pour copier par scp ta cle sur le serveur ssh en te servant du meme user (je te rappelle qu'il n'a pas encore sa cle sur le serveur ssh)

 
Des que j'ai un peu de temps, je le fais

car tu fais la modif du server ssh APRES avoir uploadé les cles des users

c le bea-ba ca