Newsgroup: it.comp.os.linux.sys
Titolo: Sicurezza del sistema

Sto configurando una Linux box con SuSE 7.1...
Lo scopo di questa macchina è fare da server mail...
Ho configurato pop3 e smtp di Qmail tramite tcpserver (del pacchetto
ucspi-tcp)...
Ho disattivato tutto inetd...cosa posso fare ancora per migliorare la
sicurezza del sistema ?
Grazie
        Riccardo

In un messaggio del Sun, 08 Jul 2001 21:41:08 GMT Riccardo Pellegrini scriveva:

Beh direi che se l'output di 'netstat -ta' dice che non hai porte aperte
dovresti essere a posto.
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
<<   For my real address... ask the Balrog.       >>
* Sostenete la Lega per la Soppressione dei Troll *

 dovresti essere a posto.
Ho chiuso tutte le porte tranne la 110 e la 25...ovviamente...
Ciao
    Riccardo

 Ho chiuso tutte le porte tranne la 110 e la 25...ovviamente...
Allora dovresti essere a posto.


Volendo proprio essere paranoici potresti aggiungere regole di
ipchains/iptables per filtrare l'accesso alle porte solo da specifici
range di IP (es: se i tuoi pop client si possono connettere solo
dall'ufficio puoi restringere gli accessi con una regola del tipo 
ipchains -P input DENY
ipchains -A input -s IP.Validi.DaCui.Connettersi --destination-port
110 -j ACCEPT
ipchains -A input --destination-port 25 -j ACCEPT
o qualcosa di simile).
Ciao
S.


 ipchains -A input --destination-port 25 -j ACCEPT
Purtroppo non è per un ufficio...è un service provider...
Infatti il pop3 deve poter essere utilizzazto da ovunque...
Chiaramente il smtp l'ho limitato ai soli ip della rete locale (tramite
tcprules, un utility del pacchetto ucspi-tcp che ho usato al posto di inetd)
che serve per )...non è che volevo fare un open relay ;-)
Ciao
        Riccardo



Fai un bel nmap "approfondito" e controlla se non c'e' qualche porta
strana aperta. E,  cosa fondamentale, controlla 10.000  volte che il
tuo SMTP non sia un open relay !
-- 
 __
| _         "The Internet is slow, could you please reboot it ?"
|__|iambo   mailto:
gabr...@giambonini.com
 
www.giambonini.com

 tuo SMTP non sia un open relay !
Ho fatto un portscan da linux e mi trova aperte soltanto la 25 e la 110...
Ma poi ho provato con un portscanner da Windows...ed ecco il risultato...
389  :CONNECT
CLOSED
END PORT INFO
1002 :CONNECT
CLOSED
END PORT INFO
Praticamente a queste due porte mi connette e mi disconnette subito...
Ho guardata fra i port number assegnati dallo IANA...e la 389 (sia TCP che
UDP) corrisponde a Lightweight Directory Access Protocol (LDAP)...mentre per
la 1002 non c'e' alcuna corrispondenza...
Il bello è che se faccio un telnet dalla shell su quelle porta mi risponde
come se non fosse aperta...se invece faccio un telnet da Winzozz mi si
connette e dopo mi da l'errore "Connessione all'host perduta"...
Ciao e grazie
        Riccardo

1002 :CONNECT
Non  compare  in  /etc/services  :-) Controlla  magari  con  netstat
(netstat -ap | less) ...


 (netstat -ap | less) ...
Non c'e' in esecuzione...anche con netstat -ap non si trova niente... (porte
25,110...servizi syslogd, gpm, nscd, splogger, klogd, cron)
Niente...in LISTEN soltanto pop3 e smtp...mentre il portscan da Windows mi
ritorna sempre il solito risultato : sulla 1002 e sulla 389 si connette e
poi si disconnette...
Ho provato anche nmap...bello non l'avevo mai usato (avevo scaricato un
portscanner molto primitivo da rootshell)...
Ma anche nmap riporta solo 25 e 110...
Mah...a questo punto penso che sia Windows buggato...perchè se faccio un
telnet da Windows su quella porta per un istante si connette, ma poi perde
la connessione...
Boh...
Ciao e grazie
        Riccardo

 che serve per )...non è che volevo fare un open relay ;-)
forse è un po eccessivo: se c'è un server POP la posta deve entrare in
quella macchina in qualche modo, percui la porta SMTP deve essere aperta a
tutto il mondo (oppure avere qualcun'altro che fà da relay per il tuo
dominio e accettare connessioni SMTP solo da quella macchina).
per evitare di essere un open relay devi configurare l'MTA (sendmail,
postfix, qmail, ...) dicendogli di accettare:
i messaggi destinati a utenti del tuo dominio (e questi devono poter
arrivare da dovunuqe)
i messaggi inviati da IP "interni" (dove stanno i tuoi utenti),
oppure fare cose più raffinate come accettare solo SMTP autenticato (ma da
qualunque indirizzo) o obbligare gli utenti a controllare la posta con POP
prima di poter inviare mail da un certo indirizzo
MAtteo

 la connessione...
I casi sono 2:
1) il servizio incriminato gira da (x)inetd. Viene quindi forkato se
necessario. Si guarda la configurazione di (x)inetd e si trova l'inghippo.
2) si tratta di un daemon stand-alone, come per es. un server smtp, che e'
sempre attivo e quindi puo' essere identificato con fuser e ps.
Non mi pare ci siano altri casi.
-- 
        Giuseppe "Cowo" Corbelli  -->>  Riding on Linux-2.4.3-xfs
	**ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
  -<! When you say "I wrote a program that crashed Windows", people just stare
     at you blankly and say "Hey, I got those with the system, *for free*" !>-
                                (By Linus Torvalds)

 prima di poter inviare mail da un certo indirizzo
E' bene limitare queste cose...altrimenti qualsiasi malintenzionato potrebbe
spacciarsi per un utente del mio server e fare spamming.
Basta usare come relay il server SMTP del provider a cui ci si connette...la
maggior parte di questi provider controlalno solamente che l'ip di chi invia
il msg appartenga alla rete del provider...
Ciao
        Riccardo

 sempre attivo e quindi puo' essere identificato con fuser e ps.
La cosa strana è che la porta risulta perfettamente chiusa facendo un telnet
dalla macchina Linux...se invece lo faccio dalla macchina Windows2K verso la
macchina Linux mi mi si conentte e mi si disconnette subito alla porta 389 e
1002...
Per fuser non ci sono servizi aperti a quelle due porte...
Secondo me è un bug di Windows ;-)
Ciao
        Riccardo

 Secondo me è un bug di Windows ;-)
Si.
--
  	Giuseppe "Cowo" Corbelli  -->>  Riding on Linux-2.4.3-xfs
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
  -<! I Never Wanted To Be What They Told Me To Be
  		Fulfill My Fate Then I'll Be Free >!-
  			Blind Guardian - Mordred's Song

prima di poter inviare mail da un certo indirizzo
Questa e' una soluzione, un'altra, meno sicura ma che realizza un buon
compromesso in termini di funzionalita', la trovi nella risposta a Riccardo.
-- 
BlueRaven
Prima di parlare, ricorda:
mount -t auto /dev/brain /mnt/mouth

il msg appartenga alla rete del provider...
Prova a connetterti con Libero e tenta di mandare un messaggio con un
indirizzo 
none...@microsoft.com
 verso 
neanch...@tin.it
.
La risposta e' un bel 550: Relaying denied, anche se sei collegato con loro
(giustamente).
Io ho usato una soluzione intermedia (come SMTP uso qmail): per gli utenti
che si collegano direttamente al mio POP, permetto il relaying, visto che se
mi arriva una segnalazione di spamming rintraccio il malcapitato attraverso
i log dell'access server e gli spezzo le gambine! :-)
Per quelli che si sono fatti fregare l'account dallo spammer, e' invece
prevista la crocifissione in sala server o l'uso di Windows 95 liscio.
Per i casi di cui sopra, uso una patch, che si trova sui mirror di
www.qmail.org
, che permette di creare un file di controllo in cui inserire
gli indirizzi o i domini a cui deve essere permesso mandare posta anche se
provengono da fuori.
Per cui, se il mio utente 
x...@suodominio.it
 e' a Milano col portatile, puo'
continuare a mandare la sua posta anche collegandosi al nodo locale di
Libero: l'IP non e' tra quelli autorizzati, ma il file relaymailfrom
contiene quel dominio e quindi passa lo stesso.
Non e' a prova di bomba, visto che da fuori uno spammer potrebbe usare un
indirizzo del tipo @
suodominio.it
 per i suoi comodi, ma deve almeno sapere
il nome di un dominio autorizzato e se ci prova a tentativi me ne accorgo
dai log... a quel punto, non scommetterei una lira sull'integrita' delle sue
chiappe.
Tra l'altro, la simpatica patch fa anche un'altra cosa: se uno tenta di
mandare quantita' massicce di mail, dopo tot invii (con tot configurabile)
introduce _di proposito_ un ritardo (anche questo configurabile) tra un
invio e l'altro.
Se il ritardo e' alto, lo spammer pensera' che io mi sono accorto di lui e
gli ho chiuso il firewall... mentre invece non e' cosi'.
Impostandola in modo ragionevole (es. 5 invii e 5 minuti), si tarpano le ali
- non per niente, la funzione si chiama tarpit() :-) - ai rompipalle, con il
gradevole effetto collaterale che gli utenti imparano che far girare le
catene di S. Antonio con 200 indirizzi in chiaro non e' salutare, ne' per la
Rete ne', soprattutto, per la loro bolletta. <BOFH satanic laugh>
Scusate la lunghezza, ma credo possa essere utile a molti.


Ti ringrazio molto...sei stato molto gentile a spendere tanto tempo ni
questa risposta.
Avevo già pensato ad usare una soluzione del genere (che trall'altro non
avevo trovato su Qmail, ora mi vado a cercare la patch di cui parli)...
Questa soluzione era però stata sconsigliata da alcune documentazioni che ho
trovato in giro per Qmail...
Ti faccio sapere...
Ciao
       Riccardo


Ti faccio sapere...
Quando vuoi, mi fa piacere esserti stato utile.
