⭐현대오토에버 모빌티리 SW 스쿨 최종프로젝트⭐

🍅주제

협력사 기반 침해사고 분석 및 보안 솔루션 대응

1. 개발환경

개발 언어: PHP, JavaScript
프레임워크: React
개발환경: Vim, VSCode
기타: Git Hub, AWS, Ubuntu

2. 내 역할:

보안 솔루션 운영: IPS 탐지 규칙 최적화, ACL/보안 그룹 설정
침해사고 분석: 협력사 파트 로그 및 침해사고 분석
인프라 구축: 전체적인 인프라 구축 및 보안솔루션 운영
공격: 시나리오를 통한 본사 침투 시뮬레이션

3. 인프라 구조

대기업 본사: 개발망, 보안망, 직원업무망으로 망분리, 부분적으로 취약점 존재
협력사: 대기업 본사의 협력사인 SI기업, 보안이 취약한 웹서버 존재
공격자: Kali Linux

4. 프로젝트 목적

취약한 협력사를 통한 본사 침투 시뮬레이션
사고 발생 과정 및 공격 기법 식별 및 근본적인 보안 취약점 도출

5. 공격 시나리오

협력사
1. 공격자가 협력사 웹서버 스캐닝 툴(Nikto)로 스캔
2. SQL Injection을 통해 웹서버 로그인
3. 디렉토리 인덱싱 + 파일업로드를 통한 리버스쉘, exploit.c 코드 업로드
4. 웹서버에서 CVE-2019-0211을 통한 아파치 취약점을 통해 root로 권한상승
5. 웹서버 코드 수정하여 협력사 직원에게 피싱 공격
6. 협력사 직원 PC에서 키로깅 및 화면 모니터링을 통해 VPN, SSH 키 탈취

본사
1. 탈취한 키를 통해 본사 개발망으로 접속
2. 개발망에서 스캐닝 툴을 실행하여 사내 내부망 발견 및 접속
3. 사내 내부망에 회원가입(내부망이다보니 별도의 인증과정이 없음) 및 로그인
4. 게시판에 랜섬웨어(WannaCry)업로드
5. 본사의 일반 직원이 첨부파일(랜섬웨어) 다운로드 및 실행을 통해 랜섬웨어 감염

6. 공격 영상

---

🍅문제점 및 해결방법

1. AWS SIEM 인스턴스 장애

✅문제점
공격 시나리오 실행 후 대량의 로그가 쌓이며 Wazuh가 과부하 발생
로그 폭증으로 인해 Elasticsearch 및 Wazuh-Manager가 비정상 종료
OOM-Killer(디스크 및 메모리 부족) → 시스템 전체 불안정 → SSH 접속 불가
AWS 콘솔에서 원격 접속, 재부팅, 메모리 확장 등 모든 복구 시도 실패
실시간 로그 분석 불가능 → 보안 가시성 저하

✅해결방법
AWS SIEM 장애 대응 및 로그 백업 시스템 구축
AWS 인스턴스 복구 불가능 → MySQL을 이용한 로그 백업 시스템 활용
MySQL 백업 로그를 사용하여 침해 분석 진행, 데이터 유실 방지

2. 보안 그룹 & ACL 설정 미흡 (망 간 차단 정책 & SIEM 로그 수집 문제)

✅문제점
개발망 → 보안망 트래픽이 일부 허용되거나, 필요한 로그 수집이 차단되는 문제 발생
SIEM이 개발망의 로그를 받아야 하지만 ACL이 트래픽을 차단하여 로그가 유실됨
반대로, 불필요한 트래픽(SSH, ICMP 등)은 차단되지 않아 내부 이동 가능성 존재

✅해결방법
VPC 서브넷 간 ACL을 최적화하여 불필요한 트래픽 차단, 로그 수집 트래픽 허용
보안 그룹에서 SIEM으로 가는 특정 포트(Syslog, ElasticSearch 등)만 허용

3. WireGuard VPN 사용 시 Suricata 로그에서 원래 IP가 기록되는 문제

✅문제점
VPN을 통해 접속하면 WireGuard에서 설정한 IP가 아닌 실제 원래 IP가 기록됨
VPN 사용 여부를 정확히 탐지할 수 없어 보안 정책 적용이 어려움

✅해결방법
WireGuard 인터페이스(wg0)도 Suricata의 모니터링 대상으로 추가
iptables NAT 규칙을 추가하여, VPN 내부 IP가 기록되도록 변경
VPN을 통한 SSH 접속과 일반 SSH 접속을 구별하여 탐지 가능하도록 개선

4. Suricata에서 SSH 트래픽이 과도하게 기록되어 로그 분석이 어려웠던 문제

✅문제점
SSH 접속 시 Suricata가 비정상적으로 많은 로그를 생성하여 탐지 정확도 저하
SSH Brute-force 시도와 정상 접속을 구분하는 것이 어려움

✅해결방법
일정 시간 내 SSH 접속 횟수 기준 설정하여 탐지 최적화

5. SSH 포트 52000으로 접속 불가 (Access Denied 오류 발생)

✅문제점
SSH 포트를 기본 22 → 52000으로 변경하려 했으나 접속 불가 (Access Denied 발생)

📌가능한 원인 분석

1. AWS 보안 그룹(Security Group) 또는 네트워크 ACL(NACL)에서 52000번 포트 차단 가능성
2. OS 내부 방화벽(UFW, iptables)에서 특정 포트 제한 가능성
3. AWS 내부적으로 특정 포트(52000)가 예약되었을 가능성
4. SSH 설정 파일(/etc/ssh/sshd_config)에서 포트 설정이 적용되지 않았을 가능성

✅해결방법
포트를 8888로 변경하니 정상적으로 접속 가능 → 특정 포트(52000)에서만 문제가 발생

6. Suricata 로그가 보이지 않는 문제

✅문제점
Suricata가 정상적으로 실행되었지만, sudo를 사용해도 로그가 보이지 않음

📌 가능한 원인 분석

1. Suricata의 로그 파일이 root 권한으로만 접근 가능하도록 설정됨
2. Suricata 서비스 실행 계정이 일반 사용자와 다름
3. /var/log/suricata/ 디렉터리의 권한이 제한됨

✅해결방법
root 계정으로 직접 확인하니 정상적으로 로그가 출력됨
Suricata 로그 디렉터리 권한 변경 → 일반 사용자도 읽기 가능하도록 조정
sudo chmod -R 755 /var/log/suricata/ 또는 sudo chown -R (whoami):(whoami) /var/log/suricata/ 실행
Suricata 서비스 실행 계정 확인 후, 필요 시 sudoers 설정 변경

7. Suricata의 공격 미탐

✅문제점
해당 문제점은 에러는 아니고 공격 성공을 위해 의도적으로 IPS인 Suricata의 룰을 취약하게 작성
그로 인해 내부망 이동(Lateral Movement), 엔드포인트 공격(악성파일 업로드) 미탐 등 몇몇 보안 취약점 존재

✅해결방법
1. WAF 도입
파일 업로드 필터링 적용
특정 파일 전송 시 차단 룰 추가
특정 확장자 업로드 제한

2. IPS 정책 수정
SMB 프로토콜에서 비정상적인 트래픽 차단 기능 추가
SSH, SMB, RDP 전반적으로 탐지 가능하도록 개선
WAF + IPS 연동하여 웹 공격 및 내부망 이동 감지 가능하도록 개선