Politique de sécurité informatique par exemple configuration pare-feu et DNS

L’article suivant tente d’aborder les thèmes de la politique de sécurité à l’aide d’un pare-feu et d’un dns. Il peut être utilisé dans votre entreprise dans son intégralité ou comme un modèle pour la croissance ultérieure.

Pare-feu

1.Le pare-feu vise à rendre votre organisation plus sûre en :

 

  • Bloquer les tentatives d’accès non autorisé (contrôle et restriction de l’accès au réseau interne).
  • L’inspection du trafic réseau à plusieurs niveaux (m.in pare-feu effectue un contrôle en fonction des adresses IP, de la direction et de l’état des connexions, des protocoles et des applications, des utilisateurs individuels).
  • Création de zones de sécurité et modélisation des caractéristiques du trafic entre elles.
  • Masquer l’organisation interne et la structure du réseau.
  • Surveillance des zones de sécurité pour générer des alarmes appropriées.
  • Collecter des journaux sur les événements et fournir des statistiques et des rapports.

2. À l’entreprise, agd.com le trafic extérieur est limité à l’accès à son site Public Business à l’extérieur au port 443. La partie administrative du site n’est accessible qu’à partir du réseau interne du port 8080. Le service dns est disponible sur le port 53. En outre, une connexion au serveur de messagerie sur le port 110, au port 3306 pour les connexions à la base de données et à un port 2020 est ouverte au port SSH pour l’administration à distance du serveur.

 

3. La procédure suivante s’adresse aux administrateurs de réseau et ne doit pas être divulguée aux personnes non autorisées:

 

  • Le script détaillé iptables est secret et se trouve dans un coffre-fort au 8ème étage de l’immeuble A. Vous devez le suivre si vous modifiez la configuration du pare-feu. L’administrateur principal du réseau est autorisé à le faire.

 

Le pare-feu est configuré à l’aide d’un script pour iptables qui ressemble à ceci:

-!/bin/sh
##############################################################################
IPTABLES-iptables
PATH"/usr/sbin »
Adresse du serveur 
SERVEUR="192.168.1.3 »
 
# Adresse de l’ordinateur de l’administrateur 
ADMIN-« 192.168.1.10 » 

# Espace d’adresse de notre réseau en ligne et carte que je prends en charge 
WEW_NET="192.168.1.0/24 »
WEW_DEV-« eth0 »
 
# Adresse de dégagement - externe et carte de service
ZEW_NET"0/0 »   
ZEW_DEV"eth1 »
 
# Services TCP que nous voulons passer  
TCP_IN"ssl, » 443, 53
TCP_OUT"ssl, » 443, 53
  
# Services UDP,que nous passons
UDP_IN"443 »
UDP_OUT »
 
# Services ICMP que nous voulons faire passer 
ICMP_IN »
ICMP_OUT »
 
#################################################################################
 
# Supprimer les règles précédentes
$IPTABLES -F INPUT
$IPTABLES -F FORWARD
$IPTABLES -F OUTPUT
 
# Définir une politique par défaut 
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT ACCEPT  
$IPTABLES -P FORWARD DROP
 
# Nous écrivons tout notre trafic dans les journaux 
$IPTABLES -A INPUT -j LOG -m limit --limit 15/hor              
$IPTABLES -A OUTPUT -j LOG -m limit --limit 15/hour
$IPTABLES -A FORWARD -j LOG -m limit --limit 15/hour
 
# Nous élisons la puissance de la commande de la boîte 
modprobe ip_conntarck
modprobe ip_conntarck_ftp
 
# Nous élisons les réponses aux pings
echo « 1 » > /proc/sys/net/ipv4/icmp_echo_ignore_all
 
# Protection contre les attaques de type Schtroumpf 
echo « 1 » > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
 
# Nous protections la protection contre la communication ICMP erreur 
echo « 1 » > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
 
# Allume la connexion paquets étranges (usurpé source routed. redirects) 
echo « 1 » > /proc/sys/net/ipv4/conf/all/log_martians
 
# Nous n’acceptons pas le datagramme IP avec l’option « source route »
echo « 0 » > /proc/sys/net/ipv4/conf/all/accept_source_route
 
# Nous n’acceptons pas les paquets ICMP redict qui peuvent changer nos tableaux de routage
echo « 0 » /proc/sys/net/ipv4/conf/all/accept_redirects
 
# Toutes les cartes ne seront pas acceptées avec des paquets d’autres que ceux
# à partir du tableau de routage 
echo « 1 » /proc/sys/net/ipv4/conf/all/rp_filter
 
# Nous laissons les paquets courir sur notre ordinateur
# c’est-à-dire déverrouiller petle retour LOOPBACK
$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A OUTPUT -o lo -j ACCEPT
 
# Nous permettons de coq avec le protocole en mode passif sur
$IPTABLES -A INPUT -m state --state ESTABLISHED, RELATED -j ACCEPT
  
# Débloquer des services sur le serveur pour d’autres édifiants de l’extérieur
 
-$IPTABLES -A INPUT -p tcp -s 0/0 --dport 443 -j ACCEPT 
-$IPTABLES -A INPUT -p udp -s 0/0 --dport 443 -j ACCEPT 
 
$IPTABLES -A INPUT -p tcp -s 0/0 --sport 443 -j ACCEPT 
$IPTABLES -A INPUT -p udp -s 0/0 --sport 443 -j ACCEPT 
 
# Déverrouiller les services sur le sérum pour une adresse IP donnée - KOMP voir ci-rès définitions TCP_IN, UDP_IN
 
-$IPTABLES A INPUT -p tcp -s $KOMP -m multiport --dport $TCP_IN -j ACCEPT
    -$IPTABLES $ INPUT -p udp -s $KOMP -m multiport --dport $UDP-IN -j ACCEPT
 
-$IPTABLES -A INPUT -p udp -s $KOMP --dport 137:139 -j ACCEPT ' protokol udp
 
# Nous autorisons tout à partir d’une adresse IP donnée – l’administration à partir de cette adresse J
 
$IPTABLES -A INPUT -s $KOMP -j ACCEPT # c’est pourquoi les règles ci-dessus sont désassapérées
 
Accès à DNS
 
$IPTABLES -A INPUT -p tcp -s 0/0 --sport 53 -d $SERWER -j ACCEPT
$IPTABLES -A INPUT -p udp -s 0/0 --sport 53 -d $SERWER -j ACCEPT
 
-$IPTABLES -A OUTPUT -p tcp -s $SERWER -d 0/0 --dport 53 -j ACCEPT
-$IPTABLES -A OUTPUT -p udp -s $SERWER -d 0/0 --dport 53 -j ACCEPT
  
# Nous fermons les paquets avec une adresse de parenté définie sur notre
 
$IPTABLES -A INPUT -i $WEW_DEV -s $SERWER -j DROP # attaque Land
 
# Forfaits avec adresses non routées, multidiffusion et réservées
 
$IPTABLES -A INPUT -i $WEW_DEV -s 10.0.0.0/8 -j DROP #class A
$IPTABLES -A INPUT -i $WEW_DEV -s 172.16.0.0/12 -j DROP #class B
#$IPTABLES -A INPUT -i $WEW_DEV -s 192.168.0.0/16 -j DROP #class C - nous utilisons cela
$IPTABLES -A INPUT -i $WEW_DEV -s 224.0.0.0/4 -j DROP #multicast
$IPTABLES -A INPUT -i $WEW_DEV -d 224.0.0.0/4 -j DROP #multicast
$IPTABLES -A INPUT -i $WEW_DEV -s 240.0.0.0/5 -j DROP #reserved
$IPTABLES -A INPUT -i $WEW_DEV -s 127.0.0.0/5 -j DROP #lo
 

  • Nous écrivons ce script avec les droits d’accès 700 et nous exécutons sur le serveur.
  • Ensuite, lorsque vous exécutez le script pare-feu, nous allumons le stockage des journaux. Pour ce faire, nous tapons le code suivant à la fin du fichier /etc/syslog.conf:
*.* /dev/tty12 
*.* /var/log/pare-feu
  • Nous redémarrons le démon syslogd:
 Killall -HUP syslogd
  • A partir de ce moment, nous aurons tous les journaux système dans le fichier /var/log/firwall (également sur la console 12 – alt+12).

4. Les modifications apportées à la configuration du pare-feu ne peuvent être apportées que par l’administrateur réseau principal. Cela se fait par le biais d’une demande de téléchargement 43 auprès des administrateurs de réseau, qui doit être approuvée par le chef de l’informatique.

5. Seuls les dirigeants informatiques individuels peuvent demander des modifications à la configuration du pare-feu.

6. En cas de suspension du pare-feu, les administrateurs réseau sont responsables de sa réinitialisation ou, à l’extrême, de la surtension du serveur de secours.

7. Vous ne devez pas modifier la configuration du pare-feu en fonction d’une demande d’une personne non vérifiée.

8. Toutes les mises à jour du système d’exploitation et des applications utilisées doivent être installées dès leur apparition. Si cette instruction interfère avec le fonctionnement des systèmes de production critiques, des mises à jour doivent être effectuées dès que possible.

9. L’audit de la validité des paramètres doit être effectué une fois par trimestre par les administrateurs du réseau.

  • Il peut l’exécuter à l’aide de l’outil nmap du réseau externe avec la commande :
nmap -p 1-65535 -T4 -A -v firma.com -Pn
  • Le résultat devrait être le suivant:
Rapport d’analyse Nmap pour agd.com (x.x.x.x)
Host est en place (0.00047s latence).
Non affiché: 65533 ports filtrés
VERSION DU SERVICE D’ÉTAT DU PORT
53/tcp ouvert tcpwrapped
443/tcp ouvert tcpwrapped
  • En cas de non-conformité, ce fait doit être signalé au principal administrateur du réseau chargé de la vulnérabilité.

DNS (DNS)

1. La sécurité de la configuration DNS repose sur trois principes fondamentaux :

  • Le serveur doit répondre à tout membre seulement du domaine qu’il exploite;
  • Répondre à chaque question SEULEMENT sur le réseau qu’il exploite;
  • Permet de transférer ses domaines seulement à ses serveurs enfants;

2. Les modifications apportées à la configuration dns ne peuvent être apportées que par l’administrateur réseau principal. Cela se fait par le biais d’une demande de téléchargement 45 auprès des administrateurs de réseau, qui doit être approuvée par le chef de l’informatique.

3. Seuls les responsables informatiques individuels peuvent demander des modifications à la configuration dns.

4. Vous ne devez pas modifier la configuration du pare-feu en fonction d’une demande d’une personne non vérifiée.

5. En cas de suspension du DNS, les administrateurs réseau sont responsables de sa réinitialisation ou, dans le cas extrême, de la surtension vers le serveur de secours.

6. Toutes les mises à jour du système d’exploitation et des applications utilisées doivent être installées dès leur apparition. Si cette instruction interfère avec le fonctionnement des systèmes de production critiques, des mises à jour doivent être effectuées dès que possible.

7. La configuration suivante s’adresse aux administrateurs réseau et ne doit pas être divulguée aux personnes non autorisées:

Chez agd.com DNS est basé sur le service BIND dns et ressemble à ceci :

  • Avant la section Options globales du fichier named.conf.options, définissez qui peut interroger le serveur sur n’importe quel domaine :
Avant la section Options globales du fichier named.conf.options, définissez qui peut interroger le serveur sur n’importe quel domaine
  • Vous devez ensuite configurer les paramètres pour savoir qui peut poser des questions sur notre domaine :
Ensuite, vous devez configurer les paramètres pour qui peut poser des questions sur notre domaine
  • Une attention particulière doit être accordée à la directive allow transfer, qui peut révéler toutes les entrées dans notre domaine. Si nous n’avons pas de serveurs de secours, nous bloquons cette option comme dans l’entrée ci-dessus.
  • La prochaine étape consiste à vérifier la validité de la configuration.
    • Pour ce faire, nous pouvons utiliser l’outil dig.
    • Nous vérifions le verrouillage de la question de notre serveur sur d’autres adresses, ce qui en fait à partir d’un autre réseau:
creuser @ip_naszego_serwera jakieś_inne_ip 
  • le résultat de l’action devrait être similaire à celui suivant:
<>> DiG 9.3.2 <> > 'agd.com wp.pl A
		 ; (1 serveur trouvé)
		 ;; options mondiales: printcmd
		 ;; J’ai eu une réponse:
		 ;; ->>HEADER<- opcode: QUERY, status: REFUSED, id: 65151
		 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
  • Nous examinons la possibilité de transférer un domaine via un serveur externe:
creuser agd.com AXFR
  • Le résultat de l’action devrait être similaire à celui suivant:
<>> DiG 9.3.2 <> > agd.com AXFR
;; options mondiales: printcmd
; Transfert échoué.
  • En cas de non-conformité, ce fait doit être signalé au principal administrateur du réseau chargé de la vulnérabilité.

Chcesz wiedzieć więcej?

Zapisz się i bądź informowany o nowych postach (zero spamu!). Dodatkowo otrzymasz, moją prywatną listę 15 najbardziej przydatnych narzędzi (wraz z krótkim opisem), których używam przy testach penetracyjnych.

Nigdy nie podam, nie wymienię ani nie sprzedam Twojego adresu e-mail. W każdej chwili możesz zrezygnować z subskrypcji.

Pour marque-pages : Permaliens.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *