MySQL 외부 접근 차단, 이렇게 하면 불필요한 공격 로그를 줄인다

병원 웹서버에서 DB 비밀번호가 복잡하다고 해서 안전하다고 볼 수는 없습니다. 3306 포트가 외부에 열려 있으면 계속 시도가 들어오고, 그래서 MySQL 외부 접근 차단은 기본 점검 항목이어야 합니다.

실제로 포트 점검을 하다가 3306이 외부에서 접근 가능한 상태를 발견한 적이 있습니다. 비밀번호는 복잡했지만 무차별 대입 시도 로그가 쌓이고 있었고, iptables와 bind-address 설정을 적용한 뒤 로그가 사라졌습니다. 이 경험 이후 MySQL 외부 접근 차단을 신규 서버 체크리스트에 넣었습니다.

먼저 노출 여부 확인

외부 PC나 별도 점검 환경에서 포트를 확인합니다. 내부 서버에서만 확인하면 방화벽 바깥 상태를 놓칠 수 있습니다.

nmap -p 3306 example.com

열려 있다면 DB가 꼭 외부 접속을 받아야 하는지부터 판단합니다. 병원 홈페이지와 DB가 같은 서버이거나 같은 내부망이라면 외부 공개가 필요 없는 경우가 많습니다.

확인할 항목은 다음과 같습니다.

1. DB 접속이 로컬에서만 필요한지
2. 외부 관리자가 직접 DB 접속을 하는지
3. 방화벽에서 3306이 열려 있는지
4. MySQL 설정이 전체 주소로 바인딩되어 있는지

iptables 차단 예시

MySQL 외부 접근 차단은 방화벽에서 먼저 막는 것이 좋습니다. 아래는 일반적인 예시이며, 실제 적용 전에는 서버 정책과 관리 도구를 확인해야 합니다.

iptables -A INPUT -p tcp --dport 3306 -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p tcp --dport 3306 -j DROP

클라우드 방화벽이나 보안 그룹을 쓰는 환경이라면 그쪽에서도 3306 인바운드를 닫아야 합니다. 서버 안쪽과 바깥쪽을 같이 막아야 이중 차단이 됩니다.

my.cnf 설정

MySQL 설정에서도 로컬만 듣도록 제한합니다. 대표적으로 아래 항목을 확인합니다.

[mysqld]
bind-address = 127.0.0.1

설정 변경 후에는 MySQL을 재시작하고 애플리케이션 접속이 정상인지 확인합니다. MySQL 외부 접근 차단 후 홈페이지가 DB에 연결되지 않는다면 워드프레스 설정의 DB_HOST 값과 서버 구조를 다시 봐야 합니다.

외부 관리는 SSH 터널로

외부에서 DB 관리가 필요하다면 포트를 직접 열기보다 SSH 터널을 쓰는 편이 낫습니다.

ssh -L 3307:127.0.0.1:3306 user@example.com

이후 로컬 DB 도구에서는 127.0.0.1:3307로 접속합니다. 실제 서버 계정이나 IP는 공개 문서에 남기지 말고 내부 절차서에만 보관합니다.

운영 기준

MySQL 외부 접근 차단은 공포 마케팅이 아니라 기본 위생에 가깝습니다. DB 포트가 닫혀 있으면 공격자가 시도할 면적이 줄고, 로그도 훨씬 읽기 쉬워집니다.

정리하면 방화벽에서 3306을 닫고, MySQL은 127.0.0.1만 듣게 하고, 외부 관리는 SSH 터널로 처리합니다. 병원 홈페이지 서버 점검 시 MySQL 외부 접근 차단 여부를 매번 확인하면 불필요한 위험을 줄일 수 있습니다.