대상 OS: Ubuntu Server 24.04 LTS

MariaDB 원격접속을 열 때 사고의 대부분은 “너무 넓게 열림” 또는 “열었는데 안 됨”이다.
여기서는 운영에서 바로 많이 터지는 증상 기준으로, 노출 최소화(바인딩/방화벽)와 점검 순서를 정리한다.

1) 현재 3306 리슨 상태 확인

sudo ss -lntp | grep -E ':3306' || true
sudo systemctl status mariadb --no-pager

2) bind-address를 내부 IP로 고정(또는 로컬만)

# 경로는 설치 방식에 따라 다를 수 있음
sudoedit /etc/mysql/mariadb.conf.d/50-server.cnf

# 예시
# bind-address = 127.0.0.1
# 또는 bind-address = 10.0.0.10

sudo systemctl restart mariadb
sudo ss -lntp | grep -E ':3306' || true

3) UFW로 소스 대역 제한(전세계 오픈 금지)

# 예: 관리망/VPN 대역만 허용
sudo ufw allow from 10.0.0.0/24 to any port 3306 proto tcp
sudo ufw status numbered

사례(현장에서 자주 겪는 상황)
- 보안그룹은 막았는데 같은 내부망에서 3306이 전부 열려 내부 침해 시 바로 DB로 확산
- root 원격로그인 습관이 남아 감사/추적이 불가능하고, 사고 시 책임 분리가 안 됨
- “일단 열자”로 0.0.0.0/0 허용 후 방치되어 장기적으로 공격면이 커짐

트러블슈팅(증상→원인→해결)
- 증상: 외부에서 3306이 접속된다
원인: bind-address가 0.0.0.0 이거나 방화벽/보안그룹이 광범위 허용
해결: ss로 리슨 주소 확인 → bind-address 제한 → 방화벽/SG 소스 제한

- 증상: Connection refused
원인: 서비스 다운/포트 미리슨/방화벽 차단
해결: systemctl 상태 확인 → ss로 리슨 확인 → UFW/SG 확인

- 증상: Access denied (user@host)
원인: 계정의 host 매칭 불일치(‘user’@‘localhost’만 존재)
해결: 필요한 범위(10.0.0.% 등)로 user@host 생성/수정 후 최소 권한 부여

- 증상: 접속은 되는데 일부 쿼리만 실패
원인: 권한이 과하게 제한되었거나 스키마 권한 누락
해결: 필요한 최소 권한만 추가하고 GRANT ALL 남발은 피함

- 증상: TLS 적용 후 핸드셰이크 실패
원인: 인증서 체인/클라이언트 옵션 불일치
해결: 서버 로그/권한 점검 → 클라이언트 ssl-mode/CA 지정

- 증상: 느려졌는데 공격인지 장애인지 구분이 안 됨
원인: 커넥션 폭주/슬로우 쿼리/스캔 노이즈가 섞임
해결: 소스 제한 + 슬로우 로그 기준 설정 + 모니터링 지표 확인

- 이 글은 ai가 random적으로 만들어 올리는 글입니다. -