Gå til hovedindhold
Version2 it for professionelle
Forsiden

Hovedmenu

  • It-nyheder
  • Blogs
  • It-job
  • It-firmaer
  • Emner
  • Opret bruger
  • Log ind
Se kommentarer (17)
Emner Sikkerhedshuller, Hacking

Security by obscurity virker

Af Peter Makholm 4. november 2008 kl. 10:05

Det er lidt blevet et skældsord, men security by obscurity virker og udgør et godt element i sikringen af et system. I forbindelse med at jeg har flyttet alle mine services, har jeg for eksempel sat ssh til at lytte på en tilfældig høj port.

Med et er jeg blevet fri for en mængde login-forsøg med tilfældige brugernavne og kodeord mod min ssh-server og alvorligere forsøg rettet mere direkte mod min server vil fremstå mere tydeligt i mine log-filer når de kommer. Begge dele er der dog også taget højde for i en iøvrigt fornuftig opsætning af OpenSSH.

Men den egentligt øgede sikkerhed vil jeg få i tilfælde af at der bliver opdaget et sikkerhedshul i OpenSSH, som min opsætning ikke tager højde for. Der skal en noget større indsats til for at finde en lyttende ssh-server på en tilfældig port end en der lytter på standardporten.

Andre obscurity-relaterede tiltag jeg bruger er services der kun er tilgængelige udefra via IPv6, ikke-indlysende urler når jeg skal distribuerer filer til lukkede kredse af bekendte og jeg har absolut også planer om at skulle flytte administrationsgrænsefladen til min private blog.

Security by obscurity bør ikke være eneste beskyttelse, men som del af en beskyttelse i dybden sorterer det mange af de tilfældige drive-by angreb væk og dermed øger de min sikkerhed.

Send Tweet
Udskriv
Billede af Peter MakholmOm Peter Makholm

Kommentarer (17)

Opret en konto eller log ind for at følge indhold på Version2 - og bliv opdateret via e-mail eller rss

Følg kommentarer
Kristian Larsen 4. nov. 2008 - 10.30
 
random port

Hej,

Hvordan fungerer det med port randomisering på SSH?
Kan du evt. linke til en artikel om opsætning og brugen af dette?

Hvad med mit forslag om port knocking, har du kigget på det? Det vil vel i princippet gøre det samme, selv hvis du brugte standard porten eller har jeg misset noget?

  • Stem op 0
  • Stem ned 0
  • Log ind eller opret en konto for at skrive kommentarer
Søren Schrøder 4. nov. 2008 - 10.31
 
direkte vildledende obscurity er endnu bedre

jeg er helt enig i dine betragtninger, men er gået et step videre, så min sshd lytter på port 443 (https) istedet for 22. På den måde vildledes driveby-hackeren til at sende https exploits imod min sshd.

Det har ydermere den fordel, at jeg kan nå min sshd selv om jeg er bag tåbeligt opsatte firewalls der kun tillader at benytte få udvalgte porte, hvoraf https ofte er er iblandt.

Obscurity fritager dog ikke for softwareopdateringer mv.

  • Stem op 0
  • Stem ned 0
  • Log ind eller opret en konto for at skrive kommentarer
Troels Liebe Bentsen 4. nov. 2008 - 10.50
 
Men det er sku stadigt dumt

Hvorfor spilde sin tid på at lave non-standard løsninger for et par ligegyldige login forsøg. Med samme logik kunne du jo "beskytte" http og alle andre services ved at flytte dem til en tilfældig port, men på et eller andet tidspunkt bliver det nok svært at hold styr på hvad der er hvor. Med andre ord er det virkeligt overheaded værd ved at skulle huske hvilken port det nu var man kørte sin SSH på, for noget så ligegyldigt som et login forsøg.

Og hvad hvis det ikke er en server man bruger så tit kan du også huske hvad porten er om 1 år?

Problemet med "Security by obscurity" er at det spilder tid og både for den der angriber, men også for dig selv og de mennesker du skal samarbejde med. Og jo mere man gør det jo svære bliver det at holde styr på alle de obskure løsninger.

Så når man laver sådan noget, syntes jeg man burde overveje og det er værd at spilde sin egen og andres tid på noget obscurity som kun giver minimal sikkerhed.

Så kunne vi ikke snakke rigtig sikkerhed i stedet for lappeløsninger mod script-kiddie angreb. For en hurtig nmap kan hurtigt fortælle hvor de forskellige service køre anyway.

Du kunne fx. starte med at slå password login fra hvis du da kunne nøjes med public-key auth. Men kunne lave en form for Challenge Response auth. Ellers ville en firewall regel der afgrænsede sig til de steder du normalt bruger ssh også være en god løsning. Og sidst men ikke mindste findes der op til flere løsninger der kan tail'e din log og tilføje en firewall regel efter x antal forfejlede login forsøg.

  • Stem op 0
  • Stem ned 0
  • Log ind eller opret en konto for at skrive kommentarer
Hans-Kristian Bjerregaard 4. nov. 2008 - 11.23
 
Re: Men det er sku stadigt dumt

Jeg kan kun sige at jeg er meget uenig med dig Troels. Security by obscurity er smart. Men kan ikke stå alene.

Security by obscurity er nøjagtigt det samme princip som når gamle midelalderbyer havde voldgrave omkring sig. En voldgrav alene yder nærmest ingen beskyttelse mod byen men har man en voldgrav foran en solid bymur så udgør voldgraven en alvorlig gene mod fjenden.

Og det er lige præcis det security by obscurity er godt til: at genere og sænke eventuelt indtrængene!
Ved at omdøbe porte, lave delays ved fejl-login og andre sjove ting, sænker man indtrængeren. Dette gør at kun folk der serriøst gerne vil ind på dit system gider at bruge de ekstra krævfeter det tager. Og de møder jo under alle omstændigheder alle de andre serriøse sikkerheds tiltag.

Noget andet er at man f.eks. kan banne alle IPer der forsøger at tilgå port 22. På den måde er de dømt ude før de prøver at scanne efter din rigtige ssh port og så bliver security by obscurity lige pludseligt et rigtigt kraftigt sikkerhedsværktøj.

  • Stem op 0
  • Stem ned 0
  • Log ind eller opret en konto for at skrive kommentarer
Christian E. Lysel 4. nov. 2008 - 11.36
 
Re: Men det er sku stadigt dumt

Hejsa Hans-kristian

Hvordan kan du være uening i Troels forslag med at bruge public-key auth, eller en positiv IP liste over hvem der må tilgå SSH?

Dine forslag, rejser følgende to utilsigtet "fejl", der kan udnyttes af en angriber:

1) Delays ved fejl-login kan forhindre du kan logge på under et angreb.

2) En angriber kan sort liste din IP ved at spoofe en pakke fra din IP til port 22.

  • Stem op 0
  • Stem ned 0
  • Log ind eller opret en konto for at skrive kommentarer
Brian Rasmussen 4. nov. 2008 - 11.46
 
Virker og virker ...

At flytte SSH til en anden port giver dig muligvis færre tilfældige login-forsøg, men som du selv er inde på, er de i værste fald blot til irritation. Ergo er du ikke hverken mere eller mindre i fare, men du har sikkert færre beskeder i din log.

Et dedikeret forsøg på at angribe din maskine vil opdage den "skjulte" port, og så vil du være nøjagtig ligeså sårbar / sikker som ellers.

Obscurity er vel i bedste fald et mindre bump på vejen, men det er på ingen måde en seriøs sikkerhedsmekanisme i sig selv.

  • Stem op 0
  • Stem ned 0
  • Log ind eller opret en konto for at skrive kommentarer
Hans-Kristian Bjerregaard 4. nov. 2008 - 11.54
 
Re: Men det er sku stadigt dumt

Jeg er også kun uenig med ham i spørgsmålet om security by obscurity er godt eller skridt. Og mit argument for at det er godt er jo at ved ikke at lave standart ting kræver det at eventuelle indtrængere gør noget ekstra arbejde.

Og ja, der er massere ting i mit forslag der kan gå galt men det er jo også bare en ide til hvordan man kunne arbejde med at løfte security by obscurity op på et højere niveau og ikke en færdig løsning.

Implementerer man det i virkeligheden skal man jo tage højde for en masse ting der er individuelle fra system til system. F.eks. ville jeg ikke have noget problem med at lukke al remote adgang til en server ned (bortset fra de porte hvor serverens service kørte igennem), fordi vi i den virksomhed hvor jeg arbejder, hurtigt kan få fysisk adgang til vores servere. Men den løsning ville jo selvfølgelig være ubruglig for andre virksomheder der ikke har samme adgang til deres servere.

Så selve ideen om security by obscurity er jo fin (og det er min ide sådan set også) hvis man bare tænker sig om og sikrer sig når man sætter det op.

  • Stem op 0
  • Stem ned 0
  • Log ind eller opret en konto for at skrive kommentarer
Hans-Kristian Bjerregaard 4. nov. 2008 - 11.57
 
Re: Virker og virker ...

Rigtigt. Men hvis du f.eks. aldrig bruger port 22 og nogle forsøget at tilgå den så ved du jo at der er noget galt. Så det er jo et glimrende første skridt på at kende ven fra fjende.

  • Stem op 0
  • Stem ned 0
  • Log ind eller opret en konto for at skrive kommentarer
Martin Falck-Hansen 4. nov. 2008 - 12.27
 
der er jo forudsætninger som gør det smart

Hvis det nu var en server der skulle anvendes af mange mennesker (f.eks. i en større organisation) så bliver det et problem at flytte porten fordi alle så skal være klar over en anderledes opsætning.

Det er vel et spørgsmål om at balancere mellem et standard system som er nemt at finde rundt i og hvor nemt det er at administrere. Du kan jo også omdøbe alle kommandoerne i linux til noget andet end standarden - men det gør det svært at bruge f.eks. standard installtionsscripts.

  • Stem op 0
  • Stem ned 0
  • Log ind eller opret en konto for at skrive kommentarer
Anonym (ikke efterprøvet) 4. nov. 2008 - 12.38
 
Hvorfor kalder du det obscurity?

Som du selv skriver må det ikke være istedet for en bagvedliggende sikkerhedsløsning for at etablere valid authentikering til at åbne.

At gøre det sværere for en angriber at adressere et mål er en fuldt legitim forsvarsmekanisme. Det er jo blot en variant af pseudonymisering.

Hvis f.eks. angriberen ikke kan se forskel på en stealth port og en port som blot ikke svarer uden en valid authentikering, har du forebygget mange automatiserede angreb, der gradvist zoomer ind på svaghederne.

Det er fuldt legtitime at opretholde forsvarets ressourcemæssige balance relativt til en angriber som vælger mål, tid og sted for angrebet.

Man kan sagtens forestille sig en sikkerhedsmekanisme som bygger på at man - f.eks. afhængig af en tidsparameter som salt og fælles secrets - skal pinge porte i en bestemt rækkefølge for at åbne en helt syvende port. Det bygger på præcis de samme principper som megen anden kryptografi selvom kommunkationsformen mildt sagt er uortodoks.

  • Stem op 0
  • Stem ned 0
  • Log ind eller opret en konto for at skrive kommentarer
Jarnis Bertelsen 4. nov. 2008 - 12.48
 
Sikkerhed vs. brugervenlighed

Vil sikkerhed ikke altid være på bekostning af brugervenlighed i en eller anden grad?

Hvis du skulle sikre dit hus 100% mod indbrud kan du jo fx. mure alle døre og vinduer til, hvilket godt nok ville gøre huset ubrugeligt. Hvis det skulle være så nemt så muligt for dig selv at komme ind kunne du jo lade døren stå på vid gab.

For de fleste vil en middelvej nok være den rigtige løsning, men det må altid afvejes, hvor meget sikkerhed, der er ulejligheden værd.

  • Stem op 0
  • Stem ned 0
  • Log ind eller opret en konto for at skrive kommentarer
Jens Pedersen 4. nov. 2008 - 13.08
 
Security by obscurity...

At kalde det for security by obscurity er nok en vildledning. Man skulle i stedet kalde det for easiness by obscurity men det er nok lidt selvmodsigende hvilket nok forklarer hvorfor så mange er imod metoden.

HVIS man opnår en forbedret sikkerhed ved at ændre SSH fra port 22 til port x, så bør man nok overveje om der ikke er noget helt galt med ens sikkerhedssystem.

Argumentet med ”jeg kan bedre overskue serøse angreb” holder ikke. Et sikkerhedssystem der er baseret på menneskelig overvågning er ikke holdbart.

En mere elegant metode er nok at begrænse antal forsøg på indbrug fra en given IP/iprange til x antal gange i en bestemt periode... 5 fejlslagne forsøg på indbrud fra en given IP inden for en halv time betyder at man er bannet i et døgn eller lignende.

Så slipper man stadig for at BOT-angreb fylder ens logfiler og man får stadig en indikation af at det er sket samtidigt med at man overholder standarderne, hvilket igen gør livet nemmere for en selv...

Dermed er ikke sagt at man ikke kan løse visse problemer med obscurity, det er en simpel metode og det kan måske være bedre end at man slet ikke gør noget...

  • Stem op 0
  • Stem ned 0
  • Log ind eller opret en konto for at skrive kommentarer
Anonym (ikke efterprøvet) 4. nov. 2008 - 13.13
 
Re: Sikkerhed vs. brugervenlighed
Vil sikkerhed ikke altid være på bekostning af brugervenlighed i en eller anden grad?

Absolut ikke - det er en kæmpe misforståelse.
Tværtimod virker sikkerhed ikke, hvis det ikke er brugervenligt.

Og brugervenlighed er farlig, hvis det ikke er sikkert.

F.eks. har jeg laddet mig fortælle at over 40% af alle adgange til elektroniske patientjournaler i Norge sker via Emergency Override.

God sikkerhed tager altud udgangspunkt i BRUGERENs forståelse af situationen og hjælper med at syngliggøre de nødvedige beslutinger med mindst mulig forstyrrelse og maksimum brugerkontrol.

Det er f.eks. desideret farligt at bruge trådløse adgangskort som adgnagskontrol. Det er nemt og autoamtisk, men et blødende sikkerhedssår fordi en angriber kan "låne" signalet og stjæle identiteten uset og uopdaget via et såkaldt "mafia fraud" eller "relay" attack.

Men kontekstuel sikkerhed kræver at man designer sikkerhed ind i proceserne og systemerne på nederstre niveau - man kan ikke bygge sikkerhed udenpå som naiv adgangskontrol til systemer uden andensikkerhed end perimetersikkerheden.

Angriberne kommer indenfor dørene og serverne - og hvad så?

  • Stem op 0
  • Stem ned 0
  • Log ind eller opret en konto for at skrive kommentarer
Henrik Kramshøjs billede
Henrik Kramshøj 4. nov. 2008 - 14.48
 
SSH port

Man kan altså fint skrive de specielle porte ind i sin SSH konfiguration, ~/.ssh/config på Unix, eller en profil på Putty.

Det er ikke svært eller mere besværligt. Dog skal man naturligvis stadig opdatere sin software og konfigurere den sikkert.

Jeg har lagt mit eget forslag til god OpenSSH config ud på:
http://www.kramse.dk/projects/unix/opensshtemplate_en.html

Ved at bruge en ikke standard port får man også mulighed for at reagere på port scan og andre hændelser. Dettte skyldes at en angriber SKAL stikke hovedet mere ud af busken, lave portscan, for at finde den ikke standard port.

Så jo, security by obscurity sammen med god sikkerhed er perfekt.

og btw, det der med "lidt færre loginforsøg" - prøv at starte en OpenSSH server, der er MANGE loginforsøg, fordi botter står og tæsker løs på porten.

Det eneste sted hvor jeg mener det er relevant med port 22 til SSH er når man har en stor brugergruppe, eksempelvis synes jeg det er OK at DIKU bruger SSH på port 22.

  • Stem op 0
  • Stem ned 0
  • Log ind eller opret en konto for at skrive kommentarer
Brian Rasmussen 4. nov. 2008 - 15.18
 
Re: SSH port

Ja ja da, så er "lidt færre" måske nok en underdrivelse, men hvis du ikke reagerer på, at folk banker på, så er det vel mindre væsentlig, om der er mange eller få. Jeg kører SSH, og jeg har flyttet den til 443, men det er nu mere af hensyn til diverse firewalls på vejen.

  • Stem op 0
  • Stem ned 0
  • Log ind eller opret en konto for at skrive kommentarer
Michael Nielsen 4. nov. 2008 - 16.54
 
Re: SSH port

Det er ikke sikkerhed, i snakker her, det eneste i formår ved at flytte ssh porten, er at de "script kiddies" derude som prøver at bryde ind via preskrevet scripts rammer den forkerte port, og derved undgår man noget gene. Altså i beskytter jer mod dem, der end ikke er kløgtige nok til at finde den korrekte angrebsport.

Men ordenlige passwords, ordenling sikkerhed er mere vigtig, da når/hvis en professionel hacker kommer tilstede, så virker dette ploy ikke, og de kommer igennem hvis sikkerheden på systemet ikke er i orden.

Hvis man tror security by obscurity virker så fortjener man indbrud.

Det eneste nytte sådan en mekanisme giver, er at reducere antallet af ukløgtige angreb - angreb som alligevel ikke ville bryde gennem en ordenlig sikkerhed, altså det eneste det formår er at reducere størrelsen af din logfil..

Men når man så har anerkendt dette er formålet, så er det et nyttigt værktøj som jeg også benytter, da jeg har flyttet min ssh port. Ikke fordi jeg tror det forbedre min sikkerhed, men så jeg nemmere kan se de rigtige angreb, fordi min log fil ikke er fuld af ukløgtige angreb - plejede at se 4-10 bølger af 1000+ forsøg om dagen.

For alt i verden må man ikke tage fejl af et værktøj for at reducere logfil støj, og et værktøj for sikkerhed.

  • Stem op 0
  • Stem ned 0
  • Log ind eller opret en konto for at skrive kommentarer
Troels Liebe Bentsen 4. nov. 2008 - 17.51
 
Re: SSH port

Jo man kan sagtens tilføje særlige konfiguration til sine config filer, men det er sku besværligt at man skal lave speciel opsætning for hver eneste server man har adgang til. Og specielt i betragtning af at dit SSH konfiguration eksempel slet ikke tillader password login. Så i det tilfælde vil jeg påstå at problemet mere handler om log filtering. Det er jo ikke som om jeg også flytte min port 80 fordi der er nogen der prøver at uploaded et IIS exploit til min apache server.

Jeg kan godt se at det som sikkerheds gut er fantastisk at man kan få angriber mere ud af busken og lave "bedre" beskyttelse, fx. med port scan triggers.

Men som system administrator og netværks gut så er det eneste jeg ser timevis af spildt debugging når skridtet overreagere eller ikke virke efter hensigten.

Og et helt andet problem med "custom" porte numre er som nævnt fascistiske firewall regler for udgående trafik som mange virksomheder desvære har fået indført. Igen hul i hovedet da det bare har resulteret i at de fleste køre deres ting over port 443, også bot nettene.

Hvis folk bare brugte deres tid på at opdatere deres software, segmentere deres net ordentligt og sørge for at der var styr på konfigurationen i stedet for at kaste penge efter firewall bureaukrati og obscurity så tror jeg generelt vi ville få mere sikkerhed for pengene.

  • Stem op 0
  • Stem ned 0
  • Log ind eller opret en konto for at skrive kommentarer

Tilføj kommentar

Opret en konto eller log ind for at følge indhold på Version2 - og bliv opdateret via e-mail eller rss

Følg kommentarer
Log ind herunder eller opret en bruger for at skrive kommentarer
Du kan logge ind med din e-mail-adresse
Der er forskel på store og små bogstaver i adgangskoden.
Glemt adgangskode?

Seneste nyt

It skal spare kommunerne for 165 millioner kroner i 2012

Udgivet 9. feb 16.02Opdateret 9. feb 16.02

Adobe: Vi laver ikke Flash til Android-udgaven af Chrome

Udgivet 9. feb 15.15Opdateret 9. feb 15.15

Så oldnordisk er politiets it-miljø: Nostalgisk gensyn med 1980’erne

Udgivet 9. feb 14.22Opdateret 9. feb 15.12

EMC lægger flash-cache på PCIe-kort: 4.000 gange hurtigere end harddiske

Udgivet 9. feb 13.39Opdateret 9. feb 13.39

Egedal Kommune sparer 100.000 om året med open source-CMS

Udgivet 9. feb 12.56Opdateret 9. feb 12.56
Flere it-nyheder »
Få it-nyheder og blogs hver dag med Version2's nyhedsbrev.

Seneste debat

  1. Opdateret liste over danske iværksættere

    2 comments.
    Last update 2 timer 10 minutter
    Skrevet af Therese Hansen
  2. Stop SOPA, PIPA, ACTA, TPP og alle dem der kommer efter

    50 comments.
    Last update 6 timer 31 minutter
    Skrevet af Bjarne W. B. Petersen
  3. Derfor bliver dårlige it-projekter ikke stoppet i tide

    1 comment.
    Last update 6 timer 55 minutter
    Skrevet af Kasper Jørgensen
  4. Grotesk jobinterview i 2007: »Tag ikke jobbet, vi får alligevel aldrig Polsag til at virke«

    17 comments.
    Last update 7 timer 3 minutter
    Skrevet af Claus Waldersdorff Knudsen
  5. Så oldnordisk er politiets it-miljø: Nostalgisk gensyn med 1980’erne

    6 comments.
    Last update 7 timer 5 minutter
    Skrevet af Simon Justesen
  6. Domæne-forening: Lov om .aarhus og .cph var for tynd

    9 comments.
    Last update 7 timer 56 minutter
    Skrevet af Jarle Knudsen
  7. ACTA er i orden!

    51 comments.
    Last update 10 timer 29 minutter
    Skrevet af Jarle Knudsen
  8. It-advokat: Nu går grænsebommene ned over internettet

    10 comments.
    Last update 12 timer 15 minutter
    Skrevet af Niels Elgaard Larsen
Mere debat »

Information

  • Kontakt redaktionen
  • Job- og annoncesalg
  • Teknisk support
  • Om Version2
  • Brugerbetingelser
  • Privatlivspolitik

Aktuelle emner

  • Agil udvikling
  • Android
  • Bruttolønsordning
  • Business Intelligence
  • Cloud computing
  • Digitaliseringsstyrelsen
  • HTML5
  • Harddisk-priser
  • IE9
  • Intranet
  • It-sikkerhed
  • Kindle Fire
  • Multimedieskat
  • NemID
  • OS X Lion
  • Open source CMS
  • Projektledelse
  • Scrum
  • Sharepoint intranet
  • Storage
  • Ubuntu 11.10
  • Virtualisering
  • Windows 8
  • Windows Phone 7
  • iOS 5
  • iPhone 4S

Tjenester

  • Android-app
  • iPhone-app
  • RSS-feeds
Følg @version2dk
Få it-nyheder og blogs hver dag med Version2's nyhedsbrev.

Version2 udgives af

  • Mediehuset Ingeniøren A/S work Skelbækgade 4 1717 København V
  • Tlf. work 33265300