Конкретну відповідь на ваше запитання див. Https://magento.stackexchange.com/a/72700/361
Фон
По-перше, конкретного подвигу немає - є низка статей, які роблять тури в даний момент, які неправильно прочитали та неправильно зрозуміли початкову статтю.
Оригінал статті просто сказав (і я перефразую),
Якщо хакер був в змозі отримати доступ до ваших файлів Magento, вони могли б збирати інформацію від клієнта
Ключова частина - хакер, який потребує фактичного доступу до вашого сервера та зміни файлів.
Не панікуйте ... це не є специфічним для Magento
Що стосується збору інформації, для Magento немає нічого конкретного, ніж будь-який інший веб-сайт / платформа. Якщо хакер отримає доступ до ваших файлів, його фактична гра закінчиться - вони зможуть захопити будь-яку інформацію, яку вони хочуть.
Найкраще, що ви можете зробити (і, нарешті, мінімум, який ви повинні робити) - це підтримувати належну політику безпеки, яка дотримується стандартів безпеки PCI в галузі обробки платежів, список ви знайдете тут, https://www.pcisecuritystandards.org /documents/Prioritized_Approach_for_PCI_DSS_v3_.pdf
Загартуйте свій магазин
Ви дійсно можете заблокувати грані вашого магазину, що значно скорочують поверхню атаки на хакера, або, принаймні, сповільнюють їхній прогрес, якщо їм вдасться потрапити /
Блокування дозволів
Ви можете обмежити дозволи в корені документа, щоб дозволити записувати лише до основних каталогів ( /varі /media)
Це те, що ми робимо за замовчуванням у 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"
Підлаштовуйте INSTALL_PATH,SSH_USER,WEB_GROUPпід костюм. Важливо те, що ваш SSH_USERне той самий користувач, який PHP використовує для процесу веб-сервера, інакше ви, по суті, надасте повний доступ до запису на веб-сервері (пом’якшуючи будь-які переваги).
Блокуйте доступ свого адміністратора / завантажувача
У MageStack ви встановите це ___general/x.conf
set $magestack_protect_admin true;
set $magestack_protect_downloader true;
На Nginx ви можете використовувати це,
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 ;
}
Там трохи більше документації про те , як підготувати .htpasswdфайл тут
Загорніть cron.shпроцес
Я натрапив на інших хостинг-провайдерів, які використовують спеціалізовані машини для використання cron / admin - це означає, що зміна cron.shфайлу дозволить віддалено виконувати код на cron / admin, не потребуючи доступу до нього. Згортання процесу з потрібним користувачем у підробці може перейти ще трохи до блокування процесу.
Там це занадто багато коди для мене пост, але є сценарій тут . Він специфічний для MageStack, але може бути налаштований для використання на менш елегантних конфігураціях сервера :)
Аудит, аудит, аудит
Linux є фантастичним з точки зору входу в систему та використання, що дасть вам повне уявлення про те, що робить ваш сервер.
Фантастичною особливістю MageStack є інструмент аудиту, який щоденно реєструє всі види доступу та навіть зміни файлів. Ви можете знайти журнали тут,
/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
Якщо ви не використовуєте MageStack, ви можете легко повторити щось із власного хостинг-провайдера, rsyncце найпростіший інструмент для цього.
Напр. Якщо ваші резервні копії доступні локально, ви можете зробити наступне. Це дозволить порівнювати два каталоги та створити різний список виправлень.
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
Зміни PHP настільки рідкі, що ви можете запланувати це запуск щодня (або кілька разів на день) та повідомити вас електронною поштою про зміну файлу PHP.
Підводячи підсумок
- Використовуйте управління версіями, простіше відстежувати зміни
- Мати сертифікат SSL недостатньо, щоб зробити ваш сайт безпечним
- Не чекайте, щоб вас зламали, щоб розглянути питання про безпеку
- Тільки тому, що ви переспрямовуєтесь до свого постачальника шлюзових платежів (порівняно із захопленням інформації) - це не означає, що ви можете уникнути дотримання вимог PCI, вам все одно потрібно дотримуватися
- Будьте активні, будьте безпечні та ретельно - перевіряйте код модуля перед його встановленням, щодня перевіряйте файли PHP, переглядайте журнали, перевіряйте FTP / SSH доступ, регулярно міняйте паролі
Ваші клієнти покладають величезну довіру до вас, коли вони передають всю їх приватну інформацію - і якщо ви зрадите цю довіру, не працюючи в захищеному бізнесі, ви втратите їх звичай і всі майбутні звичаї.
Криміналістичні розслідування PCI неймовірно дорогі, забирають багато часу і, в кінцевому рахунку, ризикують вашою здатністю знову мати можливість здійснювати карткові платежі. Ніколи не дозволяйте себе ставити в таке становище!
Обклеїти
Останнім часом у Magento було випущено серію патчів, які фіксували отвори, включаючи деякі, які дозволяли виконувати віддалене виконання коду. Ви можете отримати їх тут, https://www.magentocommerce.com/products/downloads/magento/
Але ці нові статті не посилаються на новий подвиг, вони просто констатують, як хакери використовують історичні подвиги (або будь-який інший вектор нападу), щоб мати змогу захопити інформацію про власника картки.
Джерела