Reverse proxy (of iets dergelijks) voor mail services

[devilkin]

Hoi,

Ik ben wat aan't spelen met wat zaken op een vps te hosten ipv momenteel allerlei ongerelateerde services af te nemen, en zou daar toch enige levels van security willen rond zetten.

Standaard zaken zoals secure OS configuratie of een secure configuratie van de betreffende stukken software laat ik in deze vraag buiten beschouwing (ik bekijk dit als standard practice, je moet alle dingen goed beveiligen)

Dingen die ik erop wil gooien:

• website(s): hier zou ik cloudflare voor zetten, zodat dit niet 'open en bloot' op het internet staat (+ firewalling en enkel traffic toelaten van CF)
• vpn endpoint, wss openvpn
• mail: zowel incoming als outgoing smtp, alsook imap access voor een aantal (aliassed) domains.

Vooral voor dat laatste zit ik een beetje te zoeken naar goeie oplossingen waardoor je toch jezelf enige extra lagen beveiliging kan toe-eigenen. Een optie zou zijn om daar een extra vps voor te zetten met nginx als reverse proxy - maar eigelijk was ik aan het rondneuzen of er toevallig geen hosted solutions zijn die je daarvoor kan gebruiken (alla cloudflare).

Outgoing SMTP zou ik ook nog kunnen opvangen door gebruik van sendgrid/mailgun/AWS SES.

Enige andere ideeën?

[wagenveld]

Hosted antispam is wat je zoekt, bijvoorbeeld EOP.

[Jazzy]

Begin met het omschrijven van het probleem dat je probeert op te lossen. Wat is het risico van zelf mail aannemen op poort 25 en op welke manier verklein je dat risico met een SMTP relay dienst?

[Verwijderd]

Waarom wil je een reverse (http) proxy op je mail? Leg eens uit?

Voor de load balancing hoef je het niet te doen aangezien je MXen naar believen kan toevoegen, en het verprutst je Received: regels zonder dat het je verder wat nuttigs oplevert.

[devilkin]

Het (theoretische) risico dat ik wil mitigeren:

• incoming smtp: bugs in smtpd die exploited worden, waardoor men in het OS kan inbreken of andere rotzooi kan veroorzaken.
• outgoing smtp: spam blocklists (nee, ik stuur geen spam) proberen te vermijden

Spam filtering an sich is iets waar ik me zelf wel wil mee bezighouden - het gaat me vooral om de attack vector te verkleinen / onaantrekkelijk te maken.

[devilkin]

Verwijderd schreef op dinsdag 17 juli 2018 @ 13:19:
Waarom wil je een reverse (http) proxy op je mail? Leg eens uit?

nginx kan ook smtp/imap/pop3 proxy'en: https://docs.nginx.com/ng...de/mail-proxy/mail-proxy/

Nginx heeft toch een betere reputatie dan de meeste MTA en MDA's. (voor zover ik weet)

Het is natuurlijk geen vrijgeleide om de boel niet uptodate te houden.

[DJMaze]

devilkin schreef op dinsdag 17 juli 2018 @ 13:20:
incoming smtp: bugs in smtpd die exploited worden, waardoor men in het OS kan inbreken of andere rotzooi kan veroorzaken.

Je zoekt naar een naald in een hooiberg. SSH en Website(s) hosten zijn je 99.9% attack vector.

[devilkin]

DJMaze schreef op dinsdag 17 juli 2018 @ 13:30:
[...]

Je zoekt naar een naald in een hooiberg. SSH en Website(s) hosten zijn je 99.9% attack vector.

True. Al denk ik dat je de http(s) vector kan remediëren door de boel uptodate te houden, deftig te configureren, geen brol te deployen op de sites en iets zoals CF ervoor te zetten.

SSH is kwestie van dat toe te draaien (heb ik nu ook al publiekelijk op een aantal machines)

[Verwijderd]

devilkin schreef op dinsdag 17 juli 2018 @ 13:26:
nginx kan ook smtp/imap/pop3 proxy'en:

Ziet er naar uit dat dat bedoeld is voor client side mail handling, niet het inkomende mail verhaal. Hoeft voor die laatste ook niet want het protocol heeft load balancing al ingebouwd, waar client side dat toch anders ligt.

Nginx heeft toch een betere reputatie dan de meeste MTA en MDA's. (voor zover ik weet)

Ben er al weer een tijdje uit maar de meeste MTAs zijn prima zonder meer aan het publieke 'net te hangen. Uitzonderingen die me zo te binnen schieten zijn exchange (is ook geen echte MTA, doet het er een beetje bij) en qmail (wegens obscure gevolgen van DJBs strikt-in-de-leer houding). Postfix is zelfs helemaal opgesplitst in processen en opgezet om problemen niet van het ene in het andere proces te laten lekken, terwijl nginx daar lang zo strikt niet in is. nginx is ook bedoeld voor iets anders, en zelfs dit proxy feature is zo te zien niet voor de publieke email-aanname bedoeld. Dus als we het over reputatie hebben, dan zet ik toch nog liever zelfs sendmail neer.

Ik denk ook niet dat een extra laag gewoon voor de extra laag per definitie "beter" is. Natuurlijk is het mooi als je een protocol-filter ervoor zet waardoor misvormde rommel er niet door komt, maar aan de andere kant moet een MTA daar gewoon tegen kunnen en bovendien kan zo'n proxy zelf rare effecten introduceren die op andere wijze obscure problemen kunnen opleveren, mischien zelfs door onbedoeld andere gaten in je MTA te triggeren. Dus simpelweg het codepad verlengen, wat je hier toch doet, is niet automatisch veiliger. Vanuit het idee dat minder complexiteit minder ruimte voor problemen biedt, zelfs precies het omgekeerde.

[Jazzy]

Verwijderd schreef op dinsdag 17 juli 2018 @ 14:35:
Ben er al weer een tijdje uit maar de meeste MTAs zijn prima zonder meer aan het publieke 'net te hangen. Uitzonderingen die me zo te binnen schieten zijn exchange

Leg uit, ik ben benieuwd.

[synoniem]

Ik heb op meerdere sites een combinatie van Postfix, Dovecot, SASL, Spamassasin, ClamAV, DKIM, SPF, DMARC en Fail2Ban lopen. Waar ik nu naar aan het kijken ben is om e.e.a. in Docker containers onder te brengen om zo mail en http (Apache2) te scheiden maar tot op heden loopt het allemaal prima. Als je maar zorgt dat je tijdig update.

[Brahiewahiewa]

Jazzy schreef op dinsdag 17 juli 2018 @ 15:29:
[...]

Leg uit, ik ben benieuwd.

Met "een tijdje" bedoelt hij 23 jaar.

[DJMaze]

synoniem schreef op dinsdag 17 juli 2018 @ 15:39:
Docker containers

Wordt het niet veiliger van zoals hij wil.
Eerder brakker.

[Verwijderd]

Focker?

DJMaze schreef op dinsdag 17 juli 2018 @ 13:30:
Je zoekt naar een naald in een hooiberg.

Brand de hooiberg af en ga met een magneet door de as.

SSH en Website(s) hosten zijn je 99.9% attack vector.

Jup! SSH goed configureren (/etc/hosts.[allow|deny], sshd_config) en alleen logins met keys toestaan (1 key per user@host + ip(range)).

/etc/hosts.deny

code:

sshd: ALL

/etc/hosts.allow

code:

sshd: 192.168.0.0/16
sshd: 10.0.0.0/8

sshd_config met o.a.:

code:

...
PubkeyAuthentication no
PasswordAuthentication no

Match User example Address 10.0.0.0/8
  PubkeyAuthentication yes

authorized_keys:

code:

from="192.168.0.0/16,10.0.0.0/8" ssh-rsa keyhere example@ip_for_documentation

Dit configureer ik (gelukkig) niet handmatig, maar met Ansible.

[ Voor 19% gewijzigd door Verwijderd op 17-07-2018 19:29 ]

[synoniem]

En

PermitRootLogin no

[Verwijderd]

synoniem schreef op dinsdag 17 juli 2018 @ 18:51:
En

PermitRootLogin no

En nog een berg meer.

[synoniem]

Verwijderd schreef op dinsdag 17 juli 2018 @ 19:00:
[...]

En nog een berg meer.

Dat somt het wel redelijk op ja. Hoewel ik AcceptEnv LANG LC_* na Shellshock ook uitgezet heb.

[Verwijderd]

synoniem schreef op dinsdag 17 juli 2018 @ 19:19:
[...]

Dat somt het wel redelijk op ja. Hoewel ik AcceptEnv LANG LC_* na Shellshock ook uitgezet heb.

offtopic:
Mja, daar zat/zit ik nog over te twijfelen. Gewoon geen vuln machines hebben, maar dat valt (soms) buiten mijn controle.