EOND 스레드

이온디 1개월 전

갑자기 먹통 2025년 10월 어느 날, 레이어 디자인 스튜디오에서 연락이 왔습니다. "pnation.com 사이트 접속이 안 됩니다. 몇 주간 건드린 게 없는데 갑자기 이렇게 됐어요." pnation.com은 P-NATION의 공식 사이트입니다. 그누보드 기반으로 운영 중이었고, AWS EC2에 올라가 있었습니다. 들어가기까지가 일이었다 AWS 계정에 MFA가 걸려 있었습니다. 대표 폰으로 인증 코드가 가는 구조라 레이어에서도 바로 접근이 안 됐습니다. SSH 접속도 보안 그룹에 … 갑자기 먹통 2025년 10월 어느 날, 레이어 디자인 스튜디오에서 연락이 왔습니다. "pnation.com 사이트 접속이 안 됩니다. 몇 주간 건드린 게 없는데 갑자기 이렇게 됐어요." pnation.com은 P-NATION의 공식 사이트입니다. 그누보드 기반으로 운영 중이었고, AWS EC2에 올라가 있었습니다. 들어가기까지가 일이었다 AWS 계정에 MFA가 걸려 있었습니다. 대표 폰으로 인증 코드가 가는 구조라 레이어에서도 바로 접근이 안 됐습니다. SSH 접속도 보안 그룹에 IP 허용을 받아야 했습니다. 결국 레이어 퍼블리셔가 AWS 콘솔에서 직접 IP를 추가해줘서 SSH 접속에 성공했습니다. 원인 파악과 복구 접속 후 로그를 확인했습니다. MySQL 서비스 자체가 다운된 상태였습니다. 재시작 후 사이트 접속을 확인하고, 원인이 된 부분에 대한 점검을 진행했습니다. 약 2시간 만에 복구됐습니다. 이런 경우에 드리는 이야기 운영 중인 서버가 오랫동안 업데이트 없이 방치되면, 언제든 이런 일이 생길 수 있습니다. 유명한 사이트라고 해서 서버가 알아서 안전해지지 않습니다. 오히려 인지도가 높을수록 공격 대상이 될 가능성도 높아집니다. 서버 환경을 최신 상태로 유지하고, 정기적으로 점검하는 것이 가장 확실한 예방입니다. 운영 중인 사이트가 있다면, 마지막으로 서버 상태를 점검한 게 언제인지 한번 돌아보시길 권합니다. 레이어(lllayer.com)를 통해 의뢰된 건입니다.

원본

이온디 8년 전

서브디렉토리에 XE를 설치했을 때 백지화면이 뜰 경우Nginx 서버에서 XE를 설치할 때 root(/)에 설치할 경우 엔진엑스 설정파일을 제공합니다. 그러나 /xe/ 과 같이 서브디렉토리에 설치할 경우는 정상적으로 출력되지 않습니다. 이 경우 링크를 참조하시거나 아래 설정을 참조하시면 됩니다. Nginx 서버에서 XE를 서브디렉토리(/xe/)에 설치한 경우 rewrite rule 설정 # block direct access to templates, XML schemas, config files… 서브디렉토리에 XE를 설치했을 때 백지화면이 뜰 경우Nginx 서버에서 XE를 설치할 때 root(/)에 설치할 경우 엔진엑스 설정파일을 제공합니다. 그러나 /xe/ 과 같이 서브디렉토리에 설치할 경우는 정상적으로 출력되지 않습니다. 이 경우 링크를 참조하시거나 아래 설정을 참조하시면 됩니다. Nginx 서버에서 XE를 서브디렉토리(/xe/)에 설치한 경우 rewrite rule 설정 # block direct access to templates, XML schemas, config files, dotfiles, environment info, etc. location ~ ^/modules/editor/(skins|styles)/.+\.html$ { # pass } location ~ ^/common/manual/.+\.html$ { # pass } location ~ ^/(addons|common/tpl|files/ruleset|(m\.)?layouts|modules|plugins|themes|widgets|widgetstyles)/.+\.(html|xml)$ { return 403; } location ~ ^/files/(attach|config|cache/store)/.+\.php$ { return 403; } location ~ ^/files/env/ { return 403; } location ~ ^/(\.git|\.ht|\.travis|codeception\.|composer\.|Gruntfile\.js|package\.json|CONTRIBUTING|COPYRIGHT|LICENSE|README) { return 403; } # fix incorrect relative URLs (for legacy support) location ~ ^/(.+)/(addons|files|layouts|m\.layouts|modules|widgets|widgetstyles)/(.+) { try_files $uri $uri/ /$2/$3; } # fix incorrect minified URLs (for legacy support) location ~ ^/(.+)\.min\.(css|js)$ { try_files $uri $uri/ /$1.$2; } # rss, blogAPI rewrite ^/(rss|atom)$ /index.php?module=rss&act=$1 last; rewrite ^/([a-zA-Z0-9_]+)/(rss|atom|api)$ /index.php?mid=$1&act=$2 last; rewrite ^/([a-zA-Z0-9_]+)/([a-zA-Z0-9_]+)/(rss|atom|api)$ /index.php?vid=$1&mid=$2&act=$3 last; # trackback rewrite ^/([0-9]+)/(.+)/trackback$ /index.php?document_srl=$1&key=$2&act=trackback last; rewrite ^/([a-zA-Z0-9_]+)/([0-9]+)/(.+)/trackback$ /index.php?vid=$1&document_srl=$2&key=$3&act=trackback last; # administrator page rewrite ^/xe/admin/?$ /xe/index.php?module=admin last; rewrite ^/admin/?$ /index.php?module=admin last; # document category rewrite ^/([a-zA-Z0-9_]+)/category/([0-9]+)$ /index.php?mid=$1&category=$2 last; # document permanent link rewrite ^/([0-9]+)$ /index.php?document_srl=$1 last; # mid link rewrite ^/xe/?$ /xe/index.php?mid=$1 last; rewrite ^/xe/([a-zA-Z0-9_]+)/?$ /xe/index.php?mid=$1 last; rewrite ^/([a-zA-Z0-9_]+)/?$ /index.php?mid=$1 last; # mid + document link rewrite ^/([a-zA-Z0-9_]+)/([0-9]+)$ /index.php?mid=$1&document_srl=$2 last; # vid + mid link rewrite ^/([a-zA-Z0-9_]+)/([a-zA-Z0-9_]+)/?$ /index.php?vid=$1&mid=$2 last; # vid + mid + document link rewrite ^/([a-zA-Z0-9_]+)/([a-zA-Z0-9_]+)/([0-9]+)$ /index.php?vid=$1&mid=$2&document_srl=$3 last; # mid + entry title rewrite ^/([a-zA-Z0-9_]+)/entry/(.+)$ /index.php?mid=$1&entry=$2 last; # vid + mid + entry title rewrite ^/([a-zA-Z0-9_]+)/([a-zA-Z0-9_]+)/entry/(.+)$ /index.php?vid=$1&mid=$2&entry=$3 last; 참조 ※ #태그는 모두 구글에서 추가로 검색해볼 것 #nginx 하위 디렉토리 index#nginx 서브 디렉토리 index#AWS 서버에 nginx 설정 후 403 forbidden 에러 대처하기 / 출처 : http://miconblog.com/archives/2014/11/aws-%EC%84%9C%EB%B2%84%EC%97%90-nginx-%EC%84%A4%EC%A0%95-%ED%9B%84-403-forbidden-%EC%97%90%EB%9F%AC-%EB%8C%80%EC%B2%98%ED%95%98%EA%B8%B0/#NginX 주요 설정 (nginx.conf) / 출처 : http://sarc.io/index.php/nginx/61-nginx-nginx-conf#nginx 서브 디렉토리 인덱스#NGINX 가상호스트 사용자별 설정 예제 출처 : https://extrememanual.net/10008#[Ubuntu] 우분투 NGINX(엔진엑스) 워드프레스 설정 출처: http://webdir.tistory.com/243 [WEBDIR]#nginx index 404 Not Found /출처 : https://stackoverflow.com/questions/42437073/nginx-returns-404-not-found-error-on-sub-pages#nginx index 404 / 출처 : https://forum.nginx.org/read.php?11,3810,3830#nginx conf index sub directory / 출처 : https://serverfault.com/questions/218818/nginx-projects-in-subfoldersnginx subdirectory 404 / 출처 : https://stackoverflow.com/questions/24328628/nginx-php-fpm-subdirectorynginx index 404 / 출처 https://stackoverflow.com/questions/41099318/nginx-location-404-not-foundxe-core xe 404https://github.com/rhymix/rhymix/blob/master/common/manual/server_config/rhymix-nginx-help.mdNGINX 가상호스트 사용자별 설정 예제 / 출처 : https://extrememanual.net/10008폴더 이름 바꾸면 404 not found / 출처 : https://github.com/rhymix/rhymix/blob/master/common/manual/server_config/rhymix-nginx-subdir.confhttps://www.xetown.com/qna/639425#comment_640112

원본

이온디 1개월 전

2025년 10월 14일 오후, 레이어 디자인 스튜디오에서 연락이 왔습니다. "pnation.com 사이트 접속이 안 됩니다. 몇 주간 건드린 게 없는데 갑자기 이렇게 됐어요." pnation.com은 싸이가 대표로 있는 엔터테인먼트 레이블 P-NATION의 공식 사이트입니다. 그누보드 기반으로 운영 중이었고, AWS EC2에 올라가 있었습니다. 증상은 두 가지였습니다. mysqli_real_connect(): (HY000/2002): No such file or directory … 2025년 10월 14일 오후, 레이어 디자인 스튜디오에서 연락이 왔습니다. "pnation.com 사이트 접속이 안 됩니다. 몇 주간 건드린 게 없는데 갑자기 이렇게 됐어요." pnation.com은 싸이가 대표로 있는 엔터테인먼트 레이블 P-NATION의 공식 사이트입니다. 그누보드 기반으로 운영 중이었고, AWS EC2에 올라가 있었습니다. 증상은 두 가지였습니다. mysqli_real_connect(): (HY000/2002): No such file or directory 사이트 자체가 먹통이고, phpMyAdmin도 접속 불가. DB 서비스 자체가 죽은 상태였습니다. 들어가기까지가 일이었다 AWS 루트 계정에 MFA가 걸려 있었습니다. 대표 폰으로 인증 코드가 가는 구조라 레이어에서도 바로 접근이 안 됐습니다. SSH 접속도 보안 그룹에 IP 허용을 받아야 했습니다. 결국 레이어 퍼블리셔가 AWS 콘솔에서 직접 IP를 보안 그룹에 추가해줘서 SSH 접속에 성공했습니다. 원인은 무차별 대입 공격 접속 후 DB 로그를 확인했습니다. MySQL root 계정으로 무차별 대입 공격(Brute Force Attack)이 들어왔고, 그 과정에서 MySQL 서비스가 다운됐습니다. 서버 상태를 보니 이렇게 되어 있었습니다. OS: Amazon Linux AMI 2018.03 — EOL 상태, 보안 업데이트 없음 PHP: 7.2 DB: root 계정으로 직접 운영 (취약) 인스턴스: t2.xlarge (월 44만원) MySQL을 재시작하고 사이트 접속을 확인했습니다. 약 2시간 만에 복구됐습니다. 진단 결과 "서버 버전도 오래되고, DB 루트 권한 보안 문제도 있고." phpMyAdmin이 외부에 그대로 노출된 상태 root 계정으로 DB를 운영해서 공격 대상이 됨 OS가 EOL이라 보안 패치 자체가 불가능 t2.xlarge 오버스펙에 월 44만원 엔터테인먼트 회사 특성상 갑자기 트래픽이 몰릴 수 있어 AWS를 선택한 것 같은데, 관리 인력 없이 그냥 올려두면 이런 일이 생깁니다. 권고사항 phpMyAdmin 외부 접속 경로 변경 또는 IP 제한 MySQL root 계정 비활성화, 별도 계정 운영 OS 업그레이드 (Amazon Linux 2023) Fail2ban 설치로 무차별 대입 공격 자동 차단 그누보드 최신 버전 업데이트 보안 그룹 22번 포트 IP 제한 비용 긴급 서버 복구 기준 55만원이지만, 이번 건은 MySQL 재시작과 로그 확인 수준이었습니다. 10만원으로 처리했습니다. AWS 위에 올라간 그누보드 사이트라도 관리가 안 되면 공격받습니다. 유명한 소속사라고 해서 서버가 알아서 안전해지지 않습니다.

원본