Microsoft blokkeert vanaf mei 2024 mail van kwetsbare Exchange 2016/2019-servers
Microsoft gaat e-mail die vanaf kwetsbare Exchange 2016/2019-servers naar Exchange Online wordt verstuurd vanaf volgend jaar mei blokkeren. Exchange 2007 is al in augustus aan de beurt, gevolgd door Exchange Server 2010 en 2013 in respectievelijk november en februari. Dat heeft Microsoft bekendgemaakt. Volgens het techbedrijf wordt de maatregel genomen om het "Exchange-ecosysteem" te beschermen en is het geen manier om klanten naar de cloud te krijgen.
Exchange Server 2007, 2010 en 2013 zijn inmiddels end-of-life en ontvangen geen beveiligingsupdates meer. Exchange 2016 en 2019 worden nog wel door Microsoft ondersteund, maar alleen als die een bepaalde Cumulative Update (CU) hebben geïnstalleerd. Wanneer een Exchange 2016/2019-server geen up-to-date CU-versie draait, beschouwt Microsoft die als kwetsbaar. Om het aantal kwetsbare Exchange-servers terug te dringen kondigde Microsoft begin dit jaar het plan aan om mail afkomstig van deze servers en bedoeld voor Exchange Online te blokkeren.
Zodra een kwetsbare Exchange-server verbinding maakt met Exchange Online voor het afleveren van e-mails zal dit in het Exchange admin center van de kwetsbare server worden gemeld. Beheerders krijgen dan dertig dagen de tijd om actie te ondernemen. Na deze periode zal Exchange Online beginnen met het "throttelen" van verbindingen afkomstig van de server en een SMTP 450 foutmelding geven. In eerste instantie zal het throttelen vijf minuten per uur zijn, maar dit zal met de tijd verder toenemen.
Als deze maatregel niet helpt zal Exchange Online beginnen met het blokkeren van verbindingen, en daarmee e-mails, afkomstig van de kwetsbare Exchange-server. Ook de periode dat Exchange Online verbindingen blokkeert vindt geleidelijk plaats, totdat het helemaal niet meer mogelijk is om vanaf de kwetsbare Exchange-server e-mails naar Exchange Online te sturen. Microsoft was oorspronkelijk van plan om eind mei met het waarschuwen van Exchange 2007-beheerders te beginnen, maar heeft nu besloten om hier een maand mee te wachten. Daardoor is de hele tijdlijn met een maand verschoven.
Reacties (32)
Microsoft heeft die servers zelf kwetsbaar gemaakt! Deze uitsluitpraktijken worden niet gemeld in de EULA.
goed plan all was het maar voor de veiligheid..microsoft loopt eigelijk achter de fijten aan wat up to date betreft.....ie 11..?
oneerlijke concurentie ten opzichte van andere security providers...
immers microsoft heeft inside informatie over de kwetsbaarheden, deze servers bellen-naar-huis om te aan te geven dat ze kwetsbaar zijn...
door er actief met die informatie iets te gaan doen, veroorzaken ze een ongelijk speelveld.
het alternatief dat ze informatie geven over kwetsbare klanten lijkt me ook niet vliegen, dus in mijn optiek mag het niet wat ze doen.
immers microsoft heeft inside informatie over de kwetsbaarheden, deze servers bellen-naar-huis om te aan te geven dat ze kwetsbaar zijn...
door er actief met die informatie iets te gaan doen, veroorzaken ze een ongelijk speelveld.
het alternatief dat ze informatie geven over kwetsbare klanten lijkt me ook niet vliegen, dus in mijn optiek mag het niet wat ze doen.
Ik vraag mij af waarom zulke oude exchange servers nog steeds gebruikt worden, het is bekend dat deze soms al zeer lang end-of-life zijn. Waarom heeft met deze niet ge-update naar een nieuwere versie...
Het was te verwachten dat support voor dit soort kwetsbare/gevaarlijke servers zou stoppen, en met goed recht.
Dat er een heleboel "service" providers zijn die niets updaten omdat dit geld kost en ze dan minder winst op de contracten maken, is nog geen rede om ze te ontzien.
Als bedrijven willen dat ze kwetsbaar willen zijn voor ransomware en andere malware is dat hun keuze, maar als je andere bedrijven in de problemen brengt omdat jij niet update is een ander verhaal. Voor een van de eerste keren ben ik het eens met de keuze van microsoft
Het was te verwachten dat support voor dit soort kwetsbare/gevaarlijke servers zou stoppen, en met goed recht.
Dat er een heleboel "service" providers zijn die niets updaten omdat dit geld kost en ze dan minder winst op de contracten maken, is nog geen rede om ze te ontzien.
Als bedrijven willen dat ze kwetsbaar willen zijn voor ransomware en andere malware is dat hun keuze, maar als je andere bedrijven in de problemen brengt omdat jij niet update is een ander verhaal. Voor een van de eerste keren ben ik het eens met de keuze van microsoft
Prima strategie, jammer dat het nodig is. (Zowel qua techniek - Software niet bulletproof - , als laks update beleid beheerders).
23-05-2023, 11:56 door
Tintin and Milou
Door Anoniem: Microsoft heeft die servers zelf kwetsbaar gemaakt! Deze uitsluitpraktijken worden niet gemeld in de EULA.
Wat heeft dit met een EULA te maken?Door Anoniem: Microsoft heeft die servers zelf kwetsbaar gemaakt! Deze uitsluitpraktijken worden niet gemeld in de EULA.
Rare reactie en veel te kort door de bocht.
Inzichten veranderen, technieken veranderen. Niets is onfeilbaar.
Vooraf is bekent dat er een lifecycle zit op een product, geldt dus ook voor Exchange 2007 t/m 13 plus 16 etc.
Door Anoniem: Prima strategie, jammer dat het nodig is. (Zowel qua techniek - Software niet bulletproof - , als laks update beleid beheerders).
Meestal gebeurt dit doordat beheerders geen toestemming krijgen van "managers" om de servers down te brengen c.q. te upgraden. Maar daar lult niemand over.Door Anoniem:
Door Anoniem: Prima strategie, jammer dat het nodig is. (Zowel qua techniek - Software niet bulletproof - , als laks update beleid beheerders).
Meestal gebeurt dit doordat beheerders geen toestemming krijgen van "managers" om de servers down te brengen c.q. te upgraden. Maar daar lult niemand over.Bedrijven met dit beleid zijn vroeg of laat altijd de klos met een enorme breach, onprem of in de cloud, maakt niet uit. In de cloud is share-gehalte nog makkelijker. In mijn ogen vragen dat soort organisaties ook om slachtoffer te worden van security threats. GEEN medelijden mee. Heeft niets te maken met een software leverancier.
23-05-2023, 13:52 door
_R0N_
Door Anoniem: Microsoft heeft die servers zelf kwetsbaar gemaakt! Deze uitsluitpraktijken worden niet gemeld in de EULA.
Niemand schrijft foutloze code op die schaal. Microsoft biedt patches en fixes aan om fouten uit het verleden te verhelpen. Wanneer beheerders die patches en fixes niet toepassen is niet Microsoft maar de beheerder verantwoordelijk voor het falen.
Door Anoniem: oneerlijke concurentie ten opzichte van andere security providers...
immers microsoft heeft inside informatie over de kwetsbaarheden, deze servers bellen-naar-huis om te aan te geven dat ze kwetsbaar zijn...
door er actief met die informatie iets te gaan doen, veroorzaken ze een ongelijk speelveld.
het alternatief dat ze informatie geven over kwetsbare klanten lijkt me ook niet vliegen, dus in mijn optiek mag het niet wat ze doen.
Heb je wel enig idee, waar het hier over gaat? Gezien jouw reactie betwijfel ik dat.immers microsoft heeft inside informatie over de kwetsbaarheden, deze servers bellen-naar-huis om te aan te geven dat ze kwetsbaar zijn...
door er actief met die informatie iets te gaan doen, veroorzaken ze een ongelijk speelveld.
het alternatief dat ze informatie geven over kwetsbare klanten lijkt me ook niet vliegen, dus in mijn optiek mag het niet wat ze doen.
Door _R0N_:
Niemand schrijft foutloze code op die schaal. Microsoft biedt patches en fixes aan om fouten uit het verleden te verhelpen. Wanneer beheerders die patches en fixes niet toepassen is niet Microsoft maar de beheerder verantwoordelijk voor het falen.
Door Anoniem: Microsoft heeft die servers zelf kwetsbaar gemaakt! Deze uitsluitpraktijken worden niet gemeld in de EULA.
Niemand schrijft foutloze code op die schaal. Microsoft biedt patches en fixes aan om fouten uit het verleden te verhelpen. Wanneer beheerders die patches en fixes niet toepassen is niet Microsoft maar de beheerder verantwoordelijk voor het falen.
Daar aan toe te voegen dat exploitatie ook steeds complexer wordt door de komst van fuzzers en toolkits welke shellcode genereren.
Huh? Fuzzers en shellcode generators maken exploitatie juist makkelijker. De security mitigations en opkomst van memory safe languages maken het juist lastiger. Je moet meer vulns chainen of een ander type vuln vinden om een succesvolle exploit te maken.
Door _R0N_:
Niemand schrijft foutloze code op die schaal. Microsoft biedt patches en fixes aan om fouten uit het verleden te verhelpen. Wanneer beheerders die patches en fixes niet toepassen is niet Microsoft maar de beheerder verantwoordelijk voor het falen.
Ik heb een recht gekocht om deze software te mogen gebruiken. Dat recht kan Microsoft mij niet ontnemen als ik niet patch.Door Anoniem: Microsoft heeft die servers zelf kwetsbaar gemaakt! Deze uitsluitpraktijken worden niet gemeld in de EULA.
Niemand schrijft foutloze code op die schaal. Microsoft biedt patches en fixes aan om fouten uit het verleden te verhelpen. Wanneer beheerders die patches en fixes niet toepassen is niet Microsoft maar de beheerder verantwoordelijk voor het falen.
in de overeenkomst met Microsoft staat niet dat ik verplicht ben om te patchen of te upgraden. Dit is een vette schending van mijn gebruikersruimte.
23-05-2023, 17:06 door
Tintin and Milou
Door Anoniem: oneerlijke concurentie ten opzichte van andere security providers...
immers microsoft heeft inside informatie over de kwetsbaarheden, deze servers bellen-naar-huis om te aan te geven dat ze kwetsbaar zijn...
door er actief met die informatie iets te gaan doen, veroorzaken ze een ongelijk speelveld.
het alternatief dat ze informatie geven over kwetsbare klanten lijkt me ook niet vliegen, dus in mijn optiek mag het niet wat ze doen.
De huidige versies inclusief builds zijn gewoon openbaar bekend. Heb jij een oude versie draaien, kan iedereen dit gewoon zien.immers microsoft heeft inside informatie over de kwetsbaarheden, deze servers bellen-naar-huis om te aan te geven dat ze kwetsbaar zijn...
door er actief met die informatie iets te gaan doen, veroorzaken ze een ongelijk speelveld.
het alternatief dat ze informatie geven over kwetsbare klanten lijkt me ook niet vliegen, dus in mijn optiek mag het niet wat ze doen.
23-05-2023, 17:08 door
Tintin and Milou
Door Anoniem:
in de overeenkomst met Microsoft staat niet dat ik verplicht ben om te patchen of te upgraden. Dit is een vette schending van mijn gebruikersruimte.
Je mag het ook nog steeds gebruiken.Door _R0N_:
Niemand schrijft foutloze code op die schaal. Microsoft biedt patches en fixes aan om fouten uit het verleden te verhelpen. Wanneer beheerders die patches en fixes niet toepassen is niet Microsoft maar de beheerder verantwoordelijk voor het falen.
Ik heb een recht gekocht om deze software te mogen gebruiken. Dat recht kan Microsoft mij niet ontnemen als ik niet patch.Door Anoniem: Microsoft heeft die servers zelf kwetsbaar gemaakt! Deze uitsluitpraktijken worden niet gemeld in de EULA.
Niemand schrijft foutloze code op die schaal. Microsoft biedt patches en fixes aan om fouten uit het verleden te verhelpen. Wanneer beheerders die patches en fixes niet toepassen is niet Microsoft maar de beheerder verantwoordelijk voor het falen.
in de overeenkomst met Microsoft staat niet dat ik verplicht ben om te patchen of te upgraden. Dit is een vette schending van mijn gebruikersruimte.
Echter niemand is verplicht om jouw mail ook te accepteren of om het jouw server samen te werken voor uitwisselingen van mail.
Ik mag jouw gewoon blockeren, als jij onveilige software gebruikt, een dynamisch IP gebruikt of geen TLS kunt opzetten.
Wie verplicht mij precies om jou te accepteren?
Door Tintin and Milou:
Hoe dan? want dat is in principe een security probleem. Mijn postfix versie is niet bekend in het openbaar.Door Anoniem: oneerlijke concurentie ten opzichte van andere security providers...
immers microsoft heeft inside informatie over de kwetsbaarheden, deze servers bellen-naar-huis om te aan te geven dat ze kwetsbaar zijn...
door er actief met die informatie iets te gaan doen, veroorzaken ze een ongelijk speelveld.
het alternatief dat ze informatie geven over kwetsbare klanten lijkt me ook niet vliegen, dus in mijn optiek mag het niet wat ze doen.
De huidige versies inclusief builds zijn gewoon openbaar bekend. Heb jij een oude versie draaien, kan iedereen dit gewoon zien.immers microsoft heeft inside informatie over de kwetsbaarheden, deze servers bellen-naar-huis om te aan te geven dat ze kwetsbaar zijn...
door er actief met die informatie iets te gaan doen, veroorzaken ze een ongelijk speelveld.
het alternatief dat ze informatie geven over kwetsbare klanten lijkt me ook niet vliegen, dus in mijn optiek mag het niet wat ze doen.
Door Anoniem:
Bedrijven met dit beleid zijn vroeg of laat altijd de klos met een enorme breach, onprem of in de cloud, maakt niet uit. In de cloud is share-gehalte nog makkelijker. In mijn ogen vragen dat soort organisaties ook om slachtoffer te worden van security threats. GEEN medelijden mee. Heeft niets te maken met een software leverancier.
Het gaat er mij niet om dat die bedrijven vroeger of later de klos zijn, maar dat hier telkenmale mensen roepen dat het de schuld van de beheerder is. Ik heb bij teveel bedrijven gewerkt waar je niet mocht patchen want dan was de uptime in gevaar, maar als er dan iets gebeurt dat je dan wel de schuld krijgt en je dus moet zorgen dat er een paper trail is die aantoont dat het niet aan de beheerder ligt maar aan het "manglement" en dan nog proberen ze je onderuit te halen of je het werk zo onmogelijk te maken dat ze zelf ontslag neemt.Door Anoniem:
Door Anoniem: Prima strategie, jammer dat het nodig is. (Zowel qua techniek - Software niet bulletproof - , als laks update beleid beheerders).
Meestal gebeurt dit doordat beheerders geen toestemming krijgen van "managers" om de servers down te brengen c.q. te upgraden. Maar daar lult niemand over.Bedrijven met dit beleid zijn vroeg of laat altijd de klos met een enorme breach, onprem of in de cloud, maakt niet uit. In de cloud is share-gehalte nog makkelijker. In mijn ogen vragen dat soort organisaties ook om slachtoffer te worden van security threats. GEEN medelijden mee. Heeft niets te maken met een software leverancier.
Door Anoniem:
in de overeenkomst met Microsoft staat niet dat ik verplicht ben om te patchen of te upgraden. Dit is een vette schending van mijn gebruikersruimte.
Het is inderdaad jou server en jij beslist wat je ermee doet. Jij kan dus beslissen dat je email van andere mailservers niet meer accepteert. Dat is je goed recht. Exchange Online is van Microsoft, en Microsoft beslist dat hun server bepaalde mailservers niet meer zal accepteren. Dat is hun goed recht. Hetzelfde als dat van jou.Door _R0N_:
Niemand schrijft foutloze code op die schaal. Microsoft biedt patches en fixes aan om fouten uit het verleden te verhelpen. Wanneer beheerders die patches en fixes niet toepassen is niet Microsoft maar de beheerder verantwoordelijk voor het falen.
Ik heb een recht gekocht om deze software te mogen gebruiken. Dat recht kan Microsoft mij niet ontnemen als ik niet patch.Door Anoniem: Microsoft heeft die servers zelf kwetsbaar gemaakt! Deze uitsluitpraktijken worden niet gemeld in de EULA.
Niemand schrijft foutloze code op die schaal. Microsoft biedt patches en fixes aan om fouten uit het verleden te verhelpen. Wanneer beheerders die patches en fixes niet toepassen is niet Microsoft maar de beheerder verantwoordelijk voor het falen.
in de overeenkomst met Microsoft staat niet dat ik verplicht ben om te patchen of te upgraden. Dit is een vette schending van mijn gebruikersruimte.
Het is vriendelijkheid dat ze dit zo aankondigen, en dat ze de versturende server laten weten dat Exchange Online die server zal gaan blokkeren. Dan kan de eigenaar besluiten wat hij wil.
Door Anoniem:
in de overeenkomst met Microsoft staat niet dat ik verplicht ben om te patchen of te upgraden. Dit is een vette schending van mijn gebruikersruimte.
Door _R0N_:
Niemand schrijft foutloze code op die schaal. Microsoft biedt patches en fixes aan om fouten uit het verleden te verhelpen. Wanneer beheerders die patches en fixes niet toepassen is niet Microsoft maar de beheerder verantwoordelijk voor het falen.
Ik heb een recht gekocht om deze software te mogen gebruiken. Dat recht kan Microsoft mij niet ontnemen als ik niet patch.Door Anoniem: Microsoft heeft die servers zelf kwetsbaar gemaakt! Deze uitsluitpraktijken worden niet gemeld in de EULA.
Niemand schrijft foutloze code op die schaal. Microsoft biedt patches en fixes aan om fouten uit het verleden te verhelpen. Wanneer beheerders die patches en fixes niet toepassen is niet Microsoft maar de beheerder verantwoordelijk voor het falen.
in de overeenkomst met Microsoft staat niet dat ik verplicht ben om te patchen of te upgraden. Dit is een vette schending van mijn gebruikersruimte.
Je hebt her recht gekocht om het te mogen gebruiken, net zoals je een mobiele telefoon, wasmachine en koelkast koopt. Je hebt het recht om deze te gebruiken, alleen heeft hebben deze dingen net zoals software die je koopt niet het eeuwige leven en kwetsbaarheden die erin zitten zorgen ervoor dat deze op een gegeven moment niet meer werken of kapot zijn. helaas hebben wasmachines, koelkasten en mobiele telefoons onderdelen die verslijten en dus de werkzaamheid van de apparatuur teniet doen. hetzelfde is met software, het doet wat het moet doen maar er zitten fouten in die net als versleten onderdelen op een gegeven moment niet meer voldoen. Moet je apparatuur/ software tot het einde der tijd onderhouden ongeacht of dit veilig is of überhaupt wenselijk is? Software heeft altijd maar een bepaalde tijd gehad dat deze ondersteund en veilig is.
En zolang jij het hebt mag je het gebruiken, maar verwacht niet dat onveilige software tot het oneindige toegang blijft houden tot systemen waarvoor het een gevaar is. End-of-life software is niet nieuw.. ugh...Microsoft Windows... ugh... Er is een goede rede waarom oudere windows besturingssystemen bij bedrijven niet meer op het netwerk mogen, dezelfde rede dat microsoft exchange oudere systemen gaat buitensluiten voor de mail.
Ik ben blij dat microsoft voor de afwisseling eens denkt aan de veiligheid van het exchange systeem ten opzichten van end-of life systemen. geeft een veilig gevoel
24-05-2023, 09:50 door
Tintin and Milou
Door Anoniem:
Het gaat er mij niet om dat die bedrijven vroeger of later de klos zijn, maar dat hier telkenmale mensen roepen dat het de schuld van de beheerder is. Ik heb bij teveel bedrijven gewerkt waar je niet mocht patchen want dan was de uptime in gevaar, maar als er dan iets gebeurt dat je dan wel de schuld krijgt en je dus moet zorgen dat er een paper trail is die aantoont dat het niet aan de beheerder ligt maar aan het "manglement" en dan nog proberen ze je onderuit te halen of je het werk zo onmogelijk te maken dat ze zelf ontslag neemt.
uptime staat los van gepland onderhoud indien je dit afspreekt, wat vrij standaard is in een SLA overeenkomst.Het gaat er mij niet om dat die bedrijven vroeger of later de klos zijn, maar dat hier telkenmale mensen roepen dat het de schuld van de beheerder is. Ik heb bij teveel bedrijven gewerkt waar je niet mocht patchen want dan was de uptime in gevaar, maar als er dan iets gebeurt dat je dan wel de schuld krijgt en je dus moet zorgen dat er een paper trail is die aantoont dat het niet aan de beheerder ligt maar aan het "manglement" en dan nog proberen ze je onderuit te halen of je het werk zo onmogelijk te maken dat ze zelf ontslag neemt.
Je kunt gewoon 100% uptime hebben, als je iedere donderdag avond van 23:00-04:00 onderhoud mag plegen of in het weekend om de week.
Is dit ook niet gewenst, dan is de infrastructuur dus niet geschikt voor de afgesproken of de verwachte SLA.
Door Anoniem:
Het is vriendelijkheid dat ze dit zo aankondigen, en dat ze de versturende server laten weten dat Exchange Online die server zal gaan blokkeren. Dan kan de eigenaar besluiten wat hij wil.
Het SMTP protocol voorziet hier helemaal niet in. Microsoft maakt dan gebruik van een hackerstool. Als je hiermee problemen ondervindt zet je er gewoon postfix tussen.Door Anoniem:
in de overeenkomst met Microsoft staat niet dat ik verplicht ben om te patchen of te upgraden. Dit is een vette schending van mijn gebruikersruimte.
Het is inderdaad jou server en jij beslist wat je ermee doet. Jij kan dus beslissen dat je email van andere mailservers niet meer accepteert. Dat is je goed recht. Exchange Online is van Microsoft, en Microsoft beslist dat hun server bepaalde mailservers niet meer zal accepteren. Dat is hun goed recht. Hetzelfde als dat van jou.Door _R0N_:
Niemand schrijft foutloze code op die schaal. Microsoft biedt patches en fixes aan om fouten uit het verleden te verhelpen. Wanneer beheerders die patches en fixes niet toepassen is niet Microsoft maar de beheerder verantwoordelijk voor het falen.
Ik heb een recht gekocht om deze software te mogen gebruiken. Dat recht kan Microsoft mij niet ontnemen als ik niet patch.Door Anoniem: Microsoft heeft die servers zelf kwetsbaar gemaakt! Deze uitsluitpraktijken worden niet gemeld in de EULA.
Niemand schrijft foutloze code op die schaal. Microsoft biedt patches en fixes aan om fouten uit het verleden te verhelpen. Wanneer beheerders die patches en fixes niet toepassen is niet Microsoft maar de beheerder verantwoordelijk voor het falen.
in de overeenkomst met Microsoft staat niet dat ik verplicht ben om te patchen of te upgraden. Dit is een vette schending van mijn gebruikersruimte.
Het is vriendelijkheid dat ze dit zo aankondigen, en dat ze de versturende server laten weten dat Exchange Online die server zal gaan blokkeren. Dan kan de eigenaar besluiten wat hij wil.
Door Tintin and Milou:
Je kunt gewoon 100% uptime hebben, als je iedere donderdag avond van 23:00-04:00 onderhoud mag plegen of in het weekend om de week.
Is dit ook niet gewenst, dan is de infrastructuur dus niet geschikt voor de afgesproken of de verwachte SLA.
Wij doen onderhoud terwijl het feestje gewoon doorgaat. Enige eis is overstappen op een ander OS.Door Anoniem:
Het gaat er mij niet om dat die bedrijven vroeger of later de klos zijn, maar dat hier telkenmale mensen roepen dat het de schuld van de beheerder is. Ik heb bij teveel bedrijven gewerkt waar je niet mocht patchen want dan was de uptime in gevaar, maar als er dan iets gebeurt dat je dan wel de schuld krijgt en je dus moet zorgen dat er een paper trail is die aantoont dat het niet aan de beheerder ligt maar aan het "manglement" en dan nog proberen ze je onderuit te halen of je het werk zo onmogelijk te maken dat ze zelf ontslag neemt.
uptime staat los van gepland onderhoud indien je dit afspreekt, wat vrij standaard is in een SLA overeenkomst.Het gaat er mij niet om dat die bedrijven vroeger of later de klos zijn, maar dat hier telkenmale mensen roepen dat het de schuld van de beheerder is. Ik heb bij teveel bedrijven gewerkt waar je niet mocht patchen want dan was de uptime in gevaar, maar als er dan iets gebeurt dat je dan wel de schuld krijgt en je dus moet zorgen dat er een paper trail is die aantoont dat het niet aan de beheerder ligt maar aan het "manglement" en dan nog proberen ze je onderuit te halen of je het werk zo onmogelijk te maken dat ze zelf ontslag neemt.
Je kunt gewoon 100% uptime hebben, als je iedere donderdag avond van 23:00-04:00 onderhoud mag plegen of in het weekend om de week.
Is dit ook niet gewenst, dan is de infrastructuur dus niet geschikt voor de afgesproken of de verwachte SLA.
24-05-2023, 10:35 door
Tintin and Milou
Door Anoniem:
Je verwart hier eis met requirement. Door Tintin and Milou:
Je kunt gewoon 100% uptime hebben, als je iedere donderdag avond van 23:00-04:00 onderhoud mag plegen of in het weekend om de week.
Is dit ook niet gewenst, dan is de infrastructuur dus niet geschikt voor de afgesproken of de verwachte SLA.
Wij doen onderhoud terwijl het feestje gewoon doorgaat. Enige eis is overstappen op een ander OS.Door Anoniem:
Het gaat er mij niet om dat die bedrijven vroeger of later de klos zijn, maar dat hier telkenmale mensen roepen dat het de schuld van de beheerder is. Ik heb bij teveel bedrijven gewerkt waar je niet mocht patchen want dan was de uptime in gevaar, maar als er dan iets gebeurt dat je dan wel de schuld krijgt en je dus moet zorgen dat er een paper trail is die aantoont dat het niet aan de beheerder ligt maar aan het "manglement" en dan nog proberen ze je onderuit te halen of je het werk zo onmogelijk te maken dat ze zelf ontslag neemt.
uptime staat los van gepland onderhoud indien je dit afspreekt, wat vrij standaard is in een SLA overeenkomst.Het gaat er mij niet om dat die bedrijven vroeger of later de klos zijn, maar dat hier telkenmale mensen roepen dat het de schuld van de beheerder is. Ik heb bij teveel bedrijven gewerkt waar je niet mocht patchen want dan was de uptime in gevaar, maar als er dan iets gebeurt dat je dan wel de schuld krijgt en je dus moet zorgen dat er een paper trail is die aantoont dat het niet aan de beheerder ligt maar aan het "manglement" en dan nog proberen ze je onderuit te halen of je het werk zo onmogelijk te maken dat ze zelf ontslag neemt.
Je kunt gewoon 100% uptime hebben, als je iedere donderdag avond van 23:00-04:00 onderhoud mag plegen of in het weekend om de week.
Is dit ook niet gewenst, dan is de infrastructuur dus niet geschikt voor de afgesproken of de verwachte SLA.
Tot zo ver ik weet, draait Exchange bijvoorbeeld niet op een ander OS dan Windows.
Net zoals ik heel veel applicaties heb draaien die alleen maar op Windows draaien of Windows afhankelijkheden hebben. Dat los je op in je applicatie en niet je OS.
Je advies, is net een klaverblad reclame voorbeeld. Je oplossing, is geen oplossing en je laat zien dat je geen besef hebt van wat voor een onnozel advies je geeft.
Daarnaast als ik Tomcat of Apache moet updaten, heb ik toch ook echt impact (en risico).
Reboot ik mijn server bijvoorbeeld niet, kan het ook zo maar zijn, dat niet alle libraries opnieuw geladen zijn als ik mijn zoveelste openssl update moet uitvoeren.
Zou het zo moeten zijn, nee. maar het zal niet de eerste keer zijn of dat een reboot toch net een andere reactie geeft aan de applicatie die opstart.
Door Anoniem:
Door Anoniem:
Het is vriendelijkheid dat ze dit zo aankondigen, en dat ze de versturende server laten weten dat Exchange Online die server zal gaan blokkeren. Dan kan de eigenaar besluiten wat hij wil.
Het SMTP protocol voorziet hier helemaal niet in. Microsoft maakt dan gebruik van een hackerstool. Als je hiermee problemen ondervindt zet je er gewoon postfix tussen.Door Anoniem:
in de overeenkomst met Microsoft staat niet dat ik verplicht ben om te patchen of te upgraden. Dit is een vette schending van mijn gebruikersruimte.
Het is inderdaad jou server en jij beslist wat je ermee doet. Jij kan dus beslissen dat je email van andere mailservers niet meer accepteert. Dat is je goed recht. Exchange Online is van Microsoft, en Microsoft beslist dat hun server bepaalde mailservers niet meer zal accepteren. Dat is hun goed recht. Hetzelfde als dat van jou.Door _R0N_:
Niemand schrijft foutloze code op die schaal. Microsoft biedt patches en fixes aan om fouten uit het verleden te verhelpen. Wanneer beheerders die patches en fixes niet toepassen is niet Microsoft maar de beheerder verantwoordelijk voor het falen.
Ik heb een recht gekocht om deze software te mogen gebruiken. Dat recht kan Microsoft mij niet ontnemen als ik niet patch.Door Anoniem: Microsoft heeft die servers zelf kwetsbaar gemaakt! Deze uitsluitpraktijken worden niet gemeld in de EULA.
Niemand schrijft foutloze code op die schaal. Microsoft biedt patches en fixes aan om fouten uit het verleden te verhelpen. Wanneer beheerders die patches en fixes niet toepassen is niet Microsoft maar de beheerder verantwoordelijk voor het falen.
in de overeenkomst met Microsoft staat niet dat ik verplicht ben om te patchen of te upgraden. Dit is een vette schending van mijn gebruikersruimte.
Het is vriendelijkheid dat ze dit zo aankondigen, en dat ze de versturende server laten weten dat Exchange Online die server zal gaan blokkeren. Dan kan de eigenaar besluiten wat hij wil.
Ik krijg gewoon de headers te zien in de SMTP communicatie.
Door Anoniem:
in de overeenkomst met Microsoft staat niet dat ik verplicht ben om te patchen of te upgraden. Dit is een vette schending van mijn gebruikersruimte.
Door _R0N_:
Niemand schrijft foutloze code op die schaal. Microsoft biedt patches en fixes aan om fouten uit het verleden te verhelpen. Wanneer beheerders die patches en fixes niet toepassen is niet Microsoft maar de beheerder verantwoordelijk voor het falen.
Ik heb een recht gekocht om deze software te mogen gebruiken. Dat recht kan Microsoft mij niet ontnemen als ik niet patch.Door Anoniem: Microsoft heeft die servers zelf kwetsbaar gemaakt! Deze uitsluitpraktijken worden niet gemeld in de EULA.
Niemand schrijft foutloze code op die schaal. Microsoft biedt patches en fixes aan om fouten uit het verleden te verhelpen. Wanneer beheerders die patches en fixes niet toepassen is niet Microsoft maar de beheerder verantwoordelijk voor het falen.
in de overeenkomst met Microsoft staat niet dat ik verplicht ben om te patchen of te upgraden. Dit is een vette schending van mijn gebruikersruimte.
Je mag nog steeds je outdated en onveilige server(s) blijven gebruiken. Maar Microsoft zorgt er wel voor dat je daarmee anderen niet lastig gaat vallen. Mooi toch?
Door Anoniem:
Je hebt her recht gekocht om het te mogen gebruiken, net zoals je een mobiele telefoon, wasmachine en koelkast koopt. Je hebt het recht om deze te gebruiken, alleen heeft hebben deze dingen net zoals software die je koopt niet het eeuwige leven en kwetsbaarheden die erin zitten zorgen ervoor dat deze op een gegeven moment niet meer werken of kapot zijn. helaas hebben wasmachines, koelkasten en mobiele telefoons onderdelen die verslijten en dus de werkzaamheid van de apparatuur teniet doen. hetzelfde is met software, het doet wat het moet doen maar er zitten fouten in die net als versleten onderdelen op een gegeven moment niet meer voldoen. Moet je apparatuur/ software tot het einde der tijd onderhouden ongeacht of dit veilig is of überhaupt wenselijk is? Software heeft altijd maar een bepaalde tijd gehad dat deze ondersteund en veilig is.
En zolang jij het hebt mag je het gebruiken, maar verwacht niet dat onveilige software tot het oneindige toegang blijft houden tot systemen waarvoor het een gevaar is. End-of-life software is niet nieuw.. ugh...Microsoft Windows... ugh... Er is een goede rede waarom oudere windows besturingssystemen bij bedrijven niet meer op het netwerk mogen, dezelfde rede dat microsoft exchange oudere systemen gaat buitensluiten voor de mail.
Ik ben blij dat microsoft voor de afwisseling eens denkt aan de veiligheid van het exchange systeem ten opzichten van end-of life systemen. geeft een veilig gevoel
Het is alleen Microsoft die eigen software uitsluit, andere bedrijven met hun software niet. Heeft allemaal ook niks met SMTP of IMAP etc te maken. Microsoft wilt gewoon dat ji nieuwe gebruiksrechten koopt. Over veiligheid zullen we het maar niet hebben gezien de zero days van de laatste maanden.Door Anoniem:
in de overeenkomst met Microsoft staat niet dat ik verplicht ben om te patchen of te upgraden. Dit is een vette schending van mijn gebruikersruimte.
Door _R0N_:
Niemand schrijft foutloze code op die schaal. Microsoft biedt patches en fixes aan om fouten uit het verleden te verhelpen. Wanneer beheerders die patches en fixes niet toepassen is niet Microsoft maar de beheerder verantwoordelijk voor het falen.
Ik heb een recht gekocht om deze software te mogen gebruiken. Dat recht kan Microsoft mij niet ontnemen als ik niet patch.Door Anoniem: Microsoft heeft die servers zelf kwetsbaar gemaakt! Deze uitsluitpraktijken worden niet gemeld in de EULA.
Niemand schrijft foutloze code op die schaal. Microsoft biedt patches en fixes aan om fouten uit het verleden te verhelpen. Wanneer beheerders die patches en fixes niet toepassen is niet Microsoft maar de beheerder verantwoordelijk voor het falen.
in de overeenkomst met Microsoft staat niet dat ik verplicht ben om te patchen of te upgraden. Dit is een vette schending van mijn gebruikersruimte.
Je hebt her recht gekocht om het te mogen gebruiken, net zoals je een mobiele telefoon, wasmachine en koelkast koopt. Je hebt het recht om deze te gebruiken, alleen heeft hebben deze dingen net zoals software die je koopt niet het eeuwige leven en kwetsbaarheden die erin zitten zorgen ervoor dat deze op een gegeven moment niet meer werken of kapot zijn. helaas hebben wasmachines, koelkasten en mobiele telefoons onderdelen die verslijten en dus de werkzaamheid van de apparatuur teniet doen. hetzelfde is met software, het doet wat het moet doen maar er zitten fouten in die net als versleten onderdelen op een gegeven moment niet meer voldoen. Moet je apparatuur/ software tot het einde der tijd onderhouden ongeacht of dit veilig is of überhaupt wenselijk is? Software heeft altijd maar een bepaalde tijd gehad dat deze ondersteund en veilig is.
En zolang jij het hebt mag je het gebruiken, maar verwacht niet dat onveilige software tot het oneindige toegang blijft houden tot systemen waarvoor het een gevaar is. End-of-life software is niet nieuw.. ugh...Microsoft Windows... ugh... Er is een goede rede waarom oudere windows besturingssystemen bij bedrijven niet meer op het netwerk mogen, dezelfde rede dat microsoft exchange oudere systemen gaat buitensluiten voor de mail.
Ik ben blij dat microsoft voor de afwisseling eens denkt aan de veiligheid van het exchange systeem ten opzichten van end-of life systemen. geeft een veilig gevoel
En mijn Postfix server uit 1998 mag nog wel met M$ praten? Dit is puur om Exchange gebruikers naar de cloud te pushen. Je kan er gewoon een Postfix servertje voor zetten. Probleem opgelost.
Door Tintin and Milou:
Tot zo ver ik weet, draait Exchange bijvoorbeeld niet op een ander OS dan Windows.
Net zoals ik heel veel applicaties heb draaien die alleen maar op Windows draaien of Windows afhankelijkheden hebben. Dat los je op in je applicatie en niet je OS.
Je advies, is net een klaverblad reclame voorbeeld. Je oplossing, is geen oplossing en je laat zien dat je geen besef hebt van wat voor een onnozel advies je geeft.
Daarnaast als ik Tomcat of Apache moet updaten, heb ik toch ook echt impact (en risico).
Reboot ik mijn server bijvoorbeeld niet, kan het ook zo maar zijn, dat niet alle libraries opnieuw geladen zijn als ik mijn zoveelste openssl update moet uitvoeren.
Zou het zo moeten zijn, nee. maar het zal niet de eerste keer zijn of dat een reboot toch net een andere reactie geeft aan de applicatie die opstart.
Als je tomcat of Apache update hoef je de server niet te rebooten. Door Anoniem:
Je verwart hier eis met requirement. Door Tintin and Milou:
Je kunt gewoon 100% uptime hebben, als je iedere donderdag avond van 23:00-04:00 onderhoud mag plegen of in het weekend om de week.
Is dit ook niet gewenst, dan is de infrastructuur dus niet geschikt voor de afgesproken of de verwachte SLA.
Wij doen onderhoud terwijl het feestje gewoon doorgaat. Enige eis is overstappen op een ander OS.Door Anoniem:
Het gaat er mij niet om dat die bedrijven vroeger of later de klos zijn, maar dat hier telkenmale mensen roepen dat het de schuld van de beheerder is. Ik heb bij teveel bedrijven gewerkt waar je niet mocht patchen want dan was de uptime in gevaar, maar als er dan iets gebeurt dat je dan wel de schuld krijgt en je dus moet zorgen dat er een paper trail is die aantoont dat het niet aan de beheerder ligt maar aan het "manglement" en dan nog proberen ze je onderuit te halen of je het werk zo onmogelijk te maken dat ze zelf ontslag neemt.
uptime staat los van gepland onderhoud indien je dit afspreekt, wat vrij standaard is in een SLA overeenkomst.Het gaat er mij niet om dat die bedrijven vroeger of later de klos zijn, maar dat hier telkenmale mensen roepen dat het de schuld van de beheerder is. Ik heb bij teveel bedrijven gewerkt waar je niet mocht patchen want dan was de uptime in gevaar, maar als er dan iets gebeurt dat je dan wel de schuld krijgt en je dus moet zorgen dat er een paper trail is die aantoont dat het niet aan de beheerder ligt maar aan het "manglement" en dan nog proberen ze je onderuit te halen of je het werk zo onmogelijk te maken dat ze zelf ontslag neemt.
Je kunt gewoon 100% uptime hebben, als je iedere donderdag avond van 23:00-04:00 onderhoud mag plegen of in het weekend om de week.
Is dit ook niet gewenst, dan is de infrastructuur dus niet geschikt voor de afgesproken of de verwachte SLA.
Tot zo ver ik weet, draait Exchange bijvoorbeeld niet op een ander OS dan Windows.
Net zoals ik heel veel applicaties heb draaien die alleen maar op Windows draaien of Windows afhankelijkheden hebben. Dat los je op in je applicatie en niet je OS.
Je advies, is net een klaverblad reclame voorbeeld. Je oplossing, is geen oplossing en je laat zien dat je geen besef hebt van wat voor een onnozel advies je geeft.
Daarnaast als ik Tomcat of Apache moet updaten, heb ik toch ook echt impact (en risico).
Reboot ik mijn server bijvoorbeeld niet, kan het ook zo maar zijn, dat niet alle libraries opnieuw geladen zijn als ik mijn zoveelste openssl update moet uitvoeren.
Zou het zo moeten zijn, nee. maar het zal niet de eerste keer zijn of dat een reboot toch net een andere reactie geeft aan de applicatie die opstart.
Linux != Windows. Je hoeft zelfs in sommige gevallen de service niet eens te restarten (dnf reload apache). Zelfs zo'n simpele service als apache levert geen downtime op als deze wordt ge-restart (dnf restart apache)
Het commando needs-restarting levert een lijst met processen die ge-restart moeten worden.
(needs-restarting looks through running processes and tries to detect those that use files from packages that have been updated after the given process started.)
Daar kan Microsoft nog wat van leren. i.t.t. MSSQL draait Exchange inderdaad niet onder Linux. De alternatieven hebben meer uptime en zijn veiliger.
Door Anoniem: De alternatieven hebben meer uptime en zijn veiliger.
Alternatieven heb je alleen niets aan, als je applicatie er niet op wilt draaien of niet de functionality bied die je nodig hebt.Uptime regel je op applicatie niveau niet op een OS.
Veiliger... Is ook een discussie waard.
Door Anoniem: En mijn Postfix server uit 1998 mag nog wel met M$ praten? Dit is puur om Exchange gebruikers naar de cloud te pushen. Je kan er gewoon een Postfix servertje voor zetten. Probleem opgelost.
Het is trouwens MS.Een postfix server er voorzetten, headers kunnen nog steeds gelezen worden.
En lost maar weinig op, afgezien je een extra server en applicatie moet gaan beheren en dus kennis voor moet hebben.
Door Anoniem:
Een postfix server er voorzetten, headers kunnen nog steeds gelezen worden.
En lost maar weinig op, afgezien je een extra server en applicatie moet gaan beheren en dus kennis voor moet hebben.
Het gaat erom dat die Postfix server veel onveiliger kan zijn dan die Exchange server. Daarom is dit zo vreemd.Door Anoniem: En mijn Postfix server uit 1998 mag nog wel met M$ praten? Dit is puur om Exchange gebruikers naar de cloud te pushen. Je kan er gewoon een Postfix servertje voor zetten. Probleem opgelost.
Het is trouwens MS.Een postfix server er voorzetten, headers kunnen nog steeds gelezen worden.
En lost maar weinig op, afgezien je een extra server en applicatie moet gaan beheren en dus kennis voor moet hebben.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Information Security Officer (2fte)
Een uitdagende rol waarbij jij, op basis van security, de vertaalslag maakt tussen business en IT en direct bijdraagt aan de veiligheid van informatie binnen de gemeente Almere. Dat is in een notendop waar jij als Information Security Officer mee bezig bent. Interesse gewekt? Door groei van de organisatie zijn we op zoek naar twee nieuwe collega’s.
Specialiseer je in Forensisch ICT
Online informatieavond 19 november
Wil jij je specialiseren in digitaal forensisch onderzoek? Je kennis verbreden en tech-nische vaardigheden ontwikkelen? Ontdek de cursus- en opleidingsmogelijkheden van Hogeschool Leiden:
- Bachelor Informatica Forensisch ICT (deeltijd)
- Master Digital Forensics (vol- en deeltijd)
- Module Mobile Forensics
- Module Data Analytics
Interesse? Meld je aan!
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
