SMTP op andere poort, risico?

[Korakal]

Hi all,

Voor één van onze klanten beheer ik een applicatie. Ik wil hier een stuk bijprogrammeren, waardoor iedere keer als er een bepaalde handeling wordt verricht automatisch een e-mail verstuurd moet gaan worden (nee, geen Big Brother automatisering van handmatige taken).
De applicatie draait lokaal op de workstations, welke zijn beveiligd met een McAfee firewall. Op de applicatieserver kan ik ongestoord gebruik maken van Blat voor het versturen van e-mail naar de centrale SMTP server, maar op de workstations wordt dit tegengehouden door McAfee (op poort 25). Terecht denk ik, want bij bijv. virus-/wormbesmetting moet niet zomaar mail kunnen worden afgeleverd op centrale SMTP server. Maar dus ook niet vanuit 'mijn' applicatie.
Nu heb ik uitgevonden dat wanneer ik de SMTP service op poort 28 laat draaien (op de applicatieserver), ik wel gewoon mail kan versturen door middel van de Blat engine vanaf de workstations.

Waar ik nu benieuwd naar ben: wat voor beveiligingsrisico vormt dit nu? Ik wil de relay toestemming op de applicatieserver alleen instellen voor de workstations die daadwerkelijk mail moeten gaan versturen vanuit de applicatie. Mensen zullen er niet mee gaan knutselen, 't zijn eindgebruikers zonder verstand van ICT. Is deze oplossing ook ongevoelig voor wormen etc, omdat er geen gebruik wordt gemaakt van de standaard poort?

Thanks voor meedenken en tips!

[arjants]

Je kunt eventueel ook je applicatie excluden in de portblocking list.
De naam van je executable even toevoegen en klaar (draait er epo/protection pilot?)

[Sendy]

Het toestaan van SMTP op port 28 is in ieder geval niet erger dan het toestaan van HTTP op port 80. Beide kanalen zou je in principe kunnen gebruiken om verkeer te smokkelen.

[silverstorm]

Je kan met een firewall ook regelen dat het verkeer over een bepaalde poort naar een bepaalde bestemming mag.

[sanfranjake]

offtopic:
k5l

Mailservers op internet die ook poort 28 begrijpen zijn er volgens mij niet
Ik zou eerder zeggen dat die mailserver niet goed geconfigureerd is als 'ie zomaar van iedereen mailtjes mag accepteren... en een beetje netwerkbeheerder zorgt er ook wel voor dat ditsoort poorten geblocked worden lijkt me. Even mijn point of view dan dit, een veiligheidslek is een open smtpserver altijd...
Kan je de applicatie niet middels een of ander script rechtstreeks onder de credentials van de ingelogde users een mailtje in exchange laten droppen (of domino, whatever..)

[mbaltus]

sanfranjake schreef op dinsdag 23 december 2008 @ 21:11:
Kan je de applicatie niet middels een of ander script rechtstreeks onder de credentials van de ingelogde users een mailtje in exchange laten droppen (of domino, whatever..)

Het probleem zit er meer in dat de applicatie op de werkplek via poort 25 verbinding wil leggen, McAfee Enterprise blokkeert dat. Het maakt dus niet uit of je met een al dan niet geauthenticeerde user wil inloggen, het wordt altijd tegengehouden.

Jouw oplossing werkt wel als je vervolgens Outlook zou gebruiken voor het verzenden van de mail, maar dan gebeurt dat op naam van de gebruiker en moet je een die melding van Outlook weg zien te poetsen dat je toestemming moet verlenen.

De netste manier is inderdaad zoals arjants zegt om een exclusie voor de applicatie op te nemen. De rest van de oplossingen (verschuiven naar poort 28 oid) is allemaal vragen om problemen in de toekomst!

[ Voor 30% gewijzigd door mbaltus op 24-12-2008 14:16 ]

[BCC]

Hoe versturen de werkstations of dit moment eigenlijk hun email?

[sanfranjake]

mbaltus schreef op woensdag 24 december 2008 @ 14:15:
Het probleem zit er meer in dat de applicatie op de werkplek via poort 25 verbinding wil leggen, McAfee Enterprise blokkeert dat. Het maakt dus niet uit of je met een al dan niet geauthenticeerde user wil inloggen, het wordt altijd tegengehouden.

Jup klopt, ik heb het probleem met k5l samen gisteravond al getackeld. Er komt een rfc, maar in grote organisaties duurt dat soms nogal lang

BCC schreef op woensdag 24 december 2008 @ 14:16:
Hoe versturen de werkstations of dit moment eigenlijk hun email?

Outlook/Exchange 2003

offtopic:
sorry korakal maar kon het ff niet laten

[ Voor 20% gewijzigd door sanfranjake op 24-12-2008 14:27 ]

[Rolfie]

Het probleem zit er meer in dat de applicatie op de werkplek via poort 25 verbinding wil leggen, McAfee Enterprise blokkeert dat. Het maakt dus niet uit of je met een al dan niet geauthenticeerde user wil inloggen, het wordt altijd tegengehouden.

Als je op de werkstations het ook via blat zou kunnen doen, waarom rename je blat.exe niet gewoon naar outlook.exe? Dit zou het probleem moeten oplossen. Toch?

[Gomez12]

Rolfie schreef op woensdag 24 december 2008 @ 19:45:
[...]


Als je op de werkstations het ook via blat zou kunnen doen, waarom rename je blat.exe niet gewoon naar outlook.exe? Dit zou het probleem moeten oplossen. Toch?

Misschien een aantal jaar terug met simplistische firewalls die alleen maar naar de naam van het proces keken.
Huidige lokale firewalls gebruiken ook fingerprinting /applicatie hashes etc, waardoor het toch nog steeds een andere app is dan de standaard outlook die door de firewall probeert te komen...