Spørsmål:
Sikkerhetshensyn fra offentlig synlige Hudson & Jenkins-servere?
Salim Fadhley
2012-01-17 18:06:29 UTC
view on stackexchange narkive permalink

En venns oppstart har implementert en rekke forretningskritiske tjenester på en Hudson / Jenkins-server som kjøres på en Tomcat-container. Dette er ikke et open source-prosjekt, faktisk er mange aspekter av dette prosjektet konfidensielle. Jenkins brukes primært som et middel til å kjøre batcher & gthering resultater fra disse batchene.

Til en viss grad har systemet blitt låst, for eksempel er det installert et plugin som er ment å blokkere angrep for gissende passord. Jenkins-systemet er konfigurert til det eneste du kan se før du logger på, er et påloggingsskjermbilde, og dermed kan disse brukerne konfigurere om eller kjøre noe på Jenkins-serveren.

Spørsmålet: Gjør dette systemet utgjør noen betydelig sikkerhetstrussel for virksomheten? Har vi tatt alle relevante, rimelige sikkerhetstiltak.

Det er for eksempel mulig at en slags ukjent sårbarhet i bunken kan bli grunnlaget for en utnyttelse, men hvor bekymret skal vi være om en risiko som i beste fall ikke er kvantifiserbar, i verste fall bare teoretisk?

Fire svar:
Lucas Kauffman
2012-01-17 18:18:48 UTC
view on stackexchange narkive permalink

Du må ta tiltak som:

  • En brannmur for å sikre at bare portene som trengs for å være tilgjengelige, er
  • Hviteliste i stedet for svarteliste (som betyr, benekt tilgang fra alle og bare gi tilgang til det som faktisk trenger tilgang)
  • Skal det være tilgjengelig fra internett? (Er en VPN kanskje nok)
  • ...

Og det kan alltid være en utnyttelse, problemet med utnyttelser er at du aldri vet når noen vil finne et hull i systemet ditt. Og du kan ikke rangere hvor opptatt du skal være med mindre du tar en titt på kildekoden og utformingen av tjenesten. Når du ser at den har dårlig validering eller dårlig design, vet du at du må være skremt, hvis den er godt designet, godt kodet og det er anstendig validering, kan du være mindre bekymret. Men det er alltid en mulighet for at det kan skje.

Spørsmålet ditt er ganske bredt på den ene siden og veldig lokalisert på den andre.

"du kan ikke rangere hvor opptatt du skal være, med mindre du tar en titt på kildekoden og utformingen av tjenesten" Tull - Hvis du kunne finne utnyttelser / sårbarheter ved å ha hvem som helst som øyeepler koden, kommersiell programvare (hvor hundrevis av mennesker får betalt for å gjøre noe annet enn øyeeplekode) ville være utnyttet gratis. I beste fall kan du finne åpenbare feil ved utformingen av programvaren (forutsatt at du i det minste er en god kode som forfatter)
Jeg mente ikke det på den måten, men du kan i det minste finne hvor opptatt du skal være. Jeg mente at hvis det er crappy code, vet du at det kan være en trussel, ellers kan du være mindre bekymret.
Hva er crappy code? Hele linux er en mengde kode, så sier du linux er en sikkerhetstrussel?
Jeg legger til litt mer info da, kan du definere hodgepodge? Etter min mening kan ikke Linux-kjernen egentlig defineres som en hodgepodge? Hvorfor er det hodgepodge? Og faktisk å finne feil krever ganske mange ferdigheter, det er derfor jeg nevnte at det er vanskelig å definere et bekymringsnivå.
hodgepodge som i å motta oppdateringer fra forskjellige kilder (ved hjelp av forskjellige kodestiler). Gjør det til en utfordring å integrere. Det er ikke det at det er vanskelig, det er umulig å tallfeste, og det er alarmerende i beste fall å si at du bør vurdere risikoen basert på det du vet om kode.
Vel starter med å ta en titt på koden er ikke dårlig, er det? Jeg sier ikke at han burde, men kanskje noen som vet hva de gjør, burde. Bortsett fra det kan du skrive prøvesaker og gjøre noen pennetester. Men fremdeles hvis det er alarmerende, vet du at det kan være en risiko, så du kan være bekymret nei?
@Jim B: Det er en åpenbar forskjell mellom Open Source, en "hodgepodge" og dårlig kode.
@Dave, ikke fra et sikkerhetsperspektiv. ukjent ukjent kode, åpen kildekode eller ikke, starter utrodd. Det kan være åpen kildekode fra google (hvilken google setter omdømmet sitt på banen), i så fall har jeg mindre risiko med det. Når det gjelder Linux - er det hele selskaper (som Red Hat) som sier at de støtter produktet - noe som betyr mindre risiko - siden de får betalt for å administrere innleveringene til kodebasen. Til slutt kan jeg kjøpe et stykke programvare - jeg vet hvor det kom fra og betaler for støtten til programvaren, så jeg har mindre risiko. Dårlig kode kommer hvor som helst.
Så fra ditt sikkerhetsperspektiv er lukket kilde bedre? Dette betyr sikkerhet gjennom uklarhet ...
Bare hvis sikkerhet ved uklarhet er å stole på at sikkerhetspersonell gjør jobben de blir betalt for. Sikkerhet ved uklarhet refererer generelt til ideen om at en sårbarhet ukjent for en angriper, det er lite sannsynlig at den vil bli utnyttet. Kjøpt programvare (vanligvis men ikke alltid lukket kilde) stoler ikke på det fordi jeg forventer (og kan spørre) om en sikkerhetsgjennomgang av koden ble gjort. Siden anmelderen faktisk kan snakke med utvikleren, er gjennomgangen vanligvis en bedre kvalitetsanmeldelse.
Du forventer faktisk det, men du vet ikke det.
Men jeg * kan * vite, hvis jeg trenger det, og hvis det ikke var det, kan jeg få gjort min egen sikkerhetsanmeldelse, igjen av bedre kvalitet siden jeg nå har utvikleradgang.
... så i utgangspunktet det du sier er å få noen til å se på kildekoden, det jeg sa hele tiden ...
Hubert Kario
2012-01-17 18:32:00 UTC
view on stackexchange narkive permalink

Hvis det ikke er mulig å flytte Hudson / Jenkins til en annen server, vil jeg bruke en omvendt proxy for å deaktivere ekstern tilgang til annet enn Hudson (legg også til SSL).

Det er alltid en sannsynlighet for at Det er feil i Tomcat i Hudson, etc. Du kan bare minimere effekten de kan forårsake.

Jeff Ferland
2012-01-17 19:19:52 UTC
view on stackexchange narkive permalink

Det er en risiko. Denne risikoen er ikke kvalifisert (vi vet ikke, eller for øyeblikket bryr oss oss om hvor risikabelt det er). Mot den risikoen er det ingen fordel å la den være offentlig. Dermed er det ikke verdt å evaluere risikoen, for uansett hvilken risiko det er, er forholdet mot ingenting.

Siden jeg vet fra et annet spørsmål du så på EC2, bruk en privat sikkerhetssone som bare tillater tilgang fra ditt private firmas IP-adresser. Hvis du holder det internt i stedet for på EC2, foreslår jeg at du gjør en lignende innsats for å slippe trafikk som ikke kommer fra det forventede nettverket.

Peter Schuetze
2012-01-18 00:30:40 UTC
view on stackexchange narkive permalink

Ser jeg på oppsettet ditt, lurer jeg på om du virkelig trenger tilgang fra utenfor selskapet? Hvis ja, kan du bruke VPN, HTTPS, sertifikater, ... For å sikre kommunikasjonen fra klienten din til Jenkins Server?

En av kommentarene dine gjelder meg virkelig:

... disse brukerne kan konfigurere om eller kjøre hva som helst på Jenkins-serveren.

Må brukerne kunne gjøre noe på den Jenkins-serveren (bare gi tillatelse / tilgang til det som faktisk er nødvendig, og ikke det som kan være nødvendig i en uforutsigbar fremtid)? Kan autoriteten senkes for Jenkins / Tomcat (kjører Jenkins med root / service level autoritet)? Kan du begrense brukerne til å være seere bare når de kobler seg fra utenfor selskapet? Hva med å sikre bedriftens nettverk fra enhver mulig trussel fra Jenkins-serveren (brannmurer). Med andre ord behandle Jenkins-serveren som om den ikke ville være en del av firmaets nettverk.



ⓘ
Denne spørsmålet ble automatisk oversatt fra engelsk.Det opprinnelige innholdet er tilgjengelig på stackexchange, som vi takker for cc by-sa 3.0-lisensen den distribueres under.
Loading...