La sécurité du système n'est pas une tâche unique. Au contraire, il existe de nombreuses couches dans l'approche d'une organisation en matière de sécurité. Certaines de ces couches sont la sécurité physique des centres de données, les correctifs et la maintenance réguliers de l'infrastructure, la sensibilisation continue des utilisateurs et l'analyse des systèmes pour détecter les problèmes. Cet article explique comment utiliser le nmap et nc commandes pour analyser un système afin que vous puissiez déterminer les prochaines étapes appropriées. J'utilise ici quelques systèmes dans mes exemples. Le système qui effectue l'analyse est mon ordinateur local Red Hat Enterprise Linux (RHEL) 8.3, opendemo.usersys.redhat.com est le système Red Hat Satellite 6.8 utilisé car il a plusieurs ports ouverts et j'ai plusieurs systèmes cibles.
[ Vous pourriez également aimer : Sécurité de l'administrateur système :8 contrôles de verrouillage Linux ]
Analyses de base
Pour voir les ports utilisés sur mon serveur Satellite, je me connecte en SSH au serveur, puis j'utilise netstat :
[root@opendemo ~]# netstat -tlpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:27017 0.0.0.0:* LISTEN 1443/mongod
tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 1197/redis-server 1
tcp 0 0 0.0.0.0:5646 0.0.0.0:* LISTEN 1132/qdrouterd
tcp 0 0 127.0.0.1:8751 0.0.0.0:* LISTEN 1194/python
tcp 0 0 0.0.0.0:5647 0.0.0.0:* LISTEN 1132/qdrouterd
tcp 0 0 127.0.0.1:19090 0.0.0.0:* LISTEN 1237/cockpit-ws
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1175/sshd
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 1242/postmaster
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1396/master
tcp 0 0 0.0.0.0:9090 0.0.0.0:* LISTEN 1138/ruby
tcp 0 0 127.0.0.1:45285 0.0.0.0:* LISTEN 28650/Passenger Rack
tcp 0 0 127.0.0.1:5671 0.0.0.0:* LISTEN 1140/qpidd
tcp 0 0 0.0.0.0:8008 0.0.0.0:* LISTEN 1240/ruby
tcp 0 0 127.0.0.1:5672 0.0.0.0:* LISTEN 1140/qpidd
tcp6 0 0 :::8140 :::* LISTEN 2101/java
tcp6 0 0 127.0.0.1:61613 :::* LISTEN 1135/java
tcp6 0 0 :::5646 :::* LISTEN 1132/qdrouterd
tcp6 0 0 :::5647 :::* LISTEN 1132/qdrouterd
tcp6 0 0 :::80 :::* LISTEN 1131/httpd
tcp6 0 0 :::22 :::* LISTEN 1175/sshd
tcp6 0 0 ::1:5432 :::* LISTEN 1242/postmaster
tcp6 0 0 :::3128 :::* LISTEN 1258/(squid-1)
tcp6 0 0 ::1:25 :::* LISTEN 1396/master
tcp6 0 0 127.0.0.1:8443 :::* LISTEN 1135/java
tcp6 0 0 :::443 :::* LISTEN 1131/httpd
tcp6 0 0 :::9090 :::* LISTEN 1138/ruby
tcp6 0 0 127.0.0.1:8005 :::* LISTEN 1135/java
tcp6 0 0 ::1:5671 :::* LISTEN 1140/qpidd
tcp6 0 0 :::8008 :::* LISTEN 1240/ruby
tcp6 0 0 ::1:5672 :::* LISTEN 1140/qpidd
tcp6 0 0 :::5000 :::* LISTEN 1131/httpd
[root@opendemo ~]#
Cependant, certains d'entre eux sont limités à l'hôte local, 127.0.0.1. Pour voir quels ports sont visibles publiquement, je commence par utiliser un nmap par défaut numériser depuis mon système local :
[pgervase@pgervase ~]$ nmap opendemo.usersys.redhat.com
Starting Nmap 7.70 ( https://nmap.org ) at 2021-01-07 20:28 EST
Nmap scan report for opendemo.usersys.redhat.com (10.19.47.240)
Host is up (0.041s latency).
Not shown: 993 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp open https
3128/tcp open squid-http
5000/tcp open upnp
8008/tcp open http
9090/tcp open zeus-admin
Nmap done: 1 IP address (1 host up) scanned in 3.81 seconds
[pgervase@pgervase ~]$
Ce résultat montre que mon système local peut voir moins de ports publics que ce que je pouvais voir lorsque j'étais en SSH sur le serveur. Certains de ces ports non publics sont 25, qui sont utilisés par master , et 8005, 8140, 8443 et 61613, qui sont utilisés par java . En regardant ps sortie et grep pour le PID de maître à partir de ce netstat sortie, maître est le suffixe expéditeur :
[root@opendemo ~]# ps auxww | grep 1396
root 1396 0.0 0.0 89740 2188 ? Ss Jan05 0:00 /usr/libexec/postfix/master -w
root 29665 0.0 0.0 112816 968 pts/0 R+ 20:32 0:00 grep --color=auto 1396
[root@opendemo ~]# Ce (maître) s'exécute localement afin que le courrier puisse être envoyé à des adresses internes, mais n'écoute pas les e-mails entrants et n'envoie rien à un autre hôte.
Les autres ports mentionnés étaient pour java . Lorsque vous consultez le netstat sortie, deux java différents les processus sont responsables de ces ports :
[root@opendemo ~]# netstat -tlpn | grep java
tcp6 0 0 :::8140 :::* LISTEN 2101/java
tcp6 0 0 127.0.0.1:61613 :::* LISTEN 1135/java
tcp6 0 0 127.0.0.1:8443 :::* LISTEN 1135/java
tcp6 0 0 127.0.0.1:8005 :::* LISTEN 1135/java
[root@opendemo ~]#
Lorsque vous regardez ps sortie pour le PID 1135, il est utilisé par tomcat :
[root@opendemo ~]# ps auxww | grep 1135
tomcat 1135 0.3 3.5 12409252 2165668 ? Ssl Jan05 9:25 /usr/lib/jvm/jre/bin/java -Xms1024m -Xmx4096m -Djava.security.auth.login.config=/usr/share/tomcat/conf/login.config -classpath /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/usr/share/tomcat -Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat/temp -Djava.util.logging.config.file=/usr/share/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.catalina.startup.Bootstrap start
root 31507 0.0 0.0 112816 968 pts/0 S+ 20:53 0:00 grep --color=auto 1135
[root@opendemo ~]#
Quand je regarde dans le /usr/share/tomcat/conf/server.xml fichier, il a un contenu tel que :
<Server port="8005" shutdown="SHUTDOWN">
...
<Connector port="8443"
address="localhost"
protocol="HTTP/1.1"
SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="want"
sslProtocols="TLSv1.2"
sslEnabledProtocols="TLSv1.2"
.... Cela montre comment les ports qui seront utilisés sont définis dans le fichier de configuration.
Quand je regarde l'autre java processus que j'ai mentionné, PID 2101 pour le port 8140, je vois qu'il est utilisé par marionnette :
[root@opendemo ~]# ps auxww | grep 2101
puppet 2101 0.2 2.5 9787492 1545188 ? Sl Jan05 7:14 /usr/bin/java -Xms2G -Xmx2G -Djruby.logger.class=com.puppetlabs.jruby_utils.jruby.Slf4jLogger -XX:OnOutOfMemoryError="kill -9 %p" -XX:ErrorFile=/var/log/puppetlabs/puppetserver/puppetserver_err_pid%p.log -cp /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar:/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter.jar:/opt/puppetlabs/server/data/puppetserver/jars/* clojure.main -m puppetlabs.trapperkeeper.main --config /etc/puppetlabs/puppetserver/conf.d --bootstrap-config /etc/puppetlabs/puppetserver/services.d/,/opt/puppetlabs/server/apps/puppetserver/config/services.d/ --restart-file /opt/puppetlabs/server/data/puppetserver/restartcounter
root 31696 0.0 0.0 112816 968 pts/0 S+ 20:55 0:00 grep --color=auto 2101
[root@opendemo ~]#
Basé sur netstat sortie, le port 8140 doit être visible au public, mais nmap de mon système local ne l'a pas signalé dans ses résultats. Ici encore, est le netstat sortie du serveur Satellite :
[root@opendemo ~]# netstat -tunap| grep 8140
tcp6 0 0 :::8140 :::* LISTEN 2101/java
[root@opendemo ~]#
et le nmap depuis mon serveur local :
[pgervase@pgervase ~]$ nmap opendemo.usersys.redhat.com | grep 8140
[pgervase@pgervase ~]$
Cependant, je peux forcer nmap pour vérifier un port spécifique ou une plage de ports :
[pgervase@pgervase ~]$ nmap -p 8140 opendemo.usersys.redhat.com
Starting Nmap 7.70 ( https://nmap.org ) at 2021-01-07 21:07 EST
Nmap scan report for opendemo.usersys.redhat.com (10.19.47.240)
Host is up (0.039s latency).
PORT STATE SERVICE
8140/tcp open puppet
Nmap done: 1 IP address (1 host up) scanned in 0.39 seconds
[pgervase@pgervase ~]$ nmap -p 8000-9000 opendemo.usersys.redhat.com
Starting Nmap 7.70 ( https://nmap.org ) at 2021-01-07 21:07 EST
Nmap scan report for opendemo.usersys.redhat.com (10.19.47.240)
Host is up (0.040s latency).
Not shown: 999 closed ports
PORT STATE SERVICE
8008/tcp open http
8140/tcp open puppet
Nmap done: 1 IP address (1 host up) scanned in 2.12 seconds
[pgervase@pgervase ~]$
En forçant nmap pour vérifier ces ports, j'ai pu voir le port :8140 qui est un nmap de base scan n'a pas signalé. Cela montre qu'un nmap par défaut une analyse sans arguments supplémentaires peut être suffisante pour un premier aperçu du système, mais peut manquer des ports réellement ouverts.
Ces informations sont importantes dans les tests de sécurité afin que les administrateurs système puissent identifier les vulnérabilités potentielles. Depuis le nmap scan de sortie, exécuté localement sur mon système, vous avez vu les ports qui étaient ouverts publiquement. Les versions précédentes de Satellite avaient tomcat configuré de sorte que certains de ces ports étaient publics lorsque cela n'était pas nécessaire. Pour lire une partie de la discussion sur ce problème, vous pouvez lire le Bugzilla où cela a été résolu.
Vérifier les certificats
Un autre problème que nmap peut vous aider à vérifier les certificats utilisés sur ces différents ports. Utilisation de nmap , vous avez vu les ports ouverts. En utilisant ces ports, vous pouvez utiliser OpenSSL pour voir le certificat utilisé sur le port. Un certain nombre de ces ports utilisent des certificats auto-signés. Pour utiliser nmap et OpenSSL ensemble pour vérifier les ports sur un système distant, vous pouvez faire quelque chose comme :
$ for port in `nmap -p 1-5000 opendemo.usersys.redhat.com | grep " open " | cut -d "/" -f 1`
> do echo checking on port: $port
> echo | openssl s_client -showcerts -connect opendemo.usersys.redhat.com:$port
> done &> opendemo.certs.txt.`date +%Y%m%d`
Dans mon opendemo.certs.txt.20210127 fichier, il aurait un contenu comme :
checking on port: 443
depth=1 C = US, ST = North Carolina, L = Raleigh, O = Katello, OU = SomeOrgUnit, CN = opendemo.usersys.redhat.com
verify return:1
depth=0 C = US, ST = North Carolina, O = Katello, OU = SomeOrgUnit, CN = opendemo.usersys.redhat.com
verify return:1
CONNECTED(00000003)
….
SSL handshake has read 3476 bytes and written 463 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported Utilisez ce fichier de sortie pour vérifier que les certificats utilisés correspondent à la bonne version de TLS.
Si vous utilisez nc (ou ncat ), vous verrez peut-être plus d'informations que celles présentées dans l'interface utilisateur Web. Pour cet exemple, j'ai utilisé nc pour se connecter à un serveur Web :
$ nc 10.19.47.242 80
asdf
HTTP/1.1 400 Bad Request
Date: Sat, 09 Jan 2021 01:25:40 GMT
Server: Apache/2.4.37 (Red Hat Enterprise Linux)
Content-Length: 226
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
</body></html> À partir de cette sortie, je peux voir la version d'Apache qui a été installée. Avec ces informations, un attaquant pourrait savoir à quels exploits le serveur était vulnérable. Pour cette raison, un serveur Web doit limiter la quantité d'informations affichées :
[pgervase@pgervase ~]$ nc opendemo.usersys.redhat.com 443
GET / HTTP/1.1
HTTP/1.1 400 Bad Request
Date: Fri, 08 Jan 2021 02:33:08 GMT
Server: Apache
Content-Length: 362
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Reason: You're speaking plain HTTP to an SSL-enabled server port.<br />
Instead use the HTTPS scheme to access this URL, please.<br />
</p>
</body></html>
[pgervase@pgervase ~]$ Notez que dans cette sortie, il n'y a pas d'informations sur la version d'Apache.
Dans cet exemple suivant, j'utilise nc pour me connecter au port 21 sur mon système client, que je vois ouvert :
[pgervase@pgervase ~]$ nmap 10.19.47.242
Starting Nmap 7.70 ( https://nmap.org ) at 2021-01-08 21:02 EST
Nmap scan report for 10.19.47.242
Host is up (0.039s latency).
Not shown: 996 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
Nmap done: 1 IP address (1 host up) scanned in 0.83 seconds
[pgervase@pgervase ~]$ nc 10.19.47.242 21
220 (vsFTPd 3.0.3)
Cette version 3.0.3 est confirmée lorsque je me connecte en SSH au système et que j'utilise le rpm commande :
[root@vulnerable ~]# rpm -q vsftpd
vsftpd-3.0.3-32.el8.x86_64
[root@vulnerable ~]# rpm -qi vsftpd
Name : vsftpd
Version : 3.0.3
Release : 32.el8
<snipped> Encore une fois, tout comme pour l'apprentissage de la version d'Apache sur l'appareil, il est important de pouvoir effectuer une reconnaissance de votre environnement afin de savoir ce qu'un attaquant potentiel peut apprendre sur vos systèmes.
Numérisation depuis Kali
Dans la section suivante, je montre quelques résultats de l'analyse d'un système à partir d'un serveur Kali. Dans cet exemple, je sais que le serveur cible a distccd fonctionnant sur le port 3632, mais, comme précédemment, nmap ne détecte pas ce port par défaut, et j'ai donc dû le vérifier spécifiquement :
Maintenant que vous connaissez distccd est ouvert, vous pouvez utiliser les capacités intégrées de nmap pour déterminer où il pourrait potentiellement être exploité :
Si vous n'aviez utilisé qu'un simple nmap scan, vous auriez manqué cette vulnérabilité exploitable. Dans mon exemple, j'ai exécuté uname -a sur le système distant, mais j'aurais pu exécuter n'importe quelle commande.
Identifier les services
Une dernière façon d'utiliser nmap est avec le -sV option, qui sonde les ports ouverts et détermine les informations de service ou de version. Pour cet exemple, j'ai changé le port sur lequel Apache s'exécute de 80 à 90, puis j'ai redémarré le service. Ci-dessous, vous pouvez voir la différence entre un simple nmap scanner puis en utilisant le -sV option, qui a correctement déterminé le service comme httpd plutôt que dnsix :
[root@pgervase ~]# nmap 10.19.47.242
Starting Nmap 7.70 ( https://nmap.org ) at 2021-01-09 19:57 EST
Nmap scan report for 10.19.47.242
Host is up (0.043s latency).
Not shown: 996 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
90/tcp open dnsix
111/tcp open rpcbind
Nmap done: 1 IP address (1 host up) scanned in 1.80 seconds
[root@pgervase ~]# nmap -sV 10.19.47.242
Starting Nmap 7.70 ( https://nmap.org ) at 2021-01-09 19:52 EST
Nmap scan report for 10.19.47.242
Host is up (0.040s latency).
Not shown: 996 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 3.0.3
22/tcp open ssh OpenSSH 8.0 (protocol 2.0)
90/tcp open http Apache httpd 2.4.37 ((Red Hat Enterprise Linux))
111/tcp open rpcbind 2-4 (RPC #100000)
Service Info: OS: Unix [ Vous voulez en savoir plus sur la sécurité ? Consultez la liste de vérification de la sécurité informatique et de la conformité. ]
Récapitulez
Maintenant que vous avez pu obtenir un rapport détaillé sur ce qui s'exécute sur vos systèmes, que faites-vous ensuite ? La première chose à faire est de s'assurer qu'aucun port inattendu n'est ouvert. Pour cela, vérifiez auprès de l'équipe des applications, des équipes de sécurité et de vos collègues que cela peut être approprié. Ensuite, il faut s'assurer que les services exposés sont correctement sécurisés. Cela signifie prendre des mesures telles que s'assurer que tous les logiciels sont mis à jour, que les chiffrements mis à jour sont pris en charge, que les protocoles non sécurisés ne sont pas utilisés et que les mots de passe par défaut des services ont été modifiés.
Cet article est une introduction à l'examen de vos serveurs. Utilisez nc et nmap pour vérifier quels ports sont ouverts et utilisez le ps commande pour retracer les processus utilisant ces ports. J'ai également fourni un exemple de la façon dont vous pouvez utiliser nmap avec le --script argument pour tester vos systèmes. Pour continuer sur ce chemin d'apprentissage, une prochaine étape possible consiste à effectuer une recherche à l'aide de nmap comme moteur d'attaque en enquêtant sur les scripts par défaut dans /usr/share/nmap/scripts/ .