Newsgroup: it.comp.os.linux.sys
Titolo: [OT Sì o OT No?]Slackware 10.2, inet e xinet

Leggendo "Linux&C." numero 50 c'è un articolo interessante di
sicurezza con xinetd. Spiegano esattamente come lanciare i servizi via
xinet al posto di rc.
Il dubbio è che nell'articolo parlano di xinetd come l'evoluzione di
inetd e soprattutto dicono che inetd ha molti problemi.
Quello che mi chiedo: io sono un slackwarista dove ancora, anche nella
10.2, trovo inetd come superserver...
Io vorrei avvicinarmi al mondo di inetd, ma credete che dovrei
installare xinetd? Oppure quello che ho letto è solo un pò di "fumo",
visto che una distro secolare con slackware utilizza ancora inetd?
Fatemi sapere! Numerosissimi...
Ciao a tutti, Keres.


Non e' fumo. La sicurezza in xinetd e' gestibile in modo molto piu'
"granulare" e preciso.
Alcuni Unix (HP-UX) usano inetd, ma hanno un file per gestire la
sicurezza in inetd (se non ricordo male: /var/ad/inetd.sec), che non e'
ancora paragonabile ai file in /etc/xinetd.d/ ma e' pure sempre qualcosa.
xinetd _e'_ migliore.
-- 
Massimiliano

A lavoro mi hanno chiesto di realizzare un firewall con:
- NAT per navigare in rete dall'ip pubblico;
- Poter navigare sul sito aziendale (che è nella stessa macchina
firewall);
- Squid con clamav;
- dnsmasq.
Io ero tentato di avviarmi questi servizi con xinietd inveche che
caricarmeli a mano via rc. Lasciamo stare il discorso di quello che mi
hanno chiesto (ho già discusso).
Quello che vorrei sapere e se posso avviare i serivzi via xinetd e se
posso aggiornare la mia slack a xinetd al posto di initd...
Ciao, Keres.


io penso che la scelta sia un tantino soggettiva.
Pro e contro?
Secondo me:
Contro:
1) non puoi fermare o riavviare il singolo servizio e per farlo devi
fermare/riavviare xinetd. Praticamente sarebbe impossibile fermare il
singolo servizio, tranne che non lo disattivi nel file
/etc/xinetd.d/blabla e fai ripartire xinetd
2) non puoi decidere di far partire il singolo servizio ad un
determinato runlevel. Il runlevel con la rete di solito contiene xinetd.
Pro:
1) il controllo sulla sicurezza dei socket, cosi' come lo gestisce
xinetd e' sicuramente valido e semplice da usare
-- 
Massimiliano

 "granulare" e preciso.
]zac[
Non del tutto, è più che probabile che xinetd sia stato programmato meglio e
con più attenzione a evitare bug letali per la sicurezza rispetto a inetd
(che è nato molto tempo a), ci sono più opzioni per tentare di limitare DOS
e attachi.
Poi in pratica non cambia molto (è fumo insomma), visto che un firewall a
protezione dei servizi e del sistema è comunque più che obbligatorio e che
inetd e xinetd al massimo li puoi usare per limitare rapidamente l'accesso
a dei servizi (ad esempio in caso di manutenzione di un servizio).

 determinato runlevel. Il runlevel con la rete di solito contiene xinetd.
per mia esperienza i runlevel non sono molto usati , è difficile trovare un
applicazione pratica dove servono 2 cfg del sistema.
bye.
-- 
Non prendere la vita troppo seriamente -- non ne uscirai mai vivo.

 applicazione pratica dove servono 2 cfg del sistema.
ma si e' chiaramente soggettivo.
-- 
Massimiliano

 a dei servizi (ad esempio in caso di manutenzione di un servizio).
Assolutamente no.
Lo standard de facto di una macchina unix *in produzione* e' senza firewall.
Non so cosa tu intendi, che tipo di configurazione e cosa deve fare
quella macchina.
Io lavoravo in un posto dove c'erano circa 1000 macchine UNIX in
produzione e nessuna di queste aveva il firewall. Tuttavia, siccome si
trattava di hp-ux (che volendo avrebbe un porting del firewall di BSD),
per gli accessi ftp veniva usato /var/adm/inetd.sec
Ti renderai conto che gestire un firewall su centinaia di macchine e'
completamente inimmaginabile.
-- 
Massimiliano

 quello che ho scritto
ripartire != reload
-- 
"Non trovo nessun capello sui tuoi vestiti; non e' che mi tradisci con
una donna calva?"
                -- Da it.hobby.umorismo

 completamente inimmaginabile.
N.B. è il mio parere (rubato dall'esperienza di un amministratore di piccole
reti), una volta chiarito non servono altri post.
Non è inevitabile, specialmente se la macchine sono molto simili (replica
delle configurazioni), o si può organizzare la rete interna in zone il cui
livello di sicurezza è simile e tra le reti ci si mettono (pochi) dei 
firewall.
Comunque intendevo dire che (x)inetd è insufficiente (come limitare il
blocco al solo utente/password) in un ambiente ostile, utile se invece si
vuole limitare l'accesso a utenti ... diciamo non preparati/aggressivi,
tipicamente una rete interna con accesso molto limitato e poco variabile,
per una rete interna soggetta a variazioni dell'utenza o a utenza
potenzialmente pericolosa, (x)inetd è insufficiente.
In sintesi, se un qualcosa è talmente prezioso e/o con la possibilità di
essere danneggiato, da doverci prestare attenzione, x(inetd) non basta.

 caricarmeli a mano via rc.
Il nat viene operato dal kernel.
Per il resto, credo che solo tu possa valutare se sia o meno il caso
di lanciare servizi da xinetd o meno.
Tieni conto che, specialmente sotto carico, le differenze di performance
possono essere notevolissime (a sfavore di xinetd, ovviamente).
-- 
Chaos A.D.		|	Raging crowd
Tanks on the streets	|	Burning cars
Confronting police	|	Bloodshed starts
Bleeding the Plebs	|	Who'll be alive?

 
ma ROTFL... l'accademia della crusca ti sta aspettando.
-- 
Massimiliano

 reti), una volta chiarito non servono altri post.
ok chiaro :)
Diciamo che:
La sicurezza in generale e' un compromesso tra necessita' da una parte e
tra fattiblita', costi di mantenimento, costi di impianto dall'altra parte.
La sicurezza, in molti casi, puo' essere anche un po' balorda. Ancora
oggi, nel 2006 tante grandi aziende usano ancora i cosiddetti r-tools
(rlogin, rcp, e sono veramente tante.). Poi magari scopri che nella
stessa azienda per accedere in sala server non e' sufficiente il badge e
ci vuole anche il fingerprint. Poi scopri anche che in caso di conflitto
IP HP-UX perde il proprio indirizzo, pertanto ti puoi prendere
l'indirizzo di un server che e' nella lista rhosts di un altro server e
amen....
-- 
Massimiliano

 tra fattiblita', costi di mantenimento, costi di impianto dall'altra
]zac[
Concordo in pieno, nella realtà si scende e si deve scendere a compromessi.
E' solo che spesso quei compromessi sono presi come punto di partenza ...
per altre discese all'inferno (ho da poco visto il mio primo divx su linux
(troppo facile, due click), hellraiser 5), e si finisce per
dire/pensare/illudersi che un account, x(inetd) e simili, siano un sistema
di sicurezza, mentre sono solo una limitazione di accesso (esagerando
molto, è più o meno come mettere un cartello su una porta con su scritto
non disturbare, o per soli uomini o donne, ecc.).

 
Ma no!
ripartire= spengo e riavvio xinetd
reload = dico a xinetd di rileggersi la config
qualche differenzina c'e', no?
bye
DKano