![]() |
|
|
google unix.com
|
|||||||
| Forums | Registrer | Forum Regler | Links | Albums | FAQ | Members List | Kalender | Søgning | Dagens Stillinger | Mark Forums Read |
| Sikkerhed Diskuter UNIX og Linux computer-og netsikkerhed, cybersikkerhed, cyberattacks, IT-sikkerhed, CISSP, OWASP og meget mere. |
Mere UNIX og Linux Forum Emner du måske kan finde Helpful
|
||||
| Tråd | Thread Starter | Forum | Svar | Last Post |
| Åbn Cirrus Cloud Computing Forsøgsgrundlag: Federated Data Centers for Open Source Systems A | iBot | UNIX og Linux RSS Nyheder | 0 | 06-09-2009 12:30 AM |
| Caldera GPLing i 2001, gav "Open Access" for at åbne UNIX 8 Kildekode | iBot | UNIX og Linux RSS Nyheder | 0 | 03-12-2009 06:30 PM |
| Hvad er det bedste open source antispam? | mohammadmahdi | UNIX for dummyer Spørgsmål & svar | 1 | 09-29-2008 10:48 AM |
| Open Source NMS | Jawwad | IP Networking | 4 | 09-25-2007 04:20 AM |
| Open Source Is Dead, Long Live Open Patents? - InformationWeek | iBot | UNIX og Linux RSS Nyheder | 0 | 07-13-2007 03:00 PM |
![]() |
|
|
LinkBack | Thread Tools | Søg denne tråd | Rate Thread | Display Modes |
|
|
|
||||
|
pro's og con's enten måde ...
open source betyder enhver kan finde og lappe de bugs, men også alle kan finde og udnytte bugs. Jeg føler, at der ofte open source er mere sikker simpelt fordi patches normalt kommer ud hurtigere, hvis en fejl er fundet. (men det er ikke altid tilfældet.) i slutningen af dagen sikkerhed er mere om dig og dine vaner, hvad OS du bruger. ikke åbne porte du ikke behøver. ikke køre tjenester, du ikke har brug for. opbevare passwords stærk. gøre programrettelser ofte. |
|
|||||
|
Både ja og nej. På den ene side, da en masse mennesker kan tage et kig på den kilde, er det sværere at forsætligt indføre skadelig kode. På den anden side har en masse projekter, har ingen formaliseret sikkerhed test og er afhængige af software, der kontrollerer for visse mønstre i den kode, der kunne indføre mangler.
Det bedste eksempel er den OpenSSL fejl indført i Debian fordi Valgrind rapporteret uninitalized hukommelse. Den påståede "fix" reduceret den samlede tilfældighed af systemet, fordi coder og reviewere ikke se alle de implikationer. |
|
|||||
|
Jeg er enig med svarene.
Det er for simpelt at gøre en fejende generalisering "open source er mere sikkert" eller "open source er mindre sikker". Så enhver, der mener, enten erklæring, ja eller nej, er både rigtigt og forkert, fordi den erklæring er for generel og derfor meningsløs Selv udtrykket "sikkerhed" har ingen reel betydning. I diskuterer IT-sikkerhed skal du drøfte risikoen, og at drøfte risiko skal du tænke på sårbarheds-, trussels-og virkning. For eksempel, et open source system tændt og sidder i dit skab uden forbindelse til internettet kan være mere sikre, at de dyreste lukket source-systemet på internettet ![]() Med andre ord, er der sikkerhed eksperter født hvert minut, synes det, og meget få forstår, hvad de rent faktisk tager ca. Hvis du forstået sikkerhed og risikostyring, du ikke kunne besvare et sådant simpelt spørgsmål som "er open source mere eller mindre sikker?" fordi dette spørgsmål ikke har nogen sammenhæng, og netop udlåner til endeløse, meningsløse debatter med mennesker, der ikke forstår karakteren af IT-sikkerhed og risikostyring. |
|
||||
|
Jeg er enig med Neo. Jeg vil gerne have at opdele sagen i to adskilte dele, en teoretisk og en praktisk en.
Selv teoretisk kun talt sagen for lukket kilde versus open-source er fortsat kompliceret. En mulig fordel af open-source er en peer-review-proces, som kan finde sted. Men for at udnytte denne fordel denne proces har skal finde sted på alle, som på ingen måde er sikret ved noget er open source på alle. En mulig fordel af lukket source-software vil være den "sikkerhed ved uklarhed" tilgang. Erfaringerne tyder på, at dette ikke er en (varig) sikkerhedsforanstaltning på alle og i tilfælde af kompromitteret sikkerhed, der er en enkelt mulig kilde i stand til at give korrigerende tjenester, hvorimod open source-software kan ændres af alle, i teorien, som stadig efterlader en mange mulige ophavsmænd til korrektioner i praksis. Nærme sig problemet på det praktiske plan, skal det anføres, at "sikkerhed" er - ligesom "resultater" for den sags skyld - et relativt begreb og kan ikke bruges absolut. Der er en vis værdi af x du ønsker at beskytte, og der er nogle anslåede indsats y nødvendig for at overvinde din sikkerhedsforanstaltninger. Hvis x er (meget) større end y du har et sikkerhedsproblem, ellers har du ikke. At vurdere din sikkerhed status simpelthen sætte dig selv i stedet for den indbrudsalarmsystemer: vil det muligvis betale sig at overvinde dit forsvar? Handle, hvis svaret er "ja" eller i nærheden af der, ellers ikke gider. Det svarer til, hvad jeg har countlessly fortalte kontaktpersoner i møder om "indtjening": du har nogle krav, som kan måles (i sekunder, transaktioner gennemført, kilobyte, uanset), og der er et system der har til at imødekomme efterspørgslen. Det kommer ned til "gør systemet opfylder de fastsatte krav - ja / nej?" Performance er ikke "fast", men "hurtigt nok". Det samme gælder for sikkerhed: hvad du beskytte og bestræbelserne for at beskytte det skal være i forhold til og spørgsmålet ikke er "sikkert", men "sikkert nok". bakunin |
|
|||||
|
Jeg vil også gerne tilføje, at i det mindste for mig personligt, og taler i fejer almindeligheder, som jeg ikke kan lide at gøre, og jeg føler mindre sikker med "lukket kode" end "åben kode".
For mig kan jeg nemt tillid, hvad jeg kan se. Jeg kan søge åben kode lettere (og lede efter problemer) end jeg kan søge en binær eller krypteret kode gerne krypteret PHP (som jeg ikke kan søge på alle). For nylig har jeg nægtet at installere krypteret PHP på et websted for at præcise årsag. Jeg ikke stoler kode Jeg kan ikke se, og ser ingen grund til at installere krypteret PHP-kode, når jeg kan finde åbne alternativer. Som jeg nævnte før, jeg ikke normalt gerne besvare generaliseringer uden sammenhæng, så jeg er simpelthen at give min personlige mening, og det er, at I (min personlige mening) føle sig mere trygge, når jeg kan undersøge den kode, grep det, søge det, tilføje debug erklæringer osv. |
|
||||
|
Citat:
Hvis du pludselig opgradere din sikringsordninger og jeg ved, du bruger den metode ovenfor, så du netop har gjort brugerne opmærksomme på, at du nu har noget følsomt, at du ikke vil have andre til at få. På den anden side dog, hvis du altid har så-sikre et system som muligt, uanset hvad der er den dér, du ikke pludselig "ændre vaner" og gøre det indlysende, du forsøger at skjule noget, andre derefter alt. |
![]() |
| Bogmærker |
| Thread Tools | Søg denne tråd |
| Display Modes | Bedøm denne tråd |
|
|