Newsgroup: it.comp.sicurezza.varie
Titolo: PARERE TECNICO PER ESPERTI

buongiorno, scusate il messaggio un po' strano, spero che mi possiate
aiutare
Vengo al dunque...
Il mio sistemista mi ha spiegato che è normale riavviare il mio sito ogni
tanto a scopo di manutenzione (il sito è molto carico, contiene vari
database e la posta).
Oggi parlando con un amico questo è venuto fuori e lui mi ha detto di fare
qui quesa domanda: "ogni quanti giorni si deve riavviare un server linux?"
Spero di non offendere nessuno, perché mi ha anche detto che una domanda di
questo tipo potrebbe scatenare il finimondo; vi assicuro che io voglio solo
sapere chi ha ragione e non mi interessano le polemiche.
Ah, io ho dato l'indirizzo del sito a questo mio amico, che mi ha detto che
c'è un problema (ecco perché, scusate, non do l'indirizzo quì), cioè il mio
sito consentirebbe, a suo dire, l'accesso a "proc" (?).
Il sistemista dice che non è possibile, però il mio amico dice di si', e per
dimostrarlo mi ha detto che processore è installato sul sito, quanta ram,
che dischi, insomma informazioni tecniche che suppongo debbano essere
riservate, anche se non so quale danno potrebbero fare (cosa può succedere
se si sa la marca delle schede di rete o se si legge la configurazione del
sito?). Da questo "proc" ha estrratto l'up-time, che non corrisponde a
quanto mi dice il sistemista. (E' vero che il contatore di up-time è
azzerato al riavvio? Chi lo azzera, e si può scriverci dentro qualcosa
d'altro?)
Ora io intendo andare in fondo a questa storia ma prima di tutto vorrei
sapere chi dei due mi sta dicendo la verità: l'amico è un amico e mi pare
che se ne intenda ma, non vorrei, che la tentazione di fare il "guru" gli
abbia preso la mano. Il sistemista dal canto suo, difende il suo posto di
lavoro.
Scusate il lungo messaggio e i molti dubbi ma, capirete, che la questione mi
sta molto a cuore.
AZK

 d'altro?)
lo azzera la macchina al reboot, tentere di sovrascriverlo e' sciocco in
quanto la macchina lo tiene aggiornato in realtime (millisecondi).
la diversita' potrebbe dipendere dalla visualizzazione. nella proc trovi
un numero (es: 469789.20 292018.64) ma il comando uptime di da il delta di
tempo leggibile (14:23:28 up 5 days, 10:30,  6 users,  load average: 0.04,
0.15, 0.50). credo che il tuo amico ti abbia detto "la macchina e' accesa
dal", mentre il sistemista ti abbia detto un "e' accesa dal" diverso.
ricorda che non sempre la visualizzazione e l'impostazione del localtime
sono corrette (fuso orario).
un mayhem e le questioni delicate 
-- 
 Everyone is gay, with someone's else ass 
 Cisco  FAQ: 
http://mayhem.oltrelinux.com/icrc
 SPP  wpage: 
http://www.spippolatori.com
 Key on 
pgp.mit.edu
 ID C7393613


Per poter esprimere una valutazione occorrono informazioni dettagliate
sulla configurazione di cio' che chiami "sito".

 difende il suo posto di lavoro.
Occorre stimare correttamente l'entita' della vulnerabilita':
- Quali risorse in /proc sono accessibili? quali in lettura? quali in
scrittura? 
- l'accessibilita' e' dovuta ad un baco di tipo "directory traversal"?
in tal caso, non e'che sia possibile leggere, oltre a /proc, anche,
magari /etc? 
- l'accessibilita' e' dovuta all'esecuzione non corretta di comandi
forniti dal client? in tal caso, con che utente/permessi?
Quanto a /proc, ti dico solo alcune informazioni che sono accessibili in
lettura:
- Configurazione hardware
- Configurazione del sistema operativo
- Parametri di sicurezza
- Spazio di memoria dei processi (se qualche processo mantiene in
memoria, in chiaro o criptati con algoritmo debole, dati di
autenticazione, questi sono accessibili).
In scrittura... beh, immagina tu.
-- 
HappyCactus - Linux User #209744 - 
 
www.google.com
 - 
groups.google.com

 sito consentirebbe, a suo dire, l'accesso a "proc" (?).
L'accesso a proc è possibile in lettura a chiunque. Questo perchè sono
dati che eventuali processi devono poter conoscere.
Non è possibile cmq fare modifiche di alcun tipo se non con i dovuti
privilegi.
Per quanto riguarda invece il quando riavviare un server linux.... la
domanda è semplice, solo quando viene aggiornato il kernel.
-- 
| /
| \Byte - Andrea Briganti - kbytesys(aaattt)
tiscali.it
CSLug member: 
http://cslug.linux.it
 - JID: 
kb...@jabber.linux.it
***Molti vogliono la moglie piena e la botte ubriaca (Prof. univ.)

 dati che eventuali processi devono poter conoscere.
si, pero' che apache vada a leggere e mostrare ai client cio' che e' al
di fuori del suo percorso di lavoro, risalendo l'albero delle directory,
quello no, non e' normale.



:Provate a guardare gli ingredienti del famoso Labello che si usa per
:le labbra screpolate: Butirrospermum Parkii (sperma di maiale).

 sta molto a cuore.
Se il tuo amico ritiene che non sia sicuro che te ne dia una prova , ad
esempio spegnendo la macchina o modificando la Home Page con una bella foto
della Ferilli
Saper che hai un 486 o un Pentium non implica automaticamente una carenza
alla sicurezza.

 cotillons (mai saputo cosa siano i cotillons)
Il cotillon e' una danza in tondo che si diffuse in Francia dal 1723 ca.,
come variante della
contradanza.
Allegra e movimentata, fu introdotta con successo in Germania (ca. 1740) e
Inghilterra (1770). Intorno al 1850 divenne una sorta di passatempo, a metą
tra il gioco e la danza.
I cotillons sono i doni ricevuti durante tale ballo e, per estensione,
quelli, specialmente a sorpresa, che si ricevono in genere durante
trattenimenti danzanti (veglioni di Capodanno, ecc.).
et voila'.


<OT>il GMER... mi son sempre domandato se sia vero</OT>

 database e la posta).
Mi sembra strano.. il mio proxy dopo quasi 2 anni si è arreso ai black out 
preventivi dell'enel mentre il mio server principale è stato riavviato 
solo quando upgradavo il kernel.
Se per riavviare il sito (come ti dice il buon leonardo) intendi un 
apachectl graceful lo faccio spesso ma per riconfigurare apache e niente 
altro.
Ho un serverino di madre ignota (una ciofeca taiwanese) che se ne sta lì 
da 2 mesi (giusto il tempo dell'ultimo blackout!)
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
	Se tu fossi altro quanto sei bischero
	berresti dalle grondaie




sia.
No, ho provato io ora :-)
Piuttosto, mi stupisce che tu non sia partito all'assalto del sistemista
ad ascia sguainata; ha scritto che "e' normale riavviare il server Linux
ogni tanto, come manutenzione" :-)))
Leonardo aizzante la viulččnz


 quello no, non e' normale.
Unh? mi devo essere distratto... pensavo gli avesse dato un accesso alla
macchina! :) 
/me pensa che gli esami lo stanno rincoglionendo
-- 
| /
| \Byte - Andrea Briganti - kbytesys(aaattt)
tiscali.it
CSLug member: 
http://cslug.linux.it
 - JID: 
kb...@jabber.linux.it
***Se la risposta è Bush, la domanda doveva essere proprio stupida!

 alla macchina! :) 
Oddio, e' una spiegazione che ho fornito io. Non e' detto che sia cosi'
(ce ne possono esser altre).


 Chi lo azzera, e si può scriverci dentro qualcosa d'altro?)
crea una directory /proc fasulla e mettici dentro file con informazioni 
sbagliate e fuorvianti, se proprio ci tieni. Non avere /proc del tutto, 
comunque, è sicuramente meglio
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.3. C, C++ and ASM developers
                               and beta testers are welcome!

 Argomenta, suvvia.
solo se vieni in ics.virus ad aiutarmi col thread "Ho installato Swen", 
chè sono circondata da nubi dense


 /proc del tutto, 
Non credo sia possibile, molti software vi si appoggiano pesantemente
(ps, forse, per esempio).


 (ps, forse, per esempio).
quello è il meno: è proprio che i driver usano /proc come una specie di 
registro di sistema volatile, a quanto ricordi. Configurare periferiche 
e parametri di sistema diventerebbe impossibile


(ps, forse, per esempio).
Apache 1.3.28, per il make, si' (autoconf); per girare, no, gira anche
senza.
Leonardo
-- 
"Se e' vero che Linux in se' e' gratis, non lo sono le indispensabili
interfacce grafiche (X, KDE ecc.) che consentono alle persone normali
di utilizzarlo."                    -- Jason Matusow, Microsoft Corp.

 registro di sistema volatile
(volatile...diciamo piu' efficiente di certi ben noti registri.:-p)
Beh, si potrebbe fare a meno dello pseudo file system ed andare
solo di sysctl, a la BSD, per esempio, se si tratta solo di
cambiare on the fly parametri di sistema.
(ma ad esempio strace, su freebsd, ha bisogno di /proc)

 periferiche e parametri di sistema diventerebbe impossibile
Non impossibile, ma scomodo; e complicherebbe notevolmente la gestione
degil accessi.


 (ma ad esempio strace, su freebsd, ha bisogno di /proc)
ma soltanto per come hanno deciso di implementare l'agganciamento ad un 
processo


 più efficiente... diciamo usato molto meno :-P
Non ne sono affatto sicuro, che non sia anche piu' efficiente.
il registro di windows risiede, compresso, su disco.
la proc non risiede da nessuna parte, i dati vengono generati al
momento. Probabilmente occorre valutare caso per caso, ma di principio,
non richiedendo -generalmente- alcun accesso fisico alle periferiche, mi
aspetterei che fosse si', piu' efficiente.
Test comparativi, comunque, sono tassativi per mettere le due cose al
confronto. 
flames su /dev/null, grazie.


 confronto. 
non è che mi interessi granchè, in realtà. Per me, device e sistema van 
configurati con system call e IOCTL appositi, e se proprio voglio un DB 
per la persistenza mi scelgo quello che mi pare. Di /proc penso che sia 
solo un abuso del sistema di I/O, ma capisco il senso: sai cosa si dice 
delle persone che hanno a disposizione solo un martello?


 :-)
Non sono un programmatore ma per me non dovrebbe consumare  memoria in 
quanto la /proc dovrebbe essere una "Vista" delle varie strutture del kernel


 cosa si dice delle persone che hanno a disposizione solo un martello?
Si, system call e ioctl sono sicuramente il mezzo da utilizzare per
avere una maggior efficienza a scapito di una complicazione del codice
(credo tu sia obbligato ad usare C o comunque linguaggi ad un livello
basso), ma e' comodissimo per tarare il sistema "on the fly" da script
(classico esempio per attivare il packet forwarding: echo "1" >
/proc/sys/net/ipv4/ip_forward)
Comunque ribadisco che tutto questo nonha a che fare con la persistenza,
dato che /proc -generalmente- non e' persistente; anzi. Per fare
aggiustamenti persistenti al kernel si deve passare per altra via (lilo,
kernel command line, ricompilazione, o al limite script).
Per gli applicativi, proc non si usa di certo (e' uno strumento che si
interfaccia direttamente e solamente al kernel land) generalmente si
usano piccoli files di testo.


 kernel
Si, in un certo senso.
La proc funziona in questo modo:
- All'inizio il kernel/device driver/modulo che vuole installare un
elemento nella proc fa una richiesta al kernel tramite una funzione, la
quale alloca le strutture necessarie. Tra i dati vi sono il percorso,
ovviamente, il tipo di elemento (file/directory), gli attributi
(uid/gid/mod) e una tabella di puntatori a funzioni interne al driver.
- Quest'ultima tabella contiene una sorta di metodi per
open,read,seek,close,write.
- Quando un processo in user land apre un file nella /proc e vi opera
(lettura,scrittura,posizionamento) viene richiamata la funzione passata
nella tabella suddetta. Quest'ultima e' libera di agire come crede, ad
esempio: Inizializzando strutture dati interne (open), generando dei
dati oppure leggendoli da periferiche (read), modificando dati e
parametri interni al modulo o al kernel (write).
Quindi non si puo' dire a priori se un file sotto /proc occupi o meno
memoria!


 dirne una)
dettagli implementativi :-)


che chiedono anzichè quello di cui hanno bisogno
Ummm... ho solo una domanda: sei gia' impegnata? :-)


spippolarci su, ma i costi sono ancora proibitivi. :(
Se trovo il tizio che ha scritto la routine di ordinamento del file system
(dev'essere parente di quello che ha scritto il pezzo sulla caseness: come
minimo fratellastri, in quanto tutti e due [CENSURA]) gli offro un caffe'.
Devo solo trovare la torrefazione dove si serviva il compianto Sindona.
Leonardo "if [ -r $( echo $file | tr "[A-Z]" "[a-z]" ) ]; then..."


 persistenza, dato che /proc -generalmente- non e' persistente;
ho formulato male la frase. Ovviamente, se l'ho definito "volatile", so 
che non è persistente. Era soltanto una critica generica al concetto di 
registro di configurazione (ma non ne vale la pena. Per rendere le cose 
semplici è necessario complicarne altre, e /proc, come complessità, non 
è certo il peggio)


 Ummm... ho solo una domanda: sei gia' impegnata? :-)
TAKKINO!
HappyCactus e il suo ultimo post, prima di veder ridotto in cenere il
suo fido gufo saggio :)


 complessità, non è certo il peggio)
subscribe!


 il LSASS, nč il servizio di logging, nč CSRSS, nč Winlogon,
Piccola nota: con
Nome SO:                              Microsoft Windows XP Professional
Versione SO:                          5.1.2600 Service Pack 1 build 2600
una volta ho sbagliato mira e ho terminato winlogon. Mi si č spento
il PC :-)
-- 
Valerio Granato
http://www.musicoff.com
 - Music Online For Free
La Grande Comunitą Online per Musicisti

 il PC :-)
quello č SMSS, che fa una NtWaitForMultipleObjects su CSRSS e Winlogon, 
e chiama NtRaiseHardError non appena uno dei due processi termina (allo 
shutdown, infatti, SMSS, CSRSS e Winlogon sono tutti attivi, e si fanno 
terminare indirettamente dalla chiamata finale a NtShutdownSystem). Non 
mi devi credere sulla parola, lo puoi verificare uccidendo prima SMSS e 
poi Winlogon: il sistema non fa una piega (ma CTRL-ALT-DEL non funziona 
piů, non si puň piů fare logout e varie altre cose iniziano a fallire a 
caso)


 varie altre cose iniziano a fallire a caso)
Ma ti credo... però preferisco fare uno shutdown pulito :-)
-- 
Valerio Granato
http://www.musicoff.com
 - Music Online For Free
La Grande Comunità Online per Musicisti

 Ummm... ho solo una domanda: sei gia' impegnata? :-)
     _/_/_/      _/_/    _/_/_/_/_/  _/_/_/_/  _/
    _/    _/  _/    _/      _/      _/        _/
   _/_/_/    _/    _/      _/      _/_/_/    _/
  _/    _/  _/    _/      _/      _/        _/
_/    _/    _/_/        _/      _/        _/_/_/_/
/me testante figlet sotto cygwin.
-- 
"Ehi, fratelli. Qui c'e' scritto che c'e' anche il tempo per combattere".
SETI@home: 201WU/1yrs now on Athlon 2.2+ :-)
SecurFaq             : 
http://securfaq.usenet.eu.org
Biancorossi Siamo Noi: 
http://www.tifonet.it/free/ancona/

 notti con vega strike...
            ^^^^^^^^^^^
hmmm?


 e NFS sono due cose che non vanno troppo d'accordo 
Uh???

 Uh???
no?


 hmmm?
Conoscevi Elite e Frontier? ecco.


 caso particolare)
ah, allora il locking su NFS funziona bene?


 ah, allora il locking su NFS funziona bene?
Quello "discrezionale", almeno, pare di si'. 
