tag

공유 호스팅

이 태그가 달린 문서 6건

2026-10-15

ConoHa WING(GMO인터넷) 일부 웹서버 무단 접근(426개 계정): 고객 웹서버 영역 데이터 영향, 사이트 운영자가 오늘 해야 할 일

2026년 9월 20일 GMO Internet, Inc.는 ConoHa WING 렌탈 호스팅 서비스의 일부 호스팅 서버(웹서버)에서 제3자가 일부 고객의 웹서버 영역에 무단으로 접근해 악성 프로그램을 설치했다고 발표했습니다. 426개 계정이 영향을 받았으며, 관련 데이터는 '고객의 웹서버 영역에 저장된 데이터'입니다. 접근 및 설치는 9월 3일 시작되었고, 회사는 9월 16일 이를 발견했으며, 9월 18일 원인과 범위를 확인하고 프로그램을 제거했습니다. 회사는 원인을 파악했다고 밝혔지만 공개하지는 않았습니다. 회원, 계약, 결제 정보는 별도 환경에서 관리되며 유출되지 않았다고 밝혔습니다. 공지에는 웹서버 영역의 데이터가 탈취되었는지 여부가 나와 있지 않습니다. 영향을 받은 고객에게는 등록된 이메일 주소로 개별 연락했으며, 연락을 받지 않은 고객은 영향을 받지 않은 것으로 안내했습니다. 10월 15일 기준 후속 공지는 없습니다. 이 사이트의 판단: 먼저 개별 이메일을 받았는지 확인하고, 받았다면 그 안내를 따르십시오. 그다음 웹서버 영역에 보관된 자격 증명(wp-config.php의 데이터베이스 비밀번호, .env의 API 키 등)은 노출된 것으로 보고 변경하며, 9월 3일 이후 추가된 파일, 관리자 계정, 예약 작업이 있는지 확인하십시오.

2026-10-11

내 웹사이트나 서버가 해킹됐는지 확인하는 법: 공유 호스팅, WordPress, VPS별 점검 순서와 발견했을 때 먼저 할 일

사이트의 침입 여부를 확인하려면 밖에서 보이는 징후와 안에 남은 흔적을 둘 다 본다. 징후: Search Console의 보안 문제 보고서, 검색 결과의 '이 사이트는 해킹되었을 수 있습니다' 표시, 호스팅 업체의 알림, 모르는 관리자, 모바일이나 검색에서 들어올 때만 일어나는 리디렉션. 흔적: 관리자 사용자, 변조된 코어 파일(wp core verify-checksums), 로그인 기록, authorized_keys, cron, 리스닝 포트, 최근 변경된 파일. 본 사이트의 견해: 아무것도 찾지 못했다고 깨끗하다는 증거는 아니다. 무언가 발견했다면 정리하기 전에 증거를 보존하고, 깨끗한 기기에서 모든 자격 증명을 교체하고, 침입 이전 백업으로 복원하거나 다시 구축하고, 침입 경로를 막은 다음에 검토를 요청한다.

2026-08-18

웹 호스팅 업체가 침해당했을 때: 고객이 해야 할 일

호스팅 업체 쪽 침해는 고객의 설정으로 막을 수 없으므로, 방어의 초점은 예방에서 잃을 수 있는 양을 줄이는 쪽으로 옮겨 간다. 9월 10일 조사 결과는 가장 중요한 부분을 확정했다. 판매 관리 시스템에 대한 부정 접근은 2023년 4월부터 2026년 3월 사이에 발생했고, 영향받은 호스팅 계정은 583건에서 951건으로 늘었으며, 일부 초기 비밀번호는 해시되지 않았다. 이 사이트의 관점: 공유 호스팅에 있는 것은 모두 읽힐 수 있다고 보고, 시크릿·자격 증명·백업을 업체 바깥으로 옮기고, 아직 쓰고 있는 초기 비밀번호는 오늘 바꾼다.

2026-06-11

공개 디렉터리에 시크릿 파일을 남겨두지 않았나요? 웹루트를 점검하라

웹루트의 모든 것은 누구나 URL로 가져갈 수 있습니다. 남겨진 토큰/자격증명 JSON, .env, 백업은 즉각 노출을 뜻하며 — 공유 템플릿에서 왔다면 모든 사이트가 같은 파일을 갖습니다. 해법: 공개 디렉터리엔 공개해도 되는 것만, 시크릿은 웹루트 밖에 권한 600으로, 하나 찾으면 모든 사이트와 호스트를 점검하기.

위험2026-06-07

Laravel의 .env가 공개적으로 읽힌 사례: 공유 호스팅의 배치 실수와 고치는 법

원인: 앱 전체가 웹 루트 아래 있었다 — public/만 보여야 한다. 세 단계로 고친다 — .htaccess로 임시 차단, 키 교체, 구조 재배치 — 그리고 프로세스로 재발을 막는다.

2026-06-07

공유 호스팅에서 .env를 공개 웹에 노출하지 않기

주된 해법: 앱 본체를 docroot 밖에, public/만 노출. 먼저 .htaccess로 접근을 막고, 재구성으로 영구화한 뒤, 자가 점검. 본 사이트의 견해: 이건 한 사람의 실수가 아니라 업계 전반의 표준이 되어 버린 위험한 배치 — 경계심이 아니라 프로세스로 고치세요. bootstrap-redirect가 심링크를 이깁니다.