Skocz do zawartości

Polecane posty

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 przez N0Name (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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.

 

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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 przez Archi (zobacz historię edycji)
  • Upvote 1

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
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 ;)

  • Upvote 2

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

 

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 przez Desavil (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

 

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

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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?

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

 

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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

 

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?

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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.

 

 

 

  • Upvote 1

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

 

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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

 

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 przez Archi (zobacz historię edycji)
  • Upvote 1

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
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 :D

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ł ;)

  • Upvote 1

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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

 

Szkoda, że akurat na nich wypadło ;).

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

 

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

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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:

 

Bartek_Juszczyk_FB-600x220.jpg

 

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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość
Temat jest zablokowany i nie można w nim pisać.

×