IPS
Intrusion Prevention System · 침입 방지 시스템
는 의심 트래픽을 탐지하고 실제 통신 경로에서 정책에 따라 차단하는 시스템이다. 탐지 규칙뿐 아니라 인라인 연결·장애 동작·성능 한도가 서비스에 직접 영향을 준다.
밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.
01무엇이고, 어떤 일을 하나
- 위험 요청이 목적지에 도달하기 전에 제한한다.
- 허용·거부 결과를 규칙과 흐름 증거로 기록한다.
- 오탐과 가용성 영향을 함께 평가한다.
02어떤 순서로 동작하나
- 데이터 경로 배치
양쪽 통신이 실제로 검사 지점을 통과하도록 구성한다. 복사본만 받은 수동 센서는 원래 패킷의 전달을 같은 방식으로 막을 수 없다.
- 해석과 탐지
재조립·응용 해석 후 규칙 조건을 적용한다. 암호화·비대칭 경로·손실이 검사 범위를 줄일 수 있다.
- 집행
현재 모드와 규칙 action에 맞춰 허용·차단을 수행한다. 경보가 기록되었다는 사실만으로 실제 차단을 확정하지 않는다.
- 서비스 검증
정상 트래픽과 대상 조건의 통과·거부, 지연·처리율, 장비 장애 시 동작을 함께 검증한다. 차단 변경에는 복구 가능한 운영 경로가 필요하다.
03먼저 알아둘 용어와 구성요소
- 실제 데이터 경로 안에 장비나 엔진을 배치하는 방식.
- 정책에 따라 패킷 전달을 중단하는 동작.
- 장애 시 통신을 유지하도록 우회하는 정책.
- 장애 시 통신을 차단하는 정책.
- 장애 때 통신을 통과시킬지 막을지 정하는 정책으로 가용성과 차단 보장의 선택에 영향을 준다.
인라인 후보 인터페이스에서 수신과 전달을 따로 검증하기
센서 인터페이스에 패킷이 들어오는 것과 다른 인터페이스로 전달되는 것을 구분한다.
실습 구성과 전제
- 격리 의 관리 인터페이스와 시험용 데이터 인터페이스를 분리한다.
- 주소가 없는 인터페이스에서도 L2 프레임은 캡처될 수 있지만 전달 기능은 별도로 구성해야 한다.
관리 경로와 데이터 경로를 구분한다
- ip a에서 인터페이스 이름·링크 상태·주소를 확인한다. 두 시험 포트가 UP이라고 해서 브리지나 전달 경로가 자동으로 구성되는 것은 아니다.
- 관리 접속을 유지할 별도 경로가 있어야 데이터 경로 시험 실패 시 장비를 복구할 수 있다.
shellip -br link ip -br address인터페이스 상태와 주소를 변경하지 않는 조회 명령이다.
원본 크기로 보기 ↗- ens160에는 IPv4 주소가 보이고 ens224·ens256은 별도 인터페이스로 표시된다.
- 데이터 후보 포트의 UP·LOWER_UP과 주소 설정은 다른 필드다. 링크 상태만으로 패킷 전달을 증명할 수 없다.
확인 기준시험 포트를 케이블·가상 스위치 연결도와 맞춘다.
수신 패킷을 확인한다
- 입력 측에서 등 정상 시험 트래픽이 보이는지 확인한다. 출력 측에서도 같은 사건의 프레임이 보이는지 별도 캡처해야 전달을 증명할 수 있다.
- 반복 요청만 보이면 응답 부재·경로 단절·주소 오류가 후보가 된다. 규칙이 막았다고 단정하지 않는다.
shelltcpdump -ni ens224 -c 10 'arp or icmp' tcpdump -ni ens256 -c 10 'arp or icmp'실습 데이터 인터페이스에서 같은 정상 트래픽을 별도로 관찰한다.
원본 크기로 보기 ↗- tcpdump -i ens224가 실행되고 Ethernet 링크 타입과 반복 ARP Request가 보인다.
- 캡처는 한 인터페이스의 수신 증거다. ens256으로 전달됐다는 정보는 이 화면에 없다.
확인 기준수신·전달·응답을 세 지점에서 분리해 판정한다.
탐지 모드와 차단 모드를 검증한다
- 미러 포트의 는 복제본을 보기 때문에 원래 패킷을 직접 멈추지 않는다. 는 실제 경로에 위치하고 지원하는 캡처·전달 방식으로 동작해야 한다.
- 정상 표본이 통과하는 기준선을 먼저 만든 뒤 허가된 시험 표본의 탐지·차단·복구를 비교한다.
확인 기준경보 발생, 패킷 드롭, 클라이언트 결과가 서로 대응해야 차단 성공이라고 쓴다.
실습에서 확인한 동작 원리
- 패킷 수신과 전달은 서로 다른 검증 항목이다.
- 인터페이스 상태나 경보만으로 차단 효과를 확정할 수 없다.
인라인 차단 설정과 Apache 요청 로그를 다른 증거로 읽기
네트워크 차단 경로와 HTTP 내용 검사가 어떤 관찰 자료를 남기는지 구분한다.
실습 구성과 전제
- 격리 ·웹 서버의 설정과 기존 로그를 읽는다.
- 설정 화면과 스캔 로그는 서로 다른 환경의 비교 자료다. 한 제품이 같은 요청을 차단한 앞뒤 증거로 연결하지 않는다.
설정된 차단 방식의 위치를 확인한다
- 화면은 패키지의 Block Offenders와 Mode를 보여 준다. 모드는 실제 패킷 경로와 NIC 지원 조건을 요구한다.
- 선택 상자가 켜져 있다는 사실과 드롭이 발생했다는 사실은 다르다. 경보·차단 테이블·클라이언트 결과를 연결해야 한다.
원본 크기로 보기 ↗- Block Offenders가 체크돼 있고 IPS Mode는 Inline Mode로 선택돼 있다.
- 설명에는 Legacy가 복제 패킷을 보고 Inline은 패킷을 직접 검사한다고 적혀 있으며 지원 NIC 조건도 함께 나온다.
확인 기준현재 실행 모드·인터페이스·드롭 규칙을 확인한 뒤 차단 효과를 판정한다.
접근 로그가 보는 HTTP 결과를 읽는다
- access log의 요청 경로·상태 코드·시각·User-Agent를 분리한다. 스캔 표식 문자열이 있다고 실제 코드 실행이 일어났다고 단정하지 않는다.
- 404는 해당 경로의 HTTP 응답 상태다. 로그 처리 과정의 취약한 해석이나 다른 부작용까지 안전하다는 뜻은 아니다.
원본 크기로 보기 ↗- 여러 CGI·PHP 경로에 대한 GET과 대부분의 404, 별도 HEAD 요청의 200이 보인다.
- User-Agent 부분에는 스캐너 표식이 반복된다. 화면 하단의 '대부분 실패' 평가는 실제 취약점 부작용까지 증명하지 못한다.
확인 기준감사 로그의 규칙 ID·매치 변수·액션을 추가로 확인한다.
요청 ID로 탐지와 차단을 대조한다
- 의 탐지는 변수·연산자·변환·액션 조건으로 결정된다. access log의 상태만 보지 않고 동일 요청의 감사 로그와 응답을 연결한다.
- 관찰 모드에서는 규칙이 맞아도 요청이 통과할 수 있다. 정상 표본도 함께 시험해 오탐을 좁히고 규칙 전체 비활성화를 첫 해결책으로 삼지 않는다.
shellapachectl -t journalctl -u apache2 --since today --no-pager설정 문법과 서비스 오류를 조회하는 예시. 배포판에 따라 httpd 서비스와 도구를 사용한다.
확인 기준탐지 로그 존재·disruptive action·사용자 응답을 각각 기록한다.
실습에서 확인한 동작 원리
- 차단 설정 화면은 차단 성공 증거를 대신하지 않는다.
- 404 응답과 미탐·취약점 비영향 여부는 다른 판정이다.
탐지 배치도와 혼동행렬로 시험의 정답 만들기
센서가 볼 수 있는 경로를 먼저 정하고, 양성·음성 표본과 독립 정답을 사용해 탐지와 차단을 평가한다.
실습 구성과 전제
- 승인된 격리망의 테스트 클라이언트·보호 서버·센서를 사용한다. 외부 시스템을 시험 대상으로 삼지 않는다.
- 아래 혼동행렬 계산의 건수는 설명용 가상값이다. 배치도에 그려진 장비들이 실제로 해당 정확도를 달성했다는 뜻이 아니다.
센서가 보는 경로와 막을 수 있는 경로를 표시하기
- 배치도에서 클라이언트부터 보호 서버까지 실제 데이터가 지나는 링크를 추적한다. 인라인 는 통과 경로에 있지만 미러 포트의 는 복사된 패킷을 관찰할 뿐이다.
- 의 경보 유무와 서버 요청 도달 여부는 따로 측정한다. 둘을 같은 지표로 합치면 탐지는 했으나 차단하지 않은 경우를 잘못 성공 또는 실패로 분류하게 된다.
원본 크기로 보기 ↗- 그림은 Kali, 라우터, IPS-pfSense, 스위치와 DVWA·WebGoat 서버의 연결을 보여 준다. 시험 요청의 경로를 따라갈 수 있다.
- IDS-Snort3는 별도 센서로 표시되어 있다. 장비 이름만 보고 IPS와 같은 인라인 차단 위치라고 가정하지 않는다.
확인 기준센서 입력에서 시험 표식이 관찰되는지 먼저 확인한다. 입력 자체가 없으면 규칙 성능을 평가하기 전에 배치·미러링 문제부터 해결한다.
실제 정답과 도구의 예측을 교차시키기
- 양성은 평가할 사건이 실제로 존재하는 표본, 음성은 존재하지 않는 표본으로 정의한다. 경보가 나왔다는 이유만으로 그 표본을 양성으로 바꾸면 순환 평가가 된다.
- 격리 PCAP의 시험 번호·예상 사건 여부를 별도 목록으로 만들고, 탐지 결과는 rule SID와 시각으로 그 목록에 대응시킨다. 도구 출력과 정답 목록을 독립적으로 보관한다.
원본 크기로 보기 ↗- 행은 실제 Positive·Negative, 열은 예측 Positive·Negative로 나뉘며 TP·FN·FP·TN이 교차 위치에 놓인다.
- 실제 Positive인데 예측 Negative인 칸이 FN이다. 탐지되지 않은 공격을 정상 음성 TN으로 세면 재현율이 부풀려진다.
확인 기준모든 시험 번호가 네 칸 중 정확히 하나에 들어가야 한다. 경보가 여러 개 발생한 한 사건을 여러 양성 표본으로 중복 집계하지 않는다.
가상 수치를 계산하고 임계값 수정의 부작용 비교하기
- 가상 양성 10건 중 8건 탐지, 음성 10건 중 1건 오탐이면 TP=8, FN=2, FP=1, TN=9다. 정밀도는 8/9, 재현율은 8/10, 오탐률은 1/10으로 분모가 다르다.
- 탐지 임계값을 낮춘 뒤에는 같은 정답 집합뿐 아니라 따로 남긴 검증 표본도 시험한다. 재현율이 높아져도 정상 작업에 경보가 늘거나 차단 지연이 생길 수 있다.
text가상 표본 20건 TP 8 + FN 2 = 실제 양성 10 FP 1 + TN 9 = 실제 음성 10 정밀도 8/9 ≈ 88.9% 재현율 8/10 = 80% 오탐률 1/10 = 10%화면의 혼동행렬 구조에 가상 건수를 넣은 계산 예. 실측 결과가 아니다.
확인 기준변경 전후에 정답 집합·시간 범위·센서 손실률을 동일하게 기록한다. 수치가 좋아졌다는 결론에는 어느 분모와 조건인지 함께 적는다.
실습에서 확인한 동작 원리
- 관측 위치가 잘못되면 규칙 정확도 평가도 의미가 없어진다.
- 정확도 하나보다 정밀도·재현율·오탐률과 탐지/차단 구분이 실제 운영 영향을 잘 설명한다.
보안 실습 배치도를 요구사항과 설치 선택으로 연결하기
장비를 나열한 그림에서 요청 경로·센서 역할·서버 구성·인수 시험까지 추적 가능한 설계 항목을 만든다.
실습 구성과 전제
- 외부와 분리한 실습망에서 공격 실습 클라이언트·시험 웹 서버·관리 접속 경로를 구분한다.
- 배치도와 설치 화면은 별도 구성 사례다. 배치도의 모든 이 같은 설치 선택을 사용했다고 가정하지 않는다.
장비 이름을 데이터 흐름과 요구사항으로 바꾸기
- ' 설치'는 작업이고 '시험 요청이 센서에 도달해 해당 규칙의 경보를 남긴다'는 검증 가능한 이다. 배치도 위에 요청의 출발점·목적지·통과 장비와 복사 관측 지점을 적는다.
- 차단 시험은 앞뒤의 관찰과 서버의 도달 기록을 함께 필요로 한다. 관리 접속을 실험 트래픽과 같은 차단 경로에 두면 장애 때 제어할 수 없으므로 복구 경로도 설계한다.
원본 크기로 보기 ↗- Kali에서 라우터와 IPS-pfSense를 거쳐 서버 쪽으로 이어지는 흐름이 그려져 있다. 장비 순서가 차단·도달 시험의 위치를 정한다.
- Snort3 센서와 DVWA·WebGoat 서버의 역할이 구분되어 있다. 탐지 장비와 취약 애플리케이션을 같은 노드로 취급하지 않는다.
확인 기준각 에 입력 위치·관측 위치·기대 결과가 한 세트로 붙는지 확인한다. 연결선만으로 미러링 설정 완료를 주장하지 않는다.
OS 설치 선택을 서비스 역할과 연결하기
- 최소 설치는 필요한 패키지와 서비스부터 구성하는 출발점이다. 필요한 보안 업데이트·계정 정책·방화벽 설정까지 자동으로 충족한다는 뜻은 아니다.
- 역할별로 웹 서버, 센서, 로그 수집기의 필요한 패키지와 포트를 별도 목록으로 만든다. 한 에 모든 기능을 넣으면 포트 충돌·자원 경합·시험 실패 원인 분리가 어려워질 수 있다.
원본 크기로 보기 ↗- Rocky Linux 9.8의 소프트웨어 선택 화면에서 최소 설치가 선택되어 있다. CPU·메모리 수치를 지정하는 VM 명세 화면은 아니다.
- 추가 소프트웨어 선택란에는 표준 도구·헤드리스 관리·보안 도구 관련 선택이 보인다. 설치 구성의 선택이며 해당 서비스의 실행 결과는 아니다.
확인 기준설치 후 실제 서비스 목록과 수신 포트를 목록에 대조한다. 체크한 패키지 그룹만 보고 센서나 웹 서비스가 정상이라고 판정하지 않는다.
설계 항목마다 인수 시험과 복구 조건을 붙이기
- 가상 LAB-01을 '정상 요청은 웹 서버에 도달하고 관측 로그가 남는다', LAB-02를 '시험 패턴은 지정 규칙의 경보를 만든다'처럼 나누면 서비스 가용성과 탐지를 따로 검증할 수 있다.
- 시험마다 이미지 버전·네트워크 연결·규칙 버전·기대 출력·실패 시 복구 방법을 기록한다. 결과가 없거나 시험 전이면 준비 단계로 표시하여 설계도와 구축 완료를 구분한다.
확인 기준설계표의 모든 이 시험 ID에 연결되고, 시험 결과를 찾을 수 있어야 인수할 수 있다. 장비가 켜져 있다는 사실만으로 프로젝트 완료를 선언하지 않는다.
실습에서 확인한 동작 원리
- 그림은 요청과 관측의 경로를 설명할 때 시험 가능한 설계가 된다.
- 설치 옵션, 실행 상태, 학습 기능의 성공은 서로 다른 증거로 확인한다.
04예제로 따라가기
- 나 를 PCAP 파일에 실행한 결과는 규칙 검증 자료지만 운영 통신이 차단되었다는 증거는 아니다.
- 정상 요청이 규칙에 잘못 맞으면 에서는 경보였던 문제가 에서는 서비스 실패가 될 수 있다.
- 장비 장애 시 우회한다면 가용성은 유지될 수 있지만 해당 기간의 검사는 중단될 수 있다.
05혼동하기 쉬운 점과 확인 기준
- 규칙을 적는 것만으로 캡처 모드가 인라인 경로로 바뀌지는 않는다.
- 과도한 규칙과 재조립 비용은 처리 지연·손실을 만들 수 있으므로 기능 시험과 용량 시험을 구분한다.
06상세 노트 · 실습 자료
헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.
공식 문서 · 표준
기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.