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... :roll:

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 ? :cry:

Merci d'avance pour les commentaires/suggestions

A+

Kroc69

[quote="KROC69"]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[/quote]
oula...
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 ;)

[quote="naholyr"]Rien ne protège d'un dDos bien monté, donc autant ne pas les prendre en compte à mon avis (...)[/quote]

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:

[code]iptables -A INPUT -p tcp --syn -m limit --limit 1/m -j ACCEPT[/code]

Encore faut-il utiliser Linux et pas Unix :wink:

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?story=20031210163721614

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:
[quote]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).[/quote]

:oops:

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é :wink:

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.... :wink:

A+

KROC69

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 ;)

[quote="KROC69"]Donc je pense qu'on peut dire que mon serveur est SECURISE[/quote]

Hum... Ne poste pas ceci sur un site de black hat hackers, c'est une invitation à essayer.

Ca me rappelle l'histoire de SCO (les sois-disant propriétaires des droits Unix), qui sont en [url=http://en.wikipedia.org/wiki/SCO_Group#The_Linux_Wars]procès contre IBM[/url], 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 [u]tous[/u] les serveurs de SCO sont tombés!

Moralité, on est jamais à l'abri de black hat hackers déterminés.

Super :D :D

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 :wink:

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 :wink:

Bon allez encore un peu de mains dans le cambouis et c'est tout bon :D

A+

KROC69

Alors c'est tout bon:

[b]filtered[/b] veut dire que nmap bute sur un firewall ou un tcp wrapper (inetd, xinetd)

[b]closed[/b] 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.

Me revoulou :lol:

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 :D 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

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.

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... :lol: 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 :cry: 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

[quote="KROC69"]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
[/quote]

Un peu vide ces tables netfilter!

Essaye ceci (script bash. Tu sais comment faire pour le rendre exécutable, je suppose)

[code]#!/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]'
[/code]

:!: 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]/etc/init.d/iptables clear[/code]

Ceci remettra tout en ACCEPT.

Ceci 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/information/firewall/index.html
http://www.linux-france.org/prj/inetdoc/guides/iptables-tutorial/index.html
http://www.cgsecurity.org/Articles/netfilter.html

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

Pour iptables pour voir s'il est actif, fais un [b]iptables -L[/b] en shell root.

Ton serveur et ta station de travail sont sur le même LAN?

Bonjour

Merci Ripat pour tes conseils/soutiens :oops:

En fait ce n'est pas le port 55 qui est ouvert mais le port 53 domain d'où je pense l'alerte de sécurité de Nessus...

Quand au port 10000 c'est simplement parce que j'ai installé la console d'admin à distance Webmin qui nécessite par défaut (mais peu se changer semble-t-il) l'accès au serveur via le port 10000 en mode https.

D'ailleurs à ce propos de Webmin, c'est via l'un des modules Linux firewall que j'essaie de contrôler l'accès à mes ports, et au vu de ta réponse concernant le port 22 et les solutions possibles (qui je dois l'avouer est encore un peu obscure :oops: ) je me demande si je ne l'ai pas déjà installé car il utilise iptables semble-t-il...mais bon je vais revoir la question et tenter de mettre en place ta soluc page secrète qui effectivement me semble parfaitement correspondre à une bonne approche sur ce port. Je l'utilise assez régulièrement pour me connecter sur le serveur via putty et winscp (je travaille mon site web sur Dreamweaver puis je fais une syncronisation des répertoires local/distant sur le serveur avec, très très pratique).

Merci encore de ton aide for précieuse :lol:

A+

Kroc69