Włamanie do 2be.pl

[N0Name 48]

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.

Edytowano Marzec 2, 2016 przez N0Name (zobacz historię edycji)

[theONE 526]

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

[przemon 35]

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.

 

[Pan Kot 1535]

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

Edytowano Marzec 2, 2016 przez Archi (zobacz historię edycji)

[theONE 526]

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

[Gość Adam Szendzielorz]

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

[Desavil 88]

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.

[Pan Kot 1535]

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.

[Desavil 88]

 

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

Edytowano Marzec 2, 2016 przez Desavil (zobacz historię edycji)

[przemon 35]

 

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

[Desavil 88]

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?

[Suspect121 53]

 

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.

[przemon 35]

 

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?

[Gość patrys]

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.

[przemon 35]

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.

 

 

 

[theONE 526]

Co bez komentarza. Mają serwery w innym mieście niż siedzibę więc mają problem. Nigdy nie widziałeś jak się ludzie np pokłócą (admin/adweb). Przy tej wielkości firm nie ma co oczekiwać realnej procedury na wypadek wrogiego pracownika.

GTS jak wszystkie poważane serwerownie ma remote hands a nie remote admins...

 

Co do backupów po to przez lata stosowało i nadal stosuje się taśmy żeby w wypadu przejęcia kontroli nie było fizycznej możliwości skasowania danych.

 

Dostęp RO rozwiązuje część problemów ale nadal nie wszystkie.

[przemon 35]

Co bez komentarza. Mają serwery w innym mieście niż siedzibę więc mają problem. Nigdy nie widziałeś jak się ludzie np pokłócą (admin/adweb). Przy tej wielkości firm nie ma co oczekiwać realnej procedury na wypadek wrogiego pracownika.

GTS jak wszystkie poważane serwerownie ma remote hands a nie remote admins...

 

Co do backupów po to przez lata stosowało i nadal stosuje się taśmy żeby w wypadu przejęcia kontroli nie było fizycznej możliwości skasowania danych.

 

Dostęp RO rozwiązuje część problemów ale nadal nie wszystkie.

 

 

Szukanie na gwałt administratora w taki sposób jest...słabe i tego dotyczył brak komentarza. Pewnie że się ludzie kłócą, tylko wiesz 2 tys domen w obsłudze z czego pewnie 1/2 hostowanych to już nie jest tak mało.i fajnie jest mieć przynajmniej 2 osoby w tym jedną na miejscu.

 

A taśmy jak najbardziej się zgodzę, szczególności przy polityce d2d2t

[blfr 225]

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

NDA to non-disclosure agreement, czyli admin się zobowiązuje nie ujawniać informacji (wymienionych w NDA), do których ma dostęp w trakcie pracy.

 

Natomiast sąd w Polsce i tak odmówi egzekwowania wielomilionowych odszkodowań od byłego pracownika. Co nie ma większego znaczenia, bo sabotowanie byłego pracodawcy to najprawdopodobniej przestępstwo (zależy od konkretnego czynu).

[Pan Kot 1535]

NDA to non-disclosure agreement, czyli admin się zobowiązuje nie ujawniać informacji (wymienionych w NDA), do których ma dostęp w trakcie pracy.

 

Natomiast sąd w Polsce i tak odmówi egzekwowania wielomilionowych odszkodowań od byłego pracownika. Co nie ma większego znaczenia, bo sabotowanie byłego pracodawcy to najprawdopodobniej przestępstwo (zależy od konkretnego czynu).

 

Myślałem, że dla każdego jest oczywiste, że do tego NDA należy dołożyć jeszcze odpowiednie zapiski w umowie o pracę o nie robienie fuckupów własnoręcznie.

 

Ala "Pracownik zobowiązuje się do nie działania umyślnie na szkodę pracodawcy, w szczególności dostępu do infrastruktury pracodawcy do której nie jest uprawniony".

 

IMHO dobrym pomysłem jest postawić jeden serwer ala-proxy w firmie, który ma dostęp do wszystkich zasobów prywatnych, dać pracownikowi dostęp do VPN, po zwolnieniu ten dostęp zrevokować. W ten sposób można kontrolować kto co i jak, i przy okazji zebrać dowody jeśli pracownik dopuści się fuckupu.

[maniektme 99]

 

IMHO dobrym pomysłem jest postawić jeden serwer ala-proxy w firmie, który ma dostęp do wszystkich zasobów prywatnych, dać pracownikowi dostęp do VPN, po zwolnieniu ten dostęp zrevokować. W ten sposób można kontrolować kto co i jak, i przy okazji zebrać dowody jeśli pracownik dopuści się fuckupu.

 

W ten sposób tworzysz single point of failure, bo jak przepuszczasz ruch tylko przez jedną wirtualkę/fizyczną pełniącą rolę owego proxy to w razie jej padu odcinasz admina od wszystkiego.

[Pan Kot 1535]

 

W ten sposób tworzysz single point of failure, bo jak przepuszczasz ruch tylko przez jedną wirtualkę/fizyczną pełniącą rolę owego proxy to w razie jej padu odcinasz admina od wszystkiego.

 

Zawsze można rozwiązanie zduplikować i stworzyć 2 takie serwery, to chyba oczywiste.

 

Cały sens polega na tym, żeby admin był kontrolowany i za pomocą swojego klucza miał dostęp tylko do tych 2 serwerów proxy i za pomocą nich dalej. Dzięki temu mamy łatwy sposób logowania co się dzieje w infrastrukturze, i łatwy sposób zrevokowania klucza danego admina, zamiast zmieniania konfiguracji wszystkich serwerów.

Edytowano Marzec 4, 2016 przez Archi (zobacz historię edycji)

[Gość Spoofy]

 

W ten sposób tworzysz single point of failure, bo jak przepuszczasz ruch tylko przez jedną wirtualkę/fizyczną pełniącą rolę owego proxy to w razie jej padu odcinasz admina od wszystkiego.

 

Zawsze może to być kilka bram do vpn'a i IMHO to rozwiązanie o którym mówi @Archi sam używam i jest idealne

P.S. Znów napisałeś w tym samym momencie co ja

Dodatkowo warto mieć pod ręką urządzenie z Androidem/iOS'em czy czymkolwiek - nawet egzotycznym - bo pod wszystko będzie klient np. OpenVPN'a, a do szybkiego rekonesansu - jak znalazł

[Pan Kot 1535]

Poważna sprawa, nie ma nic gorszego niż strona 2be.pl zwracająca timed out.

 

Szkoda, że akurat na nich wypadło .

[AdminX 1]

 

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

 

Duże macierze podłączane do kilku serwerów mają podpięcie po szkiełku FCoE - dzisiaj standard 16Gbit. Często w czasie pracy dane z i do macierzy lecą z szybkością wire speed, bo wolumin jest rozłożony np. na 20 dysków i wszystkie pracują. Do tego jest deduplikacja, która działa cuda w takich środowiskach jak hostingi - ile masz tam kopii Wordprssów np.?

 

Sam backup na macierzy też jest ogarnięty i nie jest w niczym gorszy, a wręcz lepszy od półek / dysków podłączanych lokalnie. Standardem są snapshoty co godznię i one zostaną nawet po skasowaniu dd /dev/zero z poziomu OSa, wystaczy w panlelu macierzy przywrócić wolumin ze snapshota, co trwa kika minut MAX...

 

Dopiero jak ktoś ma prawa, wejdzie na macierz i pokasuje woluminy, to wtedy snapshoty (godziny, dzienny itd.) znikają.

 

Dlatego ja się zastanawiam kto to był i co robił w tym 2be, że nie ma kompletnie nic. Ile czasu to kasowanie do gołej blachy zajęło??? To jest problem dla całej branży i zaufanie klientów na pewno spadnie do wszystkich firm po tym...

[DMatii 0]

Poważna sprawa, nie ma nic gorszego niż strona 2be.pl zwracająca timed out.

 

Szkoda, że akurat na nich wypadło .

 

 

Skoro szefo tej firmy tak szuka pracownika:

 

 

To dla potencjalnych przyszłych klientów to plus, że się stało jak się stało bo wyszło na jaw, że tam od środka pracują na pełnym lajcie.