https://github.com/Muneer44/Security-Onion-Traffic-Analysis

 

GitHub - Muneer44/Security-Onion-Traffic-Analysis

Contribute to Muneer44/Security-Onion-Traffic-Analysis development by creating an account on GitHub.

github.com

 

 

 

내가 만든 룰 테스트 해볼 때 ↓

https://malware-traffic-analysis.net/index.html

 

malware-traffic-analysis.net

                                                A site for sharing packet capture (pcap) files and malware samples. I started this blog in 2013 to share pcaps and malware samples.  Due to issues with Google, I've had to take most a

www.malware-traffic-analysis.net

 

 

 

kali에서 로그인 한 후 

 

security onion에서 ip ad를 한 후

 

 

 

 

 

 

 

 

 

unzip 2024-11-26-traffic-analysis-exercise.pcap.zip

 

 

password 는 infected_20241126

 

sudo so-im  (얜 뭐지)

 

 

sudo su-import-pcap 2024-1126-traffic-analysis-exercise.pcap

 

 

security onion 명령어는 so로 시작함

 

 

 

ctrl + 링크 클릭

 

 

 

 

 

대시보드 화면 나옴 ㅜㅜ

'보안 > 보안 관제' 카테고리의 다른 글

Splunk 분석 실습  (2) 2024.12.13
Splunk  (0) 2024.12.12
SoC  (0) 2024.12.12
aws 로그 수집 구축  (1) 2024.12.12
Snort 환경 구축  (1) 2024.12.11

 

이 3개 중요함

 

 

 

Splunk 구성

index: 일종의 DB라고 생각하면 됨

source Type: DB를 구성하는 테이블 정보라고 보면 됨

이미 알려진 로그들의 필드정보를 가지고 있음

fields: column이라고 보면 됨

 

 

indexes

 

 

 

 

source Types

 

 

 

 

fields

 

 

 

 

Search & Reporting 을 많이씀

 

 

이 3개 많이 씀

 

Search에서 index="" 가 기본이 됨

** 검색하는 과정에서 시간 설정 중요 **

'보안 > 보안 관제' 카테고리의 다른 글

Splunk 분석 실습  (2) 2024.12.13
Security Onion - Dashboard  (1) 2024.12.13
SoC  (0) 2024.12.12
aws 로그 수집 구축  (1) 2024.12.12
Snort 환경 구축  (1) 2024.12.11

 

네트워크 장치 ↓

 

 

 

 

 

아무거나 넣기 (기억해 두고 있어야 함) pw -> 

 

 

 

 

설치중...

 

 

 

SIEM의 보안기능

 

고급 위협 탐지 → 로그 간 체인

 

 

 

 

 

'보안 > 보안 관제' 카테고리의 다른 글

Security Onion - Dashboard  (1) 2024.12.13
Splunk  (0) 2024.12.12
aws 로그 수집 구축  (1) 2024.12.12
Snort 환경 구축  (1) 2024.12.11
Snort Rule 구조  (0) 2024.12.11

BlueTeam(SoC) Security onion 설치, SIFT WorkStation

 

  • 트래픽 분석 및 로그분석을 위한 플랫폼   pcap
  • ELK, Squil, Snort, Suricata ...

 

 

RedTeam: kali

 

 

 

 

1. IAM에서 role 생성

2. 사용자 계정 access key 생성

3. EC2 생성, 1에서 생성한 role 연결

4. cloudwatchagent 설치

5. cloudwatchagent 설정

aws configure

/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

 

6. 서비스 설치(httpd=apache)

7. 서비스 접근

7. log 수집 확인

 

 


 

 

1단계에서

EC2  →  EC2 클릭

 

 

2단계

 

3단계

 

EC2 생성

IAM 역할 수정  (역할 이름: sesac228_agent)

 

 

 

생성한 EC2  →  우클릭  →  보안 →  IAM 역할 수정 

 

 

생성한 EC2  →  우클릭  → 연결

 

 

 

 

4. cloudwatchagent 설치

 

 

 

 

 

Access Key,

Secret Access Key,

Default region name 입력하면

aws configure 설정 끝

 

 


 

그 후에

 

/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

 

 

 

 

 

Log file path 설정 ↓

 

 

 

IAM  →  역할에서 설정한 것 적기

 

 

 

 

인스턴스에서 퍼블릭 주소로 들어가보기

 

 

 

CloudWatch에 로그 찍히는지 확인

 

 

 

 

자산 다 삭제

 

 

'보안 > 보안 관제' 카테고리의 다른 글

Splunk  (0) 2024.12.12
SoC  (0) 2024.12.12
Snort 환경 구축  (1) 2024.12.11
Snort Rule 구조  (0) 2024.12.11
mod security  (3) 2024.12.11

1. Snort 설치

apt update

apt install snort -y

snort --version

 

 

 

 

ip ad 로 ip 확인

 

 

 

cd /etc/snort/

snort.conf에 

모니터링 할 대역,

변수가 들어가있음

 

 

마우스 패드 설치  → rule 편집 용이하게 하기 위해

apt install mousepad -y

 

 

mousepad snort.conf

 

 

 

 

1, 7번이 중요

 

 

 

 

 

새로운 터미널 창 열어서

snort -v -c /etc/snort/rules/local/rules    // -v 자세히 실행, -c 룰 파일 지정

 

 

 

kali 에서 우분투로(내 ip로) ping 날려보기

 

 

 

로그가 저장되는 경로

cd /var/log/snort

 

 

 

 

여기까지가 Snort 환경구축 & 테스트 끝

 

 

 

4. 실습 (Snort 옵션 이해)

Option 4개


 

 

alert tcp any any -> 192.168. 내 ip any (msg:"file1"; file_data;content:"SIG";depth:8;sid:10000002;)   -> 8 바이트 이내에 SIG가 있나

alert tcp any any -> 192.168. 내 ip any (msg:"file2"; file_data;content:"SIG";depth:24;sid:10000003;)  -> 24 바이트 이내에 SIG가 있나

 

 

 

 

칼리에서 

python3 -m http.server 8080

 

 

 

 

 

Option 4개

 

룰 작성 > 파일 다운로드 > 탐지확인, 스노트 종료 > 로그확인 > 파일 내용 확인    반복

 

 

 

 

alert tcp any any -> 192.168.147.129 any

(msg:"file7";file_data;content:"SIG";depth:24;content:"SIG2";within:4;content:"SIG3";distance:9;byte_test:4,>,5,12,relative,little;sid:10000004;)

 

 

alert : 경고, 탐지, 설정

->: 클라이언트 > 서버로

any any -> any any: 모든 출발지로부터 모든 목적지

msg: "test"로 기록

file_data: binary로 분석, 정확도 올리기 위해

depth: 지정한 값 안에 탐지할 문자열 (좌측 방향 content)이 있어야 함

within: 첫 번째 조건식을 만족한 위치(depth)로부터 지정값 이내(4)에 탐지할 문자열(test3)이 있어야 함

distance: 첫 번째, 두 번째 조건식을 만족하면서 마지막 조건식으로부터 지정한 값만큼 건너뛰어 지정한 바이트 내(within, 4) 탐지할 문자열 존재(test3)

byte_test: 앞 조건식을 모두 만족(distance)하면서, 마지막 조건식으로부터 지정한 바이트(12)만큼 건너뛰고, 지정한 바이트 범위(4)의 값과 비교 연산(> 지정한 바이트가 더 커야함, 5보다 커야함), 리틀은 수치를 리틀엔디언으로 읽어오겠다란 의미

 

이 4가지 옵션이 Snort에 있어, 오용탐지를 위한 옵션이 됨

 

flow: to_server, estableshed: 연결이 명확하게 되었다 탐지를 위해 사용

 

content는 문자열 뿐만아니라 16진수도 가능

content:"123"  >> content:"|31 32 33|"

대소문자: nocase  옵션만 넣어주면 됨, 16진수 형태로 탐지하지 않는 한 일반적으로 사용 권장

pcre 정규표현식 사용이 가능

 

비정상행위 탐지

알려지지 않은 행동 탐지

횟수 기반의 접근 공격을 탐지 시 

 

 

alert any any -> 192.168.147.129 (msg:"SYN Flood Attack1";flags:S; threshold:type threshold,track by_src, count 10, seconds1;sid:100000013;)

flags: 플래그 값 기반으로 탐지 S는 SYN을 의미   >> TCP 3 Way에서 기반

threshold: type threshold(대량의 패킷 발생), track by_src(동일한 출발지 기준), count(횟수), seconds(초)

  >> 1초에 10번 동일한 출발지에서 발생하는 대량의 패킷이 발생하면 탐지하겠다.

 

DDOS를 생각해 

 

 

alert any any -> 192.168.147.129 (msg:"SYN Flood Attack1";flags:S; threshold:type threshold,track by_dst, count 10, seconds1;sid:100000013;)

  >> 1초에 10번 동일한 목적지로 향하는 대량의 SYN 패킷이 발생하면 탐지

 

 

 

 


 

 

마우스 패드에서 뭐 추가함 (뭔지 모름)

 

칼리에서

hping3 -c 20 192.168.135.168 -S --flood

 

 

고민해야하는 상황

오용탐지와 비정상행위 탐지 중 어느게 더 작성이 어려울까?

오용탐지가 더 쉬움 (정규표현식 이용)

비정상 >> 어디까지 카운팅을 허용할거냐에 대한 명확한 임계치가 없음

>> 서버 리소스를 감안해서 타협이 필요

 

 

snort 추가 실습

security onion 설치

splunk 설치 및 로그 수집

 

 

 

'보안 > 보안 관제' 카테고리의 다른 글

SoC  (0) 2024.12.12
aws 로그 수집 구축  (1) 2024.12.12
Snort Rule 구조  (0) 2024.12.11
mod security  (3) 2024.12.11
실습 - 환경세팅  (2) 2024.12.07

SPAN 모드 mirror 모드라고도 함

인라인 모드 →  실시간으로 탐지하기위함

 

명령모드

네트워크 침입탐지모드를 가장 많이 사용

나머지 2개는 거의 안씀

 

 

preprocessor 에서 Stream 은 데이터

 

Snort는 사용자가 정한 룰을 기반으로 패킷을 탐지

RTN (Rule header)  →  구조 외우기

OTN (option 영역)

 

 

 

 

 

 

icmp 가 ping..?

any로 하면 전체 변수에서 탐지를 해서 속도가 느려짐 

 

RTN(Rule header)

Q.    alert tcp 192.168.0.22  > 222.111.222.123.80    이 rule 헤더는 뭐가 잘못됐을까?

A. 방향 지시 > 가 아니라 ->

출발지도 잘못됨

alert tcp 192.168.0.22 any  -> 222.111.222.123.80

 

 

 

alert tcp 192.168.0.22/24 any  -> 222.111.222.123.80   >> 출발지 192.168.0.0(1 ~ 254)까지 모두 탐지

룰 작성시 목적지에 CIDR를 잘 사용하지 않음, 목적지가 명확함 (보통 WEB Server향하기 때문)

 

 

 

다 알아야 함 ↓ (보라색 빼고)

 

흐름옵션에서 to_server, to_client 를 많이 씀 from 은 잘 안씀

 

Q. TCP의 연결 초기화 과정은??  3-way handshaking을 거침  syn  >  syn/ack  > ack   이 이후에 통신이 이루어짐

tcp rule header에 established ......   놓침

TCP는 신뢰 기반의 protocol, 연결 지향형

 

 

 

'보안 > 보안 관제' 카테고리의 다른 글

aws 로그 수집 구축  (1) 2024.12.12
Snort 환경 구축  (1) 2024.12.11
mod security  (3) 2024.12.11
실습 - 환경세팅  (2) 2024.12.07
[로그]  (1) 2024.12.06

 

1. Desktop 에서 apt update  → 저장소 업데이트 (패키지)

 

 

 

2. apt install libapache2-mid-security2 -y



 

systemctl restart apache2 실행했을 때 오류나면

3. 도커에 pentestlab 서비스 종료 후에 아파치 재시작

 

 

 

4. 패키지가 제대로 설치됐는지 확인하는 명령어

apt-cache show libapache2-mod-security2

 

 

5. 설정파일 복사

cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf    

설정파일 복사  기본으로 설정파일이 허용되어있지 않음

 

6. 설정파일 설정  → rule 파일은 아님

mousepad /etc/modsecurity/modsecurity.conf

 

 

7번째 라인에 SecRuleEngine DetectionOnly를 SecRuleEngine On으로 수정하고 ctrl + s

 

 

 

***********  Rule 구조  ***********   4개의 필드로 구성됨

지시자 | 탐색영역 | 탐지할 데이터 | log에 기록할 메시지 필드

 

SecRule → 지시자

REQUEST_HEADERS:Content-Type    탐색 영역

"^application/json"  →  탐지할 데이터

"id:'200001',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=JSON"  → log에 기록할 메시지 필드

 

 

REQUEST: 요청(클라이언트가 서버로 보내는 데이터)

인터넷      웹서버

RESPONSE: 응답 (서버가 클라이언트로 보내는 데이터)

인터넷   ←   웹서버

 

 

^application/json    ^= 시작할 문자열 지정, application/json 문자열로 시작해야됨

 

id: rule 고유 식별번호

phase: 탐지할 영역 (1 ~ 5 까지 존재)

  phase1: request 헤더만

  phase2: request 헤더 + body

  phase3: 2 + response 헤더만

  phase4: 3 + response 헤더 + body

t: lowercase: 대소문자 구분 없음

pass: 통과하겠다

nolog: 로그로 기록하지 않겠다

 

 

 

7. 서비스 재시작

systemctl restart apache2

 

 

 

8. 사용자 룰 파일 위치 및 사용자 Rule 추가 실

000-default.comf 에 SecRuleDngine On 추가

 

 

 

 

SecRule ARGS:testparam "@contains test" "id:9999,deny,status:403,msg:'TEST'"

 

SecRule 은 무조건 적어야 함

ARGS: 전역변수(매개변수)

@contains: 파라미터 인자값

deny,status,msg: deny(거부), status(403출력), msg: log에 기록할 메시지명

 

http://test.com/?testparam=test  가 입력되면 403 출력

 

 

사용자 Rule 추가 후 서비스 재시작 (필수)

 

 

crul -v -X GET http://127.0.0.1/?testparam=1

정상적으로 페이지 불러옴

 

 

 

testparam에 test를 넣으면 403 이 뜸

사용자 룰이 잘 적용되었음

 

 

log에서 id값과 msg 확인 가능

 

 

로그 기록 확인

 

 

로그는 A ~ Z까지 필드가 존재하며, 기록되는 로그별로 고유값을 가짐

고유값을 통해 A ~ Z가 한 세트의 로그임

 

 

A  → 접속 정보가 존재, 시간정보, 접속주체(클라이언트)

B  → 클라이언트 헤더 정보

F  →  RESPONSE 헤더 정보

E  →    RESPONSE BODY 정보

H  → 탐지된 룰, 영역 기록

Z  → 로그의 끝

 

 

 

rules →  이미 작성된 룰 포함

 

 

 

 

security2.conf  →  이 설정파일이 기본 룰 임포트 설정, 12번 째 라인에 OWASP Rule 경로가 명시됨

 

 

gpt로 룰 수정하면 됨

'보안 > 보안 관제' 카테고리의 다른 글

Snort 환경 구축  (1) 2024.12.11
Snort Rule 구조  (0) 2024.12.11
실습 - 환경세팅  (2) 2024.12.07
[로그]  (1) 2024.12.06
보안 관제 (Security Operations Center, SOC)  (1) 2024.12.06

+ Recent posts