Alvorlig hull i Debian

[radivx]

Det står også i ssh config fila at man burde bytte fra port 22 til en annen, da dette ikke er en trygg port. Gjelder dette bare port 22 da som det står i artikkelen? Tror de fleste oppegående it admins bytter denne porten med en gang før de startet opp ssh serveren.

 

Ser ikke hva som er så oppegeående med å bytte vekk standard port. Mulig en løsning på en hjemmemaskin bak et NAT eller noe slikt, men på servere som folk faktisk bruker er dette bare et irritasjonsmoment. Tenk om man skulle flytte webserveren vekk fra port 80?

 

Er jo stort sett mulig å finne ut hvilke porter en boks lytter på uansett.

Endret 16. mai 2008 av radivx

[Canute]

Oppdatert: En oppdatering skal allerede være klar, som tetter dette hullet.

Tja, det tetter jo ikke akkuratt hullet, det bare gjør slikt at det ikke kommer et nytt hull . Tingen er jo at den lager krypteringsnøkler, når man da allerede har laget en/flere, så er jo den allerede utnyttbar. Man må derfor lage disse nøklene på nytt.

[pcp160]

Syns blandt annet omaha har sagt mye bra i denne saken, så jeg avstår fra å kommentere selve tabben noe videre.

Men har jo noe spørsmål i forbindelse med dette hvis noen føler seg kallet til å svare her.

Bolson Lagt til I går, 15:16

Som sagt ovenfor, det er helt korrekt at det har vært skikkelig med angrep på Debianbaserte servere de siste dagene, tror jeg på tirsdag kveld hadde over 20 000 forsøk og ikke få på onsdag heller. Så langt jeg kan lese av logger/overvåkningen ble alle blokkert.

Jeg har som regel ikke port 22 åpen, men hadde det en times tid i dag, og ser da av /var/log/auth.log at det har vært rundt 500 forsøk på innlogging over ca 20 minutter.

Spørsmålet blir:

1. Er det noen smarte triks for å enkelt kunne se om noen av forsøkene har vært vellykket, feks en logg av hvem som faktisk har vært innlogget?

 

2. Er dette altså en oppdatering av ssh (altså pakken: secure shell client and server (metapackage)) slik at den pakken er endret for de som installerer idag, eller er det ikke så enkelt?

 

Grunnen til at jeg spør om dette siste er at jeg jo for en stor del lærer Linux ved å ødelegge det, (noe jeg forøvrig er ganske god til ) og for å gjøre en lang historie kort hadde jeg ssh installert og i bruk sammen med Nomachine. Maskinen ble oppdatert og en test med vulnkey -a viste at jeg hadde noen skumle nøkler. Men etter, og uavhengig av dette fikk jeg lyst å starte med blanke ark, så avinstallerte/slettet ssh (og NX pakkene) med config filer og det hele.

Har installert disse pakkene på nytt nå og det fungerer utmerket, men siden ny test med vulnkey ikke kunne si om nøkler nå var trygge fant jeg ut at blacklist dsa og blacklist rsa etter mine herjinger ikke lenger var i mappen /etc/ssh. Så jeg kopierte bare de fra en litt mindre besudlet Linux maskin, og la de i mappen. Vulnkey sier nå at nøklene er "ikke svartelistet".

 

3. Jeg antar det er greit hos meg nå, men hvordan kan man i (K)Ubuntu se hvilke oppdateringer man faktisk har installert, og eventuelt fjerne eller reinstallere oppdateringer?

[Sokkalf™]

@pcp160

Du kan se de sist innloggede brukerene med kommandoen "last" i terminalen.

[pcp160]

Takk Sokkalf^, det var jo herlig enkelt. Ut fra manualen ser det ut som last -i gjør det veldig lett å se en ip som ikke er meg selv

[meastp]

Det er vel blitt påpekt tidligere, men det er altså ikke nødvendigvis nok å bare oppdatere pakken.

 

Fra Daniel Stones blogg

A quick FAQ: the reason all DSA keys have been removed from fd.o and we aren't accepting any new ones is that they are vulnerable to man-in-the-middle attacks if they have ever been used (not just generated) on a system with a predictable RNG: see Steinar's summary of the maths. We're going with precedent of debian.org rejecting DSA keys, and a general desire to be safe rather than sorry. RSA keys are the default in OpenSSH anyway, so I'm not really sure why you'd want to generate DSA.

[Bolson]

@pcp160:

 

I tillegg er loginlog i var\log en grei fil å sjekke, eventuelt å sette opp cron til å sende deg en daglig log på mail. Da får man oversikt over mye og kan følge med en server litt mer enkelt. En av mine servere, Debian er jeg neppe inne i shell mer enn 1 gang pr uke, og da er log på mail greitt for å holde litt oversikt.

 

Her er to av mine fra tirsdag kveld:

reverse mapping checking getaddrinfo for customer-reverse-entry.216.93.170.164 failed - POSSIBLE BREAK-IN ATTEMPT! : 1412 time(s)

reverse mapping checking getaddrinfo for myserver.makingthemoneyonline.com failed - POSSIBLE BREAK-IN ATTEMPT! : 11553 time(s)

 

Edit: Det er også noe jeg etterhvert setter pris på når det gjelder Linux, hvor enkelt det er med ulike kommandoer og logfiler å sjekke nøkkelstatus på systemet.

 

Når det gjelder NX-server er det faktisk ikke krise selv om autentiseringen på den skulle være noe kompromittert. Rett og slett fordi den bruker en form for dobbelt sikkerhet, uten at jeg kjenner alle detaljer. Men prinsippet går på at den logger seg inn via ssh som brukeren nx. Dette er en bruker med svært begrensa rettigheter. Deretter oppretter den en kryptert forbindelse i "tunnel", der man logger seg på som vanlig bruker. Vet at NoMachine har vært veldig fokusert på sikkerhet, i og med at de markedsfører seg mot en del sikkerhetsbevisste kunder. Faktisk vil jeg tro at f.eks det å kjøre bare terminal gjennom NX er sikrere enn terminal gjennom SSH.

Endret 17. mai 2008 av Bolson

[Prognatus]

I tillegg er loginlog i var\log en grei fil å sjekke

Jeg fant ikke denne filen her hos meg. Har en som heter auth.log, kan det være den?

Jeg kjører Ubuntu 7.10.

[Bolson]

I tillegg er loginlog i var\log en grei fil å sjekke

Jeg fant ikke denne filen her hos meg. Har en som heter auth.log, kan det være den?

Jeg kjører Ubuntu 7.10.

 

Merkelig, nå har jeg ikke sjekket på den bærbare med Ubuntu, bare på Debian serveren min. Men du vil finne de samme opplysningenen i auth.log (den logger også noe mer en loginlog. Den forteller egentlig om alle operasjoner som krever authentisering, også CRON, gnone-keyring. sudo, useradd, sshd med mer. Så den er virkelig god til å følge litt med på hva som skjer.

 

På Fedora heter visst loggen secure.

[pcp160]

Takk for godt svar Bolson.

Jeg ser heller ikke at jeg har noe som heter secure eller loginlog i min Var mappe, men loggen auth.log som Prognatus nevner var den jeg selv hadde sett på, og så at det var 500 forsøk på innlogging via ssh, noen innlegg tilbake i tråden. "Problemet" med den var at det var litt for mye info, og vanskelig å sile misslykkede forsøk, fra faktiske inlogginger/innbrudd. Sånn sett var tipset fra Sokkalf^ ganske fint, og et skritt i riktig retning.

 

Men kom til å tenke på at grunnen til at jeg gikk å så på akkurat auth.log til tross for mine begrensede kunnskaper, var at jeg så i config filen til sshd at logging pekte til auth. Er det da også slik at jeg kan opprette min egen log "sshd22.log" også i sshd.conf si at logging skal skrives dit, og på den måten bare se ssh hendelser uten all annen info?

 

I så fall kunne jeg jo bla litt i manualen til ssh, og se hva de forskjellige "loglevel" betyr (står "info" som standard) og med litt flaks kanskje få en logg som bare loggfører ssh innlogging?

He he vel, som du sier Bolson så er jeg sikkert ganske trygg med NX greiene mine. Er igrunn ikke bekymret, og ikke har jeg akkurat statshemmeligheter på maskinen heller, men det er jo greit å ha litt oversikt. Og for en gammel Windowsmann er det litt gøy med config-filer også, i alle fall når man får de til å gjøre det man vil...

Endret 17. mai 2008 av pcp160

[jorgis]

Jeg anbefaler sterkt å installere DenyHosts om du kjører en maskin med ssh-tilgang fra internett. Om noen forsøker å logge seg inn med et ugyldig brukernavn (brukernavn-bruteforce), feil passord el.l. nok ganger, vil DenyHosts legge IPen (og evt. hostname) inn i /etc/hosts.deny, sånn at eventuelle flere innbruddsforsøk blir sperret før en får opprettet tilkoblingen. Etter å hatt en Ubuntu-maskin åpen mot internett på port 22 og 80, har jeg nå litt over 600 unike IP-adresser (mesteparten fra Asia (korea og taiwan)) i min /etc/hosts.deny...

[Sokkalf™]

Støtter anbefalingen av DenyHosts. Ikke bare gjør den bruteforce-angrep håpløse, men den reduserer "støyen" i loggene kraftig også.

[Bolson]

@pcp160: Ja, du skal kunne kan logge sshd til en egendefinert loggfil og sette nivå for hva som skal vises. Men husker jeg ikke feil, er angivelsen av hvor loggen er oppgitt som følger.

 

# Logging
SyslogFacility AUTH
LogLevel INFO

 

Det betyr at det er syslog som angir hvor ulike meldinger/hendelser blir logget. Ofte er dette en fil som heter etc/syslog.conf. I og med at jeg bruker 3 ulike Linuxversjoner så husker jeg aldri alle detaljer, men dette er det viktigste som står når det gjelder hvor logger går.

 

auth,authpriv.*				 /var/log/auth.log
*.*;auth,authpriv.none		  -/var/log/syslog
#cron.*						 /var/log/cron.log
daemon.*						-/var/log/daemon.log
kern.*						  -/var/log/kern.log
lpr.*						   -/var/log/lpr.log
mail.*						  -/var/log/mail.log
user.*						  -/var/log/user.log
uucp.*						  /var/log/uucp.log

 

Grunnen til at jeg hadde loginlog på min Debian, som egentlig også bruker auth.log, er at jeg har Bastille installert.

 

Men sjekk litt i manpage til syslog, så ser du mere muligheter for å splitte logger og sette opp mer detaljert konfigurasjon.

 

Ellers har jorgis et godt råd med å bruke DenyHosts. Jeg har faktisk ikke hatt så plagsomt mye støy i loggfilene, selv om Debianserveren hoster 13 godt synlige nettsteder, og har den derfor ikke installert. Men jeg bør nok vurdere dette, også fordi det reduserer belastningen mot server.

 

Litt OT: Personlig blir jeg mer og mer glad i den solide logginga som gjøres i Linux og som etter litt bruk faktisk er meget forståelig språk. I og med at dette er rene tekstfiler, er de også lette å søke i og finne interessante oppføringer.

 

Tutorial på LinuxPlanet med noen elegante grep.

[Gjest Slettet+6132]

*nix, Ubuntu er ett skikkelig OS.

Med god sikkerhet, ryddige textfiler for configs, meget god logging (også tekst).

 

Synd det er så mange tragiske tapere der ute.

 

Her er min "BadAssList" som forsøkte seg i perioden 14-18 mai.

• 203.252.75.33 - South Korea
  
• 218.57.136.148 - Jinan, China
  
• 60.18.168.108 - Shenyang, China
  
• 62.2.211.46 - Zürich, Switzerland
  
• 88.198.7.180 - Gunzenhausen, Germany
  
• 157.88.196.29 - Valladolid, Spain
  
• 200.182.201.130 - Sao Paulo, Brazil
  
• 65.75.189.43 - Redwood City, USA
  
• 201.116.234.210 - Lázaro Cárdenas, Mexico
  
• 219.215.8.20 - Setagaya, Japan
  
• 161.116.71.99 - Barcelona, Spain
  
• 66.180.165.27 - Green Bay, Wisconsin, USA
  

Ikke så mange, men ett par av disse genererte noen tusen linjer i auth.log.

 

Ingen kom seg så langt at de fikk prøvd seg med noen nøkler.

 

Nå er ihvertfall SSH oppdatert og Denyhosts installert.

 

Takk for tips/info Jorgis/Bolson m.fl.

Endret 18. mai 2008 av Slettet+6132

[Prognatus]

Jeg har ikke noen logginnførsler av uautoriserte innbruddsforsøk i det hele tatt, hverken nå eller i tidligere vesjoner av auth.log som fremdeles ligger på disk. Det kommer antagelig av at jeg kjører en brannvegg i tillegg og at evt. forsøk blir stoppet der? Uansett føler jeg meg ganske sikker. E-postnøklene mine er laget med GnuPG og den er jo ikke berørt av denne feilen.

[Langbein]

Prognatus: Kjører du SSH på port 22 da, og er denne åpnet i firewallen?

 

Selv har jeg svært få porter åpne for den store verden. Jeg kjører riktignok SSH, men har valgt en random port. Foreløpig har ingen prøvd seg på denne (etter mange år), selv om man aldri kan gardere seg helt med denne metoden.

[pcp160]

Det er flott når en i utgangspunktet negativ tråd, tar en så informativ vending.

Du husker helt korrekt med tanke på hvordan angivelse av logging i sshd.config er satt opp Bolson, og det var fint med en liten innføring i hvordan dette henger sammen og kan endres på.

 

Ellers har jorgis et godt råd med å bruke DenyHosts. Jeg har faktisk ikke hatt så plagsomt mye støy i loggfilene, selv om Debianserveren hoster 13 godt synlige nettsteder, og har den derfor ikke installert. Men jeg bør nok vurdere dette, også fordi det reduserer belastningen mot server.

Ja, jeg er ikke så avansert og har ingen nettsider. Har som langbein nevner også satt egen port for ssh til vanlig, og det samme med RDP for Windows maskiner. Men har en FTP som kjører på standard port, og der er det tidvis voldsom pågang av svinepelser, eller "støy i loggen".

Den har kjørt Windows frem til nå nylig da jeg gjorde allvor av serverguiden til Del, bla fordi jeg føler det vil være lettere å holde oversikt/kontroll med Linux når jeg blir litt bedre kjent med det. DenyHosts har jeg hørt snakk om og det må jeg tydeligvis sjekke ut nå, og se om jeg skjønner...

For det høres jo midt i blinken ut for mitt FTP problem, og også dersom noen ved portscan, eller hva de nå gjør, finner mine åpne ssh og RDP porter.

[jorgis]

TL1000S: Sporet en gang et par av IP-adressene i min hosts.deny-fil, og fant faktisk ut at et av angrepene stammet fra en barneskole i Stavanger. Tipper at mange av slike brute-force SSH-angrep kjøres av malware på infiserte Windows-maskiner rundt omkring.

 

Bolson: Hadde serveren min vært brukt til å dele ut nettsider som skal være offentlig tilgjengelig, ville jeg passet meg litt for å kjøre DenyHosts, da det er mange "uskyldige" klienter som blir brukt til slike angrep, og fordi mange angriper fra dynamisk IP. Du skal være trygg om du setter DenyHosts til å fjerne ip-adresser som ikke har prøvet seg den siste uken eller noe sånt.

[Bolson]

Bolson: Hadde serveren min vært brukt til å dele ut nettsider som skal være offentlig tilgjengelig, ville jeg passet meg litt for å kjøre DenyHosts, da det er mange "uskyldige" klienter som blir brukt til slike angrep, og fordi mange angriper fra dynamisk IP. Du skal være trygg om du setter DenyHosts til å fjerne ip-adresser som ikke har prøvet seg den siste uken eller noe sånt.

 

Klar over det, og det er hovedårsaken til at jeg pr dato kun gjør en del manuell svartelisting pr dato. Nå viser også loggen at allerede på torsdag var jeg nede på normal aktivitet. Denne serveren har faktisk vært oppe i 2 år med logget oppetid på nettstedene på 99,95 %.

 

Men jeg ser at man ved DenyHost kan snu litt på problemet for å øke sikkerhet mot angrep, men må ta seg arbeidet med å rense opp for å sikre de som skal ha tilgang tilgang.

 

Men det er alltid flere veier til sikkerhet i Linux, det viktigste er at man er bevist, og følger med på hva som skjer.

[Prognatus]

Prognatus: Kjører du SSH på port 22 da, og er denne åpnet i firewallen?

Nei - på begge spørsmålene. Hvis jeg hadde kjørt SSH på denne maskinen ville jeg nok både kjørt gjennom en ustandard port og brukt verktøy som DenyHosts i tillegg. Jeg er litt paranoid når det kommer til sikkerhet.