보안 모니터링 잠금 구조 정리와 OPNsense 방화벽 통합

 

보안 모니터링은 한 번만 실패해도 운영자가 신뢰하기 어려워지는 작업이다. 이번에는 일일 보안 점검이 시작되자마자 이미 실행 중이라는 메시지와 함께 종료되는 문제를 정리하고, 같은 흐름에 OPNsense 방화벽 상태를 통합했다. 단순히 오류 한 줄을 없애는 데 그치지 않고, 서버 역할에 따라 수집 항목과 보고서 표현을 분리해 운영자가 필요한 정보에 빠르게 도달하도록 다듬은 작업이다.

 

## 문제의 출발점: 두 번 잡힌 잠금

 

일일 점검을 담당하는 셸 스크립트는 실행 전에 잠금 파일을 잡고 파이썬 모니터링 프로그램을 호출하고 있었다. 그런데 파이썬 프로그램도 같은 잠금 파일에 대해 비차단 방식의 `fcntl.flock`을 시도했다. 첫 번째 프로세스가 잠금을 획득한 직후 두 번째 단계가 같은 잠금에 접근하므로, 프로그램은 자신을 중복 실행으로 오인하고 종료할 수 있는 구조였다.

 

해결 원칙은 단순했다. 중복 실행 제어의 책임을 파이썬 프로그램 한 곳으로 모으고, 호출용 셸 스크립트의 외부 `flock` 처리는 제거했다. 이제 프로그램은 시작 시 잠금을 얻고, 이미 다른 실행이 살아 있을 때만 종료한다. 이 구조는 잠금의 소유자와 해제 시점을 추적하기 쉬워 장애 분석과 유지보수에도 유리하다.

 

잠금 파일을 다룰 때는 특히 조심해야 한다. 파일이 남아 보인다는 이유만으로 강제 삭제하면 실제로 실행 중인 점검을 겹쳐 실행할 수 있다. 먼저 관련 프로세스와 잠금 상태를 확인하고, 정상 종료 여부를 판단한 뒤 조치해야 한다. 운영 환경에서는 `ps`와 파일 상태 확인을 선행하고, 정기 작업 변경 전에는 기존 크론 설정을 백업하거나 기록해 두는 편이 안전하다.

 

## 환경변수와 방화벽 수집 구조 개선

 

방화벽 API를 연동하는 과정에서는 환경변수 값이 따옴표로 감싸진 경우 URL 자체에 따옴표가 포함되어 요청이 실패하는 문제가 확인됐다. 환경변수를 읽을 때 값의 양끝이 같은 작은따옴표 또는 큰따옴표이면 제거하도록 보완했다. 구성 파일을 사람이 직접 편집하는 운영 환경에서는 이런 작은 입력 차이가 장애로 이어지기 쉽다. 다만 토큰, API 키, 인증 헤더는 로그나 보고서에 남기지 않고, 별도 비밀 관리 체계 또는 접근 권한을 제한한 환경 파일로만 관리해야 한다.

 

수집 대상에는 방화벽 유형을 별도로 추가했다. 일반 리눅스 서버는 패키지 업데이트와 CrowdSec 상태를 수집하지만, OPNsense는 시스템 상태, 펌웨어와 OS 버전, 메모리, 인터페이스, 게이트웨이, 방화벽 로그를 API로 확인하도록 분기했다. 이때 주소나 인증정보는 코드와 문서에서 모두 마스킹된 변수로만 취급했다.

 

보고서도 역할에 맞춰 나눴다. 방화벽 섹션에는 제품 정보, 업데이트 또는 재부팅 필요 여부, 메모리 사용률, 활성 인터페이스, 게이트웨이 상태, 최근 차단·허용 로그의 요약을 표시한다. 반대로 방화벽에 해당하지 않는 CrowdSec 컨테이너 오류나 IP별 탐지 상세는 방화벽 섹션에서 제외했다. 같은 지표를 모든 장비에 억지로 출력하는 것보다, 장비 유형에 맞는 정보만 보여 주는 편이 경보 피로를 줄인다.

 

## 검증은 작은 단위부터 전체 흐름까지

 

변경 후에는 셸 문법 검사와 파이썬 컴파일 검사를 먼저 통과시켰다. 이어 잠금 파일이 다른 프로세스에 의해 점유되지 않았는지, 크론에는 일일 실행 항목만 남아 있는지를 확인했다. API는 각 엔드포인트가 예상한 JSON 구조를 반환하는지 점검하고, 마지막으로 모니터링 프로그램을 일일 모드로 수동 실행했다.

 

전체 실행에서는 로컬 서버, 원격 서버, 방화벽 순으로 데이터 수집이 진행됐고, 방화벽 전용 데이터가 보고서에 기록됐다. 보고서 생성과 알림 전송까지 완료된 것을 확인했으며, 방화벽 섹션에는 불필요한 CrowdSec 메시지가 더 이상 나타나지 않았다. 시스템 설정이나 크론 변경은 알림 중복, 보고서 중복 생성 같은 영향이 있을 수 있으므로, 운영 시간대에 바로 적용하기보다 수동 실행 결과와 다음 예약 실행의 로그를 함께 확인하는 절차가 필요하다.

 

## 이번 작업에서 얻은 기준

 

첫째, 잠금은 한 계층에서만 관리해야 한다. 둘째, 환경변수는 형식 오류를 허용하되 민감값을 노출하지 않는 방식으로 처리해야 한다. 셋째, 보고서는 서버 종류별로 필요한 데이터만 보여 줄 때 가장 읽기 좋다. 마지막으로 문법 검사, 개별 API 확인, 수동 실행, 예약 실행 확인의 순서로 검증하면 자동화 변경의 위험을 크게 낮출 수 있다. 다음 작업에서도 이 흐름을 점검표로 삼아 보안 모니터링의 정확성과 보고서의 가독성을 함께 관리할 생각이다.

 

## 해시태그

 

#리눅스운영 #보안모니터링 #OPNsense #크론관리 #파일잠금 #환경변수 #보고서자동화 #서버관리 #Python #ShellScript