Ismerd meg az ellenség fegyvertárát - új RDP brute force törő és szkennelő 250 dollárért

Hozzászólások

van aki ki meri rakni a windows rdp-t a netre direktbe? (ok, álnaiv kérdés, én is tudok egy-kettőt :) )

--
Gábriel Ákos

6-8 gépemen biztos ki van publikálva sokéve. És? Bruteforce-olja nyugodtan. Egy alap, 8 karakteres normális jelszót se fog vele a büdöséletben sem feltörni egy ilyen szarral, nemhogy egy certificate (smart card) alapút.

Ez arra jó, hogy vérpistikék admin:admin tipusú gépeket scanneljék és "meghackeljék".

Normális naplózás sincs. :P

This rule checks the RdpCoreTS/Operational Log for any opening connections. It is not perfect, as it will count failed AND successful connections, but this works ok in normal day life
This is necessary because login attempts with an existing user are NOT logged in the 140 event by Microsoft for some reasons.

"Elég régi és kiforrott technológia az rdp."

Önmagában az RDP-t kibaszni az internetre nem túl bölcs dolog. Erről a Microsoft is megemlékezik:

"Organizations that don't enforce network-access restrictions to Internet-facing VMs are exposed to security risks, such as a Remote Desktop Protocol (RDP) Brute Force attack."

Márpedig azok a lamer bohócok szokták kibaszni, akik nem értenek a VPN csináláshoz, a tűzfalszabályokhoz, nincs pénzük, se igényük rendes hálózatot összerakni, vagy hírből sem hallottak egyéb, kiegészítő, a biztonságot és az auditálhatóságot tovább fokozó megoldásokról.

--
trey @ gépház

Azért majd, ha lesz időd fejtsd már ki a fentebb általam emlitett certificate alapú RDP hitelesités és a brute force kapcsolatát. Tényleg rettenetesen nagy kockázat. Pont akkora, mint egy openvpn. Ha ott is admin:admin -t használsz, akkor pont úgy megtörnek brute force-al. Semmivel nem nagyobb kockázat az rdp. Mindkettőnél megvan a lehetőséged a brute force ellehetetlenitésére. Akár certificate-el, akár 2FA-val, de még csak kellően bonyolult jelszóval és nem alap username-mel is.

Persze ehhez tovább kéne jutni mint általános blődségek puffogtatásánál. Fel kéne fogni miről van szó. Lámer meg bohóc ugye, ettől leszel nagyon szakértő :)

Nem mellesleg az általad bedobott cikk sem azt mondja, hogy ne publikáld ki az rdp-t közvetlenül, hanem, hogy tűzfalon szabályozd a hozzáférést a porthoz, ami nyilván alapvetés mindenféle szolgáltatás publikálásánál, ha értelmezhető.

Imo, ne maszatolj. Nyilvánvalóan arról van szó és én is arról beszéltem, hogy ne tegyen ki közvetlenül, tűzfalszabályok nélkül (paraszt portforward) az internetre. Se nem téged neveztelek bohócnak, se nem azt mondtam, hogy itt a 2FA-s megoldásokról van szó.

Pontosan tudod te ezt, csak megint játszod az eszed. A brute forcer sem azok ellen az RDP portok ellen van, amelyeket tűzfalszabályokkal védenek (aka. meghatározott IP-król vagy IP tartományokról érhetők csak el stb.)

--
trey @ gépház

Itt nem én maszatalok. Akkor ismét megkérlek, meséld el milyen bruteforce kockázatot jelent egy tűzfalszabállyal nem védett, közvetlenül kipublikált rdp, ha mondjuk nem alap felhasználónevet és mondjuk egy 12 karakteres, erős jelszót használ. Se certificate, se 2FA, se tűzfalszabály. Hogyan lehet ezt az állitólag öngyilkos felállást brute force-al megtörni?

"A brute forcer sem azok ellen az RDP portok ellen van, amelyeket tűzfalszabályokkal védenek "

Nemhogy azok ellen, de még azok ellen sem, akik egy normális jelszót használnak. Szóval maradjunk a fentebb már általam emlitett admin:admin kategóriás gépek ellen.

Megint elkezdesz saját feltételrendszereket színezni a sztorihoz. A security guideline-ok és best practices dokumentumok egyértelműen fogalmaznak. Ha kiteszed az RDP-t az internetre, az plusz kockázat. Te azt csinálsz amit akarsz. Abban feltehetően egyetértesz, hogy ha egy RDP portot nem teszel ki az internetre közvetlenül, akkor csökkented a kockázatot. Itt pedig erről van szó.

A többi a te hozzászínezésed.

--
trey @ gépház

De ugyanezt elmondhatom az openvpn portjáról is. Ha kiteszem, az plusz kockázat. Ha nem teszem ki, az nem plusz kockázat.
És mint már emlitettem, ha már ki kell valamelyiket rakni, mert SZÜKSÉG VAN RÁ, akkor kb mindegy melyiket teszed ki. Semmivel nem biztonságosabb az openvpn mint az rdp. Mindkettőn lehet használni erős jelszót, mindkettőn lehet használni 2FA-t, mindkettőn lehet használni certificate alapú hitelesitést, mindkettőn lehet használni tűzfal szitnű korlátozást, stb-stb.

Akkor hova is a nagy hörgés a kipublikált rdp kapcsán? BS.

Mellesleg irtó gyorsan eljutottunk a vpn-hez nem értő lámer bohócoktól odáig, hogy ha megkérdezem konkrétan milyen brute force kockázatot jelent a közepesen erős jelszón kivül az ég világon semmivel nem védett rdp, hogy én csak kiszinezem a story-t.

A VPN megtörése önmagában nem jelent szerverhez való hozzáférést, te ezt pontosan tudod. Annyi történik, hogy "belső(bb)" hálózathoz fér hozzá. Ott ugyanúgy van autentikáció, adott esetben tűzfalazás, titkosított kommunikáció. Annyi történik, hogy hagymalevelekhez hasonlóan felépített rendszer legkülsőbb rétegén túljutottak.

Viszont a nagy különbség az, hogy míg az RDP port megtörése/azon való átjutás után már a szerverhez férnek hozzá azonnal, addig a VPN-en bejutás időt ad az behatolás felfedezésére, vagyis lassítja a hozzáférését.

Biztosan érted, hogy miről beszélek, csak adod a hülyét.

Az OpenVPN-t meg szándékosan kevered ide. Miért pont azt hoztad példaként? Windows környezetben ez lenne a legszélesebb körben alkalmazott megoldás?

--
trey @ gépház

Én még mindig azt szeretném hallani, hogy hogyan törik meg az rdp-t. Ugye amiről az egész post szól, az - mint fentebb többször kifejtettem - kutyagumit nem ér, még egy átlagos jelszóval védett rdp kapcsán sem, nemhogy a normálisan beállitottal.
Innentől teljesen mindegy, hogy ez hányadik réteg.

Pontosan azért hoztam ellenpéldaként az openvpn-t, mert arról itt sokan hiszik, hogy hú de biztonságos és csak azon keresztül szabad kipublikálni bármit is. Semmivel nem biztonságosabb. Az rdp "ellen" felhozott gondolatok pont úgy igazak az openvpn-re is.
De valóban emlithettem volna az SSTP-t is. Én 90%-ban azt használok, ha vpn-re van szükség.

És szóról szóra igaz az SSTP-re is minden amit fentebb már leirtam.

De emlithetném a közvetlenül kipublikált SMB-t is. Arra is hörög itt a sok "szakértő", mert 20 éve azt olvasta róla, hogy insecure.
Ma meg a fél azure ki van rakva SMB-n a microsoft és ügyfelei által és senki nem tudta megtörni. Haladni kéne a korral, nem biztos, hogy a 20 éves féligazságok mai puffogtatása okos dolog.

Igényektől függ. Ahol egyetlen árva gép, egyetlen szolgáltatását kell kipublikálni (pl. rdp) ott nincs vpn. (van ahol hardver sincs a vpn-hez)

Ahol egy rakás tűzfal mögötti gép, 2 rakás szolgáltatását kell használnia a remote usernek ott vpn van.

Van ahova tökéletesen elegendő egy közvetlenül publikált rdp vagy smb, máshol meg nem. De csak azért nem telepitek vpn szervert, mert az javasember azt mondta, hogy olyat nem szabad, mert 20 éve a kávézaccban rosszat látot a dolog kapcsán. (amúgy meg fingja sincs a protokollról)

hacsak nem a gyenge titkositas segitsegevel.
az elobb megneztem a htbridge-el egy rdp-t, es engedi pl. az RC4-et, a DH csak 1024 bites.
nem ertek hozza, tudna valaki segiteni, hogy hol lehet ezt beallitani hogy a gyenge titkositokat ne engedelyezze es a DH hany bites legyen?

koszi!

--
neked aztan fura humorod van...

Ja. Te itt tartasz, én meg inkább olyan admin bastion / PAM rendszer felé mozdulok, amiben

a) Előbb autentikál egy felületen az admin / user
b) a target rendszerek (RDP, SSH, VNC stb.) fel van számára véve, neki nincs dolga ezekkel
c) az összes, target rendszeren végzett tevékenysége full auditálható (parancsokról transcipt készül, a session-jéről videofelvétel, akár realtime nézhető stb.)

Sok sikert az internetre kibaszkodott megoldásaidhoz.

--
trey @ gépház

Nagyon okos és ügyes vagy. Kár, hogy már nagyon sokadszorra nem birod felfogni, hogy amire neked egy adott helyen szükséged van és jó megoldás az másnak egy kinkeserves baromállatság. (más helyen meg elengedhetetlen)

De majd én is bedobom egyik másik KKV-nak ezt a fantasztikus megoldást, biztos nagyra fogják értékelni.

Ne fáradj, vagyunk páran, akik a KKV-knál is kínáljuk ezt a terméket, akár termékként, akár szolgáltatásként vagy szolgáltatás részeként. Ahol meg nincs pénz ilyenre, ott is fel tudunk venni egy tűzfalszabályt, hogy a nyüves RDP portját ne boldog-boldogtalan, hanem csak meghatározott emberek meghatározott helyről érjék el.

Ja, a fenti megoldással a fentieken kívül meghatározott időbeli feltételt is hozzá lehet tenni, vagy akár olyat, hogy nincs X időben engedélye, a rendszer engedélyt kér mondjuk két felettesétől, akik ha megadják az engedélyt (reply egy levélre), akkor egyszeri hozzáférést kap az user a rendszerhez.

De nagyzolj csak az elavult nézet, kibaszok az internetre mindent hozzáállásoddal. Rajtad kívül mindenki hülye.

--
trey @ gépház

" elavult nézet, kibaszok az internetre mindent hozzáállásoddal"

Neked továbbra is orvosi szintű szövegértési problémáid vannak, azon sajnos nem tudok segiteni.

De nyugodj meg, te nagyon okos és ügyes vagy, csak úgy működhet jól és biztonságosan ahogy te a piciny világodban elképzeled. Az összes helyzetben a te megoldásod a tökéletes, az én megoldásom pedig teljesen szar (az is ahova vpn-t raktam, mert a helyzet megkivánta), csak is a vakszerencse miatt működik sok-sok éve, sok helyen, sok elégedett ügyféllel.

Az pedig ne zavarjon (én sem akadtam fenn rajta) hogy neked fingod sincs, hogy miért büfögöd a 20 éves buta mantrákat (hiába kérdeztem többször is), vagy hogy mire is jó az általad post-olt tool és milyen esetekre veszélyes.

Az se zavarjon, hogy miért lehet a fél azure storage kint közvetlenül smb-n, vagy akár az összes azure vm közvetlenül RDP-n, default porton, hiszen aki nem úgy csinálja, ahogy te, az hülye, kontár, bohóc. A microsoft is, az összes userei is, meg úgy egyébként is.

Továbbra is: /o\

Akkor magyarázd már el nekem, hogy hogyan lehet kint közvetlen SMB-n az azure storage milliónyi microsoft szerveren? Hogyan lehet kint ugyanitt alapból milliónyi VM közvetlenül RDP-n ugyanúgy a microsoft közrelműködésével?

Pofára esés akkor van, amikor a gyakorlati tények konkrétan ellentmondanak a 20 éves marhaságaidnak.

Arról a doksiról pedig elég szépen elmagyaráztam neked, hogy nem azt irják, amit állitasz, azaz hogy ne tedd ki az SMB-t vagy az RDP-t közvetlenül az internetre, hanem hogy mint bármilyen pupblikált szolgáltatást igyekezz lekorlátozni a hozzáférést tűzfallal. Ez egy hálózati biztonsági alapvetés. Nem csak az RDP-re vonatkozik, hanem minden publikált szolgáltatásra, minden oprendszeren.

Elég szomorú, ha ezt magyarázni kell.

Onnan, hogy "Imo majd megy, rohan".

Mert Imo szerint van hiba nélküli szoftver.

"hogy nem azt irják, amit állitasz, azaz hogy ne tedd ki az SMB-t vagy az RDP-t közvetlenül az internetre, hanem hogy mint bármilyen pupblikált szolgáltatást igyekezz lekorlátozni a hozzáférést tűzfallal."

ROTFL, maszatolunk, maszatolunk? Ezt én állítottam. Én mondtam, hogy szűrni kell, hogy honnan / ki férhet hozzá. Ez a minimum.

Te jöttél azzal, hogy kiteszted az internetre, aztán boldog-boldogtalan hozzáfér. Hiszen 12 karakternek mindenre elégnek kell lennie.

--
trey @ gépház

Imo rohanna. Ha igaz lenne. De persze most sem igaz, éppen forditva...

"Ezt én állítottam."

Bullshit. Te azt állitottad, hogy hülyeség SMT-t, RDP-t VPN nélkül publikálni. Erre hoztál egy azure-os doksit, amiben leirják, hogy az amúgy vpn nélkül kipublikált szolgáltatásodat jobb, ha tűzfallal korlátozod a szükséges IP tartományokra. Ahogy bármilyen publikált szolgáltatást.

És huszadjára mondom, a microsoft maga publikálja milliószámú szerverén az SMB-t és RDP-t.

"Hiszen 12 karakternek mindenre elégnek kell lennie. "

Hazudozunk, hazudozunk? Én elsőre is smart card alapú hitelesitésről beszéltem RDP-nél, csak direkt a hülyeséged kiélézésére dobtam be, hogy nemhogy ezt, de még egy átlagos 8 vagy 12 karakteres jelszót se tudnál megtörni az általad bedobott gagyi tool-al.

Sajnos nem mondasz igazat.

Ez volt az eredeti állításom:

"Önmagában az RDP-t kibaszni az internetre nem túl bölcs dolog. Erről a Microsoft is megemlékezik:"

ÉS erre hoztam egy példát, amiben a Microsoft is megemlíti, hogy MINIMUM tűzfalszabállyal illik védeni.

"És huszadjára mondom, a microsoft maga publikálja milliószámú szerverén az SMB-t és RDP-t."

Telibe' szarom. Majd szajkózd ezt az ügyfeleidnek (ha még maradnak), miután szarrá nyomták a gépeiket. Utána meg a Microsoftnak, ami körberöhög, mert a) neked nem mondta, hogy ilyet csinálj b) semmilyen garanciát sem ad neked arra, hogy te ilyet tegyél

Te egy szoftverben bízol vakon, mert más is azt csinálja. Fogalmad nincs arról, hogy a Microsoft ezt hogyan oldja meg, azt a kódot futtatja-e az Azure-ban, amit te megveszel a boltban, nincs-e a megoldásai előtt alkalmazás-szintű tűzfal vagy egyéb megoldás. Találgatsz.

További jó lamerkedést!

--
trey @ gépház

" erre hoztam egy példát, amiben a Microsoft is megemlíti, hogy MINIMUM tűzfalszabállyal illik védeni. "

Tehát a mégiscsak közvetlenül kipublikált (amit állitólag nem szabad) portot illik tűzfalszabállyal védeni. Erre hoztál egy doksit. Ezzel nemhogy cáfoltad, hanem alátámasztottad amit mondtam. Mondok neked egy meglepőt, én még a https-t is szoktam tűzfalszabályokkal korlátozni (pl. tor exit node-ok tiltva), ott ahol a környezet megengedi. Attól még közvetlenül publikálom a portot és nem vpn mögé teszem.

"Telibe' szarom."

Téged sosem zavartak a száraz tények, szajkózd nyugodtan tovább a hülyegédet :)

"Majd szajkózd ezt az ügyfeleidnek (ha még maradnak), miután szarrá nyomták a gépeiket."

Sokéve, naponta ezt mondom az ügyfeleimnek, annyiszor törték már meg a rendszereimet :)

az, hogy az azure -os gepek millioin nyitva van az egesz vilagnak az RDP es az SMB, az eleg szomoru, ez nem azert van szvsz, mert ez jo, hanem mert az egysegsugaruaknak igy tudjak eladni, barhonnan, barmit, barmikor, ez nem a security -rol szol, hanem a marketingrol.

Nyilvan ezt tudva az MS nem fogja leirni, hogy ez biztonsagilag minimum butasag...

Nezd meg az MS sajat hasznalatu szervereit, ami nem berbe adott VM, ketlem, hogy nyitva lenne barmelyiken is a 3389 az INTERNET felol, vajon miert.?.

--
FBK