Aby uzyskać szczegółową odpowiedź na twoje pytanie, patrz: /magento//a/72700/361
tło
Po pierwsze, nie ma żadnego konkretnego exploita - w tej chwili istnieje seria artykułów opisujących rundę, które źle odczytały i źle zrozumiały artykuł źródłowy.
W oryginalnym artykule tylko powiedziano (a ja parafrazuję):
Jeśli haker byli w stanie uzyskać dostęp do plików Magento, oni mogli przechwytywać informacje z klientem
Kluczową częścią jest fakt, że haker musi faktycznie uzyskać dostęp do serwera i zmodyfikować pliki.
Nie panikuj ... to nie jest nic specyficznego dla Magento
Pod względem przechwytywania informacji Magento nie ma nic konkretnego niż jakakolwiek inna strona internetowa / platforma. Jeśli haker uzyska dostęp do twoich plików, jego gra się skończy - będą w stanie przechwycić dowolne informacje, które chcą.
Najlepsze, co możesz zrobić (a ostatecznie minimum, jakie powinieneś zrobić), to utrzymać dobrą politykę bezpieczeństwa zgodną ze standardami bezpieczeństwa PCI w branży przetwarzania płatności, listę znajdziesz tutaj, https://www.pcisecuritystandards.org /documents/Prioritized_Approach_for_PCI_DSS_v3_.pdf
Zahartuj swój sklep
Możesz naprawdę zablokować aspekty swojego sklepu, które znacznie zmniejszają powierzchnię ataku hakera, a przynajmniej spowalniają ich postęp, jeśli uda im się dostać do /
Zablokuj uprawnienia
Możesz ograniczyć uprawnienia do katalogu głównego dokumentu, aby zezwolić tylko na zapis do niezbędnych katalogów ( /vari /media)
Tak właśnie robimy domyślnie w MageStack ,
echo -n "Fixing ownership"
chown -R $SSH_USER:$WEB_GROUP $INSTALL_PATH && echo " ... OK" || echo " ... ERROR"
INSTALL_PATH="/path/to/public_html"
chmod 750 $INSTALL_PATH
find $INSTALL_PATH -type d ! -perm 750 -exec chmod 750 {} \; && echo " ... OK" || echo " ... ERROR"
echo -n "Fixing file permissions"
find $INSTALL_PATH -type f ! -perm 740 -exec chmod 740 {} \; && echo " ... OK" || echo " ... ERROR"
echo -n "Fixing cron permissions"
find $INSTALL_PATH/*/cron.sh -type f ! -perm 750 -exec chmod 750 {} \; && echo " ... OK" || echo " ... ERROR"
echo -n "Fixing media/var file permissions"
chmod -R 760 $INSTALL_PATH/*/media $INSTALL_PATH/*/var && echo " ... OK" || echo " ... ERROR"
echo -n "Fixing media/var directory permissions"
find $INSTALL_PATH/*/media $INSTALL_PATH/*/var -type d ! -perm 770 -exec chmod 770 {} \; && echo " ... OK" || echo " ... ERROR"
Dopasuj INSTALL_PATH,SSH_USER,WEB_GROUPdo koloru. Ważne jest to, że nie jesteś SSH_USERtym samym użytkownikiem, którego PHP używa do procesu serwera WWW, w przeciwnym razie zasadniczo zapewniasz pełny dostęp do zapisu na serwerze WWW (co zmniejsza wszelkie korzyści).
Zablokuj dostęp administratora / downloadera
W MageStack ustawiłbyś to ___general/x.conf
set $magestack_protect_admin true;
set $magestack_protect_downloader true;
Na Nginx możesz tego użyć,
location ~* ^/(index.php/)?admin{
satisfy any;
allow x.x.x.x;
auth_basic "Login";
auth_basic_user_file /microcloud/data/domains/x/domains/x/___general/.htpasswd;
deny all;
location ~* \.(php) {
include fastcgi_params;
}
try_files $uri $uri/ /admin/index.php ;
}
Jest nieco bardziej dokumentację, jak przygotować .htpasswdplik tutaj
Zawiń cron.shproces
Natknąłem się na innych dostawców hostingu korzystających z dedykowanych maszyn do użytku cron / admin - co oznacza, że modyfikacja cron.shpliku umożliwi zdalne wykonanie kodu na cron / admin bez konieczności dostępu do niego. Podsumowanie procesu z odpowiednim użytkownikiem w fakechroocie może pójść o krok dalej, aby zablokować proces.
Nie ma zbyt dużo kodu dla mnie pisać, ale jest to skrypt tutaj . Jest specyficzny dla MageStack, ale można go dostosować do mniej eleganckich konfiguracji serwera :)
Audyt, audyt, audyt
Linux jest fantastyczny pod względem logowania i korzystania z niego, co daje pełny wgląd w to, co robi twój serwer.
Fantastyczną funkcją MageStack jest narzędzie kontrolne, które codziennie rejestruje wszystkie rodzaje dostępu, a nawet zmiany plików. Możesz znaleźć dzienniki tutaj,
/microcloud/logs_ro
|-dh[0-9]+
|---access-YYYY-MM-DD.log.gz
|---backup-YYYY-MM-DD.log.gz
|---magescan-YYYY-MM-DD.log.gz
|---php-differential-YYYY-MM-DD.log.gz
|-acc[0-9]+
|---access-YYYY-MM-DD.log.gz
Jeśli nie używasz MageStack, możesz dość łatwo powielić niektóre z nich u swojego dostawcy hostingu, rsyncbędąc najprostszym narzędziem do tego.
Na przykład. Jeśli kopie zapasowe są dostępne lokalnie, możesz wykonać następujące czynności. Spowoduje to porównanie na sucho dwóch katalogów i utworzenie listy łatek różnic.
rsync -na /path/to/public_html/ /path/to/backup/public_html/ > change.log
grep -E '\.php$' change.log | while read FILE; do
diff -wp /path/to/public_html/$FILE /path/to/backup/public_html/$FILE >> php-differential.log
done
Zmiany w PHP są tak rzadkie, że można zaplanować ich uruchamianie codziennie (lub wiele razy dziennie) i powiadamianie przez e-mail, jeśli nastąpi zmiana pliku PHP.
W podsumowaniu
- Użyj kontroli wersji, łatwiej jest śledzić zmiany
- Samo posiadanie certyfikatu SSL nie wystarczy, aby Twoja strona była bezpieczna
- Nie czekaj, aż zostaniesz zhakowany, aby rozważyć bezpieczeństwo
- Tylko dlatego, że przekierowujesz do dostawcy bramki płatności (w przeciwieństwie do przechwytywania informacji) - nie oznacza to, że możesz uniknąć zgodności z PCI, nadal musisz przestrzegać
- Bądź proaktywny, bezpieczny i dokładny - sprawdzaj kod modułu przed jego instalacją, codziennie sprawdzaj pliki PHP, przeglądaj dzienniki, sprawdzaj dostęp FTP / SSH, regularnie zmieniaj hasła
Twoi klienci obdarzają Cię ogromnym zaufaniem, gdy przekazują wszystkie swoje prywatne informacje - a jeśli zdradzisz to zaufanie, nie prowadząc bezpiecznej firmy, stracisz ich zwyczaj i wszelkie przyszłe zwyczaje.
Badania kryminalistyczne PCI są niezwykle drogie, czasochłonne i ostatecznie ryzykują twoją zdolność do ponownego przyjmowania płatności kartą. Nigdy nie daj się postawić w tej pozycji!
Połataj
Ostatnio wydano szereg poprawek z Magento, które naprawiły dziury, w tym niektóre, które umożliwiły zdalne wykonanie kodu. Możesz je pobrać tutaj, https://www.magentocommerce.com/products/downloads/magento/
Ale te nowe artykuły nie odnoszą się do nowego exploita, po prostu stwierdzają, w jaki sposób hakerzy wykorzystują historyczne exploity (lub inny wektor ataku), aby móc przechwycić informacje o posiadaczu karty.
Źródła