La seguridad del sistema no es una tarea de una sola vez. Más bien, hay numerosas capas en el enfoque de seguridad de una organización. Algunas de esas capas son la seguridad física de los centros de datos, la aplicación regular de parches y el mantenimiento de la infraestructura, la educación continua de los usuarios y el análisis de los sistemas en busca de problemas. Este artículo explica cómo usar el nmap y nc Comandos para escanear un sistema para que pueda determinar los siguientes pasos apropiados. Utilizo algunos sistemas en mis ejemplos aquí. El sistema que realiza el escaneo es mi computadora local Red Hat Enterprise Linux (RHEL) 8.3, opendemo.usersys.redhat.com es el sistema Red Hat Satellite 6.8 utilizado porque tiene varios puertos abiertos y tengo varios sistemas de destino.
[ También te puede interesar: Seguridad de administrador de sistemas:8 controles de bloqueo de Linux]
Escaneos básicos
Para ver los puertos en uso en mi servidor Satélite, I SSH al servidor y luego use 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 ~]#
Sin embargo, algunos de ellos están limitados al host local, 127.0.0.1. Para ver qué puertos son visibles públicamente, empiezo usando un nmap predeterminado. escanear desde mi sistema 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 ~]$
Este resultado muestra que mi sistema local puede ver menos puertos públicos de los que pude ver cuando estaba SSH en el servidor. Algunos de esos puertos no públicos son 25, que utiliza master y 8005, 8140, 8443 y 61613, que son utilizados por java . Mirando ps salida y grepping para el PID de maestro de ese netstat salida, maestro es el postfijo correo:
[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 ~]# Ese (maestro) se ejecuta localmente para que el correo se pueda enviar a direcciones internas, pero no escucha el correo electrónico entrante ni envía nada a ningún otro host.
Los otros puertos mencionados eran para java . Cuando miras el netstat salida, dos java diferentes los procesos son responsables de esos puertos:
[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 ~]#
Cuando miras ps salida para PID 1135, lo usa 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 ~]#
Cuando miro en /usr/share/tomcat/conf/server.xml archivo, tiene contenido como:
<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"
.... Esto muestra cómo se definen los puertos que se utilizarán en el archivo de configuración.
Cuando miro al otro java proceso que mencioné, PID 2101 para el puerto 8140, veo que esto es utilizado por puppet :
[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 ~]#
Basado en netstat salida, el puerto 8140 debería ser visible para el público, pero nmap de mi sistema local no lo informó en sus resultados. Aquí nuevamente, está el netstat salida del servidor Satélite:
[root@opendemo ~]# netstat -tunap| grep 8140
tcp6 0 0 :::8140 :::* LISTEN 2101/java
[root@opendemo ~]#
y el nmap desde mi servidor local:
[pgervase@pgervase ~]$ nmap opendemo.usersys.redhat.com | grep 8140
[pgervase@pgervase ~]$
Sin embargo, puedo forzar nmap para verificar un puerto específico o un rango de puertos:
[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 ~]$
Al forzar nmap para verificar esos puertos, pude ver el puerto:8140 que es un nmap básico el escaneo no reportó. Esto muestra que un nmap predeterminado escanear sin argumentos adicionales puede ser lo suficientemente bueno para echar un primer vistazo al sistema, pero puede pasar por alto los puertos que están realmente abiertos.
Esta información es importante en las pruebas de seguridad para que los administradores de sistemas puedan identificar posibles vulnerabilidades. Desde el nmap escaneo de salida, ejecutar localmente en mi sistema, vio los puertos que estaban abiertos públicamente. Las versiones anteriores de Satellite tenían tomcat configurado para que algunos de esos puertos fueran públicos cuando eso no era necesario. Para leer parte de la discusión sobre ese problema, puede leer Bugzilla donde se resolvió.
Verificar certificados
Otro problema que nmap puede ayudar es verificar los certificados que se utilizan en esos diversos puertos. Usando nmap , viste los puertos abiertos. Usando esos puertos, puede usar OpenSSL para ver el certificado usado en el puerto. Varios de esos puertos utilizan certificados autofirmados. Para usar nmap y OpenSSL juntos para verificar los puertos en un sistema remoto, podría hacer algo como:
$ 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`
En mi opendemo.certs.txt.20210127 archivo, tendría contenido como:
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 Use ese archivo de salida para verificar que los certificados en uso sean la versión TLS correcta.
Si usa nc (o ncat ), es posible que vea más información de la que se presenta en la interfaz de usuario web. Para este ejemplo, usé nc para conectarse a un servidor 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> A partir de ese resultado, puedo ver la versión de Apache que se instaló. Con esa información, un atacante podría saber a qué exploits era vulnerable el servidor. Debido a esto, un servidor web debe limitar la cantidad de información que se muestra:
[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 ~]$ Tenga en cuenta que en este resultado no hay información de la versión de Apache.
En el siguiente ejemplo, uso nc para conectarme al puerto 21 en mi sistema cliente, que puedo ver que está abierto:
[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)
Esa versión 3.0.3 se confirma cuando hago SSH al sistema y uso el rpm comando:
[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> Una vez más, al igual que con el aprendizaje de la versión de Apache en el dispositivo, es importante poder realizar un reconocimiento en su entorno para que sepa lo que un atacante potencial puede aprender sobre sus sistemas.
Escaneo desde Kali
En la siguiente sección, muestro algunos resultados de escanear un sistema desde un servidor Kali. En este ejemplo, sé que el servidor de destino tiene distccd ejecutándose en el puerto 3632, pero, como antes, nmap no detecta ese puerto de manera predeterminada, por lo que tuve que verificarlo específicamente:
Ahora que sabes distccd está abierto, puede usar las capacidades integradas de nmap para determinar dónde podría explotarse:
Si hubieras usado solo un nmap simple escanear, se habría perdido esa vulnerabilidad explotable. En mi ejemplo, ejecuté uname -a en el sistema remoto, pero podría haber ejecutado cualquier comando.
Identificación de servicios
Una forma final de usar nmap es con el -sV opción, que sondea los puertos abiertos y determina el servicio o la información de la versión. Para este ejemplo, cambié el puerto en el que se ejecuta Apache de 80 a 90 y luego reinicié el servicio. A continuación puede ver la diferencia entre un nmap simple escanear y luego usar -sV opción, que determinó correctamente el servicio como httpd en lugar de 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 [ ¿Quiere obtener más información sobre seguridad? Consulte la lista de verificación de cumplimiento y seguridad de TI. ]
Resumir
Ahora que ha podido obtener un informe detallado de lo que se está ejecutando en sus sistemas, ¿qué debe hacer a continuación? Lo primero es asegurarse de que no haya puertos abiertos inesperados. Para esto, verifique con el equipo de aplicaciones, los equipos de seguridad y sus compañeros de trabajo podrían ser apropiados. Lo siguiente es asegurarse de que los servicios expuestos estén debidamente protegidos. Esto significa tomar medidas como asegurarse de que todo el software esté actualizado, que se admitan cifrados actualizados, que no se utilicen protocolos inseguros y que se hayan cambiado las contraseñas predeterminadas de los servicios.
Este artículo es una introducción a la investigación de sus servidores. Usa nc y nmap para verificar qué puertos están abiertos y use el ps comando para rastrear los procesos que usan esos puertos. También proporcioné un ejemplo de cómo puede usar nmap con el --script argumento para probar sus sistemas. Para continuar en este camino de aprendizaje, un posible siguiente paso es investigar usando nmap como motor de ataque investigando los scripts predeterminados en /usr/share/nmap/scripts/ .