Audytor bezpieczeństwa naszych serwerów zażądał w ciągu dwóch tygodni:
- Lista bieżących nazw użytkowników i haseł tekstowych dla wszystkich kont użytkowników na wszystkich serwerach
- Lista wszystkich zmian haseł z ostatnich sześciu miesięcy, również w postaci zwykłego tekstu
- Lista „każdego pliku dodanego do serwera ze zdalnych urządzeń” w ciągu ostatnich sześciu miesięcy
- Klucze publiczne i prywatne dowolnych kluczy SSH
- E-mail wysyłany do niego za każdym razem, gdy użytkownik zmienia swoje hasło, zawierający zwykły tekst
Korzystamy z urządzeń Red Hat Linux 5/6 i CentOS 5 z uwierzytelnianiem LDAP.
O ile mi wiadomo, wszystko na tej liście jest niemożliwe lub niezwykle trudne do zdobycia, ale jeśli nie podam tych informacji, grozi nam utrata dostępu do naszej platformy płatności i utrata dochodów w okresie przejściowym, gdy przechodzimy do nowa usługa. Wszelkie sugestie dotyczące sposobu rozwiązania lub sfałszowania tych informacji?
Jedynym sposobem, w jaki mogę uzyskać wszystkie hasła w postaci zwykłego tekstu, jest skłonienie wszystkich do zresetowania hasła i zanotowania tego, co je ustawiło. To nie rozwiązuje problemu ostatnich sześciu miesięcy zmian haseł, ponieważ nie mogę wstecznie zalogować tego rodzaju rzeczy, to samo dotyczy rejestrowania wszystkich zdalnych plików.
Uzyskanie wszystkich publicznych i prywatnych kluczy SSH jest możliwe (choć irytujące), ponieważ mamy tylko kilku użytkowników i komputerów. Chyba że przegapiłem łatwiejszy sposób na zrobienie tego?
Wyjaśniłem mu wiele razy, że rzeczy, o które prosi, są niemożliwe. W odpowiedzi na moje obawy odpowiedział na następujący e-mail:
Mam ponad 10-letnie doświadczenie w audytach bezpieczeństwa i pełne zrozumienie metod bezpieczeństwa redhat, dlatego sugeruję sprawdzenie swoich faktów na temat tego, co jest i nie jest możliwe. Mówisz, że żadna firma nie może mieć takich informacji, ale przeprowadziłem setki audytów, w których informacje te były łatwo dostępne. Wszyscy klienci [ogólnego dostawcy przetwarzania kart kredytowych] są zobowiązani do przestrzegania naszych nowych zasad bezpieczeństwa, a ten audyt ma na celu upewnienie się, że zasady te zostały poprawnie wdrożone *.
* „Nowe zasady bezpieczeństwa” zostały wprowadzone na dwa tygodnie przed naszą kontrolą, a sześciomiesięczne rejestrowanie danych historycznych nie było wymagane przed zmianą zasad.
Krótko mówiąc, potrzebuję;
- Sposób na „sfałszowanie” sześciomiesięcznych zmian hasła i nadanie mu poprawnego wyglądu
- Sposób na „fałszywe” sześć miesięcy transferów plików przychodzących
- Łatwy sposób na zebranie wszystkich używanych kluczy publicznych i prywatnych SSH
Jeśli nie przejdziemy audytu bezpieczeństwa, stracimy dostęp do naszej platformy przetwarzania kart (krytyczna część naszego systemu) i przeniesienie się gdzie indziej zajmie dobre dwa tygodnie. Jak się pieprzę?
Aktualizacja 1 (sob. 23)
Dzięki za wszystkie odpowiedzi, z wielką ulgą wiem, że to nie jest standardowa praktyka.
Obecnie planuję odpowiedź na e-maila z wyjaśnieniem sytuacji. Jak wielu z was zauważyło, musimy przestrzegać PCI, który wyraźnie stwierdza, że nie powinniśmy mieć dostępu do haseł w postaci zwykłego tekstu. Po zakończeniu pisania wyślę wiadomość e-mail. Niestety nie sądzę, żeby nas tylko testował; te rzeczy są teraz w oficjalnej polityce bezpieczeństwa firmy. Jednak wprawiłem koła w ruch, aby na razie odsunąć się od nich i na PayPal.
Aktualizacja 2 (sob. 23)
To jest e-mail, który opracowałem, jakieś sugestie dotyczące rzeczy do dodania / usunięcia / zmiany?
Cześć [nazwa],
Niestety nie możemy dostarczyć ci niektórych wymaganych informacji, głównie haseł w postaci zwykłego tekstu, historii haseł, kluczy SSH i zdalnych dzienników plików. Jest to nie tylko technicznie niemożliwe, ale także możliwość dostarczenia tych informacji byłaby sprzeczna ze standardami PCI, a także naruszeniem ustawy o ochronie danych.
Aby zacytować wymagania PCI,8.4 Renderuj wszystkie hasła jako nieczytelne podczas transmisji i przechowywania na wszystkich komponentach systemu za pomocą silnej kryptografii.
Mogę dostarczyć listę nazw użytkowników i zaszyfrowanych haseł używanych w naszym systemie, kopie kluczy publicznych SSH i plik autoryzowanych hostów (dostarczy ci to wystarczającej ilości informacji, aby określić liczbę unikalnych użytkowników, którzy mogą połączyć się z naszymi serwerami, oraz szyfrowanie zastosowane metody), informacje o naszych wymaganiach dotyczących bezpieczeństwa haseł i naszym serwerze LDAP, ale informacji tych nie można usunąć poza witrynę. Zdecydowanie zalecamy przejrzenie wymagań dotyczących audytu, ponieważ obecnie nie możemy przekazać tej kontroli, zachowując zgodność z PCI i ustawą o ochronie danych.
Pozdrawiam
[ja]
Będę współpracownikiem w CTO firmy i naszym menedżerze konta i mam nadzieję, że CTO potwierdzi, że te informacje nie są dostępne. Skontaktuję się również z Radą Bezpieczeństwa Standardów PCI, aby wyjaśnić, czego od nas wymaga.
Aktualizacja 3 (26)
Oto niektóre e-maile, które wymieniliśmy;
RE: mój pierwszy e-mail;
Jak wyjaśniono, informacje te powinny być łatwo dostępne w każdym dobrze utrzymanym systemie dla każdego kompetentnego administratora. Brak możliwości dostarczenia tych informacji prowadzi mnie do przekonania, że znasz luki w zabezpieczeniach systemu i nie jesteś przygotowany na ich ujawnienie. Nasze żądania są zgodne z wytycznymi PCI i oba mogą zostać spełnione. Silna kryptografia oznacza tylko, że hasła muszą być szyfrowane podczas wprowadzania ich przez użytkownika, ale następnie należy je przenieść do formatu umożliwiającego odzyskanie w celu późniejszego wykorzystania.
Nie widzę żadnych problemów związanych z ochroną danych w przypadku tych wniosków, ochrona danych dotyczy tylko konsumentów, a nie firm, więc nie powinno być problemów z tymi informacjami.
Tylko czego ja nie mogę, nawet ...
„Silna kryptografia oznacza tylko, że hasła muszą zostać zaszyfrowane podczas wprowadzania ich przez użytkownika, ale następnie należy je przenieść do formatu umożliwiającego odzyskanie w celu późniejszego wykorzystania”.
Zamierzam to wrobić i położyć na ścianie.
Mam dość bycia dyplomatycznym i skierowałem go do tego wątku, aby pokazać mu odpowiedź:
Podanie tych informacji BEZPOŚREDNIO jest sprzeczne z kilkoma wymogami wytycznych PCI. Sekcja, którą zacytowałem, mówi nawet
storage
(implikując, gdzie przechowujemy dane na dysku). Rozpocząłem dyskusję na ServerFault.com (społeczność internetowa dla specjalistów sys-admin), która wywołała ogromną reakcję, sugerując, że nie można podać tych informacji. Zapraszam do przeczytania przez siebiehttps://serverfault.com/questions/293217/
Zakończyliśmy przenoszenie naszego systemu na nową platformę i zlikwidujemy nasze konto w ciągu około dnia, ale chcę, abyś zdał sobie sprawę, jak absurdalne są te żądania i żadna firma prawidłowo wdrażająca wytyczne PCI nie będzie lub powinna, być w stanie podać te informacje. Zdecydowanie zalecamy ponowne przemyślenie swoich wymagań bezpieczeństwa, ponieważ żaden z klientów nie powinien być w stanie się z tym pogodzić.
(Właściwie to zapomniałem, że nazwałem go idiotą w tytule, ale jak już wspomniano, już odeszliśmy od ich platformy, więc nie ma prawdziwej straty).
W swojej odpowiedzi stwierdza, że najwyraźniej nikt z was nie wie o czym mówisz:
Przeczytałem szczegółowo te odpowiedzi i twój oryginalny post, wszyscy respondenci muszą poprawnie ustalić swoje fakty. Byłem w tej branży dłużej niż ktokolwiek na tej stronie, uzyskanie listy haseł do kont użytkowników jest niezwykle proste, powinna być jedną z pierwszych rzeczy, które robisz, ucząc się, jak zabezpieczyć system i jest niezbędna do działania każdego bezpiecznego serwer. Jeśli naprawdę brakuje ci umiejętności robienia czegoś tak prostego, zakładam, że nie masz zainstalowanego PCI na swoich serwerach, ponieważ odzyskanie tych informacji jest podstawowym wymaganiem oprogramowania. Kiedy masz do czynienia z czymś takim jak bezpieczeństwo, nie powinieneś zadawać tych pytań na forum publicznym, jeśli nie masz podstawowej wiedzy o tym, jak to działa.
Chciałbym również zasugerować, że każda próba ujawnienia mnie lub [nazwa firmy] zostanie uznana za pomówienie i zostaną podjęte odpowiednie kroki prawne
Kluczowe punkty idiotyczne, jeśli je przegapiłeś:
- Był audytorem bezpieczeństwa dłużej niż ktokolwiek inny tutaj (zgaduje lub prześladuje cię)
- Możliwość uzyskania listy haseł w systemie UNIX jest „podstawowa”
- PCI jest teraz oprogramowaniem
- Ludzie nie powinni korzystać z forów, gdy nie są pewni bezpieczeństwa
- Udostępnianie informacji faktycznych (na które mam dowód e-mailem) w Internecie jest zniesławieniem
Doskonały.
PCI SSC udzieliło odpowiedzi i prowadzi dochodzenie w sprawie jego i firmy. Nasze oprogramowanie zostało teraz przeniesione do PayPal, dzięki czemu wiemy, że jest bezpieczne. Zaczekam, aż PCI do mnie wróci, ale trochę się martwię, że mogli używać tych praktyk bezpieczeństwa wewnętrznie. Jeśli tak, to uważam, że jest to dla nas poważny problem, ponieważ wszystkie nasze karty przetwarzały je. Gdyby robili to wewnętrznie, myślę, że jedyną odpowiedzialną rzeczą byłoby poinformowanie naszych klientów.
Mam nadzieję, że kiedy PCI zda sobie sprawę, jak źle jest, zbadają całą firmę i system, ale nie jestem pewien.
Więc teraz odeszliśmy od ich platformy i zakładając, że minie co najmniej kilka dni, zanim PCI wróci do mnie, jakieś pomysłowe sugestie, jak go trochę trollować? =)
Kiedy otrzymam zezwolenie od mojego legalnego faceta (bardzo wątpię, czy to w rzeczywistości jest zniesławienie, ale chciałem dwukrotnie sprawdzić) opublikuję nazwę firmy, jego imię i adres e-mail, a jeśli chcesz, możesz skontaktować się z nim i wyjaśnić dlaczego nie rozumiesz podstaw zabezpieczeń Linuxa, takich jak jak uzyskać listę wszystkich haseł użytkowników LDAP.
Mała aktualizacja:
Mój „legalny facet” zasugerował, że ujawnienie firmy prawdopodobnie spowodowałoby więcej problemów niż to konieczne. Mogę jednak powiedzieć, że nie jest to główny dostawca, mają mniej 100 klientów korzystających z tej usługi. Początkowo korzystaliśmy z nich, gdy witryna była niewielka i działała na małym VPS, i nie chcieliśmy podejmować wszystkich starań, aby uzyskać PCI (zwykliśmy przekierowywać do ich interfejsu, na przykład PayPal Standard). Ale kiedy przeszliśmy na bezpośrednie przetwarzanie kart (w tym uzyskanie PCI i zdrowy rozsądek), deweloperzy postanowili nadal używać tej samej firmy tylko innego API. Firma ma siedzibę w rejonie Birmingham w Wielkiej Brytanii, więc bardzo wątpię, czy ktokolwiek tutaj będzie miał wpływ.