[Lugge] Re: proposta di corso e "linea guida"

  • From: Stefano Sartini <root@xxxxxxxxxxxxx>
  • To: lugge@xxxxxxxxxxxxx
  • Date: Mon, 22 Sep 2003 04:37:37 +0200

[SNIP]

 A questo punto posso introdurre l'ultimo punto: Mandrake.
 Ma prima cito ancora te:


(a parte la scelta assolutamente discutibile di Mandrake come server)


 A tal proposito dico subito: "Mandrake per un server? Ma siamo pazzi? E
la sicurezza?"
 Ebbene questa frase con s/Mandrake/Linux/ era d'uso frequente qualche
hanno fa quando si proponeva di installare linux come server... con il
senno di poi, la SUN e l'IBM, possiamo valutare quanto valesse in
concreto quell'affermazione.

 Ma le analogie funzionano? Io non so se questa analogia funzioni però
posso dire che ho fatto cose significativamente interessanti con
Mandrake. Il che, a meno di non voler ammetere che io sia UN MAGO,
equivale a dire che si possono fare.

 Che sia conveniente farlo con Mandrake? Dipende.
 Anzitutto è più facile per me togliere un interfaccia grafica, che
funziona e mi aiuta, che aggiungerla!
 Inoltre un server è più sicuro se è facile da gestire, le cose semplici
funzionano le cose complesse si rompono!

E qui ti dai la ruspa sui piedi da solo: la Mandrake è una delle distro + grosse/complesse in circolazione, IMHO proprio per questo inadatta a farci un server... Ma t rispondo pian piano =)


 Infine è più facile compilare su un client un pacchetot RPM "sicuro" e
distribuirlo su diversi server che non scaricare il sorgente, compilarlo
ed installarlo sul server stesso.

Alt. Non so dove lavori te, ma dove lavoro io esistono i server "di produzione" ed i server di sviluppo. I pacchetti si compilano sui server di sviluppo (gemelli d qlli d produzione o quasi,ovviamente) e poi si installano sui server di produzione.


I pacchetti RPM sono insicuri di default, in quanto nel 90% dei casi sono compilati da altri che non sono gli sviluppatori. Al di la della buona fede, basta anche solo che chi si offre di creare un RPM abbia un trojan o affini, ed il gioco è fatto. Se poi mi parli di SRPM, allora ti contraddici da solo poiche gli SRPM necessitano comunque di librerie e di compilatori.

Inoltre gli RPM escono sempre e regolarmente in ritardo rispetto ai sorgenti, per ovvi motivi.

Compilare sul server significa avere a bordo un compilatore e tutte le
librerie di develop... ora installare e disinstallare tutte le librerie
di develop e il gcc ogni volta che si deve aggiornare un programma o il
kernel mi pare una politica fuori discussione, in quel caso davvero ti
servono 150 ore per spiegare come farlo.

Vedi sopra. Se metti RPM di terzi stai usando binari di terze parti (e vorrei che mi spiegassi a cosa serve tanto parlare di sicurezza se poi sul tuo server esegui codice compilato da altri ;) ed inoltre NON ottimizzati per l' Hardware su cui dovra' girare il servizio. E perdipiu', se l'RPM è ufficiale, nel momento in cui esce un bug/exploit per quella versione di RPM, stai pur certo che il tuo sarà bucabile alla grande, uno ricompilato custom no, tutalpiu' crasha, ma nn ti entra dentro nessuno.


Se fai la mossa di mettere SRPM, allora hai cmq bisogno d compilatori, librerie develop, gcc, e via discorrendo.

 Se si usa un client per farlo allora per portarlo sul server serve cmq
un formato di pachettizazzione sia pure un semplice tar-gz. Ti assicuro
che fare un rpm è facile e molti pacchetti già contengono il file di
testo da dare in pasto a rpm per ottenere il pacchetto rpm.
 Survolo poi sul fatto che MDK ha sviluppato la Corporate Server con il
programma di abbonamento e help per incidenti.

Anche Windows ha gli aggiornamenti automatici, allora perchè non mettere windows? ;)


Personalmente uso i .tgz in puro stile Slackware, e nn vedo alcun motivo di mettere RPM se non quello di avere poi problemi di dipendenze quando vado a disinstallare qkosa...

 Considerato il segmento a cui vorrei puntare (cioè non mi picco di
insegnare il lavoro di sistemista ad un professionista e neppure di
vendergli un pezzo di carta) cioè mettere, al più,
l'artigiano/hobbysta/professore in condizioni di evitare di comprare 2/3
pc nuovi con WindowsXp e un server Windows2003 per potersi leggere la
posta mi pare più che adeguato utilizzare la stessa distribuzione per il
server che per il desktop.

Ecco, questo è il vero punto. Sono assolutamente d'accordo che MDK sia una delle migliori distro (se nn la migliore) per il segmento desktop.
Mi lascia ancora perplesso il fatto ke KDE 3.x e MDK siano + pesanti di un Win2000, che poi alla fine è la stessa perplessità che mi fa pensare che GNU/Linux non sia ancora maturo per la fascia desktop...
Pero' scusa, perchè non usare la distro giusta per il compito giusto ? Il bello di GNU/Linux è proprio la possibilità di scegliere, allora perchè non trattare MDK quando si tratta di Desktop e parlare di (che so) Slackware per quanto riguarda i server?


Si, la Slackware non è user-friendly, nn usa SysV e mettere su X è sempre un dramma, ma una volta in piedi è una roccia. E non penso nemmeno che si possa insegnare a qualcuno come settare IPTABLES solo facendolo da consolle grafica, perchè quasi sempre nelle emergenze c si trova a lavorare a basso livello, da consolle. E se uno insegna solo a schiacciare i bottoni e non a CAPIRE cosa sta facendo, è tempo perso sia per lui che per chi insegna.

 Casualmente sceglierei, per il server, la stessa distribuzione, usata
per il  desktop, che riduce, grazie alla sua procedura di installazione
semplificata e basata sul riconoscimento automatico dell'hardware,
domande del tipo: "come faccio a far funzionare la sk audio"

PREZIOSISSIMA la scheda audio sui server... non se ne puo' fare a meno... ;)


 Casualmente sceglierei la stessa distribuzione che riduce, grazie alla
cura (non eccessiva, forse SUSe in questo senso è più avanti ma mi hanno
detto che la MDK 9.2RC2 è grandiosa) dell'ambiente desktop, domande del
tipo: "come faccio ad ascoltare il cdrom" o "come faccio a fare un
foglio di calcolo"

Altre cose fondamentali per chi installa un server... LOL :)


 Insomma si tratta solo di insegnare a chi sa installare ed usare un
desktop linux quali cose NON mettere, quei quattro accorgimenti che
rendono la macchina un po' più sicura, come editare in minima parte quei
4/5 file di configurazione utili per avere un apache+php+msql/postgres,
un server di posta, un proxy-vario, etc. etc.

Si ma allora torniamo alla mia domanda iniziale: COSA si vuole insegnare? A mettere su un PC Desktop decente? Allora ottima scelta MDK, ma mi devi spiegare in base a quale criterio vai a spiegare a uno che scarica la posta e browsa il web, come installare Apache, PHP, MySQL, PostGRESQL o un server di posta. Tanto per avere un bel po' di servizi esposti a potenziali hackers e usare un po' di risorse libere?
Di contro, vuoi insegnare a mettere su un gateway/firewall decente? Bene, allora spiegami perchè scegliere una distro come la MDK, perdipiu' motivando la scelta con giustificazioni (perdonami il termine) risibili quali il riconoscimento della sk audio o l'ascoldo dei CD Audio.


Ovviamente anche come duplicare un floppy con un firewall già
configurato, eventualmente con i 2 ip da settare, e poi come aprire una
porta o chiuderla.
Non credo che sia uno sforzo sovraumano e neppure penso che i corsisti
finito il corso penseranno di andare a lavorare come sistemisti. In
fondo ad utilizzare Mandrake nessuno li prenderebbe sul serio! ;-)

Tanto per non essere frainteso, ti ripeto che non ce l'ho kon MDK, semplicemente non la ritengo una scelta valida per farci dei server. Io ho anche dei server RH 7.3 (anzi, molti) ma nessuno di loro ha servizi esterni (Apache, MySQL, qmail, postfix, ftp & so on) originali della release. Alla fine se uno sa fare le cose le sa fare bene anche su MDK, ma bisogna che capisca cosa sta facendo...


 Inoltre proseguendo su questa linea si può lavorare su un progetto del
tipo:

- installa MDK base - riavvia con il cdrom hobby-server-lugge - rispondi a domande del tipo: classe ip local network, gateway, etc.
etc.
- ottieni il tuo server MDK funzionante e con quelle 3/4 sicurezza in
più rispetto al desktop


 Aggiornamenti? urpmi basta e avanza... sempre riferito al segmento
supra citato di utenti!

Benissimo, e utilissimo, ma come vedi non gli hai insegnato niente, se non a mettere un (ulteriore) CDrom e rispondere a qke domanda. E' una cosa ben differente che insegnare a mettere su apache o a filtrare una porta...


Parliamo di soldi?

 - MDK è gratis (per ora) o comunque costa 60-100 euro e poi la installi
in quanti PC vuoi.
 - Il corso LUGGe costa 100 euro? Cavoli a ben pensarci 2 giochi per
PS2/XBOX/PC costano uguale
 - Vuoi mettere quanto costi meno usare MDK che farsi prendere a
piratere Windows 2003 server?

MDK non è l'unica distro gratis... Per fortuna =) Sulle considerazioni che fai sono sostanzialmente d'accordo, ma t faccio un appunto: non consideri il fattore TEMPO, e (sarà che sono un libero professionista) sono abiutato a calcolare i TCO anche in base al TEMPO che mi ci vuole a fare disfare qualcosa. Esempio scemo: ci metto molto meno a installare una Slackware e ricompilare i servizi che so che mi serviranno su un determinato server rispetto a (come dicevi te) mettere una MDK e poi spulciarla per eliminare tutta la spazzatura che non mi serve. Questo nel mio caso ovviamente.


 Oltrettutto mi pare pure un buon affare! Mi sbaglio?
 ;-)

GNU/Linux è sempre un buon affare, se si ha tempo e voglia d starci dietro. In alcuni settori è un ottimo affare, in altri è un discreto affare, ma cmq sempre preferibile ai prodotti M$ :)


Cmq, non a breve, ma mi rendero' disponibile per fare un breve corso sull'hardening proattivo di sistemi GNU/Linux, purtroppo il paper che sto preparando è molto indietro causa lavoro/studio.



Questo invece sarà molto interessante da leggere.

Rispondendo anche alla domanda sulla sicurezza proattiva (termine suggeritomi da un membro della comunità Slackware Italia): si tratta di analizzare la sicurezza di un server partendo dalla sicurezza del codice dei singoli elementi esposti all'esterno, ovvero Kernel in primis e poi tutti quei servizi che per forza si affacciano verso internet, ovvero Apache & so on.
L'idea è di fornire qualche spunto (e qualche strumento pratico) per far capire come un servizio ricompilato ad hoc sia immune da attacchi di tipo "standard" (exploit codato per la release X.Y) e scriptkiddies, facendo in modo che nella peggiore delle ipotesi crashi il servizio (o un child come nel caso di httpd) ma che il sistema rimanga integro e non si aprano breccie di sicurezza (shell root remote, code injection and so on).
Per ora è stato frutto d un carteggio con i membri di Slackware Italia, ma sto cercando di metter giu' qcosa di concreto stile paper.


Ciao,

Ste

========---------- Prima di scrivere in m-list per favore leggi il regolamento http://www.lugge.net/soci/index.php?link=manifesto

Archivio delle e-mail postate in lista http://www.freelists.org/archives/lugge/

Modifica dell'account sulla lista LUGGe http://www.lugge.net/soci/index.php?link=manifesto.htm#list

Other related posts: