오래된 서버의 경우 커널과 필수 패키지를 업데이트 하는 게 좋습니다. 보안 패치를 무시하게 되면 해커에 먹이가 될 수 있게 때문 입니다. 현재 Cent OS7의 경우 지원이 2024.06.30 마지막 커널이며 버전은 3.10.0 입니다. 해당 서버는 운영 중이라서 추가 업데이트가 어려워서 DB 서버로만 사용하고 있으며 외부 유입은 허용된 ip 허용만 되어 있습니다.
시스템 상태 점검 및 부팅 기록 확인
부팅 이력 및 가동 시간 조회
서버 유지보수를 시작하기 전, 시스템이 언제 마지막으로 재부팅되었는지 확인하는 습관이 필요합니다. 장기간 재부팅되지 않은 서버는 업데이트 적용 후 서비스가 정상적으로 올라오는지 모니터링이 필요하기 때문입니다. 전체 재부팅 기록을 확인하려면 last 명령어를, 가장 최근 부팅 시간만 간결하게 확인하려면 who 명령어를 사용합니다.
uptime 명령어를 사용하면 현재 시스템이 얼마나 오랫동안 가동 중인지 초 단위까지 역추적할 수 있습니다. 이는 작업 전후의 시스템 상태 변화를 비교하는 데 중요한 지표가 됩니다. 만약 커널 업데이트가 예정되어 있다면, 작업 후 재부팅 시점이 명확히 기록되는지 교차 검증해야 합니다.
# 전체 재부팅 기록 확인 last reboot # 마지막 부팅 시간 확인 who -b # 시스템 가동 시간 확인 uptime -s
CentOS 7 핵심 보안 패키지 수동 업데이트
보안 업데이트 누락 문제 해결
CentOS 7은 공식 지원이 종료(EOL)되었기 때문에 리포지토리의 메타데이터가 정상적으로 갱신되지 않는 경우가 빈번합니다. 이로 인해 yum update --security 명령어를 실행해도 '업데이트할 패키지가 없다'는 잘못된 메시지가 출력될 수 있습니다. 실제로는 수백 개의 패키지 업데이트가 대기 중임에도 보안 패치만 필터링하는 기능이 작동하지 않는 것입니다.
이 상태를 방치하면 2017년도 수준의 구형 커널을 계속 사용하게 되어 최신 보안 위협에 노출됩니다. 전체 업데이트(yum update)를 진행할 경우 PHP나 MySQL 버전이 변경되어 기존 웹 서비스와 충돌할 위험이 있으므로, 핵심 보안 패키지만 골라서 업데이트하는 전략이 필요합니다.
주요 4대 보안 패키지 선별 설치
서비스 호환성에 영향을 최소화하면서 보안 수준을 높이기 위해 커널(kernel), 암호화 통신(openssl, openssh), 그리고 쉘(bash) 패키지만 수동으로 지정하여 업데이트합니다. 이들은 운영체제의 뼈대와 통신 보안을 담당하는 핵심 요소로, 웹 소스코드와 충돌할 확률이 매우 낮습니다.
업데이트 명령어를 실행한 후에는 반드시 현재 설치된 커널 버전과 실행 중인 커널 버전을 비교해야 합니다. 업데이트 직후에는 버전이 다르게 표시되므로, 재부팅(reboot)을 수행하여 새로운 보안 커널을 시스템에 로드해야만 패치가 완료됩니다.
# 핵심 보안 패키지 4종만 업데이트 yum update kernel openssl openssh bash # 업데이트 후 버전 비교 (재부팅 전) rpm -q kernel | tail -1 uname -r # 시스템 재부팅 reboot
TCP Wrappers를 이용한 SSH 접근 제어
허용 IP 등록 및 전체 차단 설정
SSH(22번 포트)는 해커들의 무차별 대입 공격(Brute Force Attack)이 가장 빈번하게 일어나는 경로입니다. 이를 방어하기 위해 특정 IP에서만 접속이 가능하도록 설정해야 합니다. 리눅스의 TCP Wrappers 기능을 활용하면 방화벽을 건드리지 않고도 hosts.allow와 hosts.deny 파일 수정만으로 즉시 접근 제어가 가능합니다.
설정 순서는 반드시 '허용'을 먼저 등록하고 '차단'을 나중에 설정해야 합니다. 관리자 PC의 IP와 비상시 우회 접속을 위한 보조 서버의 IP를 hosts.allow 파일에 등록합니다. 그 후 hosts.deny 파일에 모든 접속을 거부하는 규칙을 추가하면, 허용된 IP 외의 모든 접근 시도는 연결 단계에서 즉시 차단됩니다.
※ IP 보안을 위해 아래는 사용하는 IP가 아니므로 사용자 환경에 맞게 변경하세요.
# 1. 허용할 IP 등록 (vi /etc/hosts.allow) # 관리자 PC 및 보조 서버 IP 입력 sshd: 10.10.10.5 sshd: 192.168.0.100 # 2. 나머지 모든 접속 차단 (vi /etc/hosts.deny) # 반드시 맨 아랫줄에 추가 sshd: ALL
설정 검증 및 주의사항
이 설정은 파일을 저장하는 즉시 실시간으로 적용되므로 서비스를 재시작할 필요가 없습니다. 하지만 설정 중 실수로 본인의 접속이 차단될 수 있으므로, 현재 연결된 터미널 창을 유지한 상태에서 새로운 터미널 창을 열어 접속 테스트를 진행해야 합니다.
정상적으로 설정되었다면 허용되지 않은 IP(예: 스마트폰 LTE망)로 접속 시도 시 비밀번호 입력창이 뜨기도 전에 'Connection closed' 또는 'Access denied' 메시지가 나타나야 합니다. 반대로 허용된 IP에서는 정상적으로 로그인 프롬프트가 출력됩니다.
FirewallD를 활용한 DB 포트 관리
서비스별 보안 전략 수립
서버 운영 환경에 따라 보안 정책을 유연하게 적용해야 합니다. 관리자 접속용 SSH는 고정 IP를 통해 철저히 통제할 수 있지만, 데이터베이스(3306 포트)는 다수의 현장에서 유동 IP로 접속해야 하는 경우가 많습니다. 이 경우 IP 제한을 걸면 현장 업무가 마비될 수 있습니다.
따라서 SSH는 앞서 설정한 TCP Wrappers(hosts.allow)로 보호하고, DB 포트는 방화벽(FirewallD)을 통해 전체 개방하는 전략을 사용합니다. 방화벽이 꺼져 있다면 모든 포트가 위험에 노출되므로, 반드시 방화벽을 활성화한 후 필요한 포트만 열어주는 화이트리스트 방식을 적용해야 합니다.
FirewallD 설정 및 적용
FirewallD를 활성화하면 기본적으로 들어오는 모든 연결이 차단됩니다. 따라서 SSH 서비스가 차단되지 않도록 명시적으로 허용한 후, 업무에 필요한 DB 포트(3306)를 추가해야 합니다. 설정을 마친 후에는 반드시 reload 명령어로 규칙을 메모리에 적용하고, list-all 명령어로 설정 상태를 최종 확인합니다.
이 설정을 통해 SSH는 지정된 IP에서만 접근 가능하고, DB는 어디서든 접근 가능한 상태가 됩니다. 단, DB 포트가 전 세계에 열려 있으므로 데이터베이스 계정의 비밀번호는 반드시 복잡하게 설정하여 무차별 대입 공격에 대비해야 합니다.
# 1. 방화벽 실행 및 자동 시작 등록 systemctl start firewalld systemctl enable firewalld # 2. SSH 서비스 허용 (차단 방지) firewall-cmd --permanent --add-service=ssh # 3. DB 포트(3306) 전체 개방 firewall-cmd --permanent --add-port=3306/tcp # 4. 설정 적용 및 확인 firewall-cmd --reload firewall-cmd --list-all
