Security by obscurity virker

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.

Kommentarer (17)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Kristian Larsen

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?

  • 0
  • 0
Søren Schrøder

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.

  • 0
  • 0
Troels Liebe Bentsen

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.

  • 0
  • 0
Hans-Kristian Bjerregaard

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.

  • 0
  • 0
Christian E. Lysel

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.

  • 0
  • 0
Brian Rasmussen

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.

  • 0
  • 0
Hans-Kristian Bjerregaard

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.

  • 0
  • 0
Martin Falck-Hansen

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.

  • 0
  • 0
Anonym

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.

  • 0
  • 0
Jarnis Bertelsen

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.

  • 0
  • 0
Jens Pedersen

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...

  • 0
  • 0
Anonym

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å?

  • 0
  • 0
Henrik Kramshøj Blogger

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.

  • 1
  • 0
Brian Rasmussen

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.

  • 0
  • 0
Michael Nielsen

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.

  • 0
  • 0
Troels Liebe Bentsen

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.

  • 0
  • 0
Log ind eller Opret konto for at kommentere