La sicurezza del sistema non è un'attività da eseguire. Piuttosto, ci sono numerosi livelli nell'approccio di un'organizzazione alla sicurezza. Alcuni di questi livelli sono la sicurezza fisica dei data center, l'applicazione di patch e la manutenzione regolari dell'infrastruttura, la formazione continua della consapevolezza degli utenti e la scansione dei sistemi per rilevare eventuali problemi. Questo articolo illustra come utilizzare nmap e nc comandi per eseguire la scansione di un sistema in modo da poter determinare i passaggi successivi appropriati. Uso alcuni sistemi nei miei esempi qui. Il sistema che esegue la scansione è il mio computer locale Red Hat Enterprise Linux (RHEL) 8.3, opendemo.usersys.redhat.com è il sistema Red Hat Satellite 6.8 utilizzato perché ha diverse porte aperte e ho diversi sistemi di destinazione.
[ Potrebbe piacerti anche: Sicurezza Sysadmin:8 controlli di blocco di Linux ]
Scansioni di base
Per vedere le porte in uso sul mio server Satellite, accedo al server tramite SSH e poi utilizzo 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 ~]#
Tuttavia, alcuni di questi sono limitati all'host locale, 127.0.0.1. Per vedere quali porte sono pubblicamente visibili, inizio utilizzando un nmap predefinito scansiona dal mio sistema locale:
[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 ~]$
Questo output mostra che il mio sistema locale può vedere meno porte pubbliche di quelle che potevo vedere quando ero SSH nel server. Alcune di queste porte non pubbliche sono 25, utilizzate da master e 8005, 8140, 8443 e 61613, utilizzati da java . Guardando ps output e grepping per il PID di master da quel netstat output, master è il postfisso mittente:
[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 ~]# That (master) è in esecuzione localmente in modo che la posta possa essere inviata a indirizzi interni ma non sta ascoltando la posta in arrivo, né sta inviando nulla a nessun altro host.
Le altre porte menzionate erano per java . Quando guardi netstat output, due diversi java i processi sono responsabili di tali porte:
[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 ~]#
Quando guardi ps output per PID 1135, è utilizzato da 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 ~]#
Quando guardo in /usr/share/tomcat/conf/server.xml file, ha contenuti come:
<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"
.... Questo mostra come vengono definite le porte che verranno utilizzate nel file di configurazione.
Quando guardo l'altro java processo che ho menzionato, PID 2101 per la porta 8140, vedo che questo è usato da 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 ~]#
Basato su netstat output, la porta 8140 dovrebbe essere visibile al pubblico, ma nmap dal mio sistema locale non lo ha segnalato nei suoi risultati. Anche qui c'è il netstat output dal server Satellite:
[root@opendemo ~]# netstat -tunap| grep 8140
tcp6 0 0 :::8140 :::* LISTEN 2101/java
[root@opendemo ~]#
e la nmap dal mio server locale:
[pgervase@pgervase ~]$ nmap opendemo.usersys.redhat.com | grep 8140
[pgervase@pgervase ~]$
Tuttavia, posso forzare nmap per controllare una porta o un intervallo di porte specifico:
[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 ~]$
Forzando nmap per controllare quelle porte, sono stato in grado di vedere la porta :8140 che è un nmap di base la scansione non ha riportato. Questo mostra che un predefinito nmap la scansione senza argomenti aggiuntivi potrebbe essere sufficiente per dare una prima occhiata al sistema, ma potrebbe mancare le porte che sono effettivamente aperte.
Queste informazioni sono importanti nei test di sicurezza in modo che gli amministratori di sistema possano identificare potenziali vulnerabilità. Da nmap scansione dell'output, eseguito localmente sul mio sistema, hai visto le porte aperte pubblicamente. Le versioni precedenti di Satellite avevano tomcat configurato in modo che alcune di queste porte fossero pubbliche quando non era necessario. Per leggere alcune delle discussioni su quel problema, puoi leggere il Bugzilla in cui è stato risolto.
Verifica certificati
Un altro problema che nmap può aiutare è verificare i certificati utilizzati su quelle varie porte. Usando nmap , hai visto le porte aperte. Usando quelle porte, puoi usare OpenSSL per vedere il certificato usato sulla porta. Alcune di queste porte utilizzano certificati autofirmati. Per usare nmap e OpenSSL insieme per controllare le porte su un sistema remoto, potresti fare qualcosa del tipo:
$ 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`
Nel mio opendemo.certs.txt.20210127 file, avrebbe contenuti come:
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 Utilizza quel file di output per verificare che i certificati in uso siano la versione TLS corretta.
Se usi nc (o ncat ), potresti visualizzare più informazioni di quelle presentate nell'interfaccia utente web. Per questo esempio, ho usato nc per connettersi a un server 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> Da quell'output, posso vedere la versione di Apache che è stata installata. Con queste informazioni, un utente malintenzionato potrebbe scoprire a quali exploit era vulnerabile il server. Per questo motivo, un server web dovrebbe limitare la quantità di informazioni visualizzate:
[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 ~]$ Nota che in questo output non ci sono informazioni sulla versione per Apache.
In questo prossimo esempio, utilizzo nc per connettermi alla porta 21 sul mio sistema client, che posso vedere è aperta:
[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)
Quella versione 3.0.3 viene confermata quando accedo al sistema tramite SSH e utilizzo il 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> Ancora una volta, proprio come con l'apprendimento della versione di Apache sul dispositivo, è importante essere in grado di effettuare ricognizioni nel tuo ambiente in modo da sapere cosa può imparare un potenziale aggressore sui tuoi sistemi.
Scansione da Kali
Nella prossima sezione, mostro alcuni risultati della scansione di un sistema da un server Kali. In questo esempio, so che il server di destinazione ha distccd in esecuzione sulla porta 3632, ma, come in precedenza, nmap non rileva quella porta per impostazione predefinita, quindi ho dovuto verificarla in modo specifico:
Ora che conosci distccd è aperto, puoi utilizzare le funzionalità integrate di nmap per determinare dove potrebbe essere potenzialmente sfruttato:
Se avessi usato solo una semplice nmap scan, ti saresti perso quella vulnerabilità sfruttabile. Nel mio esempio, ho eseguito uname -a sul sistema remoto, ma avrei potuto eseguire qualsiasi comando.
Identificazione dei servizi
Un ultimo modo per usare nmap è con il -sV opzione, che analizza le porte aperte e determina le informazioni sul servizio o sulla versione. Per questo esempio, ho cambiato la porta su cui gira Apache da 80 a 90 e quindi ho riavviato il servizio. Di seguito puoi vedere la differenza tra un semplice nmap eseguire la scansione e quindi utilizzare il -sV opzione, che ha determinato correttamente il servizio come httpd anziché 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 [ Vuoi saperne di più sulla sicurezza? Consulta la checklist di sicurezza e conformità IT. ]
Concludi
Ora che sei stato in grado di ottenere un rapporto dettagliato di ciò che è in esecuzione sui tuoi sistemi, cosa fai dopo? La prima cosa è assicurarsi che non ci siano porte impreviste aperte. Per questo, verifica con il team delle applicazioni, i team di sicurezza e i tuoi colleghi potrebbe essere appropriato. Il passo successivo consiste nell'assicurare che i servizi esposti siano adeguatamente protetti. Ciò significa adottare misure come assicurarsi che tutto il software sia aggiornato, che i codici aggiornati siano supportati, che non siano in uso protocolli non sicuri e che le password predefinite per i servizi siano state modificate.
Questo articolo è un'introduzione all'analisi dei server. Usa nc e nmap per verificare quali porte sono aperte e utilizza ps comando per risalire ai processi utilizzando quelle porte. Ho anche fornito un esempio di come puoi usare nmap con il --script argomento per testare i tuoi sistemi. Per continuare questo percorso di apprendimento, un possibile passo successivo è la ricerca utilizzando nmap come motore di attacco esaminando gli script predefiniti in /usr/share/nmap/scripts/ .