Discussioni su eventuali implementazioni e migliorie nell'OS

Moderators: forart, Davy Bartoloni, gabrielilardi

mauriziodaniello
Posts: 25
Joined: Mon Dec 19, 2005 10:14 pm
Location: Romania

Re: Riassumendo

Post by mauriziodaniello »

PUOjACKz wrote:- Registro di sistema
.
Hai fatto un ottima cosa, scusami ma per qualche giorno sarò molto impegnato.
Comunque la discussione è aperta per tutti, approfittate !
:idea:

mauriziodaniello
Posts: 25
Joined: Mon Dec 19, 2005 10:14 pm
Location: Romania

Re: Per la protezione spyware e altro....

Post by mauriziodaniello »

Davy Bartoloni wrote:tempo addientro, quest'estate, ho scitto un programmino in QbasiC (QBASIC CAZZZZZZ.. qbasic nel 2005??? qbasic su "Winxp????)
pazzesco, ma cmq compilato in maniera giusta funziona,... bah!
Bello sono un appassionato di AI e conosco il Qbasic !
Potresti farmi la gentilezza di spedirmelo, su mauriziodaniello@yahoo.it

Grazie !

PUOjACKz
Posts: 116
Joined: Tue Jan 03, 2006 3:52 pm

Re: Riassumendo

Post by PUOjACKz »

mauriziodaniello wrote:
PUOjACKz wrote:- Registro di sistema
.
Hai fatto un ottima cosa, scusami ma per qualche giorno sarò molto impegnato.
Comunque la discussione è aperta per tutti, approfittate !
:idea:
Voglio essere esplicito e papale con tutti coloro che leggono e postano: Io non son venuto qua per postare 2 messaggi, tanto per gasarmi di sapere alcune cose di sistemistica e sicurezza, da mostrare agli amici, bensì, discutere APPROFONDITAMENTE, di alcune idee banali, ma che possono fare la differenza. Ho tutta l'intenzione, con il vostro avvallo ed aiuto, di sottomettere il risultato di queste discussioni, ai coders (solo che non sò, tutt'ora, come fare), per una futura implementazione, che sò... nella 1.0 dell'OS.
Ho ancora una valanga di roba da proporvi e discutere ed in futuro non mancherò nel farlo.
Ovviamente, suppongo che ogni amante dei sistemi Windows-Like, in futuro, non potrà non tener in seria considerazione il passaggio a ReactOS. Alla fin fine, Windows Live o Google Live, sono l'ultimo passo per il controllo totale dell'utente, in Internet, una cosa che non può, in alcun modo, permettere una compatibilità retroattiva con i vecchi programmi e sistemi (sì, proprio quelli che, qualche anno fà, avete pagato profumatamente). Figuriamoci con Palladium, che spero, sia alquanto rivisto, nella sua invasività, in un ipotetica implementazione futura su ReactOS.
Nei prossimi giorni, riquoterò la scaletta che ho postato qualche reply fà, per un analisi maggiormente approfondità, con le mie idee. Spero in un feedback.

PS: Se qualcuno sà il metodo per inviare quanto qui discusso, ai coders, per una loro valutazione, lo dica in modo chiaro e semplice. Questo nostro "lavoro" deve arrivare alla fine e produrre frutto e non rimanere solo delle chiacchiere.

mauriziodaniello
Posts: 25
Joined: Mon Dec 19, 2005 10:14 pm
Location: Romania

Re: Riassumendo

Post by mauriziodaniello »

PUOjACKz wrote:- Registro di sistema

* ACL per dichiarare quali programmi possono o non possono modificare il registro di sistema, in modo automatico, oppure, generalmente, quali aree possono modificare: In fase di discussione
servirebbe un demone che controlla appesantirebbe ROS
PUOjACKz wrote:
* Dispositivo Anti-Bot (contro l'automazione dei programmi), per autenticare la presenza di un persona, durante la modifica dei registri: In fase di discussione
Proteggere con pwd (in sola scrittura) il registro questa è la mia idea
PUOjACKz wrote:

* Cifratura del registro di sistema. Solo l'OS e l'utente possono modificare tale file, che non può essere manipolato dall'esterno. L'utente, necessità di un tool con dispositivo Anti-Bot, per garantire una maggior sicurezza: In fase di discussione
Molti programmi installano per funzionare correttamente dati di start-Ip programma, se lo codifichi non funzionano più
PUOjACKz wrote:
* File UnAttended che dichiara quali programmi/eseguibili hanno il diritto di modifica dei registri, sia durante l'installazione, che successivamente. Tale feature può essere utile in caso d'installazione automatiche, senza la necessità dell'interazione preventiva o Just In Time dell'utente: : In fase di discussione
servirebbe un demone che controlla appesantirebbe ROS
PUOjACKz wrote:
* Assegnazione, nell'ACL e nel file Unattended, della possibilità di autoaccettare la modifica dei registri, a tutti quei programmi/eseguibili presenti all'interno di una cartella, successivamente impostata dall'utente (dopo l'installazione), per facilitare le operazioni: : In fase di discussione
servirebbe un demone che controlla appesantirebbe ROS
PUOjACKz wrote: * Monitor delle attività di modifica del registro di sistema, con feature di comparazione (tra la versione precedente e successiva) e di roll-back (in caso di recupero del registro da errori): In fase di discussione
Questa sarebbe un ottima cosa, gestibile all'avvio di ROS
PUOjACKz wrote: * SandBox per programmi/eseguibili Win16/32, al fine di monitorare o blindare l'esecuzione di certi programmi, per questioni di sicurezza: In fase di discussione
Questo sarebbe TOSTO farlo, ma anche difficile
PUOjACKz wrote: * Behavior Blocker Nativo: In fase di discussione
servirebbe un demone che controlla appesantirebbe ROS
PUOjACKz wrote: * Utilità Anti-Dialer: : Bocciata, per questioni di performance, è consigliata la rimozione delle funzioni COM e ActiveX collegate

Spero d'aver scritto tutto. Esorto nel discutere dei punti rimanenti.

PUOjACKz
Posts: 116
Joined: Tue Jan 03, 2006 3:52 pm

Post by PUOjACKz »

mauriziodaniello wrote:
PUOjACKz wrote:- Registro di sistema

* ACL per dichiarare quali programmi possono o non possono modificare il registro di sistema, in modo automatico, oppure, generalmente, quali aree possono modificare: In fase di discussione
servirebbe un demone che controlla appesantirebbe ROS
Beh, aumenterebbe, comunque, la sicurezza di sistema.
La domanda è: si vuole un sistema sicuro, oppure un sistema veloce? Perchè, comprendo gli ambienti linux, i quali possono essere modificati in modo tale da funzionare in dispositivi dedicati, ma quelli Windows-like, van bene per PC.
Voler, a tutti i costi, che il ReactOS s'installi, ora come ora, su un 80286, IMHO, è una cosa inutile.
mauriziodaniello wrote:
PUOjACKz wrote:
* Dispositivo Anti-Bot (contro l'automazione dei programmi), per autenticare la presenza di un persona, durante la modifica dei registri: In fase di discussione
Proteggere con pwd (in sola scrittura) il registro questa è la mia idea
L'introduzione di una password, può essere utile, ma ciò implica che, in caso di smarrimento, devi reinstallare l'OS.
Al contrario, un sistema antibot, evita che il programma vada a scrivere, nel registro. Assieme al sistema ACL da me proposto, evita che eventuali programmi maligni, possano reimpostare il registro, senza che l'utente lo sappia.
mauriziodaniello wrote:
PUOjACKz wrote:

* Cifratura del registro di sistema. Solo l'OS e l'utente possono modificare tale file, che non può essere manipolato dall'esterno. L'utente, necessità di un tool con dispositivo Anti-Bot, per garantire una maggior sicurezza: In fase di discussione
Molti programmi installano per funzionare correttamente dati di start-Ip programma, se lo codifichi non funzionano più.
Ciò, ritornando alla questione dell'ACL, se il programma viene avviato in una cartella, ove l'ACL non fornisce la possibilità, l'injection nel registro viene, cmq, bloccato. Il problema della crittazione era per evitare che qualche furbastro si mettesse ad agire, senza permesso.
La decisione della cifratura del registro, era al fine di evitare che qualche intruder riesca a mettere le mani nei files, modificandoli con altri sistemi. Occorrerebbe trovare il sistema per evitare che l'attaccante possa avere una simile possibilità, senza castrare il funzionamento dei programmi.

Qualche idea?
mauriziodaniello wrote:
PUOjACKz wrote:
* File UnAttended che dichiara quali programmi/eseguibili hanno il diritto di modifica dei registri, sia durante l'installazione, che successivamente. Tale feature può essere utile in caso d'installazione automatiche, senza la necessità dell'interazione preventiva o Just In Time dell'utente: : In fase di discussione
servirebbe un demone che controlla appesantirebbe ROS
Lo sò, che tutto questo appesantirebbe l'OS, ma è, cmq, un sistema per renderlo più sicuro e configurabile, senza far apparire 1000000 popup all'utente.
mauriziodaniello wrote:
PUOjACKz wrote:
* Assegnazione, nell'ACL e nel file Unattended, della possibilità di autoaccettare la modifica dei registri, a tutti quei programmi/eseguibili presenti all'interno di una cartella, successivamente impostata dall'utente (dopo l'installazione), per facilitare le operazioni: : In fase di discussione
servirebbe un demone che controlla appesantirebbe ROS
Sarebbe una banale opzione presente nell'ACL da me spiegata.
mauriziodaniello wrote:
PUOjACKz wrote: * Monitor delle attività di modifica del registro di sistema, con feature di comparazione (tra la versione precedente e successiva) e di roll-back (in caso di recupero del registro da errori): In fase di discussione
Questa sarebbe un ottima cosa, gestibile all'avvio di ROS
Occorrerà, però, far attenzione al volume di monitoraggio dei dati. Inoltre, è bene tenerlo disattivo di default. Attivare un logger delle attività di registro, appena installato, può comportare un riempimento delle aree di storaging, con dati che, probabilmente, l'utente manco ha richiesto.
mauriziodaniello wrote:
PUOjACKz wrote: * SandBox per programmi/eseguibili Win16/32, al fine di monitorare o blindare l'esecuzione di certi programmi, per questioni di sicurezza: In fase di discussione
Questo sarebbe TOSTO farlo, ma anche difficile
Comprendo che sia difficile, ma è cmq un ottima idea.
Una cosa, in particolare, riguardo ReactOS: E' inutile, dopo un pò, continuare a stare alle calcagna di Windows.
Se presenti un OS che vuol essere l'esatto clone di Win, rischi di accollarti tutta quell'utenza orgogliosa del prodotto di casa MS, che non farà altro nel additare ReactOS come una soluzione scadente.
Occorre, pertanto, agire, nell'OS, in modo tale che permetta l'utilizzo del software per Windows, ma, in altre cose, proponendo delle idee originali.
Il SandBox, eviterebbe il bisogno di eseguire certi programmi, alquanto invasivi, nel sistema, tramite, addirittura, il RunAs. Questo, in quanto, alla fine, quel programma, agirebbe, effettivamente, con accessi massimali al sistema. Se, invece, lo si inganna, creando un istanza virtuale, che gli faccia credere di poter godere di certi privilegi si può:

1) Evitare di esporre i singoli profili, ad ipotetici rischi di sicurezza. Il RunAs, alla fine, è molto utile, ma può essere sfruttato, da un intruder, per un "Escalation Priviledge DoS", in quanto, la struttura del sistema gli darebbe libero accesso. Ok, che, in questi casi, tale attacco può essere comportato anche senza RunAs, ma, vi sarebbe già il bisogno di un "Buffer Overflow Condition", il quale, avevo in mente, di gestirlo tramite l'implementazione di "DEP" e altri dispositivi simili.
2) Emulare parte del sistema. Metti, ad esempio, che un vecchio programma vada ad installare dei files, che, anche in caso di UnInstall, rimangono permanenti, causando instabilità. Oppure, pensa all'introduzione o alla sostituzione di certe librerie. Se io eseguo il programma, in un ambiente pseudo-virtuale, posso far in modo che quest'ultimo installi le sue librerie, senza toccare quelle reali nel sistema. Ciò ridurrebbe il rischio d'instabilità e, al massimo, si avrebbe un "Only-Crash Program", cioè, se, in precedenza, quell'applicativo, durante l'inceppamento, faceva scivolare tutto l'OS nel baratro, così, viene terminata l'istanza, che può essere riaccesa, senza danni permanenti all'ambiente operativo nativo.
3) Monitorare l'attività del programma. Un programma, in precedenza, schiantava, a causa di un errore dovuto dal sistema operativo. Di per sè, il PGM era corretto, ma siccome, in passato, MS non diffondeva molto il codice sorgente, i coders non han tenuto in considerazione di una debolezza di sistema. In questo modo, è possibile patchare l'ambiente emulato, in modo da migliorare l'esecuzione di certi programmi. Inoltre, con un monitoraggio, è possibile comprendere ove i programmi vanno ad installare i files, per poter, inseguito, eseguire una pulizia manuale.
4) Monitoraggio di eventuali attività maligne. In questo modo, se l'utente è tonto a sufficienza, può salvaguardarsi.
Un esempio stupido: L'utente A, ha uno script per mIRC, dotato di WarPack (Sta cosa è molto lamera, ma noi qua dobbiam prendere in considerazione OGNI eventualità). Per qualche motivo a noi ignoto, un malware nidificato, in qualche programma, viene acceso. Se tutto ciò, avviene, a livello nativo, il sistema, poi, è da buttare (ho visto alcuni casi io e ti posso assicurare che si faceva prima a formattare, che a recuperare il tutto), che sia ReactOS oppure no, visto che, cmq, ROS emula un sistema windows, pertanto, anche lui è soggetto di quasi tutti i problemi di sicurezza dell'OS di casa MS.
Magari, qualcuno dirà, in ROS son presenti delle altre blindature che minimizzano il danno, però, in quelle condizioni, personalmente, non mi fido di cosa potrebbe accadere. Il sistema entrerebbe in uno status sconosciuto (es. malfunzionamenti vari, dovuti dal semi danneggiamento dei files o che sò io), ove, lavorare con dati sensibili, potrebbe essere pericoloso.
E' capitato un giorno al sottoscritto: su Win98, la sera prima, tutto apposto, mentre, la mattina dopo, tutti i files della cartella Windows erano stati raggruppati, in modo casuale, creando un file da 400 mega, con un nome ed un estensione strampalati. Magari, questo, su ReactOS non succederà, però noi dobbiam essere SICURI al 100%, sempre e comunque.
Se tutto sto ambaradan, veniva eseguito in un ambiente emulato, i files coinvolti e simulati potevano esser cancellati. Al massimo vi era una minima perdita di dati (es. i log delle discussioni). Il sistema è al sicuro e tutto funziona.

Da tener in considerazione una questione. Questa SandBox, eviterebbe, inoltre, il caricamento, a livello nativo, di tutti quei programmi, famosi nel scombinare i registri di sistema e, quindi, condurre, l'utente, in una formattazione finale.
In questo caso, basterebbe agire nel pseudo-registro creato, cancellandolo. Risultato dell'operazione: ti sei levato di torno un sacco di programmi, di cui non avevi più bisogno, che avrebbero combinato un casino nel sistema e ReactOS funziona, al massimo della stabilità e delle performance, sia perchè le librerie son, al massimo, state leggermente cambiate, da qualche programma installato nativamente, sia perchè, non hai più quintali di ciarpame, nel registro, da gestire, inutilmente, ad ogni StartUp.
Probabilmente, tutto ciò comporterà, come hai detto tu, un appesantimento del sistema. Ok, ma tieni in considerazione che, ora come ora, i computers son molto potenti e preferisco aver, in memoria, qualche processo legato ad un simile sistema di sicurezza, che magari qualche cazzatina piena di buchi (più del formaggio), che viene autoavviata, allo StartUp, ma di cui non ho alcuna cognizione, nè utilizzo.
mauriziodaniello wrote:
PUOjACKz wrote: * Behavior Blocker Nativo: In fase di discussione
servirebbe un demone che controlla appesantirebbe ROS
In questo caso, ovviamente, il Behavior Blocker non agirebbe nel SandBox. Inoltre, direi di farlo, in modo, da poterlo disattivare (magari temporaneamente). Però, escluderlo del tutto, secondo me, è una cazzata.

Come ho già detto, certe features possono essere presenti, ma spente per default. Ovviamente, è inutile poter millantare che il ROS possa essere eseguito in sistemi ormai datati, in quanto, più che gasarsi, non si può far molto.
Anche solo pensare di portare un OS, in un Live Enviroment, con simili hardware, è da pazzi, in quanto, è tutto datato e nei dintorni, non trovi pezzi di ricambio facilmente.
Es. dire: "Oh, guarda, ho il ROS su un 80486 e funziona meglio di windows", quando, nel giro di qualche mese, ci lavori sopra, hai dei dati importanti salvati, ma ti parte tutto, per un qualche motivo, è una situazione che ti rende "pirla" difronte agli altri. Ovviamente, con questo non dico che bisogni appesantire da pazzi l'OS, ma neanche evitare certi sistemi di sicurezza, per desiderare una velocità, raggiungibile, comunque, con i componenti hardware presenti oggigiorno.

PUOjACKz
Posts: 116
Joined: Tue Jan 03, 2006 3:52 pm

Post by PUOjACKz »

Proprio oggi, leggevo, nel forum di PI e ho trovato questi due reply:

http://punto-informatico.it/forum/pol.a ... PI#1271345

http://punto-informatico.it/forum/pol.a ... PI#1271404

Questo, è il genere di utenza che, in parte, ReactOS dovrà aspettarsi. Occorre, quindi, tener in considerazione che, una pubblicità futura, di un OS più protetto di Windows, non può che far bene allo sviluppo di ROS.
Creare un altro OS, che finisca col partecipare all' "Ammucchiata delle BOTNet", direi, sarebbe un madornale errore.

mauriziodaniello
Posts: 25
Joined: Mon Dec 19, 2005 10:14 pm
Location: Romania

Post by mauriziodaniello »

PUOjACKz wrote:Proprio oggi, leggevo, nel forum di PI e ho trovato questi due reply:

http://punto-informatico.it/forum/pol.a ... PI#1271345

http://punto-informatico.it/forum/pol.a ... PI#1271404

Questo, è il genere di utenza che, in parte, ReactOS dovrà aspettarsi. Occorre, quindi, tener in considerazione che, una pubblicità futura, di un OS più protetto di Windows, non può che far bene allo sviluppo di ROS.
Creare un altro OS, che finisca col partecipare all' "Ammucchiata delle BOTNet", direi, sarebbe un madornale errore.
Quoto in toto !

Però io lavoro sia su Win che Linux (non parteggio per nessuno), posso dire tranquillamente che l'equazione windows si buca come Linux è uguale "rubare le caramelle al bambino" al "rubare oro in Fort Knox" (cassaforte della Banca USA), infatti i Unix/Linux vengono bucati da Super cracker mentre win 2003 da pirlotti, Utonti permettendo, per quelli nessuna sicurezza serve.

Es.: In un carcere di "massima sicurezza" in Italia, nell' 80', un pericoloso criminale è evaso semplicemente perché si sono presentati dei "poliziotti" (ovvero complici) con un ordine di trasferimento (ovviamente truccato).

Dunque se veramente il problema è l'utonte (spesso non lo è), non esiste niente per proteggerlo, quindi non prenderemo in considerazioni quei problemi, non come Win che "scaricabarile" sempre è comunque.

Ciao

NB: un Firewall di base in ROS DEVE esserci !
Last edited by mauriziodaniello on Thu Jan 19, 2006 4:32 pm, edited 2 times in total.

mauriziodaniello
Posts: 25
Joined: Mon Dec 19, 2005 10:14 pm
Location: Romania

Post by mauriziodaniello »

Hai ragione, adesso installarlo su 486 è puramente hobbystico, non avrebbe senso, ma certe applicazioni, credimi, rallenterebbero anche un 686, basta vedere la velocità come scende con un semplice antivirus !
L'introduzione di una password, può essere utile, ma ciò implica che, in caso di smarrimento, devi reinstallare l'OS.
Se uno perde la pwd di sistema operativo è cretino forte, si merita di riformattare, ma visto le esperienze con utonti !
idea :!: , in installazione si deve inserire la pwd di sistema che lo scrive su un dischetto di riavvio (txt), se anche questo si perde non solo deve riformattare ma anche 20 frustate sulle gengive !

Questo perché il sistema delle pwd sui registri è la più semplice e pratica e vista l'esperienza al massimo 5 popup.

Buona l'idea di un doppio registro, il registro vero viene crittografato, del resto contiene informazioni sensibili, il secondo contiene solo la parte appena aggiunta, ovvero conterrebbe solo "INCLUDE file" del registro vero + la parte appena aggiunta e non confermata !

Tenere delle protezione di default off ma anche temporaneamente disabilitata, non è una buona idea, del resto se vuoi la frittata dei rompere le uova !

Poi teniamo conto che nella sicurezza non esiste solo il registro, ma anche le DCOM usate per i virus su rete ed altri 100 problemi causati dalla mancanza di pwd su punti di sistema operativo.
Es.: basta rendere non modificabile il command.com (ora cmd) per evitare una 90-ina di virus !

Ciao

PUOjACKz
Posts: 116
Joined: Tue Jan 03, 2006 3:52 pm

Post by PUOjACKz »

mauriziodaniello wrote:Hai ragione, adesso installarlo su 486 è puramente hobbystico, non avrebbe senso, ma certe applicazioni, credimi, rallenterebbero anche un 686, basta vedere la velocità come scende con un semplice antivirus !
Ti dirò, ho visto certi AV, che impiegano 100000000 processi, mentre, altri, con anche soli 3 di questi, riescono a fornire la stessa protezione.
Ovviamente, con quanto ho appena detto, non sto affermando che è colpa di chi produce l'antivirus, percui, giù ad appesantire l'OS. Per carità, mai e poi mai.
Però, una buona idea, sarebbe quella di implementare tutte piccole astuzie che, almeno, nei casi medi, circoscrivano il rischio per la sicurezza, effettivamente, fornendo una soluzione che non necessiti di una continua revisione, per funzionare.
Ad esempio, un Antivirus dev'essere seguito, per fornire sempre dei nuovi patterns. Se, invece, noi riusciamo ad elaborare un metodo, che invalidi l'esecuzione di certi malware, già il lavoro per i coders degli AV, è minore. Inoltre, si evitano pure programmi creati da terze parti, i quali necessitano di 10000 librerie loro, collegamenti attivi ecc...
Lo sò che questo aumenta lo spessore dell'OS, ma qua, purtroppo, almeno per ora, non vedo via d'uscita. Occorre, ahimè, cautelarsi, perchè, ora come ora, Windows è abbastanza dominante, e sistemi Windows-like, se non progettati in maniera appropriata, possono cadere dalla padella alla brace.
L'unica via di scampo, che, però, non consiglio d'intraprendere, da parte dei niubbi, è la disattivazione di certe funzioni di sicurezza. Ma è pericoloso. Siamo qua per dare una svolta decisiva, mettiamoci d'impegno direi. Inutile, inoltre, correre per ottenere tutto e subito.
Ad esempio, quell'idea del sandbox, non è attuabile ora, ma in futuro, se si vuole veramente, la si può fare.

Alla fine, ROS non è poi così indietro, come qualche trollone dice. Certo, è ovvio che Wine, ora come ora, è più aggiornata, ma capirai.. è diverso.
Qua c'è tutto da gestire, su wine, il lavoro è molto meno.
L'introduzione di una password, può essere utile, ma ciò implica che, in caso di smarrimento, devi reinstallare l'OS.

Se uno perde la pwd di sistema operativo è cretino forte, si merita di riformattare, ma visto le esperienze con utonti !
idea :!: , in installazione si deve inserire la pwd di sistema che lo scrive su un dischetto di riavvio (txt), se anche questo si perde non solo deve riformattare ma anche 20 frustate sulle gengive !

Questo perché il sistema delle pwd sui registri è la più semplice e pratica e vista l'esperienza al massimo 5 popup.
Figurati che, in internet, vidi, in un sito, un immagine di un libro, per BSD, che consigliava, all'admin, di scriversi la password di root, in un biglietto, nonostante ci siano esperti di sicurezza che lo sconsiglino caldamente ROTFL

Riguardo la cosa del dischetto, io consiglierei di estendere il tutto anche, per lo storaging di sicurezza via rete e tramite Flash Drive. Nei laptop, al giorno d'oggi, non ci sono Floppy Drive :(
Se poi, come hai detto tu, si perde tutto, allora, il mio consiglio è quello di prendere carta e penna, per i propri calcoli. C'è un limite a tutto :wink:

Buona l'idea di un doppio registro, il registro vero viene crittografato, del resto contiene informazioni sensibili, il secondo contiene solo la parte appena aggiunta, ovvero conterrebbe solo "INCLUDE file" del registro vero + la parte appena aggiunta e non confermata !
Tenere delle protezione di default off ma anche temporaneamente disabilitata, non è una buona idea, del resto se vuoi la frittata dei rompere le uova !
Sì, ecco, perfetto direi.
Ovviamente, come hai detto tu, c'è un qualche rischio, ma è comunque 100000 volte di meno di quanto c'è ora.

Poi teniamo conto che nella sicurezza non esiste solo il registro, ma anche le DCOM usate per i virus su rete ed altri 100 problemi causati dalla mancanza di pwd su punti di sistema operativo.
Es.: basta rendere non modificabile il command.com (ora cmd) per evitare una 90-ina di virus !

Ciao
Riguardo la cosa del command.com, là volevo proporre altre idee. Prima, però, continuamo a discutere di queste, in modo specifico.

mauriziodaniello
Posts: 25
Joined: Mon Dec 19, 2005 10:14 pm
Location: Romania

Post by mauriziodaniello »

PUOjACKz wrote:Ti dirò, ho visto certi AV, che impiegano 100000000 processi, mentre, altri, con anche soli 3 di questi, riescono a fornire la stessa protezione.
:shock: parlando con un programmatore di AV, questo disse "il 90% delle difese dell'antivirus è non far funzionare Win" ovvero evito di far scrivere questo e quello, blocco le porte e falle varie (0% di CPU), in realtà quando vedi 100000 processi pesanti è perché scanna il disco, spy e virus non sono molto diversi :wink: spesso !

Teniamo conto che spesso gli spy e virus sono presi da buchi di Internet Explorer !

Certo che semplificheremmo la vita ad AV e anti-spy, non possiamo sostituirli, ma oggi un sistema già deve essere sicuro se vuole affermarsi, poi casi eccezionali sono rare applicazioni.

Dunque una cosa leggera come peso macchina sarebbe passabile, ma si fa presto sforare al 100% CPU !

PUOjACKz wrote:Alla fine, ROS non è poi così indietro, come qualche trollone dice. Certo, è ovvio che Wine, ora come ora, è più aggiornata, ma capirai.. è diverso.
Infatti io discuto già di distribuzione :wink: con investitori, ma la cosa burocraticamente è lunga.
Ricordiamoci che red, suse, ecc. erano dei professori "morti di fame" è Linux era alfa quando loro lo distribuivano (veramente NON è finito ancora adesso, manca un sacco di cose come le specifiche Posix), comunque adesso sono milionari ! :evil:

Ciao

[/quote]

PUOjACKz
Posts: 116
Joined: Tue Jan 03, 2006 3:52 pm

Post by PUOjACKz »

Tra i vari appunti, da me scritti, ho voluto presentare questo:

Behavior Blocker

Code: Select all

Il Behavior Blocker deve 

* identificare l'accensione dei programmi
* identificare la sostituzione dei programmi
* identificare quando i programmi tentano di avviare altri programmi
* poter essere attivato o disattivato, in un sistema, anche limitando il suo funzionamento 
Essendo in fase molto Alpha, come idea, ho voluto abbozzare questi "capisaldi" su quello che dovrà presentare l'eventuale implementazione nativa di un behavior blocker.
I 2 punti che seguono, invece, son alcune idee che ho buttato giò, per un eventuale estensione di tale strumento, qualora anche altri mie proposte risultino valide. Ora come ora, se vuoi, dacci una pseudo-occhiata, ma prendile con le pinze, in quanto, per comprenderle, occorre tutto un antefatto che esplicherò a tempo debito.

Code: Select all

* informare dello stato di un programma (se scandito dagli engine eucaristici, oppure no)
* presentare una descrizione generica riguardo il rischio possibile, a seconda del tipo di programma attivo ad alcuni utenti
Riguardo l'AV, son d'accordo che è un argomento delicato, ma programmi quali Norton e simili, stuprano veramente molto, il sistema, con attività invasive, secondo me, completamente inutili (e non sono il solo, abbastanza esperto in materia, a pensarla così).
Per il resto, il programmatore ha pienamente ragione, ma occorrerà, sempre a tempo debito, effettuare un altro tipo di ragionamento, in quanto, dovran funzionare sia gli AV standard, che quelli opensource, anche se pensavo, per quest'ultimi, di proporre eventuali estensioni d'integrazione, per una migliore performance.

mauriziodaniello
Posts: 25
Joined: Mon Dec 19, 2005 10:14 pm
Location: Romania

Post by mauriziodaniello »

PUOjACKz wrote:Tra i vari appunti, da me scritti, ho voluto presentare questo:

Behavior Blocker

Code: Select all

Il Behavior Blocker deve

* identificare l'accensione dei programmi
* identificare la sostituzione dei programmi
* identificare quando i programmi tentano di avviare altri programmi
* poter essere attivato o disattivato, in un sistema, anche limitando il suo funzionamento 
Essendo in fase molto Alpha, come idea, ho voluto abbozzare questi "capisaldi" su quello che dovrà presentare l'eventuale implementazione nativa di un behavior blocker.
I 2 punti che seguono, invece, son alcune idee che ho buttato giù, per un eventuale estensione di tale strumento, qualora anche altri mie proposte risultino valide. Ora come ora, se vuoi, dacci una pseudo-occhiata, ma prendile con le pinze, in quanto, per comprenderle, occorre tutto un antefatto che esplicherò a tempo debito.

Code: Select all

* informare dello stato di un programma (se scandito dagli engine eucaristici, oppure no)
* presentare una descrizione generica riguardo il rischio possibile, a seconda del tipo di programma attivo ad alcuni utenti
Riguardo l'AV, son d'accordo che è un argomento delicato, ma programmi quali Norton e simili, stuprano veramente molto, il sistema, con attività invasive, secondo me, completamente inutili (e non sono il solo, abbastanza esperto in materia, a pensarla così).
Per il resto, il programmatore ha pienamente ragione, ma occorrerà, sempre a tempo debito, effettuare un altro tipo di ragionamento, in quanto, dovran funzionare sia gli AV standard, che quelli opensource, anche se pensavo, per quest'ultimi, di proporre eventuali estensioni d'integrazione, per una migliore performance.
***********************************************************
Intanto ragiono su quello che proponi e aspetto.

Dunque la cosa che mi preoccupa è che siamo in 2 in questa discussione.
Per fare una cosa completa bisognerebbe chiedere anche alle persone più esperte, pensando propongo questi link open

http://www.clamav.it/
Produce un antivirus OPEN GPL per WINDOWS, qui puoi trovare la recensione
http://www.zeusnews.it/index.php3?ar=stampa&cod=3038

Sullo stesso tema troviamo
http://www.openantivirus.org/

ma con una ricerca su sourceforge.net

http://sourceforge.net/search/?type_of_ ... rch=Search
o
http://sourceforge.net/search/?type_of_ ... rch=Search

Trovi una marea di gente che probabilmente ha risolto il problema che ti poni.

Ciao

PUOjACKz
Posts: 116
Joined: Tue Jan 03, 2006 3:52 pm

Post by PUOjACKz »

mauriziodaniello wrote: Intanto ragiono su quello che proponi e aspetto.

Dunque la cosa che mi preoccupa è che siamo in 2 in questa discussione.
Per fare una cosa completa bisognerebbe chiedere anche alle persone più esperte, pensando propongo questi link open
Ok, proverò a contattare i tizi di ClamAV e OpenAV, per approfondire meglio alcuni punti.

Ho dato un occhiata a ClamAV. Veramente notevole ed interessante il lavoro da loro fatto.

Purtroppo, però, ri-devo far notare il problema:
Su OpenAV:

Code: Select all


VirusSignatures-latest.zip last modified May 29 2004 07:04:54 PM

Ora, visto questo palese esempio di come sia più arduo gestire un antivirus free, occorre entrare nell'ottica dell'Hardening dell'OS.
Inoltre, io direi, ora come ora, riguardo gli AV, di frenare, in quanto, come hai sottolineato, quel genere di applicativo dev'essere trattato con cura. L'unica cosa che possono pensare è quella di mantenere una certa compatibilità, offrendo, inoltre, qualche interazione, con il sistema, in modo da integrare gli AV, in via più concreta, ma non invasiva.

Update della mia proposta riguardo il Behavior Blocker:

Code: Select all

Il Behavior Blocker deve 

* identificare l'accensione dei programmi
* identificare la sostituzione dei programmi
* identificare quando i programmi tentano di avviare altri programmi
* informare dello stato di un programma (se scandito dagli engine eucaristici, oppure no)
* presentare una descrizione generica riguardo il rischio possibile, a seconda del tipo di programma attivo
* poter essere attivato o disattivato, in un sistema, anche limitando il suo funzionamento ad alcuni utenti
* identificare quando i programmi tentano di agire nell'utilità di pianificazione 
* identificare quando i programmi aggiungono dei files nelle cartelle di auto-esecuzione all'avvio (es Esecuzione Automatica)

Speekix
Posts: 72
Joined: Thu Dec 08, 2005 11:32 am

Post by Speekix »

Scusate se non sono partecipe alla vostra discussione ma non riesco a seguirvi..

PUOjACKz
Posts: 116
Joined: Tue Jan 03, 2006 3:52 pm

Post by PUOjACKz »

Speekix wrote:Scusate se non sono partecipe alla vostra discussione ma non riesco a seguirvi..
Come mai? Cos'è che non comprendi? Parla pure che ti spieghiamo :)

Code: Select all

Il Behavior Blocker deve 

* identificare l'accensione dei programmi 
* identificare la sostituzione dei programmi 
* identificare quando i programmi tentano di avviare altri programmi 
* informare dello stato di un programma (se scandito dagli engine eucaristici, oppure no) 
* presentare una descrizione generica riguardo il rischio possibile, a seconda del tipo di programma attivo 
* poter essere attivato o disattivato, in un sistema, anche limitando il suo funzionamento ad alcuni utenti 
* identificare quando i programmi tentano di agire nell'utilità di pianificazione 
* identificare quando i programmi aggiungono dei files nelle cartelle di auto-esecuzione all'avvio (es Esecuzione Automatica) 
Consiglierei di creare, anche su ReactOS, un centro per la sicurezza.
Tra le varie voci, inserire anche un piccolo pannello per la gestione del Behavior Blocker qua presentato.
Essendo tale "Utility" non configurabile dall'esterno (ossia, via console), non occorre un sistema Anti-Bot.

La sezione dovrebbe presentare:

- Una breve descrizione, ove spiegare all'utente, in parole semplici, cosa fà il behavior blocker e perchè tenerlo acceso. Ad esempio:

"Benvenuti nel pannello di configurazione del Behavior Blocker di ReactOS. Questa utilità di sicurezza, permette, all'utente, di interagire su vari aspetti legati all'esecuzione dei programmi, nell'ambiente operativo, limitando, quindi, eventuali rischi legati all'esecuzione automatica di programmi sconosciuti."

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest