Systemsicherheit ist keine einmalige Aufgabe. Vielmehr umfasst der Sicherheitsansatz einer Organisation zahlreiche Ebenen. Einige dieser Ebenen sind physische Sicherheit für die Rechenzentren, regelmäßiges Patchen und Warten der Infrastruktur, kontinuierliche Schulung des Benutzerbewusstseins und Scannen von Systemen auf Probleme. Dieser Artikel beschreibt die Verwendung von nmap und nc Befehle, um ein System zu scannen, damit Sie die geeigneten nächsten Schritte bestimmen können. In meinen Beispielen verwende ich hier einige Systeme. Das System, das den Scan durchführt, ist mein lokaler Red Hat Enterprise Linux (RHEL) 8.3-Computer, opendemo.usersys.redhat.com ist das Red Hat Satellite 6.8-System, das verwendet wird, weil es mehrere offene Ports hat und ich verschiedene Zielsysteme habe.
[Das könnte Ihnen auch gefallen: Sysadmin-Sicherheit:8 Linux-Sperrsteuerungen]
Einfache Scans
Um die auf meinem Satellitenserver verwendeten Ports anzuzeigen, stelle ich eine SSH-Verbindung zum Server her und verwende dann 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 ~]#
Einige davon sind jedoch auf den Localhost 127.0.0.1 beschränkt. Um zu sehen, welche Ports öffentlich sichtbar sind, verwende ich zunächst eine standardmäßige nmap von meinem lokalen System scannen:
[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 ~]$
Diese Ausgabe zeigt, dass mein lokales System weniger öffentliche Ports sehen kann als ich sehen konnte, als ich per SSH auf den Server zugreifen konnte. Einige dieser nicht öffentlichen Ports sind 25, die von master verwendet werden , und 8005, 8140, 8443 und 61613, die von Java verwendet werden . Betrachten wir ps Ausgabe und Suche nach der PID von master von diesem netstat Ausgabe, Master ist das Postfix mailer:
[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 ~]# Dieser (Master) wird lokal ausgeführt, sodass E-Mails an interne Adressen gesendet werden können, aber er lauscht nicht auf eingehende E-Mails und sendet auch nichts an andere Hosts.
Die anderen erwähnten Ports waren für Java . Wenn Sie sich die netstat ansehen Ausgabe, zwei verschiedene Java Prozesse sind für diese Ports verantwortlich:
[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 ~]#
Wenn Sie sich ps ansehen Ausgabe für PID 1135, wird von Tomcat verwendet :
[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 ~]#
Wenn ich in die /usr/share/tomcat/conf/server.xml schaue Datei hat Inhalt wie:
<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"
.... Dies zeigt wie die zu verwendenden Ports in der Konfigurationsdatei definiert sind.
Wenn ich mir die andere Java ansehe Prozess, den ich erwähnt habe, PID 2101 für Port 8140, wie ich sehe, wird dies von puppet verwendet :
[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 ~]#
Basierend auf netstat Ausgabe sollte Port 8140 für die Öffentlichkeit sichtbar sein, aber nmap von meinem lokalen System hat es nicht in seinen Ergebnissen gemeldet. Auch hier ist die netstat Ausgabe vom Satellitenserver:
[root@opendemo ~]# netstat -tunap| grep 8140
tcp6 0 0 :::8140 :::* LISTEN 2101/java
[root@opendemo ~]#
und die nmap von meinem lokalen Server:
[pgervase@pgervase ~]$ nmap opendemo.usersys.redhat.com | grep 8140
[pgervase@pgervase ~]$
Ich kann jedoch nmap erzwingen So überprüfen Sie einen bestimmten Port oder Portbereich:
[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 ~]$
Durch Erzwingen von nmap Um diese Ports zu überprüfen, konnte ich den :8140-Port sehen, der eine einfache nmap ist Scan hat nicht gemeldet. Dies zeigt, dass ein standardmäßiges nmap Scan ohne zusätzliche Argumente könnte gut genug sein, um einen ersten Blick auf das System zu werfen, könnte aber Ports übersehen, die tatsächlich offen sind.
Diese Informationen sind bei Sicherheitstests wichtig, damit Systemadministratoren potenzielle Schwachstellen identifizieren können. Aus dem nmap Ausgabescan, lokal auf meinem System ausführen, Sie haben die Ports gesehen, die öffentlich geöffnet waren. Frühere Versionen von Satellite hatten Tomcat so konfiguriert, dass einige dieser Ports öffentlich waren, obwohl dies nicht erforderlich war. Um einen Teil der Diskussion zu diesem Problem nachzulesen, können Sie den Bugzilla lesen, in dem dies behoben wurde.
Zertifikate überprüfen
Ein weiteres Problem, das nmap helfen kann, ist die Überprüfung der Zertifikate, die an diesen verschiedenen Ports verwendet werden. Mit nmap , Sie haben die offenen Ports gesehen. Mithilfe dieser Ports können Sie OpenSSL verwenden, um das für den Port verwendete Zertifikat anzuzeigen. Einige dieser Ports verwenden selbstsignierte Zertifikate. Um nmap zu verwenden und OpenSSL zusammen, um die Ports auf einem entfernten System zu überprüfen, könnten Sie so etwas tun:
$ 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`
In meiner opendemo.certs.txt.20210127 Datei, hätte sie einen Inhalt wie:
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 Verwenden Sie diese Ausgabedatei, um zu überprüfen, ob die verwendeten Zertifikate die richtige TLS-Version sind.
Wenn Sie nc verwenden (oder ncat ), sehen Sie möglicherweise mehr Informationen als in der Webbenutzeroberfläche angezeigt. Für dieses Beispiel habe ich nc verwendet um sich mit einem Webserver zu verbinden:
$ 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> Aus dieser Ausgabe kann ich die Version von Apache sehen, die installiert wurde. Mit diesen Informationen könnte ein Angreifer erfahren, für welche Exploits der Server anfällig ist. Aus diesem Grund sollte ein Webserver die Menge der angezeigten Informationen begrenzen:
[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 ~]$ Beachten Sie, dass es in dieser Ausgabe keine Versionsinformationen für Apache gibt.
In diesem nächsten Beispiel verwende ich nc um eine Verbindung zu Port 21 auf meinem Client-System herzustellen, von dem ich sehen kann, dass es offen ist:
[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)
Diese 3.0.3-Version wird bestätigt, wenn ich eine SSH-Verbindung zum System herstelle und den rpm verwende Befehl:
[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> Auch hier ist es wichtig, genau wie beim Erlernen der Apache-Version auf dem Gerät, in der Lage zu sein, Ihre Umgebung zu erkunden, damit Sie wissen, was ein potenzieller Angreifer über Ihre Systeme erfahren kann.
Scannen von Kali
Im nächsten Abschnitt zeige ich einige Ergebnisse des Scannens eines Systems von einem Kali-Server. In diesem Beispiel weiß ich, dass der Zielserver distccd hat läuft auf Port 3632, aber, wie zuvor, nmap erkennt diesen Port standardmäßig nicht, also musste ich speziell danach suchen:
Jetzt kennen Sie distccd offen ist, können Sie die eingebauten Fähigkeiten von nmap verwenden, um festzustellen, wo es potenziell ausgenutzt werden könnte:
Wenn Sie nur ein einfaches nmap verwendet hätten scannen, hätten Sie diese ausnutzbare Schwachstelle übersehen. In meinem Beispiel habe ich uname -a ausgeführt auf dem entfernten System, aber ich hätte jeden Befehl ausführen können.
Dienste identifizieren
Eine letzte Möglichkeit, nmap zu verwenden ist mit dem -sV -Option, die die offenen Ports prüft und die Dienst- oder Versionsinformationen ermittelt. Für dieses Beispiel habe ich den Port, auf dem Apache läuft, von 80 auf 90 geändert und dann den Dienst neu gestartet. Unten sehen Sie den Unterschied zwischen einer einfachen nmap scannen und dann mit dem -sV Option, die den Dienst korrekt als httpd bestimmt hat statt 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 [ Möchten Sie mehr über Sicherheit erfahren? Sehen Sie sich die Checkliste für IT-Sicherheit und Compliance an. ]
Abschluss
Nachdem Sie nun einen detaillierten Bericht darüber erhalten haben, was auf Ihren Systemen ausgeführt wird, was tun Sie als Nächstes? Als Erstes müssen Sie sicherstellen, dass keine unerwarteten Ports geöffnet sind. Wenden Sie sich hierfür an das Anwendungsteam, die Sicherheitsteams und Ihre Kollegen, die möglicherweise angemessen sind. Als Nächstes muss sichergestellt werden, dass die exponierten Dienste ordnungsgemäß gesichert sind. Dazu müssen Maßnahmen ergriffen werden, z. B. sicherzustellen, dass die gesamte Software aktualisiert wird, aktualisierte Chiffren unterstützt werden, keine unsicheren Protokolle verwendet werden und die Standardpasswörter für die Dienste geändert wurden.
Dieser Artikel ist eine Einführung in die Untersuchung Ihrer Server. Verwenden Sie nc und nmap um zu prüfen, welche Ports geöffnet sind, und verwenden Sie den ps Befehl, um die Prozesse zurückzuverfolgen, die diese Ports verwenden. Ich habe auch ein Beispiel dafür bereitgestellt, wie Sie nmap verwenden können mit dem --script Argument, um Ihre Systeme zu testen. Um diesen Lernpfad fortzusetzen, besteht ein möglicher nächster Schritt darin, mit nmap zu recherchieren als Angriffsmaschine, indem Sie die Standardskripte in /usr/share/nmap/scripts/ untersuchen .