W0615_CA

W zeszłym tygodniu, opublikowaliśmy wywiad z CEO grupy Adweb – Bartkiem Juszczykiem. Po publikacji tego wywiadu, skontaktował się z nami były dyrektor IT i główny administrator Grupy Adweb, który przez ostatnie 13 lat budował od początku, całą infrastrukturę firmy i był odpowiedzialny za bezpieczeństwo i ciągłość usług całej grupy Adweb, a w grudniu 2015, odszedł z firmy.

Poniżej publikujemy jego  pełne oświadczenie.

 

OŚWIADCZENIE

W związku z informacjami jakie padły z ust Pana Bartłomieja Juszczyka w wywiadzie udzielonym blogowi HostingNews.pl, pragnę wyjaśnić kilka spraw.

Ad 1. Dostęp przy pomocy loginu i hasła:

Podczas gdy byłem dyrektorem IT i zajmowałem się m.in. zarządzaniem systemem hostingowym nie było możliwości aby na serwery produkcyjne ktoś z zespołu mógł logować się zdalnie przy pomocy loginu i hasła. Logowanie następowało wyłącznie przy pomocy kluczy SSH. Tak było do momentu mojego rozstania z firmą. Dostęp do serwerów przy pomocy klucza był jedyną metodą na jaką dozwoliłem.  Nawet zespół developerski nie miał dostępu do produkcji, całość wdrożeń była robiona na stage i dopiero przez administratora wgrywana na produkcję. Dostęp do serwerów do chwili mojego odejścia z pracy miały dwie osoby: ja i drugi administrator. Drugi administrator otrzymał dostęp do serwerów produkcyjnych po dokładnym sprawdzeniu wiedzy co trwało około 2 lata, było to związane z bezpieczeństwem serwerów. Nie prawdą zatem jest, że miałem jakąkolwiek wiedzę na temat loginów i haseł wygenerowanych po moim odejściu z firmy, nie miał tej wiedzy także drugi administrator. Takie dane nie funkcjonowały nigdy w firmie. Zmienienie polityki bezpieczeństwa po moim odejściu i przejście na jedno hasło i to na wszystkich serwerach, łącznie z serwerami backupu to brak wiedzy na temat bezpieczeństwa.

Dostępy do serwerów były na klucz SSH  przypisany do osoby. Odchodząc z firmy, nie przekazałem dostępów do maszyn z uwagi na ich bezpieczeństwo tzn. nie wygenerowałem dodatkowych kluczy SSH i nie przekazałem ich nikomu. W firmie nie było osoby, która mogłaby takie dostępy otrzymać. W chwili wypowiedzenia nikt także o takie dostępy nie prosił.  Taki dostęp mógłby być przez niepowołaną osobę wykorzystany przeciwko całej infrastrukturze i także przeciwko m.in. mojej osobie. Dodam, że dział supportu miał dostęp do wszystkich systemów dzięki którym w pełni można było obsługiwać klientów.

 

Z uwagi na to, że serwery stały w bezpiecznej serwerowni, odzyskanie dostępów do serwerów np. w przypadku mojego wypadku, gdy nie byłoby drugiego administratora, czy innej sytuacji losowej nie stanowiło najmniejszego problemu. To standardowe działanie. Wystarczyło zatrudnić administratora, zrobić test na wiedzę – np. w biurze dać mu serwer stage bądź developerski aby odzyskał do niego dostęp, odpowiednio zabezpieczył – nowy klucz SSH, firewall itp, zajął się podstawową polityką bezpieczeństwa.  Następnie wystarczyło podpisać umowę po weryfikacji takiego admina i następnie wraz z pracownikiem firmy (nie sam administrator) udać się do serwerowni produkcyjnej. Jak widać było to niewykonalne dla właściciela firmy, najpewniej z braku wiedzy. Procedurę taką należało zastosować także do firmy. Abt uzyskać dostęp do serwerów wystarczyło wejść w tryb INIT z konsoli, dodać klucz SSH, skasować stare dostępy SSH, dla pewności wygenerować nowe hasło na root dla dostępu lokalnego np. MD5 przemieszane z losowymi znakami specjalnymi, nie zapisywać go nigdzie i zrestartować serwer, a klucze przekazać odpowiedniej osobie. To są ogólne praktyki jakie się stosuje i które  obowiązywały gdy nadzorowałem ten system. Praca przy jednej maszynie na kilka minut przy zresetowaniu dostępu, zatem tym bardziej dziwny jest fakt, że prace prowadzone nad serwerami trwały kilkanaście dni jak stwierdza Pan Bartłomiej Juszczyk.


Ad 2. 9-10 lutego pierwsza awaria:

 

Do tego momentu nikt najpewniej nie zajmował się serwerami. Dlaczego tak sądzę? Ponieważ system monitoringu usług, i innych akcji a związany z powiadomieniami SMS nie został wyłączony z nr mojego telefonu. Z uwagi, na uciążliwe smsy o awariach usług, wyłączyłem go sam na poziomie swojego operatora komórkowego (powiadomienia sms z bramki). Wtedy też najpewniej dopiero ktoś pojechał do serwerowni i próbował uzyskać dostępy do serwerów. Wg mnie nieumiejętnie ponieważ nie skorzystano z metody INIT, bądź trybu Single Mode, tylko najpewniej próbowano dostać się do serwerów poprzez inną dystrybucję np. Rescue bądź wymontowując dyski. Dlaczego tak sądzę, ponieważ przerwy w usługach jakie zgłaszali mi znajomi (wykupiony hosting w 2be.pl) był bardzo długi, można więc sądzić, że ktoś dużo „grzebał” przy serwerach i środowisku co potwierdza sam Pan Bartłomiej Juszczyk.  Co zostało wtedy wykonane?, jakie zabezpieczenia zniesione?, jakie dane skopiowane –  tego zapewne nikt nie wie. Jak zaznaczyłem odzyskanie dostępów do serwera to wejście na każdym z nich w tryb INIT. Wcześniejsze krótkie awarie np. niedziałające WWW były najpewniej rozwiązywane przez restart serwerów – na telefon mimo, że na miejscu były zainstalowane zarządzalne listwy zasilające. W niektórych przepadkach (wysokie obciążenie serwerów , brak dostępu do usług czy np ręczne wyłączenie SSH ) wyłączenie serwerów mogło być zrealizowane przez skrypty monitorujące prace serwerów – tutaj po emailu + smsie administrator miał krótki  określony czas aby zareagować potem skrypty podejmowały określone działania.


Ad 3. Spam i bałagan:

 

Jak stwierdza Pan Bartłomiej Juszczyk, jego nowy admin był za słaby, aby opanować sprawę Spamu. Zatem twierdzenie, że był bałagan, także uważam za nieprawdziwe, bo ocena tego faktu jest subiektywna. Odnosząc się do Spamu. Na serwerach www było hostowanych dużo stron np. wykonanych przy pomocy WordPressa, Joomli a także wielu skryptów autorskich. Kilka razy w miesiącu na kontach klientów dochodziło do prób wysłania maili np. z niezabezpieczonego formularz kontaktowego, bądź z niezaktualizowanego dodatku np. do WordPressa który posiadał dziurę umożliwiającą wysyłkę Spamu, co jest sprawą normalną. System był tak przygotowany, że jeśli taka wysyłka masowa się pojawiała  (były zdefiniowane progi wysyłki) to informował administratora – email + sms o takowym fakcie i na firewallu odcinał automatycznie wyjście maili na świat, tak aby serwer nie  trafił na czarne listy. Info o takim fakcie miał także support w autorskim interfejsie do monitorowania stanów serwerów. Po takim incydencje administrator mógł podjąć konkretne działania – zablokować konto, skasować kolejkę maili, odblokować porty na firewallu. Jednak brak administratora mógł doprowadzić do tego, że kolejka maili na serwerach rosła, zapychała dyski, powodowała obciążenie poszczególnych maszyn bo fizycznie, maile nie mogły opuścić serwera. To zabezpieczenie działało poprawnie, jednak nie było admina który mógł zareagować. Zabezpieczenie wdrożone także było na serwerach smtp firmy, z tym wyjątkiem, że następował alert po zdefiniowanych progach wysyłki email przez danego usera/domenę, bądź gdy kolejka maili łącznych była ponad zdefiniowane parametry, nie było automatycznych blokad.  Są to także ogólne praktyki.


Ad 4. Backup i dostęp:

 

Jak już wspomniałem, dostęp do wszystkich serwerów na nowe hasło, został wygenerowany po moim odejściu z firmy, zatem nie byłem w jego posiadaniu.  Nowy administrator czy też firma obsługująca powinna zadbać o odpowiednią politykę bezpieczeństwa i sprawdzenie tego jak funkcjonuje środowisko. Wygenerowane hasło, najpewniej trafiło do grupy osób z którymi zaczęła współpracować Grupa Adweb , co także jest dziwne, zero podejścia do bezpieczeństwa, brak umów, sprawdzenia wiedzy i kompetencji jak stwierdza Pan Bartłomiej Juszczyk. Nie zdziwiłbym się gdyby nowe dane dostępowe do serwerów trafiły nawet do „oceny środowiska serwerowego” przez potencjalnego przyszłego administratora bądź kilku. Zatem dostęp na ten sam login i nowe hasło mogła mieć wg mnie spora liczba niepowołanych osób. Grupa Adweb z uwagi na brak osób (wewnątrz w firmie w momencie mojego odeścia)  które mogły zadbać o funkcjonowanie środowiska hostingowego do strony serwerowej, backupu powinna zlecić to  administratorowi z którym nawiązała współpracę, bądź firmie która zaczęła ją obsługiwać. Należało na pewno sprawdzić czy backup się wykonuje, na jakie maszyny, w ile lokalizacji, czy backupują się serwery produkcyjne – dane + konfiguracje serwerów, czy backupuja się serwery stage/deveoperskie lokalnie w firmie, czy w ostateczności backupuja się komputery pracowników firmy – tak to też było wdrożone gdy byłem dyrektorem IT. Przez czas gdy Grupa Adweb nie miała administratora na serwerach mogło wydarzyć się „wszystko”. Jak widać po wypowiedziach Pana Bartłomieja Juszczyka, nikt nie zrobił podstawowego audytu bezpieczeństwa przy przejęciu środowiska i obsługi firmy, nie zadbano o dostępy poprzez klucze a nie hasło, co może wiązać się z obecnymi problemami.


Ad 5. Monitoring usług i serwerów – część bezpieczeństwa:

 

Wszystkie serwery, usługi, logowania do serwerów, czy nawet procesy w tle, wykonywane skrypty w danej chwili były monitorowane. Powiadomienia o stanie były wysyłane na email + sms. Co interwał były także wysyłane/zapisywane logi z serwerów z aktywnymi procesami, procesami w tle, m.in. informacją czy ktoś jest zalogowany np. poprzez SSH. Całość tych informacji była monitorowana m.in. przeze mnie. Wyłączenie którejkolwiek usługi, przeciążenie usługi, dziwne zachowanie, trafiało na email, a także kluczowe informacje były wysyłane jako sms. Serwery były zatem monitorowane. Wyłączenie monitoringu bądź jego awaria od razu także byłoby zauważone. Była to praca ciągła, ale z 2 administratorem świetnie uzupełnialiśmy się, jeśli chodzi o dbanie o środowisko.  W skrajnych wypadkach mieliśmy możliwość wyłączenia od razu całej szafy od prądu poprzez zdalne zarządzanie zasilaniem co mogło w przypadku np. dużego ataku sprawnie wyłączyć maszyny. To czy ktokolwiek przejął ten monitoring, sprawdził rozwiązania, wdrożył swoje, stoi pod znakiem zapytania. Wedle informacji jakie podaje Pan Juszczyk, z powodu niedogadania z firmą,  braku stałej firmy obsługującej   i stałego administratora, bo jak sam stwierdził miał słabego nowego admina nie było to wykonywane, a mogło zapobiec wyzerowaniu dysków. Powyższe to także standardowe praktyki które były wdrożone.


Podsumowanie

 

Nie posiadałem loginów i haseł do serwerów, ponieważ zostały one wygenerowane na nowo, gdy administrator, bądź firma wynajęta przez Pana Juszczyka zajęła się infrastrukturą, po moim odejściu z firmy. Platforma funkcjonowała poprawnie przez ponad 10 lat i mimo zdarzających się problemów zawsze wiedza i doświadczenie wygrywały.  Kontakt ze mną w grudniu i początkiem stycznia był ograniczony ponieważ przebywałem na zwolnieniu lekarskim. Pan Bartłomiej Juszczyk od chwili mojego odejścia w grudniu nie kontaktował się ze mną telefonicznie, a miał taką możliwość. Pan Bartłomiej Juszczyk z tego co mi wiadomo wysłał kilka maili na skrzynkę firmową z której podczas choroby czynnie nie korzystałem. W pewnym okresie kontakt nastąpił od pracowników Grupy Adweb  – o pomoc bo byliśmy zespołem, jednak z uwagi, że nie byli oni uprawnieni do rozmawiania ze mną o współpracy czy zlecania jakichkolwiek prac musiałem odmówić wykonywania prac, przede wszystkim z uwagi na przebywanie na zwolnieniu lekarskim.  W grudniu zaproponowałem Panu Juszczykowi możliwość dalszej współpracy i kontynuowania utrzymania i rozwoju platformy hostingowej w formie zdalnej. Chciałem to robić ponieważ całość systemu to kilkanaście lat pracy mojej i zespołu, to jakby moje dziecko. Z punktu finansowego taka umowa była bardzo korzystna dla Pana Juszczyka ponieważ obniżyłem swoje wynagrodzenie  o 50% przy formie współpracy zdalnej i opiece wyłącznie nad systemami domenowo/hostingowymi. Serwery były zarządzane zdalnie więc taka forma pracy była czymś naturalnym. Otrzymałem odpowiedź negatywną na taka możliwość współpracy.

Jest mi bardzo przykro z powodu tego, że to co tworzyłem wraz z zespołem przez kilkanaście lat, zostało zniszczone w kilkanaście dni. Cierpią na tym moi byli współpracownicy którzy są pracownikami Grupy Adweb, cierpią przede wszystkim Klienci, także moi znajomi którzy świadomie powierzyli usługi firmie rekomendowanej przez moją osobę. Jest mi także niezmiernie przykro z powodu oczerniania mojej osoby, ponieważ jeśli coś robię to wkładam w to serce.  Stąd informacje które przekazuję w tej wypowiedzi, licząc na to, że uzupełnią całokształt zaistniałej sytuacji.

Z swojej strony zależy mi na tym by, cała sprawa była transparentna, dlatego jestem chętny do współpracy i złożenia tych informacji, które przekazuje w oświadczeniu, także Prokuraturze i /lub innym organom do tego wyznaczonym.

KONIEC OŚWIADCZENIA

W0615_CA

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *