Hallo zusammen,
sofern nicht selber schon gesehen/-lesen hier [0] FYI
Cert-Bund:
"Es wird empfohlen, den Zugriff auf RDP-Dienste auf vertrauenswürdige Quell-IPs zu beschränken oder über ein VPN abzusichern."
--> nicht das wir das auch immer sagen ;)
In diesem Sinne kontrolliert bitte mal eure RDP Freigabe via [1] ob nicht die eine oder andere zurückgenommen werden kann und ob der src IP Bereich passend limitiert ist (letzteres via [2])
VG
Bernd
p.s.: Die Verweise [1] und [2] sind nur von bei uns regisrierten Ansprechpartnern einsehbar
p.p.s.: Laut den Aufzeichnungen unseren Konnektivitätstest waren 236 angemeldete Server (auch Netzen/Netzbereichen) seid mehr als 28 Tage nicht erreichbar.
[0] https://mobile.twitter.com/certbund/status/1125725142712311808
[1] https://noc-portal.rz.rwth-aachen.de/firewall-view/
[2] https://noc-portal.rz.rwth-aachen.de/firewall-admin/routers
Hallo zusammen,
Bernd Kohler kohler@itc.rwth-aachen.de writes:
Cert-Bund:
"Es wird empfohlen, den Zugriff auf RDP-Dienste auf vertrauenswürdige Quell-IPs zu beschränken oder über ein VPN abzusichern."
Um mal aus dem ersten Tweet zu zitieren:
Seit heute informiert CERT-Bund Provider über offen aus dem Internet erreichbare RDP-Dienste. Über schlecht gesichterte RDP-Zugänge wurde zuletzt zunehmend #Ransomware wie #GandCrab oder #SamSam installiert […]
Über schlecht gesicherte (triviale Passwörter und so) brauchen wir wohl nicht reden.
Aber müsste es Windows nicht auch erlauben, RDP sicher zu konfigurieren? Da wird ja immerhin SSL benutzt, da bekommt man doch sicher auch ein entsprechend CA-signiertes Zertifikat rein. Dann hängt es nur noch an den sicheren Passwörtern.
Ich meine, gegen SSH weltweit offen hat ja niemand etwas einzuwenden. Dass das Cisco-VPN mit IKEv1 und XAuth sicher sein soll, will mir jetzt hoffentlich niemand erklären.
Aus der Erklärung, die das CERT verlinkt hat[a]:
Misconfigured RDP can allow miscreants access to the desktop of a vulnerable host and can also allow for information-gathering on a target host, as the SSL certificate used by RDP often contains the system’s trivial hostname.
Was bitte ist denn “trivial hostname”? Eigentlich gehe ich davon aus, dass auch im Rest der RWTH das Internet in Ordnung ist und jeder Host eine ordentlich eingetragene IP-Adresse hat – unser (AStA) Windows-RDP-Host hält sich selbst für wints.asta.rwth-aachen.de und ist das auch im öffentlichen DNS mit einer nicht-RFC1918-Adresse [b].
--Thomas
[a]: https://www.shadowserver.org/what-we-do/network-reporting/accessible-rdp-rep... [b]: und dass der öffentlich (auch RWTH-intern) nicht erreichbar ist, liegt hier an der seltsamen Lizensierung von Microsoft
Hi,
Am 10.05.19 um 14:44 schrieb Thomas Schneider:
Bernd Kohler kohler@itc.rwth-aachen.de writes:
Cert-Bund:
"Es wird empfohlen, den Zugriff auf RDP-Dienste auf vertrauenswürdige Quell-IPs zu beschränken oder über ein VPN abzusichern."
das ist etwas, was ich auch genauso hier schon empfohlen habe.
VPN schaltet in jedem Fall eine Authentifizierungsinstanz davor und bewahrt einen auch davor, bzgl. seiner Verbindungsprofile beobachtet zu werden.
Einschränkung auf deutlich weniger IPs als 2^32 hilft sicher auch.
Um mal aus dem ersten Tweet zu zitieren:
Seit heute informiert CERT-Bund Provider über offen aus dem Internet erreichbare RDP-Dienste. Über schlecht gesichterte RDP-Zugänge wurde zuletzt zunehmend #Ransomware wie #GandCrab oder #SamSam installiert […]
Über schlecht gesicherte (triviale Passwörter und so) brauchen wir wohl nicht reden.
Äh doch. Nicht mehr so viel und so häufig wie früher, aber es kommt eben leider immer mal wieder vor. Solange wir Passworte nutzen, muss man auch darüber reden.
Aber müsste es Windows nicht auch erlauben, RDP sicher zu konfigurieren? Da wird ja immerhin SSL benutzt, da bekommt man doch sicher auch ein entsprechend CA-signiertes Zertifikat rein. Dann hängt es nur noch an den sicheren Passwörtern.
Das ist aber nun mal derzeit nicht so.
Das eigentliche Problem bei RDP heisst aber Logging. Erstmal muss man ein Windows überhaupt konfigurieren, dass es fehlerhafte Logins loggt. Und dann macht das Logs angucken unter Windows ja auch richtig Spaß, oder? Und sieht man dann die IP, von der der fehlerhafte Login kam? (es kommt auf das Windows an - bei manchen ja, bei anderen nicht).
Ich meine, gegen SSH weltweit offen hat ja niemand etwas einzuwenden.
Hm. Hängt vom System und der Nutzerschaft ab. Aber *muss* es immer weltweit sein? Inklusive Antarktis? ;-)
Dass das Cisco-VPN mit IKEv1 und XAuth sicher sein soll, will mir jetzt hoffentlich niemand erklären.
Nicht ideal, aber auch nicht in der Schußlinie.
Im Gegensatz zu RDP, bei dem mittlerweile in gleichem Umfang wie bei SSH per brute force angegriffen wird.
Aber was man nicht weiß, macht ja auch nicht heiß. S. den Abschnitt oben zum Logging.
Aus der Erklärung, die das CERT verlinkt hat[a]:
Misconfigured RDP can allow miscreants access to the desktop of a vulnerable host and can also allow for information-gathering on a target host, as the SSL certificate used by RDP often contains the system’s trivial hostname.
Was bitte ist denn “trivial hostname”? Eigentlich gehe ich davon aus, dass auch im Rest der RWTH das Internet in Ordnung ist und jeder Host eine ordentlich eingetragene IP-Adresse hat – unser (AStA) Windows-RDP-Host hält sich selbst für wints.asta.rwth-aachen.de und ist das auch im öffentlichen DNS mit einer nicht-RFC1918-Adresse [b].
Jaja, das war Geblubber, geschenkt.
Zusammenfassend:
Reduktion der Angriffsfläche und Beschränkung des Zugriffsraums sind valide und stark unterstützende Teile einer Sicherheitsstrategie.
Gruß, Jens Hektor
Nabend,
Jens Hektor hektor@itc.rwth-aachen.de writes:
VPN schaltet in jedem Fall eine Authentifizierungsinstanz davor und bewahrt einen auch davor, bzgl. seiner Verbindungsprofile beobachtet zu werden.
Ich weiß nicht, ich bin da zwiegespalten. Es verführt dazu, nur noch blind auf das VPN zu vertrauen und an den Diensten dahinter weniger aufzupassen. Aber es ist ein weiterer Layer, das stimmt schon.
Einschränkung auf deutlich weniger IPs als 2^32 hilft sicher auch.
2^128, ftfy.
Über schlecht gesicherte (triviale Passwörter und so) brauchen wir wohl nicht reden.
Äh doch. Nicht mehr so viel und so häufig wie früher, aber es kommt eben leider immer mal wieder vor. Solange wir Passworte nutzen, muss man auch darüber reden.
Ich meinte damit, dass schlechte Passwörter einer der obersten Angriffsvektoren sind, und solange man die hat, ist die Mühe bei allem anderen es kaum wert. War etwas unklar ausgedrückt.
Aber müsste es Windows nicht auch erlauben, RDP sicher zu konfigurieren? Da wird ja immerhin SSL benutzt, da bekommt man doch sicher auch ein entsprechend CA-signiertes Zertifikat rein. Dann hängt es nur noch an den sicheren Passwörtern.
Das ist aber nun mal derzeit nicht so.
Was ist nicht so, dass Leute sichere Passwörter vergeben, oder dass Admins „richtige“ SSL-Zertifikate einbinden?
Das eigentliche Problem bei RDP heisst aber Logging. Erstmal muss man ein Windows überhaupt konfigurieren, dass es fehlerhafte Logins loggt.
Jedes Mal, wenn ich Windows eine Chance geben will …
Und dann macht das Logs angucken unter Windows ja auch richtig Spaß, oder? Und sieht man dann die IP, von der der fehlerhafte Login kam? (es kommt auf das Windows an - bei manchen ja, bei anderen nicht).
Hm. Ich habe immer so den Eindruck, dass erfahrene Windows-Admins da schon anständige Sachen machen können. Aber die sind echt selten – ich administriere ja auch so ein paar Büchsen, und ich weiß immerhin schon mal, dass ich da kein Experte bin.
Ich meine, gegen SSH weltweit offen hat ja niemand etwas einzuwenden.
Hm. Hängt vom System und der Nutzerschaft ab. Aber *muss* es immer weltweit sein? Inklusive Antarktis? ;-)
Ach, das sind auch nur Wahrscheinlichkeiten, und du wirst für keinen Netzbereich mit p=1 sagen können, dass sich niemand jemals legitim von dort einloggen wird. Für sowas wie Antarktis kommt man beliebig nahe ran – bis ein Physiker der RWTH an der Forschungsstation dort ist (ja, ich kenne so jemanden).
Abgesehen davon explodieren ja so, gerade bei der Fragmentation von IPv4, die FW-Regeln. Sowohl mit White- als auch Blacklist. Da lass ich es lieber komplett offen und sorge dafür, dass es auf Protokollebene abgesichert ist – nur Key-Login oder zumindest sichere Passwörter, 2FA, fail2ban, etc.
Dass das Cisco-VPN mit IKEv1 und XAuth sicher sein soll, will mir jetzt hoffentlich niemand erklären.
Nicht ideal, aber auch nicht in der Schußlinie.
Dabei wäre es doch ein so lohnendes Ziel. Wenn Gruppen-Credentials bekannt sind (*hust*doc.itc), sind MITM-Attacken ziemlich einfach.
Zusammenfassend:
Reduktion der Angriffsfläche und Beschränkung des Zugriffsraums sind valide und stark unterstützende Teile einer Sicherheitsstrategie.
Joa. Man sollte sich nur nicht darauf ausruhen und sich nicht selbst damit in den Fuß schießen.
--Thomas
rwth-security@lists.rwth-aachen.de
-
Bernd Kohler -
Jens Hektor -
Thomas Schneider