Topic: limitare smtp in ingresso

[v8star]

Buongiorno a tutti,

ho un cliente a cui devo trasferire nella sua struttura l'hosting di 5 caselle email fornendo pop, imap e webmail per cui sme è un must.
La ricezione delle mail (quindi l'mx record) è e resterà affidato ad un server in gestione in un datacenter che non fa altro che risparare le email pulite ad un host in relazione al dominio del cliente.
Il problema sorge dal fatto che il cliente non ha un firewall per limitare il traffico sulla porta 25 ad un solo ip e con SME non saprei come fare. il contrib Email-Whitelist l'ho testato ma putroppo non riesco a farlo funzionare o non fa a questo caso.

Si può agire con le iptables oppure c'è qualche metodo più elegante?

grazie

[Fumetto]

Una sorta di

db config setprop servizio_smtp AllowHosts a.b.c.d,x.y.z.0/32
db config setprop servizio_smtp DenyHosts e.f.g.h,l.m.n.0/24
signal-event remoteaccess-update

potrebbe funzionare...

[Stefano]

ahem...

o "db configuration" oppure "config"

in ogni caso il suggerimento è corretto.. il DenyHosts potrebbe anche essere uno 0.0.0.0/0, ma consiglio di fare dei test.

il servizio è sul quale agire è qpsmtpd, ma, mi ripeto, qualche test è da fare

[Stefano]

mi correggo, il servizio è smtpd

con un

Code: [Select]

config setprop smtpd AllowHosts ip_server/32 DenyHosts 0.0.0.0/0
signal-event remoteaccess-update

ottengo (nel mio caso ip_server è 10.0.3.254)

Code: [Select]

denylog    tcp  --  anywhere             10.0.3.15           tcp dpt:smtp
ACCEPT     tcp  --  10.0.3.254           10.0.3.15           tcp dpt:smtp

ripeto, è da testare, perchè l'ordine delle regole è fondamentale..

[v8star]

da un iptables -S ho estrapolato questo output:

-A InboundTCP -j InboundTCP_24020
-A InboundTCP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j denylog
-A InboundTCP_24020 ! -d 192.168.1.150/32 -j denylog
-A InboundTCP_24020 -d 192.168.1.150/32 -p tcp -m tcp --dport 113 -j REJECT --reject-with tcp-reset
-A InboundTCP_24020 -d 192.168.1.150/32 -p tcp -m tcp --dport 80 -j ACCEPT
-A InboundTCP_24020 -d 192.168.1.150/32 -p tcp -m tcp --dport 993 -j ACCEPT
-A InboundTCP_24020 -d 192.168.1.150/32 -p tcp -m tcp --dport 443 -j ACCEPT
-A InboundTCP_24020 -d 192.168.1.150/32 -p tcp -m tcp --dport 25 -j denylog
-A InboundTCP_24020 -s 123.123.123.123/32 -d 192.168.1.150/32 -p tcp -m tcp --dport 25 -j ACCEPT
-A InboundTCP_24020 -s 456.456.456.456/32 -d 192.168.1.150/32 -p tcp -m tcp --dport 25 -j ACCEPT
-A InboundTCP_24020 -d 192.168.1.150/32 -p tcp -m tcp --dport 465 -j ACCEPT

dalla rete locale riesco ancora a fare un telnet sulla 25 ma da fuori vengo segato

teoricamente dovrei muovere la regola in grassetto dopo le altre 2 in corsivo, right?

[Stefano]

si..

ti consiglio di porgere la domanda nei forum in lingua inglese, spiegando la tua situazione e chiedendo il miglior modo per implementarla; fossi in te non chiederei "come scambiare l'ordine delle regole di iptables"

farei comunque riferimento al metodo testato (AllowHosts e DenyHosts)

[v8star]

sto facendo un po di test, lo sme è virtuale e sto andando di snapshot a spago   

non mi è chiaro come lavora il proxy smtp: vedo che c'è anche questa regola qua


Chain SMTPProxy (1 references)
target     prot opt source               destination
denylog    tcp  --  anywhere             anywhere            tcp dpt:smtp

è così di default o è stata anch'essa coinvolta nel comando suggerito?

grz

[Stefano]

non sono nella possibilità di fare test ora, quindi non so risponderti

[v8star]

guarda, ho segato la regola nella chain e parrebbe funzionare: senza metter mano alla configrazione del dom del cliente in DC, ho creato un dominio parallelo per test in DC e in sme e sparato in DC una mail di test. Consegnata correttamente!    da un terzo/quarto ip non incluso nelle regole la connessione viene correttamente segata

iptables -D InboundTCP_24020 6

Questo lasciando inalterato tutto il resto come proxy ecc ecc.

Sarebbe bello a questo punto stilare una procedura straight-forward senza poi dover metter mano alle iptables.

[Stefano]

ed infatti è per questo che ti consiglio caldamente di chiedere altrove..
tutto è templatizzato.. tu puoi benissimo crearti un template customizzato che agisca solo ove e quando necessario al fine di ottenere quanto necessiti..

non ho modo ora di dedicarmi alla cosa ma posso dirti che
- i template sono in /etc/e-smith/templates/etc/rc.d/init.d/masq
- lo script finale, eseguito al boot e ricompilato ogni volta che richiami l'evento remoteaccess-update è /etc/rc.d/init.d/masq

puoi dare un'occhiata allo script finale, capire dove dovresti interventire, determinare il fragment coinvolto, copiarlo in /etc/e-smith/templates-custom/etc/rc.d/init.d/masq/ e modificarlo a tuo piacere
questa è l'unica via per otterere quello che vuoi in modo coerente e sicuro su SME

[v8star]

ok, vediamo se nell'altro forum qualcuno mi illumina.

sta di fatto che ho applicato gli aggiornamenti disponibili, essendo una fresh install e al riavvio sono andato a rivedermi le iptables, convinto di aver perso tutto e invece ci sono ancora, inclusa anche quella in grassetto che mi blocca tutto, generata dal denyhost.

A questo punto bisogno capire come togliere la entry denyhost per l'smtp

[Stefano]

rileggi il mio messaggio ove parlo di template
è ovvio che le tue regole siano ancora in place: le hai create usando il giusto meccanismo

[v8star]

ok, e questo mi sta bene.

Quel che mi manca da fare è segare via la regola denyhost: al momento ho risolto in maniera poco elegante dando "config setprop smtpd DenyHosts none" sme all'avvio si incazza un po segnalando che "none" non è una net valida ma comunque non creandomi la regola di deny.

Leggendo i vari tutorial https://wiki.contribs.org/Firewall non trovo altro che regole di aggiunta/replace di deniedhost

[Stefano]

stai ragionando in modo errato.. non devi segare la regola, devi modificare lo script in modo che, nel caso del servizio smtpd, le regole vengano invertite

[v8star]

voglio sono annullare il comando denyhost dato in precedenza, claro che alle iptables non va messo mano