- 요약 키워드: 저장 위치, 인증 매커니즘, HttpOnly, Secure, SameSite, 세션 하이재킹 방어
- 데이터 관리 방식 및 보안 하드닝 가이드:
HTTP는 상태를 유지하지 않는 프로토콜이므로, 클라이언트의 상태 정보를 지속적으로 추적하고 관리하기 위해 쿠키와 세션 컴포넌트를 운용합니다.
쿠키: 웹 서버가 생성하여 브라우저의 로컬 스토리지에 텍스트 파일 형태로 저장하는 키-값 쌍의 데이터셋입니다. 매 요청마다 헤더에 실려 서버로 전송되므로 파일 탈취 및 스니핑 위험에 노출됩니다.
세션: 클라이언트의 민감한 상태 정보를 브라우저가 아닌 웹 서버 단의 안전한 메모리나 DB에 저장하고 관리하는 매커니즘입니다. 서버는 클라이언트 구분을 위해 고유한 임의의 문자열인 세션 ID(Session ID)를 발급한 뒤, 이 ID만 쿠키에 담아 클라이언트에 전달합니다.
🚨 위험: 쿠키 및 세션 도용 차단을 위한 필수 보안 설정
1. HttpOnly 속성 활성화: 브라우저에서 자바스크립트를 통해 쿠키 데이터에 접근하는 것을 원천 차단합니다. 이를 통해 웹 애플리케이션의 대표적인 취약점인 XSS 공격을 당하더라도 세션 ID 쿠키가 해커에게 탈취당하는 대참사를 방어합니다. 2. Secure 속성 지정: 해당 쿠키는 오직 암호화된 HTTPS 통신 패킷 채널을 통해서만 전송되도록 강제합니다. 평문 HTTP 통신 도중 일어날 수 있는 네트워크 스니핑 공격에 의한 세션 ID 유출을 방어합니다. 3. 만료 정책 제어: 인증용 중요 쿠키는 브라우저가 닫히면 메모리에서 즉시 소멸하는 세션 쿠키로 설정하거나, 유효기간을 최소화하여 로컬 디스크 상에 영구 적재되는 것을 제약해야 합니다. 4. 보안 방법론 수립: 패스워드 등 민감한 중요 정보는 절대로 쿠키에 담지 말고 서버 세션에만 은닉해야 합니다. 비즈니스 로직 상 불가피하게 쿠키에 기록해야 하는 가용 데이터가 있다면 AES-256 등 대칭키 기반의 암호화를 거친 후 무결성 검증용 해시를 첨부해야 안전합니다.
(2) HTTP Cache-Control 헤더의 검증
- 요약 키워드: max-age=0, no-cache, no-store, 원 서버 검증, 재유효성 평가
- 캐시 메커니즘 동작 원리 비교:
웹 브라우저 및 중간 프록시 서버의 캐시 자원 제어를 위해 사용하는 두 옵션은 자원의 유효 기간 판단 및 재검증 프로세스 단에서 명확한 차이를 보입니다.
동작 메커니즘 (신선한 상태, Fresh): 지정한 시간(예: 3600초 = 1시간)이 지나지 않았다면, 브라우저나 중간 캐시 서버는 원본 서버로 HTTP 요청을 아예 전송하지 않습니다. 요청을 가로채서 자체 저장소에 있는 데이터를 즉시 반환하며, 이때 HTTP 응답 코드는 200 OK (from memory cache) 형태로 나타납니다. 네트워크 트래픽과 서버 연산이 전혀 발생하지 않는 상태입니다.
만료된 상태 (Stale): 지정한 시간이 1초라도 지나면 캐시된 데이터는 '만료(Stale)'된 것으로 간주됩니다. 이후 요청이 들어오면 클라이언트는 원본 서버에 If-Modified-Since 또는 If-None-Match 헤더를 포함한 재검증 요청을 보내야 합니다.
2. Cache-Control: no-cache
많은 이들이 오해하는 부분이지만, no-cache는 "캐시를 저장하지 말라"는 뜻이 아닙니다. (저장하지 않는 지시자는 no-store입니다.) no-cache는 "캐시는 저장하되, 사용할 때마다 무조건 원본 서버에 확인받아라"라는 의미입니다.
동작 메커니즘:max-age=0과 기술적으로 동일하게 작동합니다. 캐시 저장소에 데이터가 물리적으로 존재하더라도, 클라이언트는 해당 데이터를 화면에 그리거나 사용하기 전에 반드시 원본 서버로 HTTP 재검증 요청을 날려야 합니다.
패킷 흐름 및 응답: * 클라이언트가 서버에 If-None-Match: "ETag값" 헤더를 담아 요청을 보냅니다.
변경이 없는 경우: 서버는 본문(Body)을 비운 채 헤더만 구성하여 304 Not Modified 응답을 보냅니다. 클라이언트는 캐시 장부의 데이터를 그대로 재사용합니다.
변경이 있는 경우: 서버는 새로운 데이터 본문을 포함하여 200 OK와 함께 최신 데이터를 내려줍니다.
⚠️ 주의: 핵심 차이점 요약 및 보안 유의사항
Cache-Control: max-age는 지정된 유효 기간 동안 원본 서버로 HTTP 요청 패킷을 전혀 보내지 않고 브라우저 자체 캐시 저장소의 데이터를 즉시 재사용하는 방식입니다. 반면 Cache-Control: no-cache는 데이터가 캐시에 있더라도 사용할 때마다 무조건 원본 서버에 HTTP 재검증 요청을 전송하여 데이터가 최신 상태인지 확인받도록 강제합니다.
이에 따라 max-age는 만료 전까지 서버 통신이 발생하지 않아 200 OK (from cache)와 함께 네트워크 대역폭 소모를 물리적으로 0으로 만듭니다. 그러나 no-cache는 매번 서버와 통신하며 데이터가 안 바뀌었으면 헤더만 받는 304 Not Modified를, 바뀌었으면 최신 본문을 포함한 200 OK 응답을 받아 항상 실시간 데이터 최신성을 보장합니다.
HTTP 요청 메소드는 설계 목적에 맞는 데이터 전송 구조를 가지며, 불필요하게 활성화된 특수 메소드는 시스템 내부 정보를 노출하는 징검다리가 됩니다.
GET / POST 보안성 차이: GET 방식은 전송 파라미터 데이터를 URL 쿼리 스트링에 붙여 평문 송출하므로, 브라우저 방문 기록, 웹 서버 접근 로그, 프록시 장비 헤더에 파스워드 같은 민감 정보가 그대로 영구 노출되는 보안 취약점을 지닙니다. 반면 POST 방식은 전송 데이터를 HTTP 패킷의 Request Body에 격리하여 전송하므로 외부 노출을 최소화합니다. 단, POST 역시 암호화되지 않은 HTTP 상태라면 네트워크 스니핑 툴에 의해 본문 데이터가 평문 노출되는 것은 동일하므로 완벽한 보안을 위해서는 반드시 SSL/TLS 결합이 강제됩니다.
OPTIONS 메소드 위험성: 해당 웹 서버가 현재 어떤 HTTP 메소드를 수용하고 지원하는지 질의하여 응답받는 정보 수집형 메소드입니다. 공격자는 사전 조사 단계에서 외부 자원 수정 권한이 열려있는지 확인하기 위한 취약점 스캐닝 목적으로 악용하므로 실무에서는 인가된 대상을 제외하고 제한해야 합니다.
TRACE 메소드 및 XST 공격 원리: TRACE는 클라이언트가 보낸 HTTP 요청 패킷 스펙 그대로를 웹 서버가 응답 Body에 고스란히 반사하여 돌려주는 디버깅 목적의 메소드입니다.
XST 공격 매커니즘: 해커는 XSS 취약점과 웹 서버의 TRACE 메소드 활성화 상태를 복합 연동합니다. 일반적인 XSS 공격은 앞서 언급한 HttpOnly 쿠키 보호막에 막혀 자바스크립트로 세션 ID를 뽑아내지 못합니다. 하지만 해커가 자바스크립트의 엔진을 가동해 웹 서버에 TRACE 메소드 요청을 강제로 송출하게 만들면, 웹 서버는 브라우저가 패킷 헤더에 실어 보낸 HttpOnly 보호 쿠키까지 포함하여 HTTP 요청문 전체를 응답 본문에 텍스트로 반사해 줍니다. 해커는 이 반사된 텍스트 본문 안에서 세션 쿠키 문자열을 날것 그대로 파싱하여 탈취하는 XST 공격을 성공시키며 보안 설정을 무력화합니다.
XST 공격 ➡️ TRACE로 요청 ➡️ 브라우저가 쿠키 자동 동봉 ➡️ 서버가 텍스트로 응답 본문에 반사 ➡️ xhr.responseText로 텍스트 안의 쿠키 추출
대응방안 가이드: 웹 서버 설정 파일에서 외부에서 들어오는 TRACE 메소드 패킷 요청에 대해 웹 서버 단에서 원천 거부하도록 차단 설정을 적용해야 합니다.
OAuth 2.0은 애플리케이션이 제3의 중앙 플랫폼의 사용자 데이터 접근 권한을 안전하게 위임받기 위한 개방형 표준 인가 프로토콜입니다.
인증: 사용자가 본인이 맞는지 신원을 확인하는 절차로, OAuth 아키텍처에서는 중앙의 인증 서버 단에서 전담 처리하여 개별 앱에 패스워드가 노출되지 않게 격리합니다.
인가: 인증된 클라이언트 애플리케이션에 대해 특정 자원에 접근할 수 있는 권한 권리를 부여 및 승인하는 기술적 프로세스입니다.
접근 토큰 (Access Token): 인가가 완료된 클라이언트 앱에 발급해 주는 암호학적 문자열 키입니다. 클라이언트는 API 리소스 서버에 자원을 요청할 때 이 토큰을 HTTP 헤더에 실어 보냄으로써 자신이 인가받은 정당한 대리인임을 증명합니다. 유출 피해 최소화를 위해 짧은 수명을 가집니다.
갱신 토큰 (Refresh Token): 발급된 접근 토큰이 만료되었을 때, 사용자가 매번 로그인 과정을 다시 거치지 않도록 접근 토큰을 무중단으로 재발급 받기 위해 사용하는 장기 보관용 특수 토큰입니다. 인증 서버에만 직접 전송되며 보안 관리에 극도로 유의해야 하는 자원입니다.
2.3. FTP 모드 분석 및 취약점
(1) FTP 전송 모드별 방화벽 연동 메커니즘 심층 분석
- 요약 키워드: 포트 이원화, Command 포트, Data 포트, 능동 모드, 수동 모드, 인바운드 방화벽 거부
- 세션 연결 수립 절차 및 네트워크 토폴로지 분석:
FTP는 기본적으로 제어 신호와 실제 파일 데이터를 전송하는 채널을 분리하여 운용하는 포트 이원화 아키텍처를 가집니다. 클라이언트와 서버의 네트워크 위치와 방화벽 제약 환경에 따라 두 가지 연결 모드로 분기됩니다.
공통 베이스 (제어 채널): 어떤 모드를 사용하든 클라이언트는 먼저 서버의 TCP 21번 포트로 인바운드 접속을 시도하여 제어 세션을 수립하고 명령어를 주고받습니다.
능동 모드 (Active Mode) - 서버가 클라이언트에 접속하는 구조:
클라이언트는 자신이 사용할 임의의 사설 포트를 열고, 서버에 PORT 명령어를 전송하여 알려줍니다.
요청을 접수한 FTP 서버는 자신의 TCP 20번 포트를 출발지로 삼아 클라이언트가 알려준 사설 포트를 목적지로 찍고 역방향으로 인바운드 TCP 세션 접속을 시도하여 데이터 채널을 수립합니다.
방화벽 취약점 및 한계: 만약 클라이언트 PC 전면에 하드웨어 방화벽이나 공유기가 설치되어 외부에서 들어오는 정체불명의 인바운드 패킷을 기본 차단 정책으로 대응하고 있다면, 서버가 20번 포트로 들어오려는 접속 시도가 거부되어 파일 목록 조회 및 전송이 실패하는 치명적인 가용성 한계가 발생합니다.
수동 모드 (Passive Mode) - 클라이언트가 서버에 접속하는 구조:
능동 모드의 방화벽 차단 한계를 우회하기 위해 고안되었습니다. 클라이언트가 제어 채널을 통해 서버에 PASV 명령어를 전송합니다.
FTP 서버는 20번 고정 포트를 쓰는 대신, 자신의 시스템 내부에서 임의의 비특권 사설 대역 포트(1024포트 이상)를 동적으로 오픈한 뒤 클라이언트에게 해당 포트 번호를 반환합니다.
클라이언트는 전달받은 서버의 동적 사설 포트를 향해 스스로 아웃바운드 TCP 세션 접속을 시도하여 데이터 채널 동기화를 완료합니다. 모든 세션 연결 주체가 클라이언트에서 아웃바운드로 나가는 방향이므로 클라이언트 단 방화벽 설정에 영향을 받지 않습니다.
💡 참고: ftpusers 설정 파일을 통한 root 로그인 접근 통제
ftpusers 파일은 FTP 서비스 구동 데몬 환경에서 보안상 FTP 접속을 원천적으로 봉쇄할 시스템 계정 목록을 지정하는 블랙리스트 설정 파일입니다. 만약, vsftpd를 사용하는 경우, /etc/vsftpd.conf에 userlist_enable=YES(user_list를 활성화) 및 userlist_deny=YES(등록된 사용자를 거부목록으로 사용)로 설정되어 있다면 /etc/vsftpd/user_list 또는 /etc/vsftpd/ftpusers에 계정을 추가하여 접근을 통제할 수 있습니다. user_list는 vsftpd만 사용하는 파일입니다. ProFTP에서는 /etc/proftpd.conf에서 RootLogin off 를 설정해야 합니다.
1. 평문 전송에 따른 패킷 노출 위험: FTP는 기본 설계 상 전송 패킷에 대한 암호화를 전혀 지원하지 않습니다. 이로 인해 최고 관리자인 root 계정의 아이디와 비밀번호가 네트워크 망에 평문으로 노출되어, 중간에서 패킷을 가로채는 스니핑 공격에 매우 취약합니다.
2. 최고 관리자 권한 피격 시 피해 파급력: 최고 권한을 가진 root 계정이 탈취되면 보안 경계선이 무력화됩니다. 해커가 최상위 디렉터리(/)를 포함한 시스템 설정 및 소스코드 전체를 임의로 조작하거나 파괴할 수 있는 절대 제어권을 행사하게 됩니다.
3. 무차별 대입 공격의 최우선 타겟팅:root는 모든 시스템에 공통으로 존재하는 식별자이기 때문에, 공격자가 계정명을 유추할 필요가 없습니다. 이로 인해 해커와 자동화된 공격 봇의 무차별 대입 공격(Brute Force) 대상이 되는 최우선 표적입니다.
요약하자면 "특정 유저 리스트를 관리해서 막고 싶다" 할 때, vsftpd는 user_list라는 별도 파일에 아이디를 적는 방식을 쓰고, ProFTPD는 proftpd.conf 설정 파일 내부에 <Limit LOGIN> 지시자 내 DenyUser나 AllowUser 문법으로 직접 적어주는 방식을 사용합니다.
- 요약 키워드: FTP Bounce Attack, Anonymous FTP, TFTP Attack, 임의의 포트 스캐닝, 익명 접근 차단
- 공격 기법 및 대응방안:
1. FTP 바운스 공격 (FTP Bounce Attack)
공격 원리 및 목적: FTP 능동 모드 구성 시 사용하는 PORT 명령어가 제3의 타겟 IP 주소와 포트 번호를 아무 제약 없이 인자로 수용할 수 있다는 보안 취약점을 악용합니다. 공격자는 메인 FTP 서버에 접속한 뒤 타겟 인프라를 향한 악의적인 매개변수를 전송한 후 파일 전송 명령을 내립니다.
결과: FTP 서버가 공격자의 대리인이 되어 목적지 타겟 시스템의 포트로 대리 접속을 집행합니다. 공격자는 자신의 흔적을 완벽히 은닉한 채 내부 인프라망을 임의로 우회 포트 스캐닝하거나 방화벽 내부의 메일 서버로 악성 패킷 주입 공격을 수행하는 전초기지로 악용합니다.
대응방안: FTP 데몬 설정 파일 내에 port_promiscuous=NO 지시어를 명시하여, PORT 명령어로 들어오는 목적지 IP 주소가 현재 제어 세션을 수립 중인 클라이언트의 실제 IP와 일치하지 않으면 패킷 처리를 즉시 거부하도록 통제해야 합니다.
2. 익명 FTP 취약점 (Anonymous FTP)
공격 원리 및 목적: 사전에 인가된 계정이 없는 비인가 외부 사용자라도 ID 창에 익명 지시어(보통 anonymous 또는 ftp가 계정명)를 입력하면 패스워드 검증 단계를 건너뛰고 내부 저장소 시스템에 로그인을 허용해 주는 기본 레가시 설정 오남용 취약점입니다. 공격자는 내부 기밀 정보 파일을 무단 유출하거나, 쓰기 권한이 열려있을 경우 악성코드 웹쉘 배포 보관소로 시스템을 변질시킵니다.
대응방안: 설정 파일 내 익명 접근 허용 파라미터를 강제 거부 적용하여 무인증 접근 통로를 전면 폐쇄해야 합니다. (위 그림을 참고하세요.)
3. TFTP 공격 (Trivial FTP Attack)
공격 원리 및 목적: TFTP는 복잡한 세션 수립을 전면 생략하고 UDP 69번 포트를 통해 인증 절차 없이 데이터를 초고속 단발성으로 전송하는 경량 프로토콜입니다. 해커는 시스템에 TFTP 데몬이 방치 구동 중인 것을 식별하면, 아무런 제약 없이 시스템 내부로 침투하여 커널 민감 파일이나 계정 섀도우 파일을 무단으로 다운로드 요청하여 크래킹 공격 소스로 악용합니다.
대응방안: TFTP 서비스 백업 가동이 불가피하다면 반드시 파일 시스템 권한을 읽기 전용으로 엄격히 제한하고, 허용할 디렉터리 경로를 단 한 곳으로만 정적으로 제한해야 합니다. 2.4.(1) 을 참고하세요.
2.4. 슈퍼데몬 관리 및 SNMP 보안
(1) inetd.conf 아키텍처 구조 및 TFTP Secure 모드 연동
- 리눅스 시스템 관리 가이드:
inetd는 개별 네트워크 서비스 데몬들을 백그라운드에 항상 띄워두지 않고, 중간에서 일괄적으로 포트 리스닝을 대행하다가 패킷 요청이 접수되면 매핑된 하위 데몬을 동적으로 구동시키는 슈퍼데몬 아키텍처입니다. 메인 설정 파일인 /etc/inetd.conf의 행 단위 설정 표준 필드 구조 스펙은 다음과 같습니다.
💡 참고: inetd.conf 7대 표준 설정 필드 순서 정의
[1. 서비스명] [2. 소켓타입] [3. 프로토콜] [4. 플래그] [5. 실행계정] [6. 실행 프로그램 경로] [7. 인자값]
앞서 다룬 무인증 기반의 위험한 TFTP 서비스를 inetd 체계 하에서 보안 수준을 올려 구동시키기 위한 시큐어 모드의 구체적 설정 소스 코드 예시입니다.
# /etc/inetd.conf 내부의 tftp 설정 예시
tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd -s /var/tftpboot
tftp dgram udp wait root: UDP 프로토콜 기반의 소켓을 수립하며, 패킷 처리 동안 대기 상태를 유지하고 root 커널 권한으로 프로세스를 구동함을 지정합니다.
/usr/sbin/in.tftpd: 슈퍼데몬이 가동할 실제 tftp 바이너리 프로그램의 물리 경로입니다.
-s /var/tftpboot: 보안 하드닝의 핵심인 시큐어 모드 지정 옵션(-s)입니다. 프로세스가 기동하는 순간 지정된 디렉터리를 시스템의 최상위 루트 디렉터리로 강제 인식시키는 chroot 가상 격리 아키텍처를 집행합니다. 이 설정이 완료되면 해커가 무인증 TFTP 취약점을 뚫고 들어오더라도 격리된 폴더 외부의 상위 커널 영역으로 빠져나가는 절대경로 탐색 공격이 완벽하게 차단되어 시스템 무결성이 보호됩니다.
최신 xinetd에서는 다음과 같이 설정합니다.
# /etc/xinetd.d/tftp 내부의 tftp 설정 예시
service tftp
{
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
# [핵심 설정] -s 옵션으로 허용 디렉터리를 제한하고, -c(쓰기) 옵션을 배제함
server_args = -s /var/tftpboot
# 서비스를 활성화하려면 차단(yes)을 해제(no)함
disable = no
}
SNMP는 라우터, 스위치, 서버 등 네트워크 단말의 상태 정보를 원격 통합 수집 및 제어하기 위한 7계층(응용) 프로토콜입니다.
운용 레이어 포트 구조: 네트워크 관리 시스템인 매니저 컴포넌트와 개별 장비에 상주하는 에이전트 컴포넌트 간 통신에 대역폭 오버헤드가 적은 UDP 포트를 사용합니다. 일반적인 제어 쿼리는 UDP 161번 포트를 타며, 에이전트가 예기치 못한 장애 발생 시 긴급 송출하는 트랩 신호는 UDP 162번 포트를 목적지로 운용됩니다.
데이터 정형화 핵심 컴포넌트 구조:
MIB: 관리 장비 내부의 자원 요소들을 트리 구조의 객체 식별자 형태로 계층화하여 정의해 놓은 가상 데이터베이스 명세서입니다.
ASN.1: MIB에 정의된 유동적인 원격 데이터 객체들을 기종이 다른 하드웨어 장비 간에 패킷 전송 시 데이터 타입 에러가 나지 않도록 데이터의 구조를 정의하는 추상 구문 규칙 표준입니다.
BER: 표준 규격으로 표현된 컴퓨터 추상 데이터를 네트워크 케이블 망을 통해 실제 0과 1의 물리적인 바이너리 스트림 패킷 데이터로 변환해 주는 인코딩 전송 규칙 매커니즘입니다.
메시지 유형별 동작 특성 비교:
Get-Request / Get-Next-Request / Set-Request: 매니저가 에이전트의 161번 포트를 향해 정기적으로 자원 상태 값을 요구하거나 직접 설정을 변경 제어하는 방식으로, 관리자가 주도권을 쥐고 데이터를 긁어모으는 폴링 방식의 동작 특성을 지닙니다.
Trap: 에이전트 장비에 임계치를 초과하는 치명적인 하드웨어 결함이나 링크 다운 이벤트가 발생했을 때, 정기 폴링 주기를 기다리지 않고 매니저의 162번 포트를 향해 즉각 단발성 비동기 신호를 인바운드로 쑤셔 넣는 이벤트 리포팅 방식의 동작 구조를 가집니다.
(3) SNMPv3 보안 파라미터
- 요약 키워드: Community String, snmpv3, msgSecurityParameter, 기밀성/무결성/인증
- 인프라 하드닝 가이드라인:
초기 SNMP v1/v2c 규격은 별도의 인증 메커니즘 없이 단순 패스워드 역할을 하는 텍스트 문자열인 커뮤니티 스트링만을 대조하여 통신을 승인했습니다. 심지어 기본 초기 설정값이 취약하게 고정되어 있어, 외부 해커가 스니핑을 통해 문자열을 가로채면 방화벽 내부 시스템 설정 전체를 원격으로 변조 리셋시키는 권한 장악 위협이 존재합니다.
🚨 SNMP 시스템 보호를 위한 4대 필수 보안 대책
1. SNMPv3 정석 프로토콜 마이그레이션: 평문 통신의 취약점을 완전 제거하기 위해 기밀성, 무결성, 인증 메커니즘이 빌트인된 SNMPv3 버전 사용을 전면 강제해야 합니다. v3 패킷 헤더 속 중요 지표인 msgSecurityParameter 영역은 다양한 공격 위협으로부터 방어하기 위해 설계되었으며, 내부 구성 필드와 세부 기능 정의 구조는 다음과 같습니다.
필드
설명
Authoritative 엔진ID (msgAuthoritativeEngineID)
• 재전송 공격 방지 • SNMP 엔진 ID, 부트 횟수, 엔진 시각 정보를 이용하여 메시지의 유효시간을 계산, 재전송 여부를 판단한다.
• 위장 공격, 메시지 위변조 및 도청/스니핑 방지 • 메시지 인증을 위해 HMAC(MD5, SHA)을 사용한다. • 메시지 암호화(DES-CBC)를 지원한다.
암호 매개변수 (msgPrivacyParameters)
2. 커뮤니티 스트링 복잡성 강화: 레가시 호환으로 인해 v1/v2c를 유지해야 하는 시스템의 경우, 초기 기본 디폴트 값을 전면 폐기하고 추측이 불가능한 복잡한 문자열로 전수 변경해야 합니다. 3. 접근 권한 최소화 분리: 모니터링 수집 장치는 읽기 전용 모드 권한만 할당하고, 서버의 상태를 변조할 수 있는 쓰기 모드 권한 설정은 전면 주석 처리하여 삭제해야 합니다. 4. 미사용 데몬 서비스 전면 비활성화: 원격 진단 결과 모니터링을 연동하지 않는 단말 서버 호스트라면, 커널 서비스 데몬 자체를 중지하고 방화벽 인바운드 포트를 원천 차단 정책으로 잠가두어야 안전합니다.
