Perché i sistemi operativi basati su Linux sono considerati più sicuri di Windows? [chiuso]


19

Ho sentito che i sistemi basati su Linux sono migliori per la sicurezza. Apparentemente non hanno virus e non hanno bisogno di software antivirus. Anche la mia università lo afferma: si rifiutano di avere Windows sui loro server, il che è un vero peccato perché volevamo usare il framework .NET per creare alcuni siti Web.

L'unica ragione per cui vedo che Linux è più sicuro è perché è open-source, quindi teoricamente i bug verrebbero catturati e corretti prima.

Conosco un po 'come funzionano i sistemi operativi, ma non ho approfondito il modo in cui Linux e Windows implementano il loro sistema operativo. Qualcuno può spiegare la differenza che rende i sistemi basati su Linux più sicuri?


5
Non rispondo esattamente alla tua domanda, ma voglio difendere un po 'la scelta della tua scuola. La mia scuola gestisce sia un sistema Windows che un sistema Linux che (provano a) condividere un file system comune. Ma in pratica questo può essere costoso perché i domini windows e unix sulla rete non vanno davvero d'accordo, purtroppo. Dato che vediamo che gli utenti Windows devono utilizzare alcuni componenti open source più del contrario (scusatemi per .net), è una scelta rispettabile che supportino Linux solo su hardware di base come i server. Linux supporta oggi i servizi più importanti
Notmyfault,

grazie per la tua risposta - e anche per gli altri soccorritori, sicuramente mi ha aiutato a chiarire le cose. Per la cronaca, ero più scettico che arrabbiato per le affermazioni della mia università.
echoblaze,

Risposte:


55

Non penso che un sistema operativo sia "sicuro". Una particolare configurazione di un sistema operativo ha un particolare grado di resistenza agli attacchi.

Probabilmente mi fotterò per essere un "apologista Microsoft" qui, ma questo thread è molto propenso a generalizzazioni su "Windows" che non sono vere.

Windows 1.0 - 3.11, 95, 98 e ME sono basati su DOS. Questa stirpe di sistemi operativi non aveva alcuna sicurezza in senso formale (spazi di indirizzi protetti, separazione modalità kernel / utente, ecc.). Fortunatamente, quando stiamo parlando di "Windows" oggi non stiamo parlando di questi sistemi operativi.

La famiglia di sistemi operativi Windows NT (Windows NT 3.5, 3.51, 4.0, 2000, XP, 2003, Vista, 2008 e 7) ha un sistema di sicurezza ragionevolmente "progettato" dalla versione iniziale nel 1992. Il sistema operativo era progettato pensando al "Orange Book" TCSEC e, sebbene non perfetto, penso che sia ragionevolmente ben progettato e realizzato.

  • Windows NT era "multiutente" sin dall'inizio (sebbene la funzionalità di più utenti che ricevevano contemporaneamente un'interfaccia utente grafica dallo stesso server non fosse disponibile fino a quando Citrix WinFrame nell'era di Windows NT 3.51). Esiste una separazione in modalità kernel / utente, con la protezione dello spazio degli indirizzi che si basa sulle funzioni hardware sottostanti di MMU e CPU. (Direi che è molto "Unix-y", ma in realtà è molto "VMS-y".)

  • Il modello di autorizzazione del filesystem in NTFS è piuttosto "ricco" e, sebbene abbia alcune verruche relative alla "eredità" (o alla sua mancanza - vedi Come risolvere il difetto di progettazione di spostamento / copia NTFS? ), Non è stato fino a quando negli ultimi 10 anni circa i sistemi operativi in ​​stile Unix hanno implementato funzionalità simili. (Novell NetWare ha battuto Microsoft al massimo su questo, anche se penso che MULTICS abbia battuto entrambi ...> smile <)

  • Il responsabile del controllo dei servizi, incluso il sistema di autorizzazione per controllare l'accesso ai programmi di servizio di avvio / arresto / pausa, è molto ben progettato ed è molto più robusto nella progettazione rispetto alle varie architetture "init.d" script "(più simili a" gentleman's Agreement " ") in molte distro Linux.

  • Il gestore oggetti esecutivo (vedi http://en.wikipedia.org/wiki/Object_Manager_(Windows) ), che è vagamente analogo al filesystem / proc e al filesystem / dev combinati, ha un modello ACL che è simile al filesystem e molto, molto più ricco di qualsiasi modello di autorizzazione di cui sono a conoscenza per / proc o / dev su qualsiasi distribuzione Linux.

  • Mentre potremmo discutere i meriti e gli svantaggi del registro, il modello di autorizzazione per le chiavi nel registro è molto più granulare del modello di impostazione delle autorizzazioni sui file nella directory / etc. (Mi piacciono particolarmente i commenti di Rob Short in merito al registro nella sua intervista "Behind the Code":http://channel9.msdn.com/shows/Behind+The+Code/Rob-Short-Operating-System-Evolution Rob inizialmente era una delle persone principali dietro il registro di Windows e penso che sia sicuro di dire che non lo è necessariamente felice con come sono andate le cose.)

Linux stesso è solo un kernel, mentre Windows è più analogo a una distribuzione Linux. Stai confrontando mele e arance per confrontarle in quel modo. Concordo sul fatto che Windows è più difficile da "eliminare" rispetto ad alcuni sistemi basati su Linux. Alcune distribuzioni Linux, d'altra parte, vengono fornite anche con un sacco di "schifezze" attivate. Con l'avvento delle varie versioni "incorporate" di Windows è possibile (anche se non per il grande pubblico) costruire "distribuzioni" di Windows che differiscono nel loro comportamento dalle impostazioni predefinite di Microsoft (esclusi vari servizi, modifica delle autorizzazioni predefinite, ecc.) .

Le varie versioni di Windows hanno avuto la loro parte di valori predefiniti scelti male, i bug che hanno permesso agli utenti non autorizzati di ottenere privilegi, attacchi denial of service, ecc. I kernel Unix (e molte applicazioni basate su Unix eseguite di default come root) hanno avuto il stessi problemi. Microsoft ha svolto un lavoro straordinario, sin da Windows 2000, nel rendere più semplice la compartimentazione delle applicazioni, l'esecuzione di programmi con il minimo privilegio e la rimozione delle funzionalità non necessarie del sistema operativo.

In breve, suppongo che ciò che sto dicendo sia che la configurazione specifica di un determinato sistema operativo per le tue esigenze, per quanto riguarda la sicurezza, sia più importante del tipo di sistema operativo che stai utilizzando. Le distribuzioni Windows e Linux hanno capacità molto simili rispetto alle funzionalità di sicurezza. È possibile applicare solide tecniche di sicurezza (privilegio minimo, installazione limitata di componenti opzionali, meccanismi di autenticazione crittograficamente sicuri, ecc.) In entrambi i sistemi operativi. Che tu lo faccia o no, questo è ciò che conta.


per qualcuno come me che non ha idea di come siano stati costruiti i sistemi Windows e Linux, il tuo post è stato incredibilmente informativo
echoblaze,

Concordato. Punti buoni.
Kyle Hodgson,

1
+1 - Sono un utente Linux a casa e un professionista principalmente della sicurezza di Windows al lavoro. La configurazione conta molto di più del solo sistema operativo e devi sicuramente confrontare le distribuzioni Linux con Windows, non solo "Linux" nel kernel.
Romandia,

3
applauso lento +1
chickeninabiscuit

Una cosa che ha davvero danneggiato il mondo Windows per molto tempo (anche se ora è per lo più storia) è che per molto tempo dovevi essere un amministratore locale per fare molte cose mentre nel mondo * nix avresti semplicemente essere sudoer su quella macchina. Il problema ovviamente era che qualsiasi cosa gestita da un amministratore locale della maggior parte delle macchine poteva fare qualsiasi cosa con la macchina. Sarebbe stata una pari minaccia per linux / unix se non fosse sempre stata una pratica ben nota non essere root ma fare sudo / su quando necessario. Immagino che non sia stato davvero un problema di Windows ma di software e con UAC è principalmente risolto.
Fredrik,

16

Un'altra cosa che non è menzionata è che la sicurezza in Windows è molto più opaca che in Linux.

Ad esempio, posso guardare un paio di file di testo e vedere esattamente cosa sta eseguendo il mio server web. IIS? Non molto: puoi vedere i risultati della configurazione attraverso lo strumento GUI, ma ci sono impostazioni nascoste. Quindi devi utilizzare un diverso set di strumenti per rivedere gli ACL sui file, ecc.

È lo stesso con la maggior parte dei programmi nel mondo di Windows: è molto difficile capire esattamente cosa influenza l'ambiente di runtime, tra il registro e gli ACL.


11

Non conosco il confronto dei permessi dei file ... quando ero un amministratore UNIX / Linux, NT4 aveva file ACL molto più granulari dei permessi di stile "777" tradizionali di UNIX / Linux. Le autorizzazioni non sono tutto, ovviamente, e sono sicuro che le moderne distribuzioni Linux almeno rendano disponibili gli ACL a grana fine, anche se non sono implementati per impostazione predefinita. A mio avviso, i concetti sudo e root sono sempre stati presenti in UNIX, sebbene Windows abbia aggiunto questi concetti costantemente e probabilmente sono ora alla pari.

La mia interpretazione è che dal momento che il codice del kernel Linux, e molti dei suoi driver e utilità, sono aperti - è probabilmente stato rivisto in modo molto più ampio e viene riparato molto più frequentemente per errori di codifica che possono portare a vulnerabilità remote che un hacker può sfruttare. La teoria dice, secondo me, che dal momento che Linux non è di proprietà di una società, può esplorare l'obiettivo di sicurezza in modo più completo di quanto una società possa fare. Le imprese devono fare soldi; mentre i gruppi open source semplicemente non hanno questa limitazione.

È molto più semplice accedere a un sistema Linux e chiudere semplicemente l'intero sistema a finestre, i daemon RPC e così via: è possibile portare un sistema basato su Linux o BSD su una o due porte aperte con un minimo di pacchetti installati e ancora avere un sistema molto utile molto facilmente. Questo probabilmente ha più a che fare con l'eredità UNIX come sistema operativo per sviluppatori; tutto è stato costruito per essere modulare, non eccessivamente interconnesso. Questo porta a un sistema molto più configurabile in cui puoi semplicemente rimuovere cose che non sono rilevanti. Non penso che sia così facile indurire i server Windows in questo modo.

Il gruppo OpenBSD ha portato questo concetto all'estremo. L'obiettivo principale numero uno del programma è quello di rivedere ogni riga di codice per possibili difetti di sicurezza. La prova è nel budino, un numero incredibilmente basso di vulnerabilità per OpenBSD nel corso degli anni a causa di questa attenzione quasi fanatica (io uso la parola con rispetto) ai dettagli.

Le aziende, mentre creano software meravigliosi (MSSQL, Exchange, Windows Server 2003 sono tutte meravigliose nel mio libro), hanno solo obiettivi diversi.


5
Sì; Gli ACL di Windows sono più precisi di Linux / Unix senza ACL (sebbene la maggior parte delle versioni moderne abbia opzioni per usare gli ACL). La differenza significativa è che le persone tendono ad accedere a Windows come amministratore - questa è ancora la configurazione standard sui laptop XP forniti dall'azienda - mentre le persone su Linux / Unix non eseguono la maggior parte delle operazioni come root. Questo limita il danno che può essere fatto su Linux / Unix rispetto a Windows - per impostazione predefinita. Se qualcuno viene eseguito come root per tutto il tempo, tutte le scommesse sono disattivate (tranne per il fatto che avranno un incidente deplorevole e dispiaciuto, prima o poi).
Jonathan Leffler,

"È vero che i concetti sudo e root sono sempre stati presenti in UNIX e solo ora arrivano su Windows." Di cosa stai parlando? Windows NT non è vecchio come Unix, ma Windows NT ha una sicurezza molto ragionevole "progettata" da quando è stata rilasciata nel 1992. È un peccato che molti amministratori di Windows non distribuiscano gli utenti con account "utente limitato" (come avrebbero dovuto essere, dall'inizio), ma questo non dovrebbe dannare il sistema operativo.
Evan Anderson,

Dal punto di vista del server, garantito. Ma un tipico utente di Windows aveva bisogno dell'accesso amministrativo per avere un ambiente persino ragionevolmente confortevole fino a Vista. Vedo il "clic destro, esegui come amministratore" di Vista come paragonabile a sudo.
Kyle Hodgson,

3
Non sono completamente d'accordo. Ho depourato migliaia di desktop da Windows NT 4.0 con account utente limitato. "RunAs", che è in qualche modo analogo a "sudo", è stato nel sistema operativo da Windows 2000 (il "tasto destro, funzionalità Esegui come"). Dirò che il controllo dell'account utente è una funzionalità stupida e non avrebbe dovuto essere incluso nel sistema operativo. Microsoft ha fatto la cosa sbagliata rendendola "più sicura" da eseguire come "amministratore" invece di renderla più difficile e dolorosa incoraggiando gli sviluppatori a lavorare sulla scrittura di software che non fa schifo (cioè richiede i diritti di "amministratore").
Evan Anderson,

2
Gli utenti di Vista nei siti dei miei clienti non vedono mai il controllo dell'account utente perché vengono eseguiti come account utente limitati. Vedrai mai UAC solo se sei in esecuzione come "Amministratore". Puoi disabilitare UAC con i criteri di gruppo, ma non dovresti mai averne bisogno.
Evan Anderson,

9

Secondo me, se i sistemi basati su Linux sono configurati abbastanza bene sono più sicuri dei sistemi Windows. Alcuni dei motivi sono:

  1. Trasparenza e numerosi e semplici strumenti di rete: ad esempio, è molto facile per l'amministratore di Linux vedere l'attuale configurazione del firewall digitando "iptables -L -n" sulla shell. Puoi anche vedere quali porte sono aperte sul computer eseguendo "nmap" da un altro computer Linux. Ciò semplifica la vita in quanto è possibile specificare con precisione quali porte sono accessibili e da quali indirizzi, ecc.

  2. File di registro di testo in una posizione: i file di registro basati su testo in una posizione "/ var / log" sono facili da eseguire il backup e l'analisi. Anche strumenti come logwatch che possono monitorare questi file di registro e inviarti per e-mail linee importanti rendono le cose molto facili. Possiamo persino scrivere i nostri strumenti per analizzare i file di registro e trovare le informazioni che ci interessano. I registri possono anche essere esportati sul server remoto syslog nel caso in cui non vogliamo che i registri siano presenti sullo stesso server.

  3. Non preoccuparti dei virus: se i virus sono meno in Linux perché ci sono meno sistemi basati su Linux O perché tutti gli utenti amano Linux o perché Linux è più sicuro. Il motivo non ha importanza. Se alla fine Linux ha meno minacce da virus, allora è una buona cosa su Linux. Ho visto personalmente persone installare due antivirus, anti-spyware e anti-adware sulla stessa macchina. Tutti questi strumenti di protezione consumano molta CPU e memoria.

  4. Supporto per molti linguaggi di programmazione: è molto facile programmare in Linux. C, C ++, Python, Perl, Java, ecc. Funzionano senza la necessità di installare alcun pacchetto aggiuntivo. (Questo nel caso in cui si installi una grande distribuzione come Fedora che arriva in DVD.) Aggiunge sicurezza poiché possiamo eseguire attività ripetitive tramite la codifica. Quindi, se si commette un errore e c'è un problema, lo sarebbe con tutti gli account e sarebbe facile da rilevare e correggere. Se dovessimo apportare manualmente le stesse modifiche a un gran numero di account / directory, potremmo commettere errori in uno o due e potrebbe richiedere molto tempo per trovare tali errori. Inoltre possiamo correggere gli errori e cercare semplici errori usando il codice. Dal momento che tutti i file di configurazione, i file delle informazioni dell'utente, i file di registro, ecc. Sono in formato testo, è molto facile codificare ciò che vogliamo ottenere e ci sono molti modi per fare le stesse cose.

  5. Codice open source: poiché probabilmente molte persone hanno visto il codice, è molto raro che alcuni spyware / adware facciano parte delle applicazioni fornite con Linux. Puoi anche vedere il codice sorgente se la sicurezza è molto importante per alcuni servizi e vedere come funziona. Se sai esattamente come funziona, allora conosci i limiti e quando si romperà. In effetti, se ci sono ben noti limiti di sicurezza che sarebbero stati documentati nelle pagine man, nel sito Web del pacchetto e nei commenti nei file di configurazione. Gli sviluppatori non hanno nulla da perdere nel dire che se si utilizza il nostro strumento in tale scenario, è rischioso. Potrebbe non essere redditizio per le organizzazioni che vendono software dire limiti per il software e renderebbe il loro software un aspetto negativo e potrebbe ridurre la vendita / profitto.

  6. Gratuito e interoperabilità: sebbene ciò non sia legato alla sicurezza. Per l'università dove i costi contano, i sistemi basati su Linux sono molto più economici dei sistemi basati su Windows e non è necessario acquistare licenze per il sistema operativo, nonché per software aggiuntivo che installeremmo dopo l'installazione del sistema operativo. Per quanto riguarda l'interoperabilità, possiamo collegarci da macchine Linux ad altri sistemi operativi e condividere facilmente i file. In Linux possiamo montare molti file system tra cui FAT, NTFS, HFSPLUS. Possiamo condividere cose usando ftp, http, ssh, samba, nfs, ecc. E tutte queste cose vengono installate o possono essere installate con un solo comando. Altri sistemi operativi generalmente forniscono solo un'opzione per condividere le cose.

Ma se non configurato correttamente i sistemi basati su Linux possono causare più problemi, allora si può immaginare. Molti utenti possono accedere alla macchina contemporaneamente e fare quasi tutto solo dalla shell. È molto facile lasciare backdoor, trojan nel caso in cui il firewall non sia configurato correttamente. L'attaccante può eliminare il file di registro o manometterli per nascondere le sue tracce. L'attaccante può codificare sulla macchina attaccata poiché tutti gli editor, i compilatori e i debugger sono prontamente disponibili quando l'attaccante ha accesso alla shell. Tutti i server ftp, http, possono essere eseguiti dall'account utente non solo su porte sicure (1-1024). Quindi l'attaccante può scaricare il codice del server http, compilarlo ed eseguire il server http sulla porta 6000 per renderlo simile a X Server.

Quindi i sistemi Linux sono più sicuri a condizione che l'amministratore sappia cosa sta facendo o almeno si preoccupa di cercare informazioni nelle pagine man e nella documentazione prima di apportare qualche nuova modifica.


6

La sicurezza del server non è solo il sistema operativo. Direi che un fattore maggiore nella sicurezza del server è la persona che esegue il server e quanto sono stati attenti a bloccare le cose.

Detto questo, se l'università è un negozio Linux, non ti permetteranno di usare un Windows Server indipendentemente dai dati che trovi sulla sicurezza del server Windows. Vorrei investigare usando Mono (www.mono-project.com) se si desidera utilizzare il framework .Net.


6

trasparenza

  • Esegui ps auxfe sai quali servizi sono in esecuzione, con quale account.
  • Esegui netstat -lnpe sai quali programmi hanno quali porte TCP si aprono.
  • Esegui iptables -Le sai quali regole ha il tuo firewall.
  • Esegui straceo lsofper ispezionare l'attivazione del processo.
  • Esegui ls -laho tree -puge conosci esattamente la proprietà e le autorizzazioni di una cartella completa.
  • I registri sono presenti /var/loge possono essere controllati con una semplice "ricerca tra i file".
  • Nessuna impostazione nascosta. Tutto è leggibile dall'uomo /etc. La ricerca tra i file di testo, l'archiviazione o l'applicazione del controllo delle versioni (subversion / git) è davvero semplice.

Sistema di autorizzazione chiaro

  • Nella base, ci sono solo autorizzazioni per i file. Nessuna "autorizzazione per le chiavi regex", autorizzazioni ACL ereditate, contesti di sicurezza per processo o altre funzionalità nascoste.
  • I bit di autorizzazione sono semplici:
    • Scrivi su file = modifica il contenuto del file
    • Scrivi su cartelle = crea / rinomina / rimuovi nodi file.
    • Sticky = modifica solo i propri file.
    • I file con autorizzazioni di esecuzione o setuid sono evidenziati (in lsmodalità colore).
  • Un semplice "trova tutti i file" rivela quali autorizzazioni ha un utente.
  • Inoltre, gli ACL possono essere utilizzati solo dove è necessario.
  • Gli account utente hanno solo due posizioni per scrivere i file per impostazione predefinita: loro $HOMEe /tmp.

Opzioni di sicurezza avanzate

  • SELinux / AppArmor può limitare i processi per accedere solo a un set specifico di file (oltre alle autorizzazioni per i file)
  • Una prigione di Chroot consente agli amministratori di eseguire il programma completamente isolato dal resto. Come se fosse installato su un hard disk vuoto, con solo i file di cui ha davvero bisogno.
  • Con sudo, agli utenti e ai processi possono essere concesse le autorizzazioni per eseguire solo alcuni comandi amministrativi.

Punti singoli per l'entrata e l'elevazione dei privilegi

  • Un processo non può ottenere più privilegi da solo. L'unico modo è eseguendo un altro programma "SetUID Root", come sudoo contattando un servizio DBus che controlla prima PolicyKit. Questi programmi SetUID possono essere trovati con un singolo comando "Cerca in tutti i file".
  • L'IPC tra i processi è piuttosto limitato, riducendo i vettori di attacco.
  • L'accesso al sistema (console di testo, desktop remoto, RPC, rimuovi invocazione comandi, ecc.) Avviene tutto ssh. Questo è un tunnel SSL con controllo della chiave pubblica / privata.

Processi in background sicuri

  • I servizi in background vengono eseguiti con privilegi inferiori il prima possibile. Servizi come Apache, Dovecot e Postfix consegnano al più presto la connessione in entrata a un processo con privilegi limitati.
  • Bloccato per impostazione predefinita. Microsoft ha adottato questo approccio anche in Windows Server 2008.

Buoni strumenti di controllo

  • Strumenti come nmap, ncatsemplificano il controllo della sicurezza.
  • I servizi in background possono essere controllati dalla riga di comando.
  • Gli strumenti di controllo dei log sono comuni.
  • La codifica di un servizio sicuro è più semplice perché può essere eseguita in modo modulare.
  • Sono disponibili numerosi strumenti gratuiti per il rilevamento delle intrusioni.
  • Gli strumenti da riga di comando sono progettati per essere scriptabili, quindi gli amministratori possono automatizzare le attività.

Buoni aggiornamenti di sicurezza

  • Ogni parte del sistema operativo riceve aggiornamenti di sicurezza. Quando Apache, Python o PHP vengono installati tramite il gestore pacchetti, riceveranno anche gli aggiornamenti.
  • C'è molta apertura in ciò che corregge un aggiornamento di sicurezza, quindi puoi capire come questo ti influenza.
  • I pacchetti software condividono tutti le stesse librerie. Non spediscono copie separate, lasciando in giro versioni sfruttabili.
  • Nessun martedì di patch, in attesa di una correzione quando gli hacker stanno già sfruttando il bug in natura.
  • È facile per gli sviluppatori testare gli aggiornamenti di sicurezza e distribuirli.
  • Nessun riavvio deve essere pianificato per eseguire un aggiornamento. I file possono essere sostituiti mentre i processi esistenti continuano ad accedere ai vecchi dati sul disco. Successivamente puoi scoprire quali servizi necessitano di un riavvio ( lsof | grep =).
  • L'intero sistema operativo può essere aggiornato senza reinstallare!

Tutto ciò che viene menzionato qui viene consegnato o ogni distribuzione Linux tradizionale, ad esempio Red Hat, Debian, openSUSE o Ubuntu.


5

Linux è stato progettato per essere un sistema multiutente sin dall'inizio, quindi ha un sistema di autorizzazioni molto più forte di Windows. È stato inoltre progettato per non essere in esecuzione con diritti amministrativi (accesso root), quindi tutti i programmi sono progettati per non richiedere i diritti. Ciò significa che se il tuo account viene compromesso, l'intero sistema non lo è.

Parte di ciò probabilmente deriva anche dal fatto che le persone che usano Linux sono (in generale) più tecniche e quindi meno propense a commettere gli stupidi errori che portano ai computer ad essere hackerati.


2
Alcune differenze tra sistemi operativi multiutente e utente singolo: jdurrett.ba.ttu.edu/courseware/opsys/os01a.htm
moshen,

7
OK, uso Linux da oltre 12 anni e sistemi operativi simili a UNIX da ancora più tempo. Per quanto mi piaccia Linux, non si può dire che abbia un sistema di autorizzazioni più forte di Windows. Ha un modello di sicurezza migliore rispetto alle prime versioni di Windows (cioè, non sempre essere admin), ma WinNT e successivamente ha un forte sistema di autorizzazioni che non è stato usato con buoni risultati. Le versioni recenti di Linux hanno selinux, che è ancora più forte, ma questa è un'aggiunta relativamente recente (se molto potente).
Eddie,

5

"La sicurezza riguarda il controllo"

Dal mio punto di vista, in Windows hai meno controllo rispetto a Linux. Indurire Windows è ... più difficile :). Sebbene qualsiasi strumento dipenda dalle capacità del proprietario, considererei quanto segue:

  • Windows presenta più vulnerabilità ad alto rischio e uno sfruttamento più automatico (virus, botnet)
  • Gli amministratori di Windows sono (o dovrebbero essere) paranoici (per paura di intrusioni) e hanno indurito
  • Gli amministratori di sistema di Linux a volte si fidano troppo della sicurezza del sistema operativo e dimenticano di rafforzarsi
  • Una volta hackerato, in un sistema Linux puoi fare di più che in un sistema Windows, poiché ci sono strumenti di comando più potenti

Quindi, anche se preferisco Linux su Windows, penso che non dovresti fidarti delle installazioni predefinite.


3

La maggior parte dei post precedenti si è concentrata sull'intrusione, e un buon lavoro è stato fatto coprendo quel punto, uno dei punti della tua domanda riguardava i virus. Il motivo principale per cui le distro Linux hanno meno problemi con i virus è che ci sono più Window box là fuori che Linux e Mac messi insieme. Gli autori di virus vogliono ottenere il massimo dal loro dollaro, quindi scrivono per Windows.

Tutti i sistemi sono capaci di intrusione e infezione. Chiunque ti dica qualcosa di diverso, che si tratti dei tuoi istruttori o di altri, o sono pazzi, hanno proprietà di fronte all'oceano nello Utah per venderti.


3

A giudicare dalle correzioni di sicurezza su TUTTO il software in questi giorni, penso che il problema non sia il software ma il numero di desktop che eseguono Windows. Questo è l'obiettivo, per creare botnet. Se Linux dovesse davvero crescere nello spazio desktop, verrà anche attaccato di più. Penso che Mac OSX lo stia già vedendo.


2

C'è una ragione molto importante per cui Linux e OpenBSD hanno il potenziale per essere più sicuri di Windows. Questa è la capacità del sistema operativo di proteggersi da attacchi di rete.

Su Windows, i pacchetti di rete in entrata sono stati esposti a parti significative del sistema operativo molto prima che un firewall di Windows potesse rifiutare il pacchetto. Su Linux, usando IPTables o su OpenBSD usando PF è possibile isolare i pacchetti non autorizzati molto prima nel processo in cui il sistema operativo riceve un nuovo pacchetto di rete, riducendo l'esposizione.

Tuttavia, una volta aperta una porta ed eseguito un servizio su di essa - vale a dire rendere utile un computer in rete - si è sicuri solo del codice che esegue quel servizio.


2

Non esiste un sistema operativo più sicuro di un altro. Tutto dipende dalla conoscenza delle persone che amministrano il sistema.

Ho incontrato e lavorato con alcuni amministratori * nix estremamente talentuosi nel corso degli anni e hanno potuto configurare un server * nix estremamente sicuro. Tuttavia, attaccali di fronte a un host Windows e non avrebbero idea di come bloccare la macchina. Allo stesso modo, conosco una discreta quantità di protezione di un host Windows, ma mi metto davanti a una * nix box e non avrei idea di cosa stavo facendo.

Nessuno dei due sistemi operativi è più o meno sicuro degli altri. Certo, potremmo parlare della storia delle piattaforme e usarla per discutere su quale sia stato più sicuro nel tempo, ma non stiamo parlando di * nix OS di 10 anni fa e della distribuzione di Windows NT 4 in ambienti di produzione, vero? . Stiamo parlando di sistemi operativi moderni (o almeno dovremmo essere) e quali possono essere meglio protetti.

Ho visto qualcuno dire qualcosa in una risposta sui pacchetti che arrivano al firewall di Windows toccando più parti del sistema operativo rispetto al firewall di Linux. Dalla domanda a lui diventa chi diavolo si fida di un firewall software in esecuzione sull'host? Ecco a cosa servono i firewall end point / front end. Per proteggere la rete. L'host che esegue un servizio ha un servizio esposto. È compito degli host garantire che tale servizio non venga compromesso. È il lavoro dei dispositivi di rete davanti a esso per impedire ad altri pacchetti di passare da Internet agli host altri servizi.

Una volta che la rete è adeguatamente protetta, tutto dipende da quanto è sicura l'applicazione in esecuzione sull'host. Quell'applicazione ha buffer overflow che possono essere sfruttati? Esistono modi all'interno dell'applicazione esposta per accedere al sistema operativo e in qualche modo ottenere un livello superiore di autorizzazioni? Altrimenti è un'applicazione ben protetta. Se ci sono, hai un problema che deve essere esposto.

Se qualcuno non prenderà in considerazione un altro sistema operativo nel proprio data center, questo è un segno di ignoranza (vale per un negozio tutto Linux, così come un negozio tutto Windows). Entrambi i sistemi operativi hanno usi lì e dovrebbero essere usati come tali. Nessuno dei due è migliore o peggiore dell'altro. (E sì, abbiamo un paio di macchine Linux nel nostro ambiente che gestiscono servizi di produzione.)


1
Differirei nell'opinione che tutto dipende dalla conoscenza degli amministratori. Se ti viene chiesto di difendere un forte dagli attacchi contro una tenda, penso che tu abbia un piccolo vantaggio con un forte. Se i due confrontati qui sono Linux e Windows, sono stati progettati con due diverse filosofie per la gestione di più utenti e l'accesso simultaneo al sistema. Mentre i buoni amministratori possono aiutare a correggere le carenze, ci sono ancora dei vantaggi l'uno rispetto all'altro come punto di partenza.
Bart Silverstrim,

1

Non è necessario maledire la tua università per l'utilizzo di server Linux, per i tuoi requisiti specifici, come diceva AdamB, usa Mono (www.mono-project.com). Solitamente professore con interesse per il sistema operativo, preferisce Linux, anche qualsiasi appassionato di sistema operativo preferirebbe Linux, per semplici curiosità su come le cose funzionino in pratica senza libri.

  • Ora per quanto riguarda la sicurezza,

Linux ora segue DAC (controllo di accesso discrezionale) è un sistema più intelligente per il controllo di accesso. Come menzionato in altre risposte, sì Linux era di ritorno multiutente, e quindi il sistema di controllo degli accessi, è migliorato rispetto ad altri.

Ma la sicurezza a cui ti riferisci assomiglia alla sicurezza del server, che non è tanto un problema del sistema operativo quanto l'intero problema della rete del server. dove intendo liste di controllo accessi firewall, router ecc ... Gli aggiornamenti sono gratuiti, per tutta la vita. è aperto e quindi testato molto, il che è molto importante.

a parte la sicurezza, la fattibilità economica rende linux la migliore opzione per i server, dove pochissimi, ma si suppone che le applicazioni possano funzionare o ospitare servizi. E queste applicazioni sono molto ben portate su di esse. Ad esempio - Apache.

Penso che non sia stata la sola sicurezza, ma altri fattori che fanno sì che la maggior parte delle altre università scelga Linux su server.


1

Mentre ci sono molte risposte fantastiche qui, voglio solo aggiungere che non esiste un sistema operativo sicuro.

È noto che se un essere umano ha creato una piattaforma "sicura", un altro essere umano può trovare buchi in quella piattaforma con il tempo.

Sono d'accordo che le prime due frasi di Evan riassumono meglio la sicurezza del sistema operativo:

Non penso che un sistema operativo sia "sicuro". Una particolare configurazione di un sistema operativo ha un particolare grado di resistenza agli attacchi.

Quindi non importa se confrontiamo GNU / Linux, i sistemi BSD (Free / Open / Net), Microsoft, Windows, Mac OSX, Symbian, PalmOS, Cisco IOS, AIX, QNX, Solaris, z / OS o uno qualsiasi dei altri "sistemi operativi" che eseguono cose come TV, lettore MP3, forno a microonde, ecc. ecc.

Ognuno di questi ha una parte del tutto che ha la capacità di essere sfruttato da un individuo determinato.

Per questo motivo la maggior parte dei fornitori dispone di white paper su come impostare i propri sistemi per garantire una configurazione quanto più sicura possibile. Ciò significa utilizzare altre tecnologie per ridurre al minimo la superficie.

per esempio:

  • NAT
  • proxy inverso
  • firewall

1
metterei i miei soldi su openbsd ogni giorno per "meno probabile che sia vulnerabile a distanza".
Kyle Hodgson,

Non metterò i miei soldi contro i tuoi neanche! A meno che non parliamo di DOS <= 4 (nessun driver NDIS prima della 5.5 credo?)
Wayne,

1

Il fatto della sicurezza del sistema operativo per quanto riguarda i framework è un po 'più di un semplice problema di tipo kernel. Ognuno dei quadri ha i propri meccanismi di sicurezza conformi. La specifica dell'account multiutente all'interno di Microsoft Windows consente un po 'più di flessibilità in termini di distribuzione di massa, tuttavia con Linux hai la possibilità di controllare fino in fondo - i dettagli di autorizzazioni e delega.

Il livello di sicurezza di .NET Framework ha principalmente a che fare con i criteri di gruppo, le impostazioni di PowerShell e console console. Il motivo è la telemetria del kernel con parametri di accesso di basso livello con richieste di accesso dinamico in memoria. I framework Linux richiedono spesso un livello di attenzione simile, ma hanno principalmente a che fare con i flag specificati durante la configurazione della lingua. Linux quando configurato correttamente è dimostrato di essere più sicuro della sicurezza configurata di Microsoft Windows. Sebbene a un livello "decente" di configurazione; gli strumenti possono passare direttamente attraverso IIS e immergersi direttamente nei servizi utilizzando un GUID specifico. Nel complesso Linux consente un maggiore controllo dell'aspetto rispetto a

Punti principali:

inodes and NTFS index primers and permissions in Windows (including registry) 
    are easier to sift through than an EXT hardnened Linux 

protocol traversal within Linux for exception handling are easier to find 
    than a solid configured Windows Firewall. 

cache indexes within ASP.NET are easier to violate than cache management    
    technologies which are well handled within GNU and C++ libraries
    they are practically built for parallel systems now. 

SQL parse queries, have been proven over and over again; MySQL is faster. 
    than MSSQL, though Oracle has been pushing the belt. Transactional 
    security is proven to be more secure on Windows, but for performance 
    and sheer flexibility shows that MySQL should be used or something 
    along the lines of a iSQL or NSQL (not SQLAB like Berkeley SQL which 
    MSSQL is based on) 

Gateway permissions, Linux has an amazing ability to fondle packets and tiny 
    little things that Windows can only put into sorting bins. This being 
    said, if you are running a Windows network, you have more network auditing 
    than a Linux network because the packages are easier to apply walls to 
    than DLL files and protocol requests. 

Surface layer GUI, .NET Framework offers strict field definitions; while Linux 
    allows intense PCRE and other Regular Expressions. 

Statures governative:

OWASP proves over and over again that it is harder to crack a hardened Linux Server 
than it is to crack a hardened Windows Server. Why? Because the firewall and Group 
Policy does not allow as far a tuned key for aspects of the closed source framework 
within ASP.NET; Linux will let you choose a color for every letter on your command. 

NIST Shows over time that SQL management permissions are harder to parse with Windows 
while Linux PCRE makes it harder to bypass SQL queries whether it be within a GUI or 
a Web Interface. 

Carnagie Mellon shows that ASP.NET can hold higher regulations because it is built 
in a more module based context which employs the use of MVC frameworks and can potentially 
have a higher restriction. Meanwhile PHP and Java show that they are incredibly robust 
with their Obfuscation and encapsulation methodologies.

Opinioni personali:

Ogni sistema operativo ha il potenziale per essere più sicuro rispetto agli altri fuori dalla scatola. Preso il confronto crudo dei framework che operano con una sicurezza superiore con Linux o Windows, dovrei dire che la parte principale della sicurezza web sta usando il framework più incompatibile ma efficiente. In questo modo diventa molto più difficile agganciarsi alle autorizzazioni di accesso al disco rigido native e agli handle della libreria. In questo modo hai una ciotola saldata in cima al tuo sistema operativo. Come Evan aveva detto con le autorizzazioni NTFS e / proc o / dev. Se usi qualcosa che non può parlarci; è più difficile da rompere.

Quello che ho imparato dallo sviluppo web è, non sottovalutare mai il tuo framework. .NET dispone delle autorizzazioni per creare volumi montati condivisi e meccanismi di controllo per i cluster di SQL Server; mentre Apache Source può fare la stessa cosa con i sistemi operativi che usano Linux. È una domanda abbastanza decente, anche se dovrei dire che Linux offre maggiore sicurezza sul controllo degli aspetti individuali e sulle restrizioni e il monitoraggio multilingue; mentre Windows ha l'ampio potere di controllo e registrazione con un'interfaccia di debug logico di alto livello. Entrambi sono comparabili, alla fine si restringe a un "quanto bene - lo chiudi a chiave" e "quante campane e fischietti ci sono?" nel quadro. Apache ha più aumenti di sicurezza del componente aggiuntivo;

Al momento, confrontando PHP su Linux o Windows, è abbastanza ovvio che ci sono più estensioni che puoi usare in un sistema operativo Linux; Windows ha un diverso livello di gestione delle autorizzazioni rispetto a PHP che rende più difficile la gestione delle directory e dell'accesso ai file. All'interno di Apache, ad esempio XAMPP, LAMPP o WAMP, ritengo che Windows sia un po 'meno sicuro, considerando il fatto che le sue restrizioni sul firewall sono più facili da violare perché condivide le stesse regole di tunneling del tuo browser web. D'altra parte Linux può usare pool di app e ulteriori meccanismi di sicurezza a livello di pacchetto che sono molto più complicati da emulare. Windows richiederebbe di utilizzare tutti gli aspetti del sistema operativo per rendere la rete più sicura.

Anche IIS (su un server Microsoft, non un client Windows) su Windows con ASP.NET con i più recenti mix SEC_ATL può essere molto sicuro.

Solo Apache, potresti volerlo eseguire con Linux per abilitare i driver di livello superiore e inferiore, i titoli SMIME, codec e pacchetti. Mentre Windows richiederebbe l'installazione di meccanismi di sicurezza sovrapposti che altrimenti intaserebbero il tuo traffico un po 'più di quanto potresti desiderare se si tratta di eseguire migliaia di server.

Con Linux, più sottile è il kernel e più ottimale per la sicurezza della rete è il migliore (come fondere Apache con NSLUG).

Con Windows preferisci programmare i moduli Powershell e sovrapporre la sicurezza adizionale per il tuo framework ASP.NET e configurare i criteri di gruppo su USGS perché il più delle volte ne ha davvero bisogno per chiudere il tipo di traffico che Linux negherà automaticamente e non penserà di.

Allo stesso modo possono essere forti. Out of the Box una distribuzione live di Linux sarà più forte di un Microsoft Windows Server non configurato appena impostato con la procedura guidata.

Nel tempo, Linux supererà Windows nel gioco della sicurezza. I server Debian 3 sono ancora più potenti di Microsoft Server 2008 R2 e indovinano cosa possono supportare le stesse tecnologie senza una ricostruzione del kernel. Debian può ancora fumarlo, e l'ho visto con i miei occhi.

Comunque, come è stato detto prima, ne sono sicuro. Dipende dal personale con cui lavori e dalla tua attenzione ai dettagli. Ciò fa sempre la differenza più grande quando si tratta di lavorare in una grande rete di server.


0

Prevalentemente, credo che Linux sia visto come una scelta più sicura a causa del suo uso onnipresente di software open source.

La facilità viene dall'idea che "la comunità" noterà se qualcosa di sospetto viene aggiunto da qualche parte (diciamo, se openSSH improvvisamente ha iniziato a telefonare a casa con le password) non rimarrebbe a lungo.

Ma non posso ripetere abbastanza ciò che altri hanno già detto: la sicurezza dipende in gran parte dalla configurazione: chi se ne frega se openSSH non sta telefonando a casa se non si dispone di un firewall, una password radice nulla e PermitRootLogin abilitati in sshd;)


0

Risposta breve: inizialmente UNIX è stato progettato per essere sicuro; Windows è stato progettato per essere semplice. Ora, i discendenti di UNIX faranno finta di essere più semplici per i loro utenti; Windows finge di essere più sicuro.

Non si sono ancora incontrati


2
Bah! Nel suo progetto iniziale Windows NT aveva pensato più alla sicurezza che a Unix. In seguito, la sicurezza di Unix è stata rafforzata come ripensamento. I moderni sistemi operativi simili a Unix (come Linux, che non è in realtà un sistema operativo "Unix" poiché è una base di codice completamente nuova) sono notevolmente migliorati rispetto a Unix originale, ma Windows NT è stato progettato, dall'inizio, per soddisfare i requisiti di sicurezza "Orange Book" del DoD statunitense.
Evan Anderson,

0

Le versioni precedenti di Windows avevano applicazioni in esecuzione nello stesso spazio degli indirizzi, quindi erano in grado di attraversare i puntatori tra loro. Facevano anche affidamento sul multitasking cooperativo e talvolta non collaboravano.

Anche le prime versioni di Linux / Unix presentavano il partizionamento tra le applicazioni e tra O / S e livello di applicazione. La suddivisione dei compiti, sebbene non sempre ideale, era almeno giusta.

Quindi l'eredità di Unix (o Linux) per sistemi più robusti che richiedono una maggiore disponibilità.

Tutto questo vale ancora oggi? Questa è un'altra domanda.


Certo che no. Gran parte della stampa negativa che Windows ottiene dalla comunità Linux è in realtà direttamente indirizzata a quelle versioni precedenti e non tiene conto del fatto che le cose sono andate avanti. L'ultima versione di Windows per utilizzare coop m / t era 3.1, e l'ultima versione di Windows che aveva il cuore pulsante DOS era ME.
Maximus Minimus,

0

Ora che NT ha raggiunto Unix in molti dei punti precedentemente carenti, le autorizzazioni per i file e la protezione della memoria non rappresentano più enormi problemi di differenziazione.

Ma .... a. Nei sistemi Unix, tutti gli accessi a tutti i dispositivi passano attraverso i file, per i quali è possibile amministrare facilmente la sicurezza. Ad esempio, sai come impedire all'utente X di accedere alla scheda audio in Windows pur consentendo all'utente Y? In Unix, questo tipo di cose è facile.

b. La struttura delle directory è molto più sana. (Ad esempio, un'applicazione utente deve solo avere accesso in scrittura alla cartella principale, ecc.) Ciò è migliorato anche in Windows negli ultimi anni.

d. Questo è un grosso problema: SELinux (e la funzione sandbox "Seatbelt" di Trusted Solaris e Mac OS). Questo è noto come NDAC (controllo di accesso non discrezionale). Se stai eseguendo una distribuzione del sistema operativo con queste funzionalità, allora ci sono essenzialmente due livelli di sicurezza contemporaneamente, il normale DAC (sistema di autorizzazioni) che Unix ha sempre avuto e le versioni moderne di Windows hanno - e per di più, il "firewall applicativo" imposto da SELinux e sistemi simili. Ad esempio, è possibile impostare un criterio che dice che il server Web Apache può scrivere su / tmp e leggere da / var / www e / etc / apache. Qualsiasi altro accesso al disco verrà negato a prescinderedi autorizzazioni. Allo stesso modo, è possibile specificare che può accettare connessioni in entrata solo sulla porta 80 e non effettuare connessioni in uscita. Quindi, anche se esiste un bug che consentirebbe a qualcuno di fare qualcosa di molto brutto, e anche se apache fosse in esecuzione come root, non avrebbe importanza: la politica lo impedirebbe. Ciò richiede una penalità di velocità (molto minore) e può essere una seccatura se si utilizza una configurazione insolita, ma nel caso normale può aumentare il livello di sicurezza di una quantità enorme sia su Unix vecchio stile che su Windows.

e. Livelli: i sistemi Unix sono composti da molti più livelli e servizi discreti che possono essere scambiati. Ciò significa che possono essere analizzati individualmente per correttezza e sicurezza, scambiati, ecc. Per quasi nessuno di questi, non è necessario riavviare. Questo è un grande vantaggio sui sistemi di tipo server. Inoltre, è più facile disabilitare (e disinstallare) le cose che non sono necessarie su un sistema Unix. Ad esempio, perché eseguire una GUI su un server Web? Aumenta la superficie di attacco e occupa RAM.

f. Per quelli che hanno detto che Windows NT è stato progettato da zero per la sicurezza ... è vero, il kernel è stato progettato dall'inizio con funzionalità avanzate di sicurezza e multiutente, ma ci sono due problemi principali: 1. Scarsa esperienza di Microsoft con sicurezza e 2. Il sistema operativo nel suo complesso è stato progettato per essere compatibile con le applicazioni legacy di Windows, il che significava molti compromessi. Unix è sempre stato multiutente, quindi le applicazioni non hanno alcuna grande sorpresa quando viene applicata la sicurezza, il che significa meno compromessi.


La protezione dell'accesso ai "file di dispositivo" in Windows NT viene eseguita tramite ACL applicati nel gestore oggetti esecutivo. Ha all'incirca lo stesso modello ACL del filesystem. Ri: il punto "a": le applicazioni con logo conformi alle linee guida per lo sviluppo di Microsoft non necessitano nemmeno dell'accesso in scrittura al di fuori della home directory dell'utente. ri: "b": sono d'accordo che ci sono funzionalità MAC limitate in Windows. I livelli di integrità, aggiunti in Vista, sono una forma di MAC. Il "firewall avanzato" (anch'esso aggiunto in Vista) può limitare il traffico in uscita nel modo in cui descrivi se scegli di configurarlo in quel modo.
Evan Anderson,

ri: "e": concordo, in linea di principio, che meno software significa meno possibilità di errore. Esistono build interne di Windows che non dispongono di una GUI, ma Microsoft ha scelto di non rilasciarle. re: "f": gli sviluppatori di terze parti sono stati più di un problema in relazione a: ottenere criteri di sicurezza predefiniti sani impostati in Windows rispetto a Microsoft. Personalmente, penso che Microsoft dovrebbe essere più severa riguardo alle applicazioni che si comportano male, ma vivono in uno "spazio" diverso rispetto agli sviluppatori di sistemi operativi liberi e open source quando si tratta di assicurarsi che le applicazioni dei loro clienti funzionino.
Evan Anderson,

ri: "Il sistema operativo nel suo insieme ... progettato per avere compatibilità ..." Win32 è un sottosistema del kernel - non è NT. Se Microsoft volesse (o permettesse a qualcun altro) di creare una "distribuzione" di Windows NT che non avesse sottosistema Win32, nessuna GUI e avviata, diciamo, con il sottosistema del kernel POSIX "Interix". Praticamente tutta l'interfaccia utente in un sistema operativo NT è basata su Win32, ma il kernel è perfettamente in grado di supportare un ambiente non Win32.
Evan Anderson,

0

Esistono diversi motivi per cui i sistemi basati su Linux sono spesso considerati più sicuri dei sistemi Windows.

Uno è l'abilità del proprietario. Se entri in Best Buy o Wal-mart (qui negli Stati Uniti) e acquisti un computer senza pensarci troppo, verrà eseguito Microsoft Windows. Ciò significa che ci sono un numero immenso di sistemi Windows gestiti da persone che non ne hanno idea. Poiché quasi nessuno compra un computer Linux per caso (almeno da quando Microsoft ha contrattaccato sui netbook), la maggior parte degli utenti Linux o sa qualcosa sui computer o ha avuto il proprio computer installato da qualcuno che lo fa. Questo vale per tutti gli ambienti in cui trovi persone che non sanno cosa stanno facendo; quelli che non eseguono Windows e quelli che eseguono vari sistemi operativi diversi.

Uno è il numero di attaccanti. Microsoft Windows è un obiettivo molto più interessante, a causa di tutte le macchine mal amministrate là fuori. Ci sono molti target Linux di alto valore, ma sono generalmente ben gestiti (insieme a molti target Windows di alto valore). Per una ragionevole approssimazione, nessuno prende di mira i computer Linux in generale.

Uno è la cultura. In qualsiasi ambiente Unix / Linux, esiste una chiara distinzione tra account root e account utente e in quasi tutti i casi le persone lavorano nei loro account utente quando non hanno bisogno di essere root. La distinzione non è, secondo la mia esperienza, così forte negli ambienti Windows, in quanto ogni utente avrà normalmente un account, con qualunque privilegio sia associato. Sono sul mio computer di lavoro ora, dove ho un account, un account amministratore. Tutto quello che faccio è fatto da un account con privilegi elevati. Quando torno a casa nella mia scatola di Linux, farò quasi tutto in un account con privilegi limitati e intensificherò quando ne avrò bisogno. Mia moglie ha dovuto discutere duramente per avere due account sul suo computer al lavoro, uno con il suo normale account di amministratore e uno con un account con privilegi limitati in modo da poter vedere se gli utenti regolari hanno i privilegi per eseguire ciò che scrive.

Uno è la compatibilità con le versioni precedenti. Mentre Unix non è nato come sistema operativo sicuro, ha ottenuto presto sicurezza. I programmi per Linux non richiedono l'esecuzione come root a meno che non eseguano effettivamente le funzioni di root. Windows, d'altra parte, esegue un gran numero di programmi che richiedono account di amministratore perché è quello su cui gli sviluppatori hanno eseguito e testato (vedi il paragrafo sopra), e quegli sviluppatori di solito non erano attenti alla sicurezza e che funzionava bene. Questo è il grosso problema che Microsoft stava cercando di risolvere con Controllo dell'account utente. Non penso che sia una soluzione particolarmente buona, ma ad essere sincero Microsoft non troverà una buona soluzione qui (non credo che abbandonare la retrocompatibilità sia una buona soluzione qui).

Ciò porta al fatto che la maggior parte dei problemi di sicurezza su vasta scala riguarderà i sistemi Microsoft, indipendentemente dal merito dei modelli di sicurezza e dalla percezione che Microsoft abbia i grandi problemi di sicurezza. In base alla euristica della disponibilità, il fatto che le persone possano pensare a più problemi di sicurezza di Microsoft distorce il loro giudizio.

Questi sono, secondo me, i motivi validi. Non ho toccato l'effettiva sicurezza del sistema operativo, dal momento che non so che una distribuzione Windows o Linux sia più vulnerabile dell'altra quando gestita da un amministratore esperto. Linux ha il vantaggio dell'open source, in quanto chiunque può trovare e correggere bug, mentre Microsoft ha istituito pratiche di sicurezza che potrebbero funzionare o meno. (Se volessi eseguire un sistema operativo davvero sicuro, sceglierei OpenBSD, un sistema operativo open source che si sforza di essere sicuro.) Entrambi i sistemi operativi hanno buoni sistemi di permessi (la mia preferenza è quella di Unix, ma altre persone ragionevoli non sono d'accordo).

Vi sono, naturalmente, cattive ragioni per considerare i sistemi operativi meno sicuri. Alcune persone hanno un sistema operativo preferito e non perdono alcuna opportunità per fare il badmouth ad altri. Ad alcune persone non piace Microsoft o Richard Stallman o altre persone o organizzazioni e denigrano i sistemi operativi associati. Alcune persone non hanno notato che Microsoft è cambiata nel corso degli anni, dal momento che non molto tempo fa a Microsoft non interessava davvero la sicurezza e Windows era davvero meno sicuro di Linux.


-1

Non c'è altra vera ragione se non l'inerzia. Ho visto molti sostenitori di Linux argomentare contro Windows (e non solo sul lato della sicurezza) che in superficie sembrano validi, ma - che quando si scava un po '- si applicano solo a Windows 3.1 o 95/98.

L'ho già detto, ma mentre Windows potrebbe avere più patch / etc, queste sono correzioni per le vulnerabilità di sicurezza che sono state identificate . E non sono quelli che sono stati riparati di cui ti devi preoccupare, vero? Non credo che essere open source sia intrinsecamente più sicuro. Rotolare le tue patch può andare bene per un utente domestico, ma un utente aziendale o amministratore vorrà sempre la Cosa Reale che è certificata per funzionare (e che è stata testata completamente) con una varietà di app e che è certificata per non rompersi il prossimo aggiornamento del kernel. Lo stesso vale per le correzioni della comunità FOSS.

Quindi, nel mio libro, è un misto di inerzia, pregiudizio ed incorporazione nella cultura UNIX ad esclusione delle alternative.


-2

I processi su Linux / Unix non possono cambiare i loro privilegi dopo che sono stati assegnati ad un utente, i processi su Windows possono cambiare i loro privilegi di utente e cambiare il loro utente durante il processo.

Questa è l'essenza del perché Windows è meno sicuro di Linux / Unix.


2
Questo è vero solo se il contesto in cui è in esecuzione il processo ha i diritti "Agisci come parte del sistema operativo" (SE_TCB PRIVILEGE). Se si avvia un processo con un contesto di sicurezza che non ha SE_TCB PRIVILEGE, il processo non può semplicemente "impersonare" in modo casuale (l'ISM per assumere un altro contesto di sicurezza) un altro utente. Se stai eseguendo un'applicazione con SE_TCB PRIVILEGE senza una buona ragione, ottieni ciò che meriti, IMO.
Evan Anderson,

Quindi la sicurezza è imposta da un "contesto" rispetto a una regola di sistema, motivo per cui Windows è meno sicuro di unix / linux.
Fire Crow,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.