Pour iptables pour voir s'il est actif, fais un iptables -L en shell root.
Ton serveur et ta station de travail sont sur le même LAN?
la communauté d'entraide francophone dédiée au PHP
Sécurité serveur
le résultat d' iptables -L me donne cela
chain INPUT (policy ACCEPT) target prot opt source destination
chain FORWARD (policy ACCEPT) target prot opt source destination
chain OUTPUT (policy ACCEPT) target prot opt source destination
Effectivement je pense que oui, ma config est la suivante le serveur est branché sur la Livebox via cable ethernet et j'ai deux PC sous windows qui se connectent en Wifi sur la Livebox
chain INPUT (policy ACCEPT) target prot opt source destination
chain FORWARD (policy ACCEPT) target prot opt source destination
chain OUTPUT (policy ACCEPT) target prot opt source destination
Effectivement je pense que oui, ma config est la suivante le serveur est branché sur la Livebox via cable ethernet et j'ai deux PC sous windows qui se connectent en Wifi sur la Livebox
Un peu vide ces tables netfilter!chain INPUT (policy ACCEPT) target prot opt source destination
chain FORWARD (policy ACCEPT) target prot opt source destination
chain OUTPUT (policy ACCEPT) target prot opt source destination
Essaye ceci (script bash. Tu sais comment faire pour le rendre exécutable, je suppose)
Code : Tout sélectionner
#!/bin/sh
# Script de démarrage iptables
# variables
MON_LAN="192.168.0.0/24" # ici le masque de ton réseau LAN
MON_SERVEUR="192.168.0.xxx" # l'IP de ton serveur
# Initialisation (on flush tout! - flush = tirer la chasse!)
iptables -F
iptables -X
# Règles par défaut pour les datagrammes qui passeraient au travers
# des règles ci-dessous
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT ACCEPT
# Autorisation de loopback (logique)
iptables -A INPUT -i lo -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT
# Autorisation des connexions déjà établies
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# Accepter tout trafic ICMP depuis le réseau local:
iptables -A INPUT -s ${MON_LAN} -d ${MON_SERVEUR} -p icmp -j ACCEPT
# Autorisation accès SSH
iptables -A INPUT -s ${MON_LAN} -d ${MON_SERVEUR} -p tcp --dport 22 -j ACCEPT
# Autorisation accès APACHE:80 (tout le monde)
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
# Règle de fin de chaîne pour journaliser les paquets
# qui arriveraient jusqu'ici (et qui seront DROPpés par la Policy rule)
iptables -A INPUT -j LOG --log-prefix '[FW DROP]'
Si tu fais une mauvaise manip, tu peux bloquer toute connexion , y compris ssh depuis ta station windows. Mais comme tu es en local, pas de souçis, tu vas en console sur ton serveur et:
Code : Tout sélectionner
/etc/init.d/iptables clearCeci est un point de départ pour jouer avec netfilter. C'est un script minimum. Je t'encourage à suivre un tuto ou deux:
http://olivieraj.free.fr/fr/linux/infor ... index.html
http://www.linux-france.org/prj/inetdoc ... index.html
http://www.cgsecurity.org/Articles/netfilter.html
ripat
Merci Ripat
J'ai créé ce script qui semble bien tourner.
Je l'ai adapté car en fait tel quel je ne pouvais plus me connecter sur mon serveur sur le port 22 et/ou 10000. J'ai donc rajouter une ligne sup pour chaque port pour accepter la connexion depuis mon portable (je vais demander à mon administrateur réseau de mon bureau une IP fixe afin de ne pas avoir à la changer dans le script à chaque fois que je change d'IP...).
Une fois le script lancé et quand je lance nmap sur mon IP externe je vois en fait 4 ports: le 22 et le 10000 filtered et le 80 et le 53 open...
cela me semble pas mal.
Cependant, j'ai lu sur l'un de tes liens que tu m'as indiqué (que je connaissais déjà mais n'avait pas encore bien parcouru) celui d'Olivier Allard une possiblité de masquer comme filtered l'ensemble des ports de mon serveur vis à vis de l'extérieur via nmap en utilisant le module ip_conntrack.
J'ai essayé en suivant l'exemple donné de l'adapter à mon environnement mais pour le moment
c'est pas encore ça.
Dans son exemple les adresses de -s et/ou -d sont indiquées soit 0.0.0.0/0 et/ou selon 10.0.0.1
dois-je les remplacer par mes paramètres et si oui lesquels
Dernière question concernant le port 53 domain qui gère le domain DNS, dois-je aussi le masquer voire le stopper ?
Merci pour tout
A+
KROC69
J'ai créé ce script qui semble bien tourner.
Je l'ai adapté car en fait tel quel je ne pouvais plus me connecter sur mon serveur sur le port 22 et/ou 10000. J'ai donc rajouter une ligne sup pour chaque port pour accepter la connexion depuis mon portable (je vais demander à mon administrateur réseau de mon bureau une IP fixe afin de ne pas avoir à la changer dans le script à chaque fois que je change d'IP...).
Une fois le script lancé et quand je lance nmap sur mon IP externe je vois en fait 4 ports: le 22 et le 10000 filtered et le 80 et le 53 open...
cela me semble pas mal.Cependant, j'ai lu sur l'un de tes liens que tu m'as indiqué (que je connaissais déjà mais n'avait pas encore bien parcouru) celui d'Olivier Allard une possiblité de masquer comme filtered l'ensemble des ports de mon serveur vis à vis de l'extérieur via nmap en utilisant le module ip_conntrack.
J'ai essayé en suivant l'exemple donné de l'adapter à mon environnement mais pour le moment
c'est pas encore ça.Dans son exemple les adresses de -s et/ou -d sont indiquées soit 0.0.0.0/0 et/ou selon 10.0.0.1
dois-je les remplacer par mes paramètres et si oui lesquels Dernière question concernant le port 53 domain qui gère le domain DNS, dois-je aussi le masquer voire le stopper ?
Merci pour tout
A+
KROC69
0.0.0.0/0 est un alias de anywhere (toutes les IP)
10.0.0.1 est, sans doute l'ip du serveur à protéger dans l'exemple que tu as trouvé.
Pour le serveur DNS, c'est à toi de voir s'il est strictement nécessaire. Si tu n'as que 3 machines, ce n'est pas la mer à boire que d'éditer 3 /etc/hosts.
10.0.0.1 est, sans doute l'ip du serveur à protéger dans l'exemple que tu as trouvé.
Pour le serveur DNS, c'est à toi de voir s'il est strictement nécessaire. Si tu n'as que 3 machines, ce n'est pas la mer à boire que d'éditer 3 /etc/hosts.
ripat
Me revoulou
Juste donc pour faire le point après moults essais je suis arrivé à ce qu'un scan depuis un service sur le net de scan de port en ligne m'indique n'avoir trouvé que le port 80 d'ouvert (ce qui est normal dans mon cas...) et tous les autres ports qu'il teste sont inaccessibles donc pour lui masqués
cela me semble pas mal comme résultat.
J'ai aussi réussi à faire en sorte que malgré/grâce à mes filtrages mon serveur reste accessible depuis mon pc windows via les ports 22/10000 donc en sécurité je pense.
Par contre lorsque je teste moi-même mon serveur via nmap, il m'indique qu'effectivement le port 80 est ouvert mais il affiche les ports 22-53-10000 comme filtered et je me demande si c'est logique car quelqu'un de l'extérieur qui ferais la même commande aurait donc la même réponse et je ne suis pas sûr que cela soit top question sécurité, non? 
A+
KROC69
Juste donc pour faire le point après moults essais je suis arrivé à ce qu'un scan depuis un service sur le net de scan de port en ligne m'indique n'avoir trouvé que le port 80 d'ouvert (ce qui est normal dans mon cas...) et tous les autres ports qu'il teste sont inaccessibles donc pour lui masqués
cela me semble pas mal comme résultat.J'ai aussi réussi à faire en sorte que malgré/grâce à mes filtrages mon serveur reste accessible depuis mon pc windows via les ports 22/10000 donc en sécurité je pense.
Par contre lorsque je teste moi-même mon serveur via nmap, il m'indique qu'effectivement le port 80 est ouvert mais il affiche les ports 22-53-10000 comme filtered
et je me demande si c'est logique car quelqu'un de l'extérieur qui ferais la même commande aurait donc la même réponse et je ne suis pas sûr que cela soit top question sécurité, non? A+
KROC69
Alors c'est tout bon:
filtered veut dire que nmap bute sur un firewall ou un tcp wrapper (inetd, xinetd)
closed le port est ouvert mais il n'y a pas de service à l'écoute. Ouvre le port 22 sur ton fw et stoppe ton sshd (/etc/init.d/ssh stop) et refais un nmap -P0. Tu verras.
Si tu fais un:
nmap -P0 -p yy xxx.xxx.xxx.xxx sur un site dont tu sais qu'il se trouve derrière un pare-feu, tu auras sûrement un retour filtered. Tu peux mettre n'importe quel port en yy, tu auras la même réponse.
Te voilà suffisamment avancé maintenant. Le reste est une question d'essais-erreurs.
filtered veut dire que nmap bute sur un firewall ou un tcp wrapper (inetd, xinetd)
closed le port est ouvert mais il n'y a pas de service à l'écoute. Ouvre le port 22 sur ton fw et stoppe ton sshd (/etc/init.d/ssh stop) et refais un nmap -P0. Tu verras.
Si tu fais un:
nmap -P0 -p yy xxx.xxx.xxx.xxx sur un site dont tu sais qu'il se trouve derrière un pare-feu, tu auras sûrement un retour filtered. Tu peux mettre n'importe quel port en yy, tu auras la même réponse.
Te voilà suffisamment avancé maintenant. Le reste est une question d'essais-erreurs.
ripat
Super
Effectivement comme je le pensais le reste est un jeu d'essais-erreurs que je vais aussi appliquer sur SNORT afin qu'il arrête de m'envoyer des alertes sur des adresses qui manifestement sont bonnes
Donc je pense qu'on peut dire que mon serveur est SECURISE
Grand merci surtout à toi RIPAT de ton aide et de ta patience.
Comme je ne sais pas le faire je remercie d'avance l'un de nos administrateurs de mettre RESOLU sur ce topic
Bon allez encore un peu de mains dans le cambouis et c'est tout bon
A+
KROC69
Effectivement comme je le pensais le reste est un jeu d'essais-erreurs que je vais aussi appliquer sur SNORT afin qu'il arrête de m'envoyer des alertes sur des adresses qui manifestement sont bonnes
Donc je pense qu'on peut dire que mon serveur est SECURISE
Grand merci surtout à toi RIPAT de ton aide et de ta patience.
Comme je ne sais pas le faire je remercie d'avance l'un de nos administrateurs de mettre RESOLU sur ce topic
Bon allez encore un peu de mains dans le cambouis et c'est tout bon
A+
KROC69
Hum... Ne poste pas ceci sur un site de black hat hackers, c'est une invitation à essayer.Donc je pense qu'on peut dire que mon serveur est SECURISE
Ca me rappelle l'histoire de SCO (les sois-disant propriétaires des droits Unix), qui sont en procès contre IBM, Novell, Red Hat et, indirectement, contre toute la communauté Linux (plus volatile, il est vrai!) au sujet d'une prétendue utilisation de code Unix dans Linux. Bref, certains fanatiques Linux (extrémistes?) avait annoncé une attaque DDoS contre SCO pour une certaine date et heure.
Ha, ha! ricana Darl McBride (SCO), les idiots, et ils nous préviennent encore. Pour nous donner le temps de nous défendre, nous les rois du Unix.
Et bien, au jour J heure H l'attaque commença et tous les serveurs de SCO sont tombés!
Moralité, on est jamais à l'abri de black hat hackers déterminés.
ripat
Rien ne protège d'un dDos bien monté, donc autant ne pas les prendre en compte à mon avis, et considéré un serveur comme "sécurisé" quand ce n'est pas le premier hacker venu qui saura faire chuter le serveur.
Et puis la sécurisation ce n'est pas la garantie de fonctionnement, c'est la garantie que les données ne seront pas volées/modifiées
Et puis la sécurisation ce n'est pas la garantie de fonctionnement, c'est la garantie que les données ne seront pas volées/modifiées
Merci Ripat de ce petit rappel effectivement très utile
Bon on pourrait dire aussi qu'il serait fort peu probable qu'il y ait un tel personnage au sein de cette forte aimable communauté
Mais tu as raison on est jamais trop prudent
Tiens au fait j'ai rajouté à mon fichier iptables un petit script pour empêcher le ping au cas...
Bon allez maintenant la suite....
A+
KROC69
Exact. Mais le plus drôle, dans le cas de SCO c'est qu'il s'agissait, d'après SCO elle-même, d'attaques distribuées de type "SYN flood". Tout simplement. Pas très sohistiqué comme attaque. Un simple règle dans netfilter et on s'en protège:Rien ne protège d'un dDos bien monté, donc autant ne pas les prendre en compte à mon avis (...)
Code : Tout sélectionner
iptables -A INPUT -p tcp --syn -m limit --limit 1/m -j ACCEPT Mais certains experts en sécurité ont des doutes sur les déclarations de SCO sur le type d'attaque:
http://www.groklaw.net/article.php?stor ... 0163721614
J'adore ce procès fleuve dans le plus pur style Américain. Je pense avoir lu quelque part qu'il a déjà coûté plusieurs millions de USD à SCO dont la survie ne dépend plus que de l'issue heureuse à ce procès. Parce-que du côté de son activité en informatique, les revenus sont en chute libre. SCO ne compte donc plus que sur une victoire de son procès pour ne pas fermer boutique.
Résumé du feuilleton:
http://en.wikipedia.org/wiki/SCO_v._IBM_Linux_lawsuit
Et, la cerise sur le gâteau:
L'ensemble de la communauté Linux semble convaincue que la démarche de SCO fait partie d'un plan 'FUD' (Fear, Uncertainty, Doubt : peur, incertitude, doute) dont la source se situerait du côté de Redmond (Microsoft).
ripat
oula...le résultat d' iptables -L me donne cela
chain INPUT (policy ACCEPT) target prot opt source destination
chain FORWARD (policy ACCEPT) target prot opt source destination
chain OUTPUT (policy ACCEPT) target prot opt source destination
Effectivement je pense que oui, ma config est la suivante le serveur est branché sur la Livebox via cable ethernet et j'ai deux PC sous windows qui se connectent en Wifi sur la Livebox
policy ACCEPT?
Il te faut un policy DROP par default et ensuite autoriser seulement ce que tu veux...
le principe de base est d'exclure tout, et d'autoriser ensuite ce que tu veux...
nessus n'est pas un outil parfait, puisqu'il te trouve des exploits qui ont deja ete realisés, mais il te permettra deja de degrossir TRES GROSSIEREMENT l'architecture de ta securité...
rajoute des directives order deny,allow dans la conf de tes vhosts pour les ips qui sont autorisés ou refusées. Par exemple, il est impossible que ton interface ip se connecte a ton serveur.
donc order deny, allow
deny from ton_ip_publique
de toute facon, tu pouras pas securiser ton serveur a 100 %. d'une maniere generale, tu pourras le faire jusqu'a 80 % sans trop de probleme, apres ca sera exponentiel.
pour preuve, consulte les deux derniers magasines MISC, tu pourras voir quelques exemples d'attaque basées seulement sur le protocole HTTP. difficile de contrer ca...
bon courage
Bonsoir à tous
Me revoilou avec mon petit serveur perso et sa sécurité.
Pour le moment tout va bien du côté de mon serveur je suis en train de travailler mon site et alimenter ma base MySQL...
Par contre j'ai installé comme système d'alerte SNORT et BASE comme front-end et ainsi je surveille d'un oeil ce qui se passe et là j'ai une question somme toute assez basique je pense pour les spécialistes.
J'ai une alerte qui domine très nettement toutes les autres et qui aurait tendance à augmenter en terme de nombre et je dois avouer que je ne sais comment réagir face à elle:
MISC UPnP malformed advertisement
avec comme adresse source toujours mon adresse 192.168.1.1 qui correspond à mon routeur Livebox (qui je le précise à bien le service UpnP d'activer dans sa config) vers l'adresse 239.255.255.250 avec port de destination toujours le 1900 et en mode UDP...
J'ai lu des forums y compris chez SNORT et d'après ce que j'ai compris j'ai le choix soit de désactiver le service UPnP sur ma Livebox soit décommenter dans les règles d'alertes snort celle qui correspond à cette alerte..
Quelle politique dois-je tenir en sachant que je vois le nombre d'alertes de ce type atteindre plusieurs milliers parfois en un temps très court ? Est-ce vraiment dangereux pour mon serveur ?
Merci d'avance pour les commentaires/suggestions
A+
Kroc69
Me revoilou avec mon petit serveur perso et sa sécurité.
Pour le moment tout va bien du côté de mon serveur je suis en train de travailler mon site et alimenter ma base MySQL...
Par contre j'ai installé comme système d'alerte SNORT et BASE comme front-end et ainsi je surveille d'un oeil ce qui se passe et là j'ai une question somme toute assez basique je pense pour les spécialistes.
J'ai une alerte qui domine très nettement toutes les autres et qui aurait tendance à augmenter en terme de nombre et je dois avouer que je ne sais comment réagir face à elle:
MISC UPnP malformed advertisement
avec comme adresse source toujours mon adresse 192.168.1.1 qui correspond à mon routeur Livebox (qui je le précise à bien le service UpnP d'activer dans sa config) vers l'adresse 239.255.255.250 avec port de destination toujours le 1900 et en mode UDP...
J'ai lu des forums y compris chez SNORT et d'après ce que j'ai compris j'ai le choix soit de désactiver le service UPnP sur ma Livebox soit décommenter dans les règles d'alertes snort celle qui correspond à cette alerte..
Quelle politique dois-je tenir en sachant que je vois le nombre d'alertes de ce type atteindre plusieurs milliers parfois en un temps très court ? Est-ce vraiment dangereux pour mon serveur ?
Merci d'avance pour les commentaires/suggestions
A+
Kroc69