Rule | 설명 |
alert | 알람 발생시키고 로그 남김 |
log | 로그 남김 |
pass | 무시 |
activate | 로그 남기고 대응 dynamic action을 활성화 |
dynamic | 활성화되면 로그 남김 |
drop | iptables에 의해 패킷 차단 후 로그 남김 |
sdrop | iptables에 의해 패킷 차단, 로그 남기지 않음 |
reject | iptables에 의해 패킷 차단 후 로그 남기고 메시지(TCP reset, ICMP unreachable)를 발생 |
룰 옵션(Rule Option) :
예시 - Rule Hearder 뒤에 ( msg : "MESSAGE"; content : "abc.html"; nocase)
* 옵션 종류
msg : alert, log 시 출력될 메시지
content : 패킷의 페이로드 내부를 검색하는 문자열
offset : 검색할 문자열의 offset
nocase : 대소문자 구별하지 않음
rev : 룰 수정 횟수
sid : 룰 식별자(snort에서 사용하는 식별 번호는 100~100만 사이)
threshold type <limit | threshold | both>, track <by_src | by_dst>, count <s>, seconds <m>
● iptables
리눅스에서 사용되는 방화벽으로 상태추적 기능, 로깅기능, 포트 포워딩 및 향상된 매칭 기능을 제공하줌
<예시> iptables -A INPUT -s 192.168.1.1 -p tcp -j DROP
-A : 어떤 체인을 사용하는지 지정하며 INPUT, OUTPUT 등 있음
-s : 입력되는 패킷 주소 명시 (출발지)
-sport, -dport : 출발지 포트/도착지 포트
-d : 출력되는 패킷 주소 명시 (도착지)
-p : 프로토콜
-j : 행위
--tcp-flag ALL SYN,FIN : tcp 제어플래그
DROP : 매치된 패킷을 차단한 후 추후 어떤 동작도 하지 않음 (시스템 리소스 적게 쓰며 보안적 측면에서도 좋음) (로그 기록은 하며 로그기록 안하는 것은 SDROP)
REJECT : 매치된 패킷을 차단한 후 ICMP 에러 메시지를 발신지로 응답해주어 보안적으로 취약하며 트래픽이 추가적으로 발생하여 이점을 악용한 DDOS 공격 가능성 있음
규칙은 위부터 순차적으로 적용(먼저 적용된 것이 우선순위가 높음)
● Snort
<예시>
alert tcp any any -> any any(msg:"m"; content:"pattern"; nocase; offset: 9; depth:2; threshold:type threshold, track by_dstm, count 10, second 1; sid:1000999)
- content : 패킷 페이로드와 패턴 매칭을 통해 체크(페이로드에 검사할 문자열 지정)
- nocase : 대소문자 구별 없이 패턴 매칭
- offset : 페이로드에서 content 패턴을 검사 시작할 위치로 0부터 시작
- depth : offset부터 몇 바이트까지 검사할 것인지 지정
- threshold~~ : 목적지 ip 기준으로 매 1초동안 10번째 이벤트마다 alert 액션 수행
- flag:SF : tcp 제어 플래그
TCP 제어 비트에서 SYN와 FIN이 함께 쓰이면 공격으로 간주
<PCRE 헤더 액션 항목 : alert 등>
1. alert : 정해진 방식에 따라 alert(경고) 발생 시키고 패킷 기록
2. log : 패킷 기록(로깅)
3. pass : 패킷 무시하고 패스
4. activate : alert 발생시키고 대응 dynamic 시그니처 유효하게 함
5. dynamic : activate에 의해 활성화 되면 log와 동일한 기능
6. drop : 패킷 차단 후 로깅
7. reject : 패킷 차단 로깅 후 ICMP Port Unreachable 또는 TCP reset 전달
8. sdrop : 패킷 차단 후 로깅X
'정보보안기사' 카테고리의 다른 글
FTP Bounce Attack (0) | 2020.05.09 |
---|---|
SNMP 보안대책및 목록화 (0) | 2020.05.06 |
정보통신기반시설 취약점 분석 (4) (0) | 2020.04.21 |
정보통신기반시설 취약점 분석 (3) (0) | 2020.04.19 |
정보통신기반시설 취약점 분석 (2) (0) | 2020.04.17 |