패닉 모드 | LabEx

소개

가끔 문제가 발생합니다. 그것도 매우 심각한 문제가 발생할 수 있습니다. 해커가 서버를 공격하거나 바이러스가 빠르게 퍼지는 상황을 예로 들 수 있습니다. 이때는 컴퓨터를 즉시 네트워크에서 분리해야 합니다.

firewalld는 패닉 모드라는 기능을 제공합니다. 패닉 모드를 활성화하면 방화벽이 모든 인바운드 및 아웃바운드 연결을 즉시 차단합니다.

따라서 패닉 모드는 일반적인 설정 조정이 아니라 사고 대응을 위한 기능입니다. 통신을 즉시 중단하는 것이 연결을 유지하는 것보다 중요한 상황에서 신속하게 위협을 격리하도록 설계되었습니다.

패닉 모드는 비상 격리를 위한 기능입니다. 일반적인 관리 작업에는 사용하지 않지만, 방화벽 정책을 사고 발생 시 신속한 격리 도구로도 사용할 수 있다는 점을 이해하는 데 유용합니다.

원격 서버에서 발생하는 문제:

물리 서버 앞에 직접 앉아 있다면 문제가 되지 않습니다. 하지만 이 LabEx VM 이나 클라우드 서버처럼 원격 환경에서는 패닉 모드를 켜는 순간 현재 연결도 즉시 끊깁니다. 서버에서 접속이 차단되어 패닉 모드를 다시 끌 수 없게 됩니다.

이 실습에서는 "Dead Man's Switch" 스크립트를 만들어 이 기능을 안전하게 시뮬레이션하고 테스트합니다. 이 스크립트는 패닉 모드를 켜고 테스트를 실행한 다음 자동으로 패닉 모드를 다시 꺼서 접속을 복구합니다.

안전한 테스트 스크립트 만들기

firewall-cmd --panic-on을 직접 실행하면 세션이 끊기므로, 이 과정을 자동으로 처리하는 스크립트를 작성합니다.

이는 더 넓은 범위의 운영 기법이기도 합니다. 네트워크 변경으로 접속이 차단될 수 있다면, 위험한 변경을 적용하기 전에 롤백을 자동으로 실행하도록 구성합니다. 이렇게 하면 테스트가 장애로 이어질 가능성을 줄일 수 있습니다.

이 스크립트는 다음 작업을 수행합니다.

"Before" ping 결과를 기록합니다 (성공).
패닉 모드를 활성화합니다.
"During" ping 결과를 기록합니다 (실패해야 함).
패닉 모드를 비활성화합니다 (접속 복구).

safe_panic_test.sh라는 파일을 만듭니다.

nano safe_panic_test.sh

다음 내용을 파일에 붙여 넣습니다.

#!/bin/bash
LOGFILE="panic_test.log"

echo "--- PHASE 1: Normal State ---" > $LOGFILE
ping -c 2 8.8.8.8 >> $LOGFILE 2>&1

echo "" >> $LOGFILE
echo "--- PHASE 2: Enabling PANIC MODE ---" >> $LOGFILE
firewall-cmd --panic-on
echo "Panic Mode is ON." >> $LOGFILE

echo "Attempting to ping 8.8.8.8 (Should fail)..." >> $LOGFILE
## -W 2 means wait max 2 seconds for response
ping -c 2 -W 2 8.8.8.8 >> $LOGFILE 2>&1

echo "" >> $LOGFILE
echo "--- PHASE 3: Disabling PANIC MODE ---" >> $LOGFILE
firewall-cmd --panic-off
echo "Panic Mode is OFF." >> $LOGFILE

echo "Checking connectivity restored..." >> $LOGFILE
ping -c 2 8.8.8.8 >> $LOGFILE 2>&1

저장하고 종료합니다 (Ctrl+O, Enter, Ctrl+X).

스크립트를 실행할 수 있도록 권한을 변경합니다.

chmod +x safe_panic_test.sh

안전하게 테스트 실행하기

이제 중요한 단계입니다. 스크립트를 일반적으로 실행하면 패닉 모드가 켜지는 순간 세션 연결이 끊길 수 있습니다. 그러면 패닉 모드를 끄기 전에 스크립트가 종료될 수 있습니다.

이를 방지하기 위해 nohup(No Hang Up) 을 사용합니다. nohup을 사용하면 터미널 세션이 종료되더라도 스크립트가 백그라운드에서 계속 실행됩니다.

이는 프로세스의 수명과 터미널의 수명을 분리하는 좋은 예입니다. 대화형 세션에서 연결이 끊기더라도 복구 스크립트가 계속 실행되어야 실습을 안전하게 수행할 수 있습니다.

sudo와 nohup을 사용해 스크립트를 실행합니다.

sudo nohup ./safe_panic_test.sh &

예상되는 결과:

터미널이 약 5~10 초 동안 멈추거나 응답하지 않을 수 있습니다. 페이지를 새로 고침하지 마세요.
스크립트가 3 단계 (패닉 모드 비활성화) 를 완료하면 연결이 자동으로 복구됩니다.

15 초 이상 기다립니다.

결과 분석하기

이제 연결이 복구되었으므로 로그 파일을 확인해 패닉 모드가 실제로 작동했는지 검증합니다.

패닉 모드는 의도적으로 연결을 중단하므로 여기서 검증하는 작업이 특히 중요합니다. 테스트 중에 격리가 발생했는지, 이후 정상적인 연결이 복구되었는지 확인해야 합니다.

로그 파일을 읽습니다.

cat panic_test.log

다음과 같은 순서의 결과가 표시되어야 합니다.

PHASE 1: ping 이 성공합니다.
PHASE 2: 패닉 모드가 켜집니다. 이 단계의 ping 시도에는 Network is unreachable 또는 100% packet loss와 같은 오류가 표시되어야 합니다.
PHASE 3: 패닉 모드가 꺼집니다. ping 이 다시 성공합니다.

이 결과를 통해 몇 초 동안 서버가 네트워크에서 완전히 격리되었음을 확인할 수 있습니다.

상태 확인하기

마지막으로 시스템이 정상 상태로 돌아왔고 패닉 모드가 확실히 비활성화되었는지 직접 확인합니다.

패닉 모드 상태를 확인합니다.

sudo firewall-cmd --query-panic

결과로 no가 반환되어야 합니다.

이와 같은 "스크립트를 사용한 토글" 기법은 DevOps 엔지니어에게 매우 중요한 기술입니다. 접속을 끊을 수 있는 네트워크 설정을 변경할 때는 항상 되돌리기 명령을 미리 예약하거나, 이와 같은 래퍼 스크립트를 사용하세요.

더 큰 관점에서 중요한 교훈은 운영 안전성입니다. 위험한 방화벽 변경을 수행할 때는 접속을 잃은 뒤에 즉흥적으로 복구하려 하지 말고, 사전에 복구 경로를 계획해야 합니다.

요약

이 실습에서는 원격 환경에서 패닉 모드를 안전하게 사용하는 방법을 배웠습니다. 다음 작업을 수행했습니다.

패닉 모드를 자동으로 켜고 끄는 "Dead Man's Switch" 스크립트를 만들었습니다.
네트워크 연결이 끊겨도 스크립트가 계속 실행되도록 nohup을 사용했습니다.
로그를 분석해 네트워크 격리가 실제로 발생했는지 확인했습니다.

이 방법을 사용하면 서버에서 접속이 차단되는 상황을 피하면서 위험한 보안 설정을 관리할 수 있습니다.