Sikker fil­overførings­teknikk var ikke så sikker likevel

[Harald Brombach (digi.no)]

Sikker fil­overførings­teknikk var ikke så sikker likevel

[missi]

Bruker SCP ukentlig. Den er helt genial!

[pitrh]

Mulig jeg er naiv og ikke har fått nok kaffe innabords, men jeg sitter med en følelse av at dette er hauset opp til mer enn det egentlig er verd. scp forutsetter gyldig autentisering i begge ender og vil gjøre det brukeren sier, innenfor rettighetene brukeren som kjører kommandoen har.

 

scp kan endre rettigheter og eierskap på til-filer: ja, noen ganger er det akkurat det som er grunnen til at du bruker scp -p (liten p for 'preserve') for å få bevart slike ting som fildato, eierskap og om x-bit (utførbarhet) er på, og bare for filer som skal være utførbare.

 

Om du skulle kopiere noe fra en boks der noen allerede har tuklet med filene dine, så er jo det egentlige problemet at noen har kommet i posisjon der det er mulig å tukle med filene dine, og om du da skal begrense scp sin adgang til å gjøre nøyaktig det du ber den om smaker for min del av å begynne i feil ende.

[Egil Hjelmeland]

Slik jeg leser det, så er skadepotensialet begrenset hvis jeg passer på å være på en ikke-essensiell underkatalog når jeg henter filer via scp.

[Gjest Slettet+5132]

Har ikke undersøkt selv, men noen som vet om rsync er påvirka når en bruker ssh til overføring?

[Bolson]

Har ikke undersøkt selv, men noen som vet om rsync er påvirka når en bruker ssh til overføring?

 

Hvorfor skulle rsync være påvirka - det er en helt annen "teknologi".

[Gjest Slettet+5132]

Hvorfor skulle rsync være påvirka - det er en helt annen "teknologi".

 

Kunne jo vært at de brukte scp i bakgrunnen når man slo på ssh-modus. 

[NULL]

Sitat: "men tar i tillegg i bruk SSH (Secure Shell) til autentisering."

 

Er det bare til autentisering? Benyttes det ikke for å kryptere selve overføringen også?

[Bolson]

 

Hvorfor skulle rsync være påvirka - det er en helt annen "teknologi".

 

Kunne jo vært at de brukte scp i bakgrunnen når man slo på ssh-modus. 

Poeng forstått. Nei så vidt jeg vet så brukes ikke noe scp. Nå er faktisk rsync primært laget for remote sync, rsync står for remote sync. Rsync kopierer jo ikke filer, det synkroniserer filer ved hjelp av delta-enkoding, https://en.wikipedia.org/wiki/Rsync#Algorithm.

 

Når en fil overføres med rsync (den kopieres ikke), så sjekkes det ført om filen finnes - og deretter overføre filen som biter (chunks) som testes med sjekksum både på avsender og mottakerside.

[Gjest Slettet+5132]

Poeng forstått. Nei så vidt jeg vet så brukes ikke noe scp. Nå er faktisk rsync primært laget for remote sync, rsync står for remote sync. Rsync kopierer jo ikke filer, det synkroniserer filer ved hjelp av delta-enkoding, https://en.wikipedia.org/wiki/Rsync#Algorithm.

 

Når en fil overføres med rsync (den kopieres ikke), så sjekkes det ført om filen finnes - og deretter overføre filen som biter (chunks) som testes med sjekksum både på avsender og mottakerside.

 

Takk for oppklaring  Da virker rsync relativt sikker mot feil som nevnes i artikkelen iallfall.

[pitrh]

Sitat: "men tar i tillegg i bruk SSH (Secure Shell) til autentisering."

 

Er det bare til autentisering? Benyttes det ikke for å kryptere selve overføringen også?

 

Det var en snodig formulering, det der. Ja,

 

scp bruker den autentiseringen som er konfigurert for ssh, og bruker så ssh som transport. Så trafikken er kryptert på samme måte som alle andre sesjoner.

 

Risikoen her er primært at scp ikke hindrer deg mer enn lokal cp i å ødelegge filer du har tilgang til.

 

Og hvis noen har griset med filene du kopierer slik at filnavnene eller annen output fra kommandoen kan inneholde sekvenser terminalen din tolker som noe annet enn bein tekst, så er det et potensiale for at det kan lage problemer for deg.

 

Jeg havner fortsatt på at om noe av dette skjer, så er det egentlige problemet at noen har hatt tilstrekkelig tilgang til å gjøre skumle ting med filene dine.

[linux-fan]

Slettes ikke bra.

 

scp kan som oftes ganske lett erstattes med bruk av sftp og unngå risiko, og på klient siden har man normalt et valg hvis man heller vil bruke sftp.

 

scp brukes normalt mellom servere man stoler på i eget nett, sftp for mer ukjente.

 

scp kjøres svært sjeldent av root, så videre spredning direkte ved å oppdatere scp programmet lite trolig.

 

Man kunne ellers frykte en orm som brukte alle kjente ssh forbindelser fra en datamaskin videre på samme måte.

[Penguin]

 

Sitat: "men tar i tillegg i bruk SSH (Secure Shell) til autentisering."

 

Er det bare til autentisering? Benyttes det ikke for å kryptere selve overføringen også?

 

Det var en snodig formulering, det der. Ja,

 

scp bruker den autentiseringen som er konfigurert for ssh, og bruker så ssh som transport. Så trafikken er kryptert på samme måte som alle andre sesjoner.

 

Risikoen her er primært at scp ikke hindrer deg mer enn lokal cp i å ødelegge filer du har tilgang til.

 

Og hvis noen har griset med filene du kopierer slik at filnavnene eller annen output fra kommandoen kan inneholde sekvenser terminalen din tolker som noe annet enn bein tekst, så er det et potensiale for at det kan lage problemer for deg.

 

Jeg havner fortsatt på at om noe av dette skjer, så er det egentlige problemet at noen har hatt tilstrekkelig tilgang til å gjøre skumle ting med filene dine.

Njææ...

Man *kan* jo forestille seg at en administrator et sted spicer opp sin sshd, for derigjennom å droppe barneporno på noen som laster ned legitime filer via samme sshd. Uten at bruker oppfatter hva som skjer. For eksempel.

[pitrh]

Jeg havner fortsatt på at om noe av dette skjer, så er det egentlige problemet at noen har hatt tilstrekkelig tilgang til å gjøre skumle ting med filene dine.

Njææ...

Man *kan* jo forestille seg at en administrator et sted spicer opp sin sshd, for derigjennom å droppe barneporno på noen som laster ned legitime filer via samme sshd. Uten at bruker oppfatter hva som skjer. For eksempel.

 

Her er igjen problemet at noen har fått tilganger de ikke skulle hatt.

 

Det er selvfølgelig fornuftig å sjekke at filene du har tenkt å kopiere ikke er blitt erstattet med noe annet, eller at noe uønsket er lagt til ut over det du selv har plassert der.

 

Men det ligger utenfor det en kan forvente å kode inn i et program for kopiering av filer.

[NgZ]

Mulig jeg er naiv og ikke har fått nok kaffe innabords, men jeg sitter med en følelse av at dette er hauset opp til mer enn det egentlig er verd. scp forutsetter gyldig autentisering i begge ender og vil gjøre det brukeren sier, innenfor rettighetene brukeren som kjører kommandoen har.

 

scp kan endre rettigheter og eierskap på til-filer: ja, noen ganger er det akkurat det som er grunnen til at du bruker scp -p (liten p for 'preserve') for å få bevart slike ting som fildato, eierskap og om x-bit (utførbarhet) er på, og bare for filer som skal være utførbare.

 

Om du skulle kopiere noe fra en boks der noen allerede har tuklet med filene dine, så er jo det egentlige problemet at noen har kommet i posisjon der det er mulig å tukle med filene dine, og om du da skal begrense scp sin adgang til å gjøre nøyaktig det du ber den om smaker for min del av å begynne i feil ende.

Det er jo ikke gitt at det er din egen server (eller for den del en server hos noen du stoler så voldsomt på) som du skal hente filen fra. Det kan være du henter en datafil fra en underleverandør, en loggfil fra et eksternt system med en viss risiko for fysisk tampering fra tredjepersoner fordi offentligheten eller en vid krets av mennesker har tilgang, fra en distribusjonsplatform e.l.

 

Du vil ikke at noen med fysisk tilgang til en billettmaskin e.l. skal kunne ta over hele kjernesystemet ditt fordi scp-klienten på serveren ikke sjekker at den mottar (bare) filen den ber om, men villig vekk fyller disken med andre filer serveren serverer samtdig.