ELKF 구축 전 update&upgrade 진행 - 시스템의 안정성과 보안, 호환성을 위해 진행Java가 설치되어있지 않으므로 설치 진행Java 설치 후 버전 확인elasticsearch 인증키 설치 - OK 문구가 떠야 성공적으로 인증키 설치가 된 것elasticsearch 저장소 등록update 진행 - 새로 등록한 elastic 저장소에서 패키지 목록을 가져오기 위해 진행elasticsearch 패키지 설치elasticsearch.yml파일 수정주석 제거, 이름 작성주석 제거, 구문 작성주석 제거주석 제거주석 제거, 위 23라인의 node이름 작성데몬 실행, 활성화http://<ELKF서버IP>:9200 접속하여 정상작동 확인kibana 패키지 설치kibana 환경설정 파일 수정주석 제거주석 제거, 구문 수정주석 제거, ELKF서버IP작성kibana 데몬 실행, 활성화http://<ELKF서버IP>:5601 접속 확인, 아직 전부 설치하지 않았으므로 kibana 작동 안되는 것이 정상logstash 패키지 설치logstash.conf 파일 생성해서 로그 작성위와 같이 logstash 파일 작성 - 로그 수집을 위해 작성logstash데몬 실행, 활성화filebeat 패키지 설치filebeat 환경설정 파일 수정구문 수정구문 수정구문 수정138, 140 주석 처리151, 153 주석 제거, <ELKF서버IP>입력filebeat 모듈 실행ELKF 데몬 순서대로 실행 - 무작위로 실행 시 데이터 흐름때문에 오류 발생 가능http://<ELKF서버IP>:9200/_cat/indices?v 검색시 정상 절치와 작동 확인 가능http://<ELKF서버IP>:5601로 kibana접속
2. UD_board, Rocky_board, DVWA - filebeat 설정
filebeat 연동 전 ELKF에 설치된 elasticsearch버전 확인
-> 각 서버에 ELKF서버의 elasticsearch버전과 맞는 filebeat 설치해줘야 함.
-> 버전이 안맞을 경우 생기는 문제
API 변경 문제
: Elasticsearch는 버전 업이 되면서 내부 API나 통신 프로토콜이 변경되는 경우가 있어요.
Filebeat가 오래된 버전이면, 최신 Elasticsearch의 API를 인식 못 해서 에러가 납니다.
필드 매핑 오류
: Filebeat는 로그를 Elasticsearch에 보낼 때 기본적으로 사용하는 필드 매핑이 있어요.
버전이 다르면 이 매핑이 충돌하거나 로그가 제대로 저장되지 않을 수 있어요.
Ingest Pipeline 호환성
: Filebeat는 자체적으로 Ingest Pipeline을 사용할 수 있는데,
이건 Elasticsearch와 tightly coupled 되어 있어서 버전이 맞아야 제대로 작동해요.
Module 설정 차이
: 예를 들어 apache, mysql 같은 module들을 쓸 때도,
Elasticsearch에 적절한 대시보드나 템플릿을 설치하는데 이게 버전에 따라 다를 수 있어요.
위 elasticsearch 공식 홈페이지에서 맞는 버전 찾아서 다운로드 데비안계열은 deb 레드헷계열은 rpm으로 설치
-> filebeat설치 후 압축파일 성공적으로 압축해제 시 filebeat.yml파일이 생성됨.
모든 서버에서 /etc/filebeat/filebeat.yml 설정파일 열어서 아래와 같이 구문 수정.
Rocky의 경우 34라인만 차이 발생. 나머지는 전부 동일
이후 과정 모두 동일
22, 28, 32-35 구문 수정Rocky의 경우 apache2가 아닌 httpd이므로 수정. 또한 로그기록 수집되는 파일이 .log파일이 아니어서 *.log 설정시 board게시판에 로그인하는 접속 기록 등 뜨지 않음. 그러므로 *_log로 수정해줘야 *_log에 수집되는 로그기록 확인 가능구문 수정138, 140 주석처리151, 153 주석제거,구문수정 ELKF서버IP 작성filebeat 모듈 활성화filebeat 데몬 실행, 활성화
3. ELKF - Snort 설치
update&upgrade 후 진행snort 필수 패키지 설치IP설정 후 enter눌러 설치 이어서 진행snort 환경설정 파일 수정구문 수정, ELKF서버IPsnort.conf 파일의 세팅 여부 확인위와 같이 뜨면 정상 구동됨 확인 가능snort 실행 시 돼지가 보인다면 성공적으로 실행된 것추가 패키지 설치추가 패키지 설치snort 데몬 실행, 활성화websnort 실행http://<ELKF서버IP>:8080 접속접속시 기록 확인 가능snort 탐지 규칙 공통 요소 파일 수정구문 수정80번 포트가 제일 앞인지 확인 - 성능과 룰 작동 방식에 영향을 줄 수 있어서 80번 포트 우선 감지를 위해 확인/etc/snort/rules/local.rules 파일 열어서 snort 탐지 룰 설정snort 데몬 실행, 활성화
pfsense - snort
Services > Snort > INTRA Inteface Settings - General Settings - Enable 체크
→ Snort가 해당 인터페이스(INTRA)에서 트래픽 감시하도록 활성화
Send Alerts to System Log - rsyslog 통해 elkf로 보냄 & Enable Unified2 Logging - snort alert로그 확인 및 백업용 체크Status > System Logs > Settings > Remote Logging Options > Enable Remote Logging -> System Events 체크 안해주면 Snort가 보낸 알림은 pfSense의 System Log (syslog) 로 들어가고, 거기서 외부로 전송되기 때문에 이 항목을 체크하지 않으면 로그가 외부로 전송되지 않음. 또한 Remote Syslog Contents에서 Everything에 체크를 하게되면 모든 로그가 다 뜨기 때문에 공격만 보기 쉽지 않음. 그래서 System Events만 선택해주면 공격감지만 가능하다.Services > Snort > Interface Settings > DMZ Rules - custom.rules 작성System > General Setup 시간 설정/etc/rsyslog.d/50-snort.conf
→ pfsense IP = 172.2.2.254.
→ pfsense가 포트번호 514로 전송하는 pfsense 로그 받아서 /var/log/snort.log파일에 저장
위에서 설정해준 /var/log/snort.log 파일을 syslog가 읽을 수 있어야하므로 그룹권한 변경해줌/etc/logstash/conf.d/logstash.conf (1)/etc/logstash/conf.d/logstash.conf (2)Brute Force - Python(1)Brute Force - Python(2)System Event Log 중에 [Brute Force]만 탐지
