Debian-facile

puis faîtes un

Vous devriez obtenir un truc du genre

C'est sûrement PAM qui fout le bins

Faîtes un

Et vous devriez obtenir ensuite

Et là, normalement c'est bon, vos users virtuels ont bien été ajoutés

Toujours en étant dans le rep /etc/pure-ftpd/auth
Faites cela pour virer les authorisations unix inutiles dans votre cas

et après, vous aurez bien seulement que vos utilisateurs virtuels pour l'authentification de pure ftpd

Amicalement.

/!\Toute l'équipe de Debian Facile vous rappelle que l'usage d'un scanner ne doit être que pour son réseau personnel! Si une plainte est déposée à votre FAI, votre connexion internet sera coupée. Je rappelle que nous sommes constructifs, nous cherchons à nous préserver de ceux qui utilisent cet outil à des fins destructrices, pas à les imiter /!\

Il y a le FTP bounce scan (technique désuète de nos jours) qui permet de se connecter à un serveur FTP qui peut se trouver derrière un pare-feu.

Le TCP reverse ident scan permet de révéler le nom d’utilisateur d’un processus quelconque et d’obtenir des informations sur les serveurs.

Le Decoy scan, cette technique permet de camoufler l’identité de l’attaquant.

Le Fragmentation scan, l’idée est de diviser un paquet en plusieurs fragments IP, en fractionnant l’en-tête TCP, afin de s’infiltrer dans un système sécurisé.

Le Spoofed scan, cette technique permet de rediriger les paquets

L'est puissant le Nmap

Amicalement.

Voir le wiki : http://debian-facile.org/doc:systeme:mv

Peut être faut-il stopper apache ...? À vrai dire, je ne sais pas si l'on peut renommer se fichier, il est partie intégrante de apache... => http://technique.arscenic.org/lamp-linu … e-securite

Amicalement

Bah chez moi, avec ma machine en DMZ et quand ma mini livebox ne buggue pas , le scan est bon, j'ai fait tous les tests hormis le test rapide et la vitesse de connexion. Il a même trouvé lors du Stealth Test que des ports udp répondaient tandis que les tcp sont furtifs. 'Vais essayer de corriger cela.

Ceci dit, c'est basique mais je trouve l'idée pratique. Bien entendu, rien ne remplace un scan de son réseau avec des outils disponible comme l'évoquait vince



Édit

Merci JC1 pour le site que tu mentionnes, j'ai testé et tout semble OK

puis reprendre le tuto comme te l'a indiqué martinux_qc

Si t'as Optimus, voir le tuto http://debian-facile.org/doc:materiel:c … ia:optimus

Amicalement.

Lorus.

• Utiliser une faille ou un défaut de sécurité du logiciel pour pénétrer complète-
  ment le système : c’est l’exploit.

• Utiliser une faille du système pour exécuter du code : c’est installer un troyen,
  par exemple.Voir la liste de nos amis de Fédora => http://books.google.fr/books?id=zz8cDAF … ux&f=false, Brrrrrrr

• Utiliser une faille par accès distant répertorié.

/!\Toute l'équipe de Debian Facile vous rappelle que l'usage d'un scanner ne doit être que pour son réseau personnel! Si une plainte est déposée à votre FAI, votre connexion internet sera coupée. Je rappelle que nous sommes constructifs, nous cherchons à nous préserver de ceux qui utilisent cet outil à des fins destructrices, pas à les imiter /!\

Iptables supporte nativement la détection de scans avec l'option --tcp-flags, Nmap permet de pouvoir prévoir les futures attaques, avec plusieur type de scan entenant compte des six segments qui composent le protocole TCP: URG, ACK, SYN, FIN, PUSH, RST

• URG : Signale la présence de données URGentes

• ACK : Signale que le paquet est un accusé de réception (ACKnowledgement)

• PSH : Données à envoyer tout de suite (PuSH)

• RST : Rupture anormale de la connexion (ReSeT)

• SYN : Demande de synchronisation (SYN) ou établissement de connexion

• FIN : Demande la FIN de la connexion

Le scan en vanilla TCP connect qui est le scan par défaut de Nmap:

Les scans furtifs:
Le scan en connexion demi-ouverte, si un port est ouvert, il y a réponse positive

Le scan FIN consiste en l'envoi de paquets TCP avec seulement le flag FIN armé

Le scan NULL consiste en l'envoi de paquets TCP avec seulement le flag NULL armé

Le Xmas (joyeux noël ) scan consiste en l'envoi de paquets TCP avec les flags FIN/URG/PUSH armés.

L'otion -O permet de trouver le système d'exploitation:

Cette règle permet de détecter l'envoi un grand nombre de paquets TCP avec les flags précités...
Configurer Iptables pour empêcher les scans (ou les ralentir fortement)

Il faut noter que certains segments au niveau de la couche IP ou TCP sont propres à chaque système d'exploitation...
Chaque segment de la couche TCP a un but et celui-ci est déterminé, Ils permettent à l'expéditeur ou au destinataire de préciser quels indicateurs devraient être utilisés si le segment est géré correctement par l'autre extrémité.

Je détail un peu plus mon otion limit de ma règle:
Tout d'abord, ce module doit être spécifié explicitement avec `-m limit' ou `--match limit'
Comme vous pouvez le constater, le module  --limit bloque le nombre maximum de correspondances acceptées par seconde. On peut spécifier son unité explicitement, en utilisant `/second', `/minute', `/hour' ou `/day', ou en abrégé (ainsi `1/second' est identique à `1/s'). Cela peut être pratique pour un serveur en surcharge également.

Quant à l'option --tcp-flags elle vous permet de filtrer les requêtes excessives du à un scanner sur des protocoles TCP avec les flags FIN et/ou SYN et/ou ACK et/ou RST armé(s) etc....

Mon serveur était configuré avec cette option, je n'ai jamais eu de souci particulier! Mais une sécurité n'est jamais parfaite

Sinon il y a la méthode bourrin...

On drop (refuse) tous les fanions et puis c'est tout. Na, nan mais!


ÉDIT: j'ajoute que le scan peut avoir lieu sur le protocole UDP, ce protocole est apparu avec le développement des réseaux locaux dont la fiabilité permet de s'affranchir des fonctions de contrôle... À vous d'adapter votre règle Iptables en conséquence.

@MaTTux_: Finalement, avec un Iptable correctement configuré, Snort est-il utile?

Édit:

Rendez vous ici -> http://debian-facile.org/viewtopic.php?pid=56239#p56239