일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 미탐
- snort
- isdataat
- HTTP2
- Suricata
- dsize
- header dos
- sinature
- TLS
- 수리카타
- flowbits
- stream buffer
- signatrue
- rule
- 오탐
- 크롬 탐지
- idps
- IPS
- DDOS
- slowloris
- 시그니처
- Reassembly
- chromium 탐지
- 암호화
- IDS
- stream_size
- 탐지
- SSL
- chrome 탐지
- 재조합
- Today
- Total
목록Rules (5)
linefilt
raw stream based Slowloris Slowloris는 서버의 가용 자원을 최대한 낭비하여 DoS를 유발하는 공격으로 일반적인 Flooding 공격과 달리 단순한 임계 값으로는 확인할 수 없으며, 문자열 식별 방식 또한 한계를 가지고 있다. 리버스 프록시나 HTTP 서버 등 최종 Termination 역할을 하지 않는 대부분의 보안장비에서, Slowloris 공격을 탐지하는 방식으로 HTTP 메시지에서 0x0d0a0d0a가 없는 세그먼트를 탐지한다. 이 방법은 대부분 간단한 테스트를 진행하는 방식에 초점이 맞춰져 있기 때문에 실제 트래픽에 이러한 탐지 방법을 적용하는 것은 무리가 있다. 이 문서에서는 문자열 탐지 방식에 적합한 Suricata를 사용하여 Slowloris 공격의 오탐을 최소화..
GREASE(Generate Random Extensions And Sustain Extensibility)는 크롬 55버전 부터 추가된 필드이다. 이 필드를 통해서 현재 Chromium 기반의 브라우저를 탐지하는데 사용할 수 있다. GREASE의 목적은 TLS 통신에서 서버의 버그를 사전에 발견하고 프로토콜 확장에 따라 발생하는 문제를 방지하고자 하는 것이다. SSL/TLS에서는 데이터를 교환하기 이전에 핸드쉐이킹을 통해서 버전 및 암호화에 필요한 정보를 교환한다. 클라이언트가 서버로 전송하는 ClienHello에 TLS 1.2을 명시하고 전송했을 때, TLS 1.2을 지원하는 서버라면 이에 대하여 정상적인 ServerHello를 통해서 응답을 진행한다. 만약 서버가 TLS 1.2를 지원하지 않는다면,..
TCP 스트림은 재조합을 지원하기 때문에 문자열 분할에 대해 크게 문제될 것은 없다. 하지만, 문자열 패턴이 아닌 순수한 스트림 또는 트래픽 양을 확인해야 하는 경우에는 탐지하기 곤란하거나 고려해야 할 요소들이 훨씬 많아질 수 있다. 이런 요소들 중 TCP Out-Of-Order (OOO) 또는 segment loss는 연속된 스트림에서 TCP segement의 양을 측정하는 것을 매우 어렵게 만든다. 아래 내용은 TCP OOO와 segment loss가 정확히 몇번 발생했는지 등의 완전성을 목표하지 않는다. 이런 현상이 발생하는 빈도를 탐지하는 것을 목표(실시간 완전 탐지는 어려움이 존재)로 하며, Suricata IPS(Inline)모드를 사용하여 탐지한다. suricata는 기본적으로 설정된 chu..
원격 데스크톱은 대상 컴퓨터가 원격 데스크톱을 허용해두었다면, 윈도의 mstsc 이용해서 간단하게 접속할 수 있고 RDP 환경에서는 대부분의 기능을 거의 동일하게 사용할 수 있기에 많은 표적이 될 수 있다. 그림 1은 윈도우에서 mstsc를 이용한 원격 데스크톱 접속 시 패킷, 그림 2는 우분투에서 RDV, KRDC, Remmina를 통해서 접속 시의 패킷 페이로드를 나타낸다. 두 개의 패킷에서 공통적으로 찾아볼 수 있는 패턴은 |03 00 00|과 |e0 00 00 00 00| 이며, 이 패턴들은 Emerging-Threats Open 룰에서도 거의 동일하다시피 찾아볼 수 있는 패턴이다. 이처럼 RDP가 경유하는 구간에서는 IDS, IPS의 간단한 정책만으로도 RDP 요청을 탐지할 수 있다. 문제는 R..
Client에서 Scan과 Crawler의 차이라고 한다면 서버의 데이터를 가져온(GET) 뒤 데이터 파싱의 유무라고 볼 수 있다. 이를 다시 중간 경유지인 네트워크 구간 탐지 관점(IDS뿐만 아니라)으로 본다면, URL Scan과 Crawler의 특별한 차이는 없다. Crawler는 많은 정보를 가져오기 위해서 결국 URL을 탐색해야 되기 때문이다. 외부 구간이 HTTPS 프로토콜을 사용하더라도 리버스 프록시 등을 이용해서 내부 구간에 있는 IDS를 통해서 탐지가 가능 하기 때문에 특정 스캐너가 가지고 있는 문자열을 기반으로 탐지 할 수 있다. 하지만, Scanner를 식별할 수 있는 패턴은 변경이 가능하며, 이러한 종류가 너무 많다는 것이 가장 큰 문제이다. 또한 Injection과 같은 공격과 달리..