![]() |
|
|
google unix.com
|
|||||||
| Forum | Registrati | Regole Forum | Collegamenti | Album | FAQ | Members List | Calendario | Ricerca | Today's Posts | Mark Forums Read |
| Sicurezza Discuti di UNIX e Linux computer e la rete di sicurezza, sicurezza informatica, cyberattacks, sicurezza IT, CISSP, OWASP e molto altro ancora. |
Più di UNIX e Linux Forum Argomenti potreste trovare utili
|
||||
| Filo | Thread Starter | Forum | Risposte | Ultimo Post |
| Apri Cirrus Cloud Computing Banco di prova: federati Data Center per uno Sistemi Open Source | iBot | UNIX e Linux RSS News | 0 | 06-09-2009 12:30 AM |
| Caldera GPLing nel 2001, ha dato "Open Access" per aprire il codice sorgente di UNIX 8 | iBot | UNIX e Linux RSS News | 0 | 03-12-2009 06:30 PM |
| qual è il miglior antispam open source? | mohammadmahdi | UNIX for Dummies Domande & Risposte | 1 | 09-29-2008 10:48 AM |
| Open Source NSM | Jawwad | Reti IP | 4 | 09-25-2007 04:20 AM |
| Open Source è morto, viva Apri Brevetti? - InformationWeek | iBot | UNIX e Linux RSS News | 0 | 07-13-2007 03:00 PM |
![]() |
|
|
LinkBack | Thread Tools | Cerca in questo Thread | Rate Thread | Modalità di visualizzazione |
|
|
|
||||
|
pro ei contro di una strada ...
open source, media e chiunque può trovare la patch per bug, ma anche chiunque può trovare e sfruttare il bug. Io credo che spesso l'open source è più sicuro perché le patch di solito semplice uscire più veloce se si trova un bug. (ma questo non è sempre il caso.) alla fine del giorno la sicurezza è più su di voi e le vostre abitudini OS allora cosa si sta utilizzando. non aprire le porte non necessarie. non eseguire i servizi non è necessario. conservare le password forte. fare patch spesso. |
|
|||||
|
Entrambi sì e no. Da un lato, dal momento che un sacco di gente può dare un'occhiata alla fonte è difficile intenzionalmente introdurre codici maligni. D'altro canto, molti progetti non hanno formalizzato le prove di sicurezza e di contare su un software che controlli per alcuni modelli il codice che potrebbe presentare difetti.
Il miglior esempio è il OpenSSL bug introdotto in Debian perché riferito uninitalized valgrind memoria. La presunta "fissare" la riduzione globale casualità del sistema in quanto il coder e recensori non vedere tutte le implicazioni. |
|
|||||
|
Sono d'accordo con le risposte.
E 'troppo semplice per effettuare una scansione generalizzazione "open source è più sicuro" o "open source è meno sicuro". Così, chi ritiene che sia stato, sì o no, è giusto e sbagliato, perché la dichiarazione è troppo generica e quindi di significato Anche il termine "sicurezza" non ha alcun significato reale. Nel discutere di sicurezza informatica che si deve discutere di rischio, e per discutere dei rischi è necessario pensare in termini di vulnerabilità , delle minacce e l'impatto. Per esempio, un sistema open source acceso e in seduta tuo armadio senza una connessione a Internet può essere più sicuro che il più costoso sistema closed source su Internet ![]() In altre parole, ci sono esperti di sicurezza nasce ogni minuto, a quanto pare, e molto pochi a capire che cosa sono in realtà di circa. Se avete capito di sicurezza e di gestione del rischio, non si può rispondere a una semplice domanda come "open source è più o meno sicuro?" perché questa domanda non ha senso e solo presta ad infinite, dibattiti senso da parte di persone che non capiscono la natura di sicurezza IT e di gestione del rischio. |
|
||||
|
Sono d'accordo con Neo. Vorrei dividere la questione in due parti distinte, una teorica e una pratica.
Anche solo teoricamente parlato della questione di closed-source versus open-source rimane complicata. Un possibile vantaggio di open-source è il processo di peer-review, che può aver luogo. Ma per sfruttare tale vantaggio a questo processo ha che si terrà a tutti, che non è in alcun modo garantita da una fase di open-source a tutti. Un possibile vantaggio di software closed-source sarebbe la "sicurezza attraverso l'oscurità " approccio. L'esperienza suggerisce che questa non è una (della durata) misura di sicurezza a tutti e in caso di compromissione della sicurezza vi è un unico possibile fonte in grado di fornire servizi di correzione, mentre il software open-source potrebbe essere modificato da chiunque, in teoria, che lascia ancora lotto dei possibili autori delle correzioni nella pratica. Affrontando il problema a livello pratico, deve essere dichiarato che "sicurezza" è - come "prestazioni" per questo - un termine relativo e non possono essere assolutamente utilizzati. Vi è una certa valore di x si desidera proteggere e vi è un certo sforzo di stima y necessaria per superare il tuo misure di sicurezza. Se x è (molto) più grande di y hai un problema di sicurezza, altrimenti non hai. Per valutare la sicurezza di stato semplicemente mettere in te il luogo della intruso: si eventualmente pagare per superare le difese? Legge, se la risposta è "sì" o in prossimità di lì, altrimenti non preoccupatevi. E 'simile a quello che i dirigenti hanno countlessly detto alle riunioni in materia di "prestazioni": hai qualche domanda, che può essere misurata (in secondi, le operazioni a termine, kilobyte, qualunque sia) e non vi è un sistema di dover rispondere alla domanda. Si tratta di "il sistema di soddisfare le richiesta - sì / no?" Prestazioni non è "veloce", ma "abbastanza veloce". Lo stesso vale per la sicurezza: cosa proteggere e gli sforzi per la protezione che deve essere in proporzione e la questione non è "sicuro", ma "abbastanza sicuro". Bakunin |
|
|||||
|
Vorrei anche aggiungere che, almeno per me personalmente e parlando in spazzante generalità che non mi piace fare, mi sento meno sicuro con "codice chiuso" rispetto a "codice aperto".
Per quanto mi riguarda, posso facilmente fiducia quello che posso vedere. Sono in grado di aprire il codice di ricerca più facilmente (e cercare problemi) che non posso cercare un binario o codice criptato, come codificato PHP (che non posso cercare a tutti). Recentemente, mi sono rifiutato di installare PHP codificato su un sito web per la esatta ragione. Non mi fido di codice non riesco a vedere e non vedono motivi per installare codice PHP criptati quando posso trovare alternative aperte. Come ho detto prima, non mi piace in genere di rispondere alle generalizzazioni senza contesto, quindi sono semplicemente fornire il mio personale parere, e questo è che io (il mio parere personale), si sentono più sicuri quando si può esaminare il codice, è grep, ricerca, aggiungere le dichiarazioni di debug, ecc |
|
||||
|
Citazione:
Se improvvisamente il tuo aggiornamento dei sistemi di sicurezza e so usare il metodo di cui sopra, allora hai appena fatto sapere che gli utenti hanno ora qualcosa di sensibile che non si desidera ottenere altri. D'altro canto, tuttavia, se si ha sempre come un sistema sicuro per quanto possibile, non importa ciò che è in là , non si improvvisa "cambiare abitudini" e rendono evidente che si sta tentando di nascondere qualcosa, allora tutto ciò che gli altri. |
![]() |
| Segnalibri |
| Thread Tools | Cerca in questo Thread |
| Modalità di visualizzazione | Vota questo thread |
|
|