SMTP relay csak helyi felhasználóknak

Linux-haladó

Sziasztok!

Van egy SENDMAIL levelezőszerverem amely a helyi felhasználóknak szeretne egy speciális porton (nem 25) SMTP szolgáltatást nyújtani StartTLS azonosítással
ha a cégen kívül vannak a nagyvilágban, bármilyen IP címről.

Hogyan állítom azt be egy CentOS szervereren, hogy csak azoktól a felhasználóktól fogadjon és relay-eljen akik előtte azonosították már magukat!

Az access fájl körül keresgélek de nem tudom megoldani, hogy csak az azonosított felhasználókat engedje.

Remélem tudtok segíteni...

  • 7624 megtekintés

( uid_7086 | 2013. 12. 02., h – 13:00 )

subs...
(bár csak kíváncsiságból)

off: régen, még a levelező listák idejében volt szokás, hogy ha egy listára írni akartál vagy csak olvasni akartad az ott folyó társalgást, fel kellett iratkozni. Ennek egyik módja egy a listát működtető szerver címére küldött, "subscribe" tartalmú e-mail küldése volt. Itt meg úgy lehet megjelölni egy témát, hogy a "saját friss tartalmak" közt megjelenjen, ha írsz hozzá valamit. Kb. ezt jelenti az a "subs". :)

A többi meg csak annyit jelent, hogy engem is érdekel a téma, de csak a kíváncsiság vezet, nincs rá szükségem. ;)

A linken leírtakat annyival egészíteném ki hogy az AuthOptions-ban lehet megmondani, hogy csak starttls után engedjen könnyen lehallgatható authentikációt (PLAIN, LOGIN):
Pl. /etc/mail/sendmail.mc-ben MAIL FROM előtti azonosítással, starttls utáni PLAIN/LOGIN authentikációval, anonymous metódusok tiltásával engedett relay:
pl.
define(`confAUTH_OPTIONS', `A p y')dnl

Annak szabályzása, hogy milyen authentikáció után enged relay-t:
pl.
TRUST_AUTH_MECH(`LOGIN PLAIN')dnl

Köszönöm szépen a hozzászólásokat, nagyon sokat pöcsöltem mindennel, beállítottam, amit írtatok, de nem nyertem még. Még a régi (de egyetlen) magyar referenciakönyvet is felhajtottam a Sendmailról (Sendmail Linuxra c. SAMS könyv), de még mindig nem teljesen értem, hogyan történhet az ami történik.

Leírom, hogy hogy állok most:

Elvileg akkor tudnak a szerverről küldeni levelet SMTP-n keresztül, ha azonosítják magukat, titkosított csatornán. A többi kísérletet nem továbbítja a szerver.

Azt látom, hogy valami zombi háló másodpercenként 20-30 alkalommal próbál meg rajtam keresztül emailt küldeni, változatos IP címekről és mindig valamelyik valós tényleg általam kiszolgált hostnéven mutatkozik be a szervernek random felhasználónevekkel.

pl. ztrrb@valami.hu, majd gjkekju@valami.hu aztán fgo@valami.hu és így tovább.
Amikor belép, másolatban megcímez 4-5 nevet, ezek a spam listájából jönnek biztos és megpróbál nekik egy levelet elküldeni.

A levelek ugyan nem mennek el, de percenként néhány 100 fájllal növekszik a mail queu directorym.
Nem lehet valahogyan azt beállítani, hogy ha kamu a feladónév a bejelentkezéskor, rögtön dobja el a szerver a kapcsolatot a pi..ába?

Emellett még azt vettem észre, hogy a levelezőszerveren kiszolgált kb. 10 cégnek a fele tud a gmailre küldeni, a másik felét visszadobja, hogy erről az IP-ről blokkolva van, miközben a másik ötnek meg megy a levelezés.

Ezek után ha kigreppelem a maillogból, hogy hány levelet kezdett el továbbítani ma, akkor meg több ezres számot kapok.. Nem értem.

Napok óta bújok mindent, de nem jutok igazán előrébb.

Hát két dologgal próbálkoznék a helyedben, ha még nem volt meg.
1. goaway PRIVACY FLAG
define(`confPRIVACY_FLAGS',`goaway,restrictmailq,restrictqrun')dnl
http://docstore.mik.ua/orelly/other/Sendmail_3rd/1565928393_ch24-91368…
http://www.getshifting.com/wiki/sendmailsecurity

2. ratecontrol & conncontrol FEATURE
FEATURE(`greet_pause',`5000')dnl
FEATURE(`ratecontrol', `nodelay',`terminate')dnl
FEATURE(`conncontrol', `nodelay',`terminate')dnl
http://tech.nifelheim.info/2009/03/hardening-sendmail-against-ddos/

Illetve még az access file-ban lehet ilyen Srv_Features, hogy Try_TLS és TLS_Clt.

Üdv:
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

A tanácsok nagyon hasznosak voltak!

Úgy sikerült orvosolnom a porblémát, hogy nagyon beleásva magam a linkekbe amit adtatok, meg a sendmail könyvbe, drasztikusan szigorítottam a szabályokon. A plain text auth-ot teljesen kitiltottam, csaak az SSL/TLS alapon lehet a szerverhez szólni, van greet_pause is és a miltereket is szigorúbbra állítottam.
Korlátoztam az egyszerre megnyitható processzeket és szigorúbbra vettem a felhasználók küldési szabályait is.

Így most úgy tűnik, sikerült úrrá lennem a helyzeten.

Amivel most szívok, hogy elés sok SPAM RBL listára felkerült a szerver IP és egyenként puncsolok mindenhol, hogy szedjenek le, de nem megy hamar.
Ráadásul a gmail és a yahoo mail is ilyen listára tett. Van valakinek ötlete, tippje, hogy hogyan lehetne az ő blokkolásuk alól kikerülni? :(

De azt mondtad, hogy a levelek nem mentek ki, csak töltötte fel a queue könyvtárat.
Ha ezek az email-ek ki tudtak menni, akkor nincs jól beállítva a relay. Vagy ez még az előtt volt, hogy elkezdted állítgatni? Mindenféle varázslás nélkül nem lenne szabad, hogy csak úgy levelet tudjanak küldeni rajtad keresztül. Ilyen szempontból az SSL/TSL indifferens.
A fenti linkeknél fontos volt a goaway opció, ami magába foglalja a noexpn és a novrfy opciókat is. Ezek megakadályozzák, hogy a spammer a felhasználókat illetően tapogatózni tudjon a szerveren.

Üdv:
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Igen ez igaz alapból nem relay-elt a szerver máshová és nem tudtak küldeni,
viszont a logból az derült ki, hogy volt amikor eltalálták valamelyik tényleg létező felhasználó
adatait és azzal sikerült levelet kiküldeniük.

Igazság szerint a legmagasabbra állítottam a log levelet a sendmailnál hogy lássam mi történik, de
olyan irtóztatóan sok bejegyzés készült, hogy szinte követhetetlen volt számomra, hogy pontosan mi történik.

A mqueue könyvtárban ilyen fájlok keletkeztek:
(a domain nevet kicseréltem, meg az ip címet elrejtettem.)

V8
T1386198167
K1386198185
N1
P360418
I253/2/50858294
MUser unknown
Fbs
$_ti-228-133-69.telkomadsl.co.za [105.228.133.69]
$rESMTP
$skcmgdztb
${daemon_flags}
${if_addr}9X.22X.X.XXX
S
MDeferred: 421 mtaig-mbe02.mx.aol.com Service unavailable - try again later
rRFC822; judddas@aol.com
RPFD:
MDeferred: 421 RP-001 (COL0-MC4-F54) Unfortunately, some messages from 9X.22X.X.XXX weren't sent. Please try again. We have limits for how many messages can be sent per hour and per day. You can also refer to http://mail.live.com/mail/troubleshooting.aspx#errors.
rRFC822; 8zimo690@hotmail.com
RPFD:<8zimo690@hotmail.com>
rRFC822; mr.mcdaniels@yahoo.com
RPFD:
rRFC822; hugh.granr95@yahoo.com
RPFD:
rRFC822; ornadust@yahoo.com
RPFD:
MDeferred: 421 4.7.1 [TS03] All messages from 9X.22X.X.XXX will be permanently deferred; Retrying will NOT succeed. See http://postmaster.yahoo.com/421-ts03.html
rRFC822; tdoneki@yahoo.com
RPFD:
H?P?Return-Path: <▒g>
H??Received: from kcmgdztb (ti-228-133-69.telkomadsl.co.za [105.228.133.69])
(authenticated bits=0)
by sajatdomainem.hu (8.13.8/8.13.8) with ESMTP id rB4MIjLQ026768;
Thu, 5 Dec 2013 00:02:47 +0100
H?M?Message-Id: <201312042302.rB4MIjLQ026768@sajatdomainem.hu>
H??From: "Zbo Xho"
H??Subject:
H??Date: Wed, 4 Dec 2013 23:50:16 -0700
H??To: , ,
,
, ,
,
<8zimo690@hotmail.com>, ,
H??Mime-Version: 1.0
H??Content-Type: text/plain; charset=iso-8859-1
.

Aham.
Akkor erre egyrészt a goaway-re van szükség, másrészt hogy kívülről csak authentikálva lehessen levelet küldeni.
Elvileg sínen kell legyél.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( kea | 2013. 12. 04., sze – 09:47 )

Én úgy korlátoztam a helyi júzerek (egy részhalmazára), hogy az smtp (és az imap is) csak localhost-on szolgáltat, a felhasználó meg csinál ssh alagutat. Felhasználói gépen a mail kliensnek smtp localhost:2525, imap localhost:1143, ssh alagút

ssh -f -N -L 2525:localhost:25 júzer@kiszolgáló

és persze ugyanez az imap-ra. Ssh elérés korlátozható felhasználóra (sshd_config, AllowUsers) és kaputovábbításra (~/.ssh/authorized_keys-be: no-pty,command="/bin/false" ssh-rsa ..., ha jól emlékszem).

Nem túl nagy számosságú felhasználói halmaz esetén kényelmes megoldás.

Üdv:
KEA.

( junior013 | 2013. 12. 04., sze – 17:05 )

Ha nem ragaszkodsz feltétlenül a sendmail-hez, postfix-el viszonylag egyszerű összehozni akár a user/pass SMTP authentikációt, akár a "pop before smtp"-t (bár a pop meg már kiment a divatból)