Office 365 "Direct Send" - onveilige feature?

[maratropa]

In mijn zoektocht naar opties om scan-to-mail te laten werken op een aantal printers kwam ik uit bij de opties die MS zelf geeft. Optie 2 is "direct send", waarbij je zonder authenticatie gewoon het MX endpoint aanspreekt.

https://docs.microsoft.co...crosoft-365-or-office-365

Mails zouden in de spambox moeten komen op deze manier. Nu merkte ik al dat na een aantal scans mails gewoon direct in mijn inbox komen..? Daarbij, ze adviseren een SPF regel aan te maken in de DNS met het externe IP adres er in zodat mails niet in de spam komen..

iig, is dit niet een onwijze aanvalsvector, helemaal als iemand het externe (ge-whiteliste) IP weet (en kan spoofen)? Dan kun je toch extern nepmails (lijkende) uit het domein bij elke andere mailbox in het domein krijgen?

Sowieso lijkt O365 default security vaak niet als prio te hebben, maar valt hier nog iets aan te beveiligen?

[garriej]

Tsja, er moeten mails naar het MX gestuurd kunnen worden anders kun je geen mail ontvangen.

Spoofing is iets dat al bestaat sinds de uitvinding van email.

SPF, DMARC en DKIM inrichten dat helpt hiertegen. Spamfilter anders inrichten dat alles met verkeerde SPF de prullenbak in gaat.

[nelizmastr]

Waar denk je dat SPF, DKIM en DMARC voor zijn

Je autoriseert en authenticeert zo alle mailverkeer voor je domein.
Dat is de beveiliging.

Als je dat niet zint kan je altijd nog plan B toepassen:

- Maak een mailbox aan met exchange online licentie, bijv. [e-mail]
- Stel deze in op elke printer.

Op deze manier heb je SMTP authentication.

Je hebt nog steeds SPF, DKIM en DMARC nodig echter. Dat is anno 2020 niet meer te negeren.

[ Voor 11% gewijzigd door nelizmastr op 21-08-2020 16:12 ]

[maratropa]

@garriej @nelizmastr thnx logisch, wat dan meer mijn issue is, is dat na een paar keer (zonder dat ik het als "geen spam" heb aangemerkt oid) zo'n mail van de printer (die niks doet met dkim dmarc etc) toch in mijn inbox komt? Omdat ik hem al een paar keer eerder geopend heb oid?

@nelizmastr smtp auth via zon account is natuurlijk ook een optie om te bekijken.. Al ging het me meer om de aanwezigheid van direct send in z'n algemeen.

[Xelefim]

maratropa schreef op zaterdag 22 augustus 2020 @ 14:44:
@garriej @nelizmastr thnx logisch, wat dan meer mijn issue is, is dat na een paar keer (zonder dat ik het als "geen spam" heb aangemerkt oid) zo'n mail van de printer (die niks doet met dkim dmarc etc) toch in mijn inbox komt? Omdat ik hem al een paar keer eerder geopend heb oid?

DKIM en DMARC (indien geconfigureerd) komen juist wel nog te pas bij scan to mail printers TENZIJ je je mails stuurt via O365 via hun smtp relay (smtp.office365.com?). Je dient dus altijd zowel interne als externe (gmail, hotmail) scans te sturen en duidelijk de headers checken om te zien of alles oke is.


Het accounting dept van een grote klant wilde dit ook hebben. Accounting program moest facturen uitsturen via anonymous smtp

Issue:
- uitsturen van mails via mailplatform MOET via een shared mailbox account
- er mag geen licentie verspild worden

Oplossing:
Statisch IP van het bureau in de SPF, publiek IP toevoegen aan de connector en klaar... anonymous mails versturen zonder auth en geen last van te belanden in de spam van de ontvanger...

Ik ben niet echt vertrouwd met cyber security maar je hebt het over dat dit onveilig is doordat het public IP gespoofed kan worden?

Hmmmmmm

Stel voor dat je eigen publiek IP 1.1.1.1 is en je spoofed deze van een multinational met als statisch IP 2.2.2.2. Je doet een connectie met een smtp (= TCP) die normaliter een handshake doet. Jouw source IP (als je deze gespoofed hebt) is 2.2.2.2. Naar waar stuurt de smtp zijn reply? Juist niet naar 1.1.1.1 (jou) maar naar 2.2.2.2. Indien 2.2.2.2 beschikt over een firewall kun je het al helemaal vergeten aangezien deze zodanig ingesteld kan worden dat die de spoof replies meteen dropt.

Ik durf dit niet met zekerheid te zeggen maar ik ben zo goed als zeker dat het spoofen van public IP’s voor TCP services onmogelijk is aangezien het krijgen van de replies als hacker enorm moeilijk is tenzij je toegang hebt tot de omgeving van het gehackte bedrijf OF je geluk hebt in het gokken van de randomised sequence numbers van de tcp pakketjes.

[ Voor 4% gewijzigd door Xelefim op 23-08-2020 02:32 ]

[Question Mark]

maratropa schreef op vrijdag 21 augustus 2020 @ 16:03:
Sowieso lijkt O365 default security vaak niet als prio te hebben, maar valt hier nog iets aan te beveiligen?

Als je het artikel goed leest, dan zie je dat "Direct Send" ook niet de aangeraden manier is vanuit MS. MS adviseert nl de optie waarbij het device zichzelf netjes authenticeerd.

Als jij echter gekozen hebt voor apparatuur die dit soort features niet ondersteund heeft MS echter nog de optie "Direct Send" voor je achter de hand.

De keuze welke optie je gebruikt is de jouwe. Als jij kiest voor apparatuur die niet secure is, dan is het gevolg dat de keten wat minder secure is. Dan is het niet MS die security niet als prio heeft, maar ben jij het.

[MainframeX]

Question Mark schreef op maandag 24 augustus 2020 @ 12:08:
[...]

De keuze welke optie je gebruikt is de jouwe. Als jij kiest voor apparatuur die niet secure is, dan is het gevolg dat de keten wat minder secure is. Dan is het niet MS die security niet als prio heeft, maar ben jij het.

Daar ben ik het beslist niet mee eens. Microsoft maakt zich juist medeplichtig aan de instandhouding van dit soort onveilige constructies. Het zou ze sieren als ze een keer qua security het voortouw nemen en dat dit soort printer gebruikers de deksel op hun neus krijgen met hun slechte apparatuur.

[Jeroenneman]

MainframeX schreef op maandag 24 augustus 2020 @ 18:26:
[...]


Daar ben ik het beslist niet mee eens. Microsoft maakt zich juist medeplichtig aan de instandhouding van dit soort onveilige constructies. Het zou ze sieren als ze een keer qua security het voortouw nemen en dat dit soort printer gebruikers de deksel op hun neus krijgen met hun slechte apparatuur.

Ja, en dan kunnen voor de rest prima printers worden afgeschreven omdat er ooit, misschien iets mee gedaan zou kunnen worden.

Dit moet je niet technisch willen oplossen, je moet je gebruikers gewoon trainen om spam/phishing te negeren.

[Jazzy]

MainframeX schreef op maandag 24 augustus 2020 @ 18:26:
[...]


Daar ben ik het beslist niet mee eens. Microsoft maakt zich juist medeplichtig aan de instandhouding van dit soort onveilige constructies. Het zou ze sieren als ze een keer qua security het voortouw nemen en dat dit soort printer gebruikers de deksel op hun neus krijgen met hun slechte apparatuur.

Kun je wat specifieker zijn, wat precies zou Microsoft moeten aanpassen?

[Compizfox]

maratropa schreef op zaterdag 22 augustus 2020 @ 14:44:
@garriej @nelizmastr thnx logisch, wat dan meer mijn issue is, is dat na een paar keer (zonder dat ik het als "geen spam" heb aangemerkt oid) zo'n mail van de printer (die niks doet met dkim dmarc etc) toch in mijn inbox komt? Omdat ik hem al een paar keer eerder geopend heb oid?

Dat kan. Dat hangt van je spamfilter af. De meeste hedendaagse spamfilters (zoals Rspamd, SpamAssassin, etc) werken met een scoresysteem. Mail die SPF/DKIM failt krijgt daarmee dus een positieve score mee. Maar als jij de Bayesiaanse classifier aanleert dat het ham is, dan kan de bijdrage vanuit daar de score weer zover naar beneden drukken dat het niet boven de spam-threshold uitkomt.

[Trommelrem]

nelizmastr schreef op vrijdag 21 augustus 2020 @ 16:11:
- Maak een mailbox aan met exchange online licentie, bijv. [e-mail]
- Stel deze in op elke printer.

Op deze manier heb je SMTP authentication.

Legacy Auth wordt op 13 oktober uitgeschakeld.

[nelizmastr]

Trommelrem schreef op maandag 24 augustus 2020 @ 20:57:
[...]

Legacy Auth wordt op 13 oktober uitgeschakeld.

Ga je dit nu bij elk Office topic posten zonder context?

Graag ook toelichten wat de impact hiervan is en wat nog wel en niet kan na 13 oktober.

[Jazzy]

nelizmastr schreef op maandag 24 augustus 2020 @ 21:39:
[...]


Ga je dit nu bij elk Office topic posten zonder context?

Graag ook toelichten wat de impact hiervan is en wat nog wel en niet kan na 13 oktober.

Als je niet bekend bent met de term kun je natuurlijk ook even zelf onderzoek doen alvorens toelichting te eisen. Zeker als je de term inmiddels al vaker langs hebt zien komen maar nog niet weet wat het is.

[ Voor 16% gewijzigd door Jazzy op 24-08-2020 21:45 ]

[Trommelrem]

nelizmastr schreef op maandag 24 augustus 2020 @ 21:39:
[...]


Ga je dit nu bij elk Office topic posten zonder context?

Wat voor context wil je? Legacy Auth wordt uitgeschakeld. Simple as that.

Graag ook toelichten wat de impact hiervan is en wat nog wel en niet kan na 13 oktober.

Dat zal iedere organisatie voor zichzelf moeten bepalen, of ze moeten een consultant inhuren die het voor ze bepaalt. Met de default tools in AzureAD kom je al een heel eind. Ik denk wel dat het impact heeft op de bovenstaande oplossing, dus vandaar dat ik het aangeef.

[Question Mark]

MainframeX schreef op maandag 24 augustus 2020 @ 18:26:
[...]


Daar ben ik het beslist niet mee eens. Microsoft maakt zich juist medeplichtig aan de instandhouding van dit soort onveilige constructies. Het zou ze sieren als ze een keer qua security het voortouw nemen en dat dit soort printer gebruikers de deksel op hun neus krijgen met hun slechte apparatuur.

Als ze dat doen krijgt MS klachten dat bedrijven versneld hun multi-functionals moeten gaan afschrijven...

En dit is niet uniek. Default staan (onveilige) zaken in een Windows omgeving uitgeschakeld, voor Backwards Compatiblity kan een beheerder kiezen om de onveilige features toch weer te enablen. Da's hier niet anders.

Microsoft gaat niet over het security beleid van een klant. Ze kunnen wél adviseren, en dat is precies wat ze hier doen. Ze raden deze methode ook niet aan, staat ook duidelijk in het artikel.

[hellknight]

Trommelrem schreef op maandag 24 augustus 2020 @ 20:57:
[...]

Legacy Auth wordt op 13 oktober uitgeschakeld.

Het stopt dan voor nieuwe tenants, en tenants waarbij gebruik hiervan niet gedetecteerd is. Voor tenants waarbij het wel in gebruik is, is dit uitgesteld naar 2e helft 2021: https://techcommunity.mic...-2020-update/ba-p/1275508

[Trommelrem]

hellknight schreef op dinsdag 25 augustus 2020 @ 08:22:
[...]

Het stopt dan voor nieuwe tenants, en tenants waarbij gebruik hiervan niet gedetecteerd is. Voor tenants waarbij het wel in gebruik is, is dit uitgesteld naar 2e helft 2021: https://techcommunity.mic...-2020-update/ba-p/1275508

Het gaat dan alsnog gebeuren en het is dus geen werkbare oplossing.

De meeste organisaties hebben Legacy Auth al uitgeschakeld middels Conditional Access en kleinere organisaties middels Security Defaults. Maar nu nog ergens Legacy Auth gaan gebruiken is dus geen goed idee. Het stopt met werken.

[hellknight]

Ik ben het helemaal met je eens dat Legacy Auth niet gebruikt moet worden en dood moet - het ging er mij puur om dat het daadwerkelijk uitschakelen hiervan uitgesteld is