My-SQL 보안설정 가이드

My-SQL은 세계적으로 가장 널리 쓰이고 있는 대중적인 DBMS이다. My-SQL 말고라도 MS-SQL 같은 소규모DB, 또 ASP와 연동하여 쓰이는 MS-SQL 등 많은 다른 SQL이 있긴 하지만 My-SQL이 공개 소프트웨어라는 이점 때문에 다른 SQL들을 압도하고 있다.

우선 My-SQL은Linux, Apache, PHP 등과 같이 Open Source를 지향하는 Application과 환상적인 조화를 이루고 있다.

전 세계적으로 인터넷상에서 가장 많은 비중을 차지하는 서버는 Linux로서 PHP와 My-SQL의 연동은 Linux 서버의 일반적인 구성이라고 할 수 있다.

그러한 이유로 Hacker에게 가장 많은 Target 이 되는 목표이기도 하다. My-SQL 서버가 침해사고에 노출이 되었다고 의심될 경우에는 필요한 점검 절차를 알아보도록 하자.

 

 

가. 관리자 아이디를 Default로 사용하고 있는가?

My-SQL 보안에 가장 중요한 것은 디폴트 설치시 설정되지 않은 채 비어있는 데이터베이스 관리자 패스워드를 변경하는 것이다.

My-SQL의 관리자인 root는 실제 Linux(또는 Unix)시스템의 root 사용자와는 관계가 없다.

다만 그 이름이 같을 뿐이다. 따라서 침해사고 발생시 가장 먼저 해야 할 일이 바로 My-SQL 데이터베이스의 root 사용자 패스워드를 Default 상태로 운영하지 않았는지 점검하는 것이다. 이유는 My-SQL의 root라는 관리자 패스워드는 누구나가 알고 있는 사실이기 때문이다.

따라서 관리자 계정을 root가 아닌 다른 계정으로 바꾸는 것이 안전하다. 디폴트로 설정되는 관리자 계정(root)을 무차별 대입 공격이나 사전대입 공격 등으로 추측해 내기 어려운 이름으로 변경한다.

변경해 두면 설사 공격을 당하더라도 공격자는 패스워드뿐 아니라 계정정보도 추측해 내야 하기 때문에 공격은 더 어려워진다.

 

● 점검 사항

아래와 같은 방법으로 root 계정에 대한 점검을 수행하며, root 계정을 admin 계정으로 계정명을 바꾸는 예이다.

 

 

 

나. 패스워드가 설정되지 않은 DBMS 계정이 존재하는가?

패스워드가 설정되어 있지 않은 DBMS계정이 존재할 경우 인가되지 않은 일반사용자가 DBMS에 불법접속이 가능하므로 DBMS에 저장되어 있는 주요 데이터들의 파괴, 변조 등의 위험성이 존재한다.

특히“가”의 경우처럼 root 의 패스워드가 설정되지 않을 때는 누구나 My-SQL 의 root 권한으로 접속 가능하다.

 

● 점검 사항

패스워드 설정 Table 점검방법은 다음과 같다.

 

위와 같이 root의 경우 패스워드가 설정되지 않은 경우 일반유저도 데이터베이스를 root 권한으로 접속 가능해 진다.

- 패스워드가 설정되지 않았을 때 접속 예시

# mysql -u root -p

mysql>

 

● 대응 방법

패스워드가 설정되지 않은 사용자에 대해 패스워드를 설정한다.

- 방법 1. mysql>UPDATE user SET password=password‘( new-password’)

mysql>WHERE user =‘ user_name’

mysql>flush privileges;

- 방법 2. mysql>SET PASWORD for user_name=password‘( new_password’);

- 방법 3. $My-SQLadmin u username password new-password

 

 

다. Remote에서 My-SQL 서버로의 접속이 가능한가?

먼저 My-SQL이 디폴트로 리스닝하는 3306/tcp 포트를 차단해 데이터베이스가 로컬로 설치된 PHD 어플리케이션에 의해서만 사용되게 한다. 이유는 3306/tcp 포트가 My-SQL 통신포트라는 사실은 누구나 다 알고 있는 사실이기 때문에, 3306/tcp 포트를 리스닝하지 못하게 하면 다른 호스트로부터 직접 TCP/IP 접속을 해서 My-SQL 데이터베이스를 공격 할 가능성이 줄어든다. 그러나 mysql. socket 을 통한 로컬 커뮤니케이션은 여전히 가능하다.

 

● 대응 방법

3306/tcp 포트를 리스닝하지 못하게 하려면 /chroot/mysql/etc/my.cnf의 [mysqld] 부분에 다음을 추가한다.

skip-networking

데이터 백업 등의 이유로 데이터베이스로 원격에서 접속해야만 하는 경우 아래와 같이 SSH 프로토콜을 사용한다.

$ ssh mysqlserver /usr/local/mysql/bin/mysqldump -A > backup

 

 

라. My-SQL 계정을 이용한 접속이 가능한 상태인가?

My-SQL DB를 Install 하면 자동으로 서버에 My-SQL이라는 계정이 생성된다. 따라서 서버관리자들이 My-SQL 계정에 대한 관리가 소홀한 점을 이용하여 이 계정으로 서버에 불법으로 침투하는 경우가 종종 발생한다.

 

● 점검 사항

$ more /etc/passwd

My-SQL:x:60004:102::/export/home/My-SQL:/bin/sh

현재 My-SQL이라는 계정으로 외부에서 Login 가능하다.

 

● 대응 방법

/etc/passwd 파일에서 /bin/sh를 bin/false로 변경한다. 이는 My-SQL 사용자 계정을 이용한 remote Login 금지하는 옵션이다.

 

 

마. 각 시스템사용자들의 DB들에 대한 권한설정은 올바른가?

필요 이상의 권한인 어플리케이션 사용 유저에게 부여되어 있을 경우 외부의 침입자는 획득유저 권한 획득 후 DBMS를 컨트롤 할 수 있는 권한이 주어지므로, 필요 이상의 권한의 부여를 지양해야 한다.

 

● 점검 사항

아래의 경우에는 test, test＼_%, ccrco 라는 3종류의 데이터베이스 가 설정되어 있다. 특히 test, test＼_% DB는 모든 호스트의 모든 시스템 사용자에 의해 사용 가능하도록 설정되어 있음을 확인할 수 있다.

또한 ccrco DB는 localhost의 시스템의 root 유저에 의해서만 사용 가능한 상태이다.

관리 목적의 사용을 위하여 root / mysql 계정 이외에 관리목적의 계정을 만들어서 현재의 root의 권한을 부여하여 이용하고, root 사용자의 권한은 모두 revoke 시키는 것이 원칙이다.

 

● 대응 방법

test, test＼_% DB는 모든 호스트의 모든 사용자에 의해 사용 가능한 상태이므로 불필요 한 권한을 Revoke시켜야 한다.

mysql> UPDATE db SET Update_priv =‘ N’

WHERE db =‘ test’

mysql> flush privileges;

 

만약 test, test＼_% DB가 불필요한 DB라면 아래와 같이 실행하여 데이터베이스를 삭제하는 것이 안전하다.

mysql> DROP 데이터베이스 db_name

 

 

바. 데이터베이스내의 사용자별 접속/권한 설정은 올바른가?

데이타베이스에 대한 적절한 권한 설정이 되어 있지 않은 경우 dba가 아닌 사용자가 중요 테이블에 대한 조작을 할 수 있으므로 각 User 별 데이터베이스권한 설정이 적절하게 이루어져야 한다.

특히, 일반 사용자에게 File_priv, Process_priv 권한이 주어질 경우 해커에 시스템 침입의 대상이 되어 질 수 있다.

 

● 점검 사항

user 테이블 현황 점검방법은 다음과 같다.

 

위의 결과에서는 외부 호스트인 (203.xxx.xxx.237, 47, 52, 66)에서 root사용자로 로그인해 모든 작업이 가능한 상태이다. 또한 localhost에서는 ccrco와 root가 로그인하여 모든 작업이 가능한 상태이다.

 

● 대응 방법

ccrco 계정이 일반 운영용 계정이라면 특성에 따라 권한 설정을 조정할 것이 바람직하다.

또한 localhost에서 root 사용자는 모든 권한을 revoke시키고 다른 이름의 DBA계정을 만들어 사용하도록 해야 한다. 그리고 remote Login시 root사용자가 아닌 다른 사용자로 Login 하고 접근할 때 접근권한을 최소화할 것이 좋다.

 

다음은 절대 일반 사용자나 remote 사용자에게 주어져서는 안 되는 권한들을 설명한 내용이다.

- File_priv : 파일에 대한 권한

- Process_priv : 쓰레드 정보를 볼 수 있으며, 쓰레드를 중지 시킬 수 있는 권한

- Shutdown_priv : My-SQL 서버의 실행을 중지 시키는 권한

이외에 불필요한 권한은 revoke 시켜야 한다.

 

다음은 root 계정이 203.xxx.xxx.237 서버에 대한 Process_priv 서버에 대한 권한을 revoke 시키는 방법이다.

mysql> UPDATE user SET Process_priv =‘ N’

WHERE host =‘ 203.xxx.xxx.237’

AND User =‘ root’

 

 

사. 안정적인 My-SQL 버전을 사용하고 있는가?

3.22.32 미만의 버전에서는 사용자 인증처리 부분에서 버그 보고된 바 있다. 따라서 권한을 가지지 않은 일반인도 My-SQL의 모든 권한을 가지고 접근할 수 있다. 자신이 운영하고 있는 My-SQL DB의 버전을 점검해 보도록 하자.

 

● 점검 사항

위의 경우에는 안정적인 3.23.55 버전을 사용하고 있다.

 

● 대응 방법

대응방법은 간단하다. 가장 안전한 상태의 최신 버전을 다운받아 사용할 것이 가장 좋다.

 

 

아. My-SQL의 데이터 디렉터리는 안전하게 보호되고 있는가?

My-SQL은 테이블의 데이터를 파일 형태로 관리한다. 이 파일은 My-SQL 데이터 디렉터리라고 불리는 디렉터리에 저장되는데, 이 디렉터리의 권한을 잘못 설정할 경우, 서버의 일반 User가 My-SQL의 모든 데이터를 삭제해 버리는 경우도 있다. 또는 서버를 해킹한 해커에 의해서 My-SQL 데이터를 삭제해 버리는 사고도 발생한다.

이는 My-SQL의 로그파일도 마찬가지이다. My-SQL의 경우에는 Update 로그 파일이나 일반적인 로그파일에는 사용자가 패스워드를 바꾸려고 하는 쿼리도 기록된다. 따라서 로그 파일의 퍼미션이 부적절하여 DB 권한이 없는 User가 My-SQL Log 파일에 접근하여 DB 패스워드가 노출되는 경우가 발생한다.

뿐만 아니라 지정된 옵션 파일(my.cnf, my.cnf)들에 대한 접근통제도 마찬가지이다.

My-SQL 관리자는 여러 옵션을 옵션파일에 지정하여 관리를 쉽게 할 수 있으며, 이 옵션 파일들에는 root를 비롯한 일반 사용자들의 패스워드가 들어 있는 경우도 있다. 따라서 옵션 파일은 관리자나 해당 사용자만이 읽고 쓸 수 있도록 한다.

 

● 점검 사항

 

위의 예는 디렉터리의 permission이 적절하게 설정되어 있는 경우이다.

또한 에러로그(v480.err)만 생성되며 permission이 정상적으로 설정되어 있는 경우이다.

 

● 대응 방법

해당 디렉터리는 chmod 명령어를 이용하여 My-SQL 그룹 및 소유자만 사용할 수 있게 permission을 변경해야 한다.

해당 옵션 파일들에 대한 설정은 오직 소유자만이 읽고 쓸 수 있도록 설정한다.

#chmod 700 /etc/my.cnf

#chmod 700 DATADIR/my.cnf

#chmod 700 $HOME/my. cnf