Skocz do zawartości


 

Zdjęcie

Włamanie do 2be.pl

Włamanie do 2be.pl awaria t-mobile centrum danych adweb 2be.pl włamanie hosting

  • Zamknięty temat Ten temat jest zablokowany
457 odpowiedzi na ten temat

Włamanie do 2be.pl

#21 theONE

theONE

    Weteran WHT

  • Firma Bronze
  • PipPipPipPipPipPipPipPip
  • 1253 postów
  • Skąd:Warszawa
  • Firma:Dataspace.pl

Napisany 02 marzec 2016 - 11:48

Nazwa tematu jest lekko z d. T-mobile nie jest NIC winne sytuacji że ich klientowi ktoś się wbił.  

 

Trzymanie starszych wersji jeżeli się o nie dba czyli łata wszystkie podatności nie jest niebezpieczne.


  • 0

#22 is_wm

is_wm

    Weteran WHT

  • WHT Pro
  • PipPipPipPipPipPipPipPip
  • 943 postów

Napisany 02 marzec 2016 - 11:55

Poza tym nie pamiętam ile lat temu Apache czy PHP miało taką lukę, która umożliwiałaby wbicie się na serwer. Jeśli ktoś ma lepszą pamięć, to poproszę o przypomnienie :)


  • 0

#23 behemoth

behemoth

    Weteran WHT

  • Firma Bronze
  • PipPipPipPipPipPipPipPip
  • 1237 postów
  • Skąd:Łódź
  • Firma:swhosting.pl
  • Imię:Jakub

Napisany 02 marzec 2016 - 12:10

is_wm: https://www.cvedetai.../CVE-2010-0425/

Dotyczy windowsa, więc raczej niewielkiej ilości środowisk produkcyjnych.


  • 0

#24 is_wm

is_wm

    Weteran WHT

  • WHT Pro
  • PipPipPipPipPipPipPipPip
  • 943 postów

Napisany 02 marzec 2016 - 12:17

Ok, 6 lat temu i windows. A linux?


  • 0

#25 behemoth

behemoth

    Weteran WHT

  • Firma Bronze
  • PipPipPipPipPipPipPipPip
  • 1237 postów
  • Skąd:Łódź
  • Firma:swhosting.pl
  • Imię:Jakub

Napisany 02 marzec 2016 - 12:22

Nope, nic tak krytycznego, przynajmniej nie wypatrzyłem, albo jeszcze nikt nie znalazł.


  • 0

#26 N0Name

N0Name

    Weteran WHT

  • WHT Pro
  • PipPipPipPipPipPipPipPip
  • 849 postów
  • Skąd:PL / DE
  • Firma:STYL-SPORT.pl
  • Imię:Szymon

Napisany 02 marzec 2016 - 13:18

Na fejsie tej że firmy można przeczytać:

 

Mariusz Czeki Czytam, obserwuję i obgryzam paznokcie z nerwów... Nie zamierzam po was jechać bo i tak jesteście już w bardzo nieciekawym położeniu i jeszcze się nasłuchacie. Powiedzcie proszę tylko czy pliki na naszych serwerach są do odzyskania lub czy były robione kopie zapasowe?
 
    2BE.PL Pracujemy nad tym, aby odzyskać tyle danych i plików, ile jest możliwe.

 

Wszystko wskazuje na to że ktoś natrzodził na serwerze www z klientami, czyżby dane stron www sie ulotniły?. Tylko gdzie jest backup? Awaria trwa 5 dzień, troszkę długo, mocno to wpłynie na opinie firmy.


Edytowany przez N0Name, 02 marzec 2016 - 13:34.

  • 0

#27 theONE

theONE

    Weteran WHT

  • Firma Bronze
  • PipPipPipPipPipPipPipPip
  • 1253 postów
  • Skąd:Warszawa
  • Firma:Dataspace.pl

Napisany 02 marzec 2016 - 15:06

Backup na włam jest poważniejszą sprawą niż backup na awarie. Włamywacz mógł niestety skasować i ten backup


  • 0

#28 przemon

przemon

    Stały użytkownik

  • Użytkownicy
  • PipPipPipPipPip
  • 149 postów
  • Skąd:Kraków
  • Imię:Przemyslaw
  • Nazwisko:Nowakowski

Napisany 02 marzec 2016 - 16:11

I dlatego backupy na poziomie plików wolę zawsze zasysać na serwer backup niż wypychać z produkcyjnego.

Mało tego czasem jak przejmuję serwery po kimś to często kopii albo nie ma/nie było, albo jest robiona na tym samym serwerze tylko na innej partycjji czy też zasobie NFS. No i do tego kopia wirtualek + plan disaster recovery.

 

Współczuję i liczę, żę jakoś wybrną z tego.

 


  • 0

#29 Pan Kot

Pan Kot

    Mrrr

  • Zbanowani
  • PipPipPipPipPipPipPipPip
  • 2819 postów

Napisany 02 marzec 2016 - 17:15

I dlatego backupy na poziomie plików wolę zawsze zasysać na serwer backup niż wypychać z produkcyjnego.

Mało tego czasem jak przejmuję serwery po kimś to często kopii albo nie ma/nie było, albo jest robiona na tym samym serwerze tylko na innej partycjji czy też zasobie NFS. No i do tego kopia wirtualek + plan disaster recovery.

 

Współczuję i liczę, żę jakoś wybrną z tego.

 

 

Problem jest taki, że musisz jednak access to tego serwera backupowego jakoś autoryzować, więc jedynym sensownym pomysłem jest zrobienie takiego myku, żeby umożliwić jedynie zapis nowych plików, ale już nie usuwanie starych, co jest jednak nieco skomplikowanym zabiegiem, bo podstawowy access to rwx.

 

A skoro włamywacz dostał się do main servera, który te backupy śle dalej, to pewno nie było problemu zalogować się i tam i te backupy skasować.


Edytowany przez Archi, 02 marzec 2016 - 17:16.

  • 1

#30 theONE

theONE

    Weteran WHT

  • Firma Bronze
  • PipPipPipPipPipPipPipPip
  • 1253 postów
  • Skąd:Warszawa
  • Firma:Dataspace.pl

Napisany 02 marzec 2016 - 18:38

A i jeszcze jedna sprawa z którą walczą firmy hostingowe. Na serwerze mają czasami sporo danych typu 10 TB, backup jest pakowany przed wysłaniem w kawałkach albo snapshotach na jeden serwer backupowy. 

 

Serwer backupowy ma 30-50 TB i łączność 1 Gtbi/s. Do robienia kopii wystarcza, ale jak masz odzyskać to 6 dni kopiowania i rozpakowywania


  • 0

#31 Gość_Adam Szendzielorz_*

Gość_Adam Szendzielorz_*
  • Goście

Napisany 02 marzec 2016 - 20:40

A i jeszcze jedna sprawa z którą walczą firmy hostingowe. Na serwerze mają czasami sporo danych typu 10 TB, backup jest pakowany przed wysłaniem w kawałkach albo snapshotach na jeden serwer backupowy. 

 

Serwer backupowy ma 30-50 TB i łączność 1 Gtbi/s. Do robienia kopii wystarcza, ale jak masz odzyskać to 6 dni kopiowania i rozpakowywania

 

Dlatego ja osobiście nigdy nie byłem i nie będę zwolennikiem rozwiązań b. dużych macierzy w hostingu współdzielonym, z których korzysta kilka/naście serwerów, chociaż diler IBMa nas na na dużą macierz namawia od lat :) Nawet jak mamy dwie to i tak jest jakieś ryzyko dużego padu (vide dawny pad w beyond, czy w oktawave). Max 2-3TB per maszyna i wystarczy. Średnie wykorzystanie u mnie to 1,5TB per serwer, disaster recovery po gigabicie to max 4h przerzucania. Pozatym jak padnie, to nie działa 2% klientów, a nie 100%. Polecam ;)


  • 2

#32 Desavil

Desavil

    Weteran WHT

  • WHT Pro
  • PipPipPipPipPipPipPipPip
  • 567 postów
  • Skąd:/dev/random
  • Imię:Wojtek

Napisany 02 marzec 2016 - 22:26

A ja mam pytanie z innej beczki.

Jeżeli to faktycznie jest działanie ze strony, np. zwolnionego, sfrustrowanego administratora, jak przed takim czymś się uchronić, zabezpieczyć? Pomijam już kwestię backupów, ale ogólnie wpływu na infrastrukturę. Zawsze przecież może zostawić jakieś backdoory na serwerze itp.


  • 0

#33 Pan Kot

Pan Kot

    Mrrr

  • Zbanowani
  • PipPipPipPipPipPipPipPip
  • 2819 postów

Napisany 02 marzec 2016 - 22:28

A ja mam pytanie z innej beczki.

Jeżeli to faktycznie jest działanie ze strony, np. zwolnionego, sfrustrowanego administratora, jak przed takim czymś się uchronić, zabezpieczyć? Pomijam już kwestię backupów, ale ogólnie wpływu na infrastrukturę. Zawsze przecież może zostawić jakieś backdoory na serwerze itp.

 

NDA. Klauzula poufności z sumkami opiewającymi na kilka milionów zł, tak żeby taki administrator się dwa razy zastanowił zanim zrobi fuckup.


  • 0

#34 Desavil

Desavil

    Weteran WHT

  • WHT Pro
  • PipPipPipPipPipPipPipPip
  • 567 postów
  • Skąd:/dev/random
  • Imię:Wojtek

Napisany 02 marzec 2016 - 22:37

 

NDA. Klauzula poufności z sumkami opiewającymi na kilka milionów zł, tak żeby taki administrator się dwa razy zastanowił zanim zrobi fuckup.

 

To oczywiście podstawa od strony formalnej, mam na myśli kwestie techniczne co można zrobić.

Może być jakiś zdesperowany administrator, który np. po przepracowaniu pół życia w danej firmie nagle zostaje zwolniony, odbija mu i chce za wszelką cenę zniszczyć firmę. Firmy warte kilkadziesiąt/kilkaset milionów jakoś muszą przed takim czymś się zabezpieczać.

 

@ Koniec Offtop


Edytowany przez Desavil, 02 marzec 2016 - 22:43.

  • 0

#35 przemon

przemon

    Stały użytkownik

  • Użytkownicy
  • PipPipPipPipPip
  • 149 postów
  • Skąd:Kraków
  • Imię:Przemyslaw
  • Nazwisko:Nowakowski

Napisany 02 marzec 2016 - 22:49

 

Problem jest taki, że musisz jednak access to tego serwera backupowego jakoś autoryzować, więc jedynym sensownym pomysłem jest zrobienie takiego myku, żeby umożliwić jedynie zapis nowych plików, ale już nie usuwanie starych, co jest jednak nieco skomplikowanym zabiegiem, bo podstawowy access to rwx.

 

A skoro włamywacz dostał się do main servera, który te backupy śle dalej, to pewno nie było problemu zalogować się i tam i te backupy skasować.

 

Pierdoły mi tu piszesz.

 

Autoryzuję się osobnym kluczem, dodatkowo po openvpn ograniczając dostęp per ip na osobnej podsieci + otp.  Wycinam ruch produkcja - > backup, ograniczam ruch doo minimum backup -> produkcja (np rsync+ssh). Nie widzę powodu dla którego miałbym dodatkowo ograniczać modyfikację na serwerze backup. Jak ma się ktoś niby zalogować do serwera backup? Sytuacja którą opisujesz to push danych na serwer backup, co określiłem jako rozwiązanie do dupy którego należy unikać.


  • 0

#36 Desavil

Desavil

    Weteran WHT

  • WHT Pro
  • PipPipPipPipPipPipPipPip
  • 567 postów
  • Skąd:/dev/random
  • Imię:Wojtek

Napisany 02 marzec 2016 - 23:05

Wycinam ruch produkcja - > backup, ograniczam ruch doo minimum backup -> produkcja (np rsync+ssh). Nie widzę powodu dla którego miałbym dodatkowo ograniczać modyfikację na serwerze backup. Jak ma się ktoś niby zalogować do serwera backup? Sytuacja którą opisujesz to push danych na serwer backup, co określiłem jako rozwiązanie do dupy którego należy unikać.

 

Czyli rozumiem najlepsza praktyka to serwer backupu uruchamia, np. rsync i zaciąga backup (tym samym może łączyć się do serwerów produkcyjnych po kluczach, na usera backup), a nie odwrotnie?


  • 0

#37 Suspect121

Suspect121

    Stały użytkownik

  • Użytkownicy
  • PipPipPipPipPip
  • 199 postów
  • Imię:Mateusz

Napisany 02 marzec 2016 - 23:31

 

Pierdoły mi tu piszesz.

 

Autoryzuję się osobnym kluczem, dodatkowo po openvpn ograniczając dostęp per ip na osobnej podsieci + otp.  Wycinam ruch produkcja - > backup, ograniczam ruch doo minimum backup -> produkcja (np rsync+ssh). Nie widzę powodu dla którego miałbym dodatkowo ograniczać modyfikację na serwerze backup. Jak ma się ktoś niby zalogować do serwera backup? Sytuacja którą opisujesz to push danych na serwer backup, co określiłem jako rozwiązanie do dupy którego należy unikać.

 

Odnosisz się do nie mojego postu ale ja także widzę, że pierdoły piszesz. Włamywacz łączy się z serwerem backupu z poziomu serwera do którego się włamał i Twoje backupy w tym momencie przestają istnieć  :) Właśnie tyle jest warte Twoje rozwiązanie.


  • 0

#38 przemon

przemon

    Stały użytkownik

  • Użytkownicy
  • PipPipPipPipPip
  • 149 postów
  • Skąd:Kraków
  • Imię:Przemyslaw
  • Nazwisko:Nowakowski

Napisany 02 marzec 2016 - 23:34

 

Czyli rozumiem najlepsza praktyka to serwer backupu uruchamia, np. rsync i zaciąga backup (tym samym może łączyć się do serwerów produkcyjnych po kluczach, na usera backup), a nie odwrotnie?

 

 

Pulll na serwer backup  wg w/w schematu u mnie sprawdza się od lat, tak działa też komercyjne dedykowane oprogramowanie i takie są dobre praktyki (czasem jest jeszcze dodatkowy sync + ew taśma). Podobne praktyki widziałem 15 lat temu w jednej z top 5 firm hostingowych EU gdzie miałem staż. Tylko tam administratorzy od infrastruktury backup nie mają/mieli dostępu do zasobów produkcyjnych w trybie rw, tylko ro no i każdy każdemu patrzy na ręce. To samo w drugą stronę.


 

Odnosisz się do nie mojego postu ale ja także widzę, że pierdoły piszesz. Włamywacz łączy się z serwerem backupu z poziomu serwera do którego się włamał i Twoje backupy w tym momencie przestają istnieć  :) Właśnie tyle jest warte Twoje rozwiązanie.

 

Jak się łączy?

Ma klucze SSH? Nie ma.

Ma klucze OpenVPN? Nie ma.

Ma dostęp do OTP? Nie ma

 

 

Czym się łączy, emacsem przez sendmail?


  • 0

#39 Gość_patrys_*

Gość_patrys_*
  • Goście

Napisany 02 marzec 2016 - 23:53

Można to ominąć wysyłając dane na jakieś konto chrootowane czy wirtualizacje które/która następnie wyżej wpada wyżej w rotacje danych.

Usunięcie danych poprzez połączenie z serwera z źródłowego do serwera kopii nic nie zmieni, bo dane mamy już gdzie indziej.

 

Przejęcie serwera kopii jest dużo mniej prawdopodobnie z uwagi na zabezpieczenia tych serwerów czyli np. dostęp przez sieci prywatne.

Więc jeżeli ktoś wysyła dane o tak sobie na serwer kopii zapasowych to powinien przemyśleć co się stanie w przypadku przejęcia maszyny która jest kopiowana.


  • 0

#40 przemon

przemon

    Stały użytkownik

  • Użytkownicy
  • PipPipPipPipPip
  • 149 postów
  • Skąd:Kraków
  • Imię:Przemyslaw
  • Nazwisko:Nowakowski

Napisany 03 marzec 2016 - 00:08

Na upartego backupy można zasysać przez TORa w przypadku małej ilości danych i włamywacz nawet nie będzie wiedział gdzie one faktycznie są,  Panie @Suspect121

 

Dodam jeszcze ciekawy post właściciela adweb.pl z FB -  cytuję jego post

 

"HELP!!!!!!!!!!!!!!
Ludzie z Wawy. Potrzebuje pomocy administratora IT który podjedzie za hajjs dziś/jutro na ul. Piekna cos tam zrobić z serwerami. HELP!!!! Priv pls!!! PLSSSSSSSSSS!"

 

Bez komentarza.

 

 

 


  • 1






Także otagowane jednym lub więcej z tych słów kluczowych: awaria, t-mobile, centrum danych, adweb, 2be.pl, włamanie, hosting

0 użytkowników czyta ten temat

0 użytkowników, 0 gości, 0 anonimowych użytkowników