고객 신용 카드 데이터를 수집하기 위해 해킹 당했다고 생각되는 사이트를 사용하고 있지만 확실하지 않습니다.
나는 하지 않았다 내가 여러 기사에서 제시 본 적이 일반적인 장소에서 의심스러운 코드를 찾을 수 있습니다.
나는 한 의심스러운 "깨진"이미지 파일을 찾을 수 :
/skin/adminhtml/default/default/images/db-tab-bottom-right-bg_bg.gif
파일 확장명을 변경하고 파일 확장자를 열었지만 JPEG-1.1흩어져있는 암호화 된 텍스트의 벽 일뿐 입니다.
사이트가 손상되었는지 어떻게 알 수 있습니까?
패치가 적용되었음을 확인했지만 패치 전에 해킹이 발생했을 수 있습니다.
편집 : 영향을받는 버전은 1.7.0.2입니다
답변:
귀하의 질문에 대한 구체적인 답변은 /magento//a/72700/361을 참조 하십시오.
첫째, 특정 악용은 없습니다. 현재 기사를 잘못 읽고 이해 한 일련의 기사가 있습니다.
원래의 기사는 , 단지 말했다 (내가 의역하고 있습니다)
해커 가 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_USERPHP가 웹 서버 프로세스에 사용하는 사용자와 동일하지 않다는 것 입니다. 그렇지 않으면 본질적으로 웹 서버에 대한 완전한 쓰기 액세스를 제공해야합니다 (모든 이점을 완화 함).
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.gzMageStack을 사용하지 않는 경우 rsync가장 간단한 도구 인 자체 호스팅 제공 업체와 함께이 중 일부를 아주 쉽게 복제 할 수 있습니다 .
예 : 백업이 로컬에서 사용 가능한 경우 다음을 수행 할 수 있습니다. 이것은 두 디렉토리를 건식 실행하고 diff 패치 목록을 생성합니다.
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
donePHP 변경은 너무 드물기 때문에 매일 (또는 매일 여러 번) 실행되도록 예약하고 PHP 파일 변경이있을 경우 이메일로 알려줄 수 있습니다.
고객은 모든 개인 정보를 전달할 때 엄청난 신뢰를 받고 있습니다. 안전한 비즈니스를 운영하지 않아서 그 신뢰를 배신하면 고객의 관습과 미래의 모든 관습을 잃게됩니다.
PCI 포렌식 조사는 엄청나게 비싸고 시간이 많이 걸리며 궁극적으로 카드 결제를 다시 할 수 없게 될 위험이 있습니다. 자신을 그 자리에 두지 마십시오!
요즘 Magento에서 원격 코드 실행을 허용하는 패치를 포함한 일련의 패치가 수정되었습니다. https://www.magentocommerce.com/products/downloads/magento/에서 가져올 수 있습니다.
그러나이 새로운 기사는 새로운 익스플로잇을 언급하는 것이 아니라 해커가 과거의 익스플로잇 (또는 다른 공격 경로)을 활용하여 카드 소지자 정보를 캡처 할 수있는 방법을 설명하고 있습니다.
출처
다른 답변이 실제로 질문에 답변하지 않았기 때문에 다른 답변을 추가하고 있습니다. 더 이상은 더 이상 필요하지 않습니다!
궁극적으로는 할 수 없습니다. 때로는 눈에 띄는 지표가 있습니다.
예 :
그러나 컨텐츠가 단순한 텍스트가 아닌 경우 컨텐츠를 판별하기 위해 2 진 파일의 컨텐츠를 요약하는 것이 특히 어려울 수 있습니다.
가장 일반적으로는 내가 가진 파일에 일반 텍스트 데이터를 쓰는 포함하지 않는 본 적이 악용 .jpg|png|gif|etc확장, 그들은 일반적으로 (예. 데이터를 당황하게하는 인코딩 / 암호화의 어떤 종류를 포함 base64하거나 mcrypt등). 이것은 간단한 grep이 작동하지 않음을 의미합니다.
당신은 할 수 있습니다 (그리고 이것은 결코 철저하지는 않습니다) ...
비정상적으로 큰 파일 찾기
find \
/path/to/public_html/skin \
/path/to/public_html/media \
-type f -size +20M 2>/dev/nullCC 정규식과 일치하는 파일 찾기
grep -lE '([0-9]+\-){3}[0-9]{4}|[0-9]{16}' \
/path/to/public_html/skin \
/path/to/public_html/media 2>/dev/null이미지 파일이 유효한지 확인
find \
/path/to/public_html/skin \
/path/to/public_html/media -type f \
-regextype posix-egrep -regex '.*\.(jpg|gif|png|jpeg)' |\
xargs identify 1>/dev/null또는
find \
/path/to/public_html/skin \
-name '*' -exec file {} \; | grep -v -o -P '^.+: \w+ image'설치 파일을 비교하는 가장 쉬운 방법은 깨끗한 복사본과 코어를 비교하는 것입니다. 이것은 테마 파일을 설명하지 않지만 설치에서 수천 개의 파일을 확인하는 데 먼 길을갑니다.
과정은 정말 쉽습니다.
예 : 마 젠토 버전 1.7.0.2
wget sys.sonassi.com/mage-install.sh -O mage-install.sh
bash mage-install.sh -d -r 1.7.0.2
tar xvfz latest-magento.tar.gz
diff -w --brief -r magento-ce-*/app/code/core app/code/core
diff -w --brief -r magento-ce-*/lib lib이전 Magento 릴리즈는 (불쾌하게) 패치되지 않았으므로 코어 diff를 수행하면 변경 사항이 표시됩니다. 이를 방지하려면 새로 다운로드 한 클린 소스에 패치를 적용한 후 다시 확인하십시오.
훌륭한 글이지만 불행히도 모든 것이 똑같이 만들어지는 것은 아닙니다.
공유 호스팅이 대중화되면서 사람들이 동일한 서버에서 다른 사람의 컨텐츠를 볼 수 없도록하는 것이 더욱 중요해졌습니다. FreeBSD 감옥이 출현 할 때까지 이것은 다음을 의미했습니다.
이렇게하면 웹 서버 프로세스와 계정 소유자가 같은 컴퓨터의 다른 사용자에게 액세스 권한을 부여하지 않으면 서 계정 소유자가 HTML 파일을 수정할 수있었습니다.
이것은 크게 변하지 않았으며 공유 호스팅 (CPanel, DirectAdmin, Plex)에 맞춘 소프트웨어 패키지는 모두 이러한 원칙을 사용합니다. 이는 주요 진입 점 (웹 서버 및 / 또는 스크립트 인터프리터)이 계정의 모든 파일에 쓸 수있어 파일 권한을 쓸모 없게 만듭니다.
CC 데이터가 실제로 서버로 전송되는지, 그렇다면 암호화되지 않은 상태로 전송 된 경우 CC 지불 제공자에게 알리십시오. 요즘 JavaScript는 매우 강력하며 고객의 JavScript 엔진을 사용하여 서버로 전송하기 전에 중요한 정보를 암호화하는 Payment Service Provider가 있습니다. 이 정보 수집기는 암호화 된 데이터뿐만 아니라 세션 키를 얻을 수 있지만 수집 된 데이터가 더 크고 봇의 AI는 훨씬 더 복잡하므로 수집기는 흥미롭지 않습니다. .
TripWire의 환생을 보았을 때 15 년이 넘는 유닉스는 여전히 내 얼굴에 그리운 미소를 짓고 있습니다. 이것도 좋은 도구입니다. 사이트 로컬 수정이 더 빈번한 설치보다 더 빈번하기 때문에 추가를 고려하지 않고 다시 좋은 도구를 사용하기 때문에 알려진 좋은 버전과 비교하면 다소 적습니다.
다운로더를 문서 루트 외부로 이동하는 것은 HTTP 인증 형식을 설치하는 것만 큼 쉽습니다. 그런 다음 사용시에만 다시 넣으십시오. 이것이 실용적이지 않다면 다른 사용자 / 비밀번호 레이어가 아닌 원격 주소, 특히 일반 텍스트로 비밀번호를 보내는 레이어를 기준으로 잠금을 선호합니다.
웹 응용 프로그램 방화벽은 공격의 스캔 단계에서 이미 많은 문제를 방지 할 수 있습니다. 불행히도, 이들은 고가의 블랙 박스이지만 일부 대안이 있습니다.
나는 우리가 많은 것들을 다루었다고 생각하지만 내 petpeeve로 끝내도록하겠습니다.
FTP 사용 중지
그곳에. 내가 말했어. 그리고 여기에 가십시오 : https://wiki.filezilla-project.org/Howto