mé un firewall permet de préciser les IO face aux interfaces non sûres........ Bien entendu, si apache n'est pas sécurisé, il ne va te servir à rien, ton firewall..... Mais si il y a une faille dans le noyau ki active un port à partir de données envoyées sur un autre, bah le firewall empêchera la prise de contrôle de ce port...

je repondrai oui

ah ??
tu peux m'en dire plus ?  

bah iptables ne sert pas k a fermer des ports

oué mais ma question se limite à cet usage
mais en fait je crois que j'ai saisi, mais par contre j'ai pas compris l'exemple de sozi

activation d'un trojan à travers apache et php par exemple.....

ah ok, l'exemple tout con en somme
ok mais tu fais comment pour bloquer ça avec iptables ? (c'est une vrai question hein, pas une critique )
 
et une deuxieme me vient dans la foulé : est-il possible d'empécher (peut-être par grsec ? ) un démon d'écouter sur les ports supérieurs à 1024 ?

et une deuxieme me vient dans la foulé : est-il possible d'empécher (peut-être par grsec ? ) un démon d'écouter sur les ports supérieurs à 1024 ?

tu bloques en sortie

et une deuxieme me vient dans la foulé : est-il possible d'empécher (peut-être par grsec ? ) un démon d'écouter sur les ports supérieurs à 1024 ?

par grsec tu peux effectivement limité les acces a la couche réseau
soit interdire un user de faire tourner un serveur ou/et de se connecter sur une machine distante.
tu as aussi du TPE ce qui peut etre fort utile vu que l'user en question ne pourra lancer aucun binaire qu'il aurait réussi a compiler on ne sait comment si ce binaire n'est pas dans un répertoire donné avec les droits qui vont bien (tm)
apres si tu rajoutes a cela une couche d'acl ca devient tres correct je pense , ce n'est pas parfait comme la perfection n'existe pas mais ce n'est a priori pas le quidam moyen qui arrivera a faire quelque chose sur ta machine
(par contre la conf des regles acl ... )

 
 
nan mais sérieux tomate, fait un effort  

c pour cela ke quand on crée des règles iptables, on bloque d'abord TOUS les ports, et on n'ouvre uniquement que ceux dont on a besoin : 80 pour http, 21 pour ftp, 22 pour ssh, ..... et on ne pourra accéder k'à ces ports là (théoriquement).

c est toi ki comprend pas la
 
si tu fermes tout en sortie sauf certains ports et ke ton virus utilise un port a la con, il est baisé

ouai ça c'est la base, je suis d'accord, mais doit bien y avoir des trojans qui se connectent eux même sur un serveur distant plutot que d'écouter ... et là tu l'as dans le cul

et il sait bloqué les programmes qui tente d'écouter en udp ou tcp, quelque soit l'utilisateur, sans bloquer les acces "normaux" ?

par le biais des acl tu peux correctement limité une application(par la j'entends *un* binaire donné sur un path donné  ) .
cad que tu peux l'autoriser ou pas a se binder sur une ip donnée , sur un port donné , sur un protocole tcp/udp donnée lui autoriser l'acces ou non aux sockets unix .l'autoriser ou non a se connecter a une ip distante . de meme tu peux limiter le nombre de fois possible que cette appli peut se casser la gueule , la taille maximale utilisable par l'application en mémoire bref y a un tas de choses

oui mais compliqué d'autant plus que pour grsec 2.x spender n'a toujours pas sorti de documents donc j'ai pu d'acl chez moi
http://www.grsecurity.net/
ah oui avec les acl tu limites le pourvoir du root
donc si par hasard quelqu'un parvenais a devenir root il serait quand meme un poil emmerdé car par exemple par défaut /etc est en readonly  

oui mais compliqué d'autant plus que pour grsec 2.x spender n'a toujours pas sorti de documents donc j'ai pu d'acl chez moi
http://www.grsecurity.net/
ah oui avec les acl tu limites le pourvoir du root
donc si par hasard quelqu'un parvenais a devenir root il serait quand meme un poil emmerdé car par exemple par défaut /etc est en readonly  

qui a le droit de conf la machine, modifier les acls etc ... alors

ah ok, et tu fais la liste des acl pour chaque démon que tu veux autoriser ... 't1 c'est bien ça
du coup les démon non connu, ils l'ont dans le cul, ils peuvent rien faire par le réseau, c'est ça ? et on peut faire ça que par grsec ? (et SELinux peut-être) ?

qui a le droit de conf la machine, modifier les acls etc ... alors

y a un super admin au dessus de root

faut rebooter la machine sur un autre noyau j'imagine  

ca ne fait que reporter le probleme alors ?

non.
tu as des 'roles' qui apparraissent
enfin il y a eu un netchangement par rapport au 1.9
par exemple dans le 1.9 il y avait qu'un statut d'admin on dira
dans le cas grsec 2.0 on peut ajouter une foultitude de rôle .
dans la meme série passer d'un rôle a l'autre semble devoir suivre un cheminement particulier mais bon j'ai aucune doc sur grsec 2.x donc je vais peut etre dire des conneries

non.
tu as des 'roles' qui apparraissent
enfin il y a eu un netchangement par rapport au 1.9
par exemple dans le 1.9 il y avait qu'un statut d'admin on dira
dans le cas grsec 2.0 on peut ajouter une foultitude de rôle .
dans la meme série passer d'un rôle a l'autre semble devoir suivre un cheminement particulier mais bon j'ai aucune doc sur grsec 2.x donc je vais peut etre dire des conneries

1) faut savoir qu'il y a grsec d'installer & que les acl tournent  
2) tu peux limité le nombre d'essai possible pour se logguer en superadmin sur une période donnée .
dans le meme genre tu as bien sur les logs qui vont bien avec
bref ca rulezz bien

ah ok, enfin la solution du rebootage, ça me paraissait bien secure quand même

donc tu éparpilles les droits de conf sur plusieurs users
root1 a le droit de faire ca et pas ca  
pour accéder à root2 faut passer par root1 puis root3 puis root25
root2 peut faire si et ca mais pas trucbdule
etc ..
 
c'est ca ? (traduit dans ma langue à moi)

donc tu éparpilles les droits de conf sur plusieurs users
root1 a le droit de faire ca et pas ca  
pour accéder à root2 faut passer par root1 puis root3 puis root25
root2 peut faire si et ca mais pas trucbdule
etc ..
 
c'est ca ? (traduit dans ma langue à moi)

bof  
logiquement tu fous déja le PAX & grsec en dur sans passer par systcl .( il y a une possibilité de configuration envisagable par ce biais de grsec en fin de certains features de grsec )
apres comme tu un vrai sauvage tu enclenches les acl en rc 2. en premier donc ca rulezz bien
ceci dit faut vérifier quand meme que ces acls sont corrects car par exemple sp18 avait oublié de se donner l'acces au binaire qui passait en superadmin , obligé de redémarrer sa machine car le root avec les acls ne sert pas a grand chose

on avait vu    

et PAX, ça fait quoi ?

merci