ispini 님의 블로그

OpenVPN 구성하기

ispini — Sat, 31 Jan 2026 07:22:30 +0900

VPN 구성을 초반에 썼어야 했는데, 늦어졌다.

우리 프로젝트에선 모든 팀원이 내 노트북에 설치된 ESXI를 이용하여 모든 서버를 내 노트북에서 구축하는 식으로 작업이 이루어졌는데, 팀원들의 접근을 위해 VPN이 필요했고, 난이도가 높지 않다고 알려진 OpenVPN을 이용하기로 결정했다.

방법을 알아보던 가운데, 현재 본인이 쓰고 있는 ASUS사의 공유기에서 자체적으로 OpenVPN 서비스를 지원하는 것을 알게 되었고, 그리하여 해당 기능을 이용해 VPN 연결 작업을 진행하였다.

본인이 사용한 공유기의 모델은 ASUS사의 RT-AX53U이다.

(공유기마다 OpenVPN 서비스 지원 여부가 다를 수 있으니 해당 게시글은 참고만 바란다.)

먼저 관리자 페이지에 로그인 한 뒤 VPN에 들어간다.

이후 목록에서 OpenVPN에 들어간 뒤,

사진처럼 팀원이 공유할 VPN 계정의 아이디와 비밀번호를 새로 만들어준다.

(당연히 개개인별로 서로 다른 계정 클라이언트를 만들어 각각 부여할 수도 있고, 보안상으로도 그게 더 좋다.)

암호키 종류, 접속할 VPN 대역, DNS 응답 여부 등을 체크한 뒤..

VPN 클라이언트 파일을 내보낸다.

(Internet and local network를 체크해 줘야 팀원들이 인터넷 이용도 자유롭게 할 수 있다.)

이후 팀원들에게 해당 클라이언트 파일을 제공하였고,

각자 다운받은 OpenVPN 프로그램을 실행하여 해당 파일을 불러온 뒤,

위에서 지정한 VPN 계정의 ID/PW을 입력해 내 컴퓨터의 서버에 접속하여 같이 작업을 진행하였다.

공유기에서 제공하는 iptables 기능을 이용하여 팀원들의 특정 네트워크 대역 접근 허용/차단을 할 수도 있다.

먼저 공유기의 설정에 접근하기 위해 SSH를 열어준다.

(가급적이면 LAN 대역에서만 접속할 수 있도록 제한하기)

그런 다음 공유기의 게이트웨이 ip 입력, 공유기의 ID/PW 입력한 뒤..

대충 iptables 규칙들 우겨넣을 파일 하나 만들어서 팀원들이 접속할 수 있도록 적절하게 규칙들을 넣고 저장한다.

(#!/bin/sh 명령어를 추가해 해당 파일을 배시로서 실행할 수 있도록 하기)

# VPN 클라이언트의 프로젝트 서버 접근 허용 및 관리자 페이지 차단 등등..
#!/bin/sh
iptables -I INPUT -s 10.8.0.0/24 -d 192.168.50.1 -p tcp --dport 8443 -j DROP
iptables -I INPUT -s 10.8.0.0/24 -d 192.168.50.1 -p tcp --dport 443 -j DROP
iptables -I INPUT -s 10.8.0.0/24 -d 192.168.50.1 -p tcp --dport 80 -j DROP
iptables -I INPUT -s 10.8.0.0/24 -d 192.168.50.1 -p udp --dport 53 -j ACCEPT
iptables -I INPUT -s 10.8.0.0/24 -d 192.168.50.200 -p tcp --dport 8443 -j ACCEPT
iptables -I INPUT -s 10.8.0.0/24 -d 192.168.50.200 -p tcp --dport 443 -j ACCEPT
...

이런 식으로 팀원들이 접근할 수 있는 서버 대역, 접근하면 안 되는 서버 대역들을 구분하여 각각 허용/차단 규칙을 설정할 수 있으며, 이를 통해 OpenVPN 서버 환경에서 내부망 접근 권한을 제어할 수 있다.

(iptables -I: 규칙을 리스트의 맨 위(가장 높은 우선순위)에 추가한다는 뜻이다. 가장 나중에 추가한 규칙이 가장 먼저 적용됨)

한 가지 귀찮은 점이 있다면, 공유기는 보안 문제 때문에 주기적으로 설정을 초기화한다고 한다. ASUS사의 경우 ‘Merlin’이라는 커스텀 펌웨어를 설치하면 커스텀 규칙들을 저장 및 유지할 수 있다고 하나, 본인 공유기의 경우 해당 펌웨어를 쓰기 힘들다는 정보를 보고 포기했다. 그냥 주기적으로 규칙 파일 실행하는 거 밖에 답이 없어 보인다.

그러므로 어쩔 수 없지만 VPN을 열어줄 때마다 해당 파일 실행해 iptables 규칙을 등록해주는 게 좋을 것 같다.

GitLab 구축하기

ispini — Sat, 31 Jan 2026 07:00:13 +0900

GitLab이란?

소스코드 저장소(Git)이나 통합 및 배포(CI/CD), 이슈 추적 등 소프트웨어 개발의 모든 과정을 한 플랫폼에서 관리할 수 있는 웹 기반의 DevOps 플랫폼으로, 소스 코드 관리(SCM)이나 CI/CD 자동화, 보안 및 모니터링 등의 기능을 제공하며 팀원들과의 협업에 최적화되어 있는 것이 특징이다.

누구나 접근할 수 있는 오픈형 커뮤니티인 GitHub와는 달리 자체 설치형으로서 회사나 팀원 공용 서버 내부에 소스 코드 및 작업 산출물들을 저장하여 폐쇄적으로 관리하므로 GitHub보다 좀 더 보안상으로 유리한 부분이 있다.

우리 프로젝트는 사실 개발 프로젝트가 아니라 보안 쪽, 그것도 여러 보안 솔루션 활용을 통한 인프라 보안? 구축 및 실습이 주 목적이다 보니 깃랩을 크게 활용하진 않았지만, 실전 환경과 최대한 비슷한 환경을 구축해 다양한 각도에서 보안 정책 및 고도화 등을 고민 및 구축해본다는 느낌을 주기 위해 개발망의 개발용 서버에 같이 구축해 보았다.

먼저 패키지를 준비한다.

apt update
apt install -y ca-certificates curl openssh-server tzdata

그 다음 깃랩의 CE 저장소를 추가한다.

curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash

The repository is setup 어쩌고 뜨면 추가가 잘 된 것이다.

이후 아래 명렁어로 CE 패키지를 깔아준다.

apt install gitlab-ce

여기서 시간이 좀 오래 걸린다. 느긋이 기다리다 보면,

아래처럼 화면이 뜰 것이다.

그럼 이제 /etc/gitlab/ 경로 안에 있는 gitlab.rb 파일을 편집기로 들어가서 external_url 부분을 본인이 원하는 도메인으로 바꿔준다. (이제 이 도메인으로 깃랩 홈페이지에 들어가게 된다.)

(주의: registry_external_url 얘는 아니다, 애초에 주석 처리가 되어있으므로 헷갈리지 말기)

이후 바뀐 설정을 적용하기 위해 아래와 같이 명령어를 입력한다.

gitlab-ctl reconfigure

얘도 마찬가지로 시간이 좀 걸린다. 느긋이 기다리자.

gitlab Reconfigured! 뜨면 적용이 잘 된 것이다.

(이후 gitlab-ctl status를 입력했을 때 모두 run 이라 뜨면 잘 실행되고 있는 것)

이후 해당 서버의 웹브라우저에 들어가 위의 external_url을 입력한다.

이 때, localhost가 아닌 위 사진처럼 커스텀 도메인을 지정하면 바로 안 들어가지는데,
/etc/ 경로의 hosts 파일을 편집기로 들어가서 루프백 IP에 해당 도메인을 짝 맺어주면 된다.

이런 식으로

그런 뒤 브라우저에서 다시 도메인을 쳤을 때, 아래처럼 퐉스가 뜨면 성공이다.

이름이랑 비밀번호를 모르는데??
=> 이름은 gitlab을 깔은 리눅스 계정(여기선 root), 비번은 /etc/gitlab/ 경로 안의 initial_root_password 파일에서 볼 수 있다.

저 밑줄의 비밀번호를 복사해 붙여넣으면 되는데, 솔직히 너무 길고 복잡하다.

저걸 계속 쓰기엔 정신건강에 해로우므로, 프로필 설정에서 바꿔주자.

위 순서대로 들어가서 바꿔주면 된다.

이제 SSH 키를 등록해야 한다.

콘솔창에서 아래와 같이 입력해 RSA 키를 만들어 준다.

ssh-keygen -t rsa -b 4096

(키 값 길이는 굳이 4096을 주지 않아도 됨)

만든 키를 확인하여 gitlab 홈페이지에서 ssh 키를 등록한다.

root 계정으로 만들었다면 경로는 /root/.ssh/, 파일 이름은 id_rsa.pub

(참고: id_rsa는 개인키, id_rsa.pub는 공개키 파일, 개인키는 보관 각별히 할 것)

이제 위 사진의 'ssh-rsa' 부분부터 마지막의 '-VMware' 부분까지 모두 복사하여 아래 창에서 추가한다.

타이틀이 잘 뜨는지 확인한 뒤 저장하면 된다.

이제 테스트를 위해 프로젝트를 만들어 본다.

Projects 메뉴에서 새로운 프로젝트를 만들어 준다.

위 사진처럼 적절하게 프로젝트 이름 등을 추가해서 등록한다.

그럼 이렇게 프로젝트가 등록된 것을 볼 수 있다.

이제 커밋 테스트를 해 본다.

아래 사진처럼 프로젝트가 들어갈 디렉터리를 만든 뒤, Git 계정을 만들어 준다.

git config --global user.name “이름”
git config --global user.email “이메일”

이후 해당 프로젝트의 디렉터리에 들어간 뒤 아래 명령어를 입력한다.

git init --initial-branch=master

(디렉터리를 초기화한 뒤 Git 저장소로 만들고 저장소를 master라고 선언하는 명령어이다. 사실 굳이 master라 등록 안 해도 된다.)

커밋이 이루어질 원격 주소(gitlab 홈페이지 주소)를 아래처럼 입력한다.
(포트 뒤에 경로도 같이 적기)

git remote add origin http://potato.com:8081/root/local_test.git

(만약 주소를 잘못 적었으면 => git remote remove origin)

대충 시험 삼아 올릴 파일 하나 만든 뒤 상태를 확인해준다.

위처럼 추가/수정된 파일이 있으면 빨간색으로 뜬다.(git status 명령어로 확인할 수 있음)

아래 명령어로 커밋할 명단에 해당 파일 올린 뒤,

git add test.txt

(모든 파일을 한 번에 올리고 싶으면 'git add .' 라고 입력하면 된다.)

아래 명령어로 커밋한다.

git commmit -m “아무 메시지”

푸시를 해야 프로젝트에 올라가므로 명령어를 입력한 뒤,

git push -u origin master

gitlab 홈페이지의 ID/PW 입력하면 push가 완료된다.

이후 웹페이지의 프로젝트에 들어가보면 커밋 및 푸시된 파일을 확인할 수 있다.

이번 프로젝트에서 깃랩을 전혀 활용하지 않은 건 아니다. 도박이나 성인 사이트 등의 도메인들이 모여 있는 텍스트 파일을 구할 수 있었는데, 해당 텍스트 파일을 먼저 해당 서버로 옮긴 뒤 위에서처럼 깃랩을 이용해 프로젝트에 커밋/푸시를 한 다음 해당 프로젝트 내 파일의 URL을 OPNsense의 웹 스퀴드(웹사이트 접근을 제한할 수 있는 ACL 기능을 제공하는 프록시 서버 솔루션)에서 등록 + Remote Access Control Lists 설정을 건드려주면 각 서버마다 텍스트 파일 내 유해 도메인 접근을 차단할 수 있었다.

해당 텍스트 파일을 블랙리스트로서 활용하며 새로운 차단 대상 사이트가 생기면 따로 외부 연동 작업을 할 필요 없이 새로운 도메인만 추가해 다시 Commit/Push 하면 되고, 언제 왜 차단 사이트 목록을 갱신했는지 버전 추적도 가능하므로 GitLab을 활용한 보안 작업 역시 충분히 쓸모 있지 않을까 하는 경험을 얻을 수 있었다.

ProxySQL과 스플렁크 연동 및 대시보드 커스텀화하기

ispini — Sat, 31 Jan 2026 05:59:01 +0900

전 게시글에서 본대로, 내부망 쪽에 설치한 스플렁크에 ProxySQL의 쿼리 로그들을 넘긴 뒤, 그 곳에서 대시보드를 커스텀화해 로그들을 알아보기 쉽게 하도록 할 예정이다.

일단 ProxySQL에서 기록하는 로그 파일의 내용들은 한 눈에 알아보기가 다소 힘들다.

이를 좀 더 알아보기 쉽게 하고 또 깔끔하게 보이게 하기 위해서, 스플렁크와 로그 연동 및 대시보드 커스텀화를 진행해 볼 예정이다.

로그 연동시키기

먼저 ProxySQL에서 스플렁크 포워더를 설치했다.

wget -O splunkforwarder-10.0.2-e2d18b4767e9-linux-amd64.deb "[https://download.splunk.com/products/universalforwarder/releases/10.0.2/linux/splunkforwarder-10.0.2-e2d18b4767e9-linux-amd64.deb](https://download.splunk.com/products/universalforwarder/releases/10.0.2/linux/splunkforwarder-10.0.2-e2d18b4767e9-linux-amd64.deb)"

그런 다음 아래 3줄을 순서대로 입력해 패키징, 포트포워딩, 시작프로그램 등록을 진행한다.

dpkg -i splunkforwarder-10.0.2-e2d18b4767e9-linux-amd64.deb
/opt/splunkforwarder/bin/splunk add forward-server 192.168.50.201:9997
/opt/splunkforwarder/bin/splunk enable start

이후 방화벽에서 NAT로 룰을 열어준 뒤,

pf 입장에서 외부인 opn으로부터 로그를 받아야 하므로 pf에서 포트포워딩을 열어줬다.

방화벽 룰도 열어준다.

(OPNsense의 경우 개발 VLAN에서 룰을 열어줌)

이후, var/lib/proxysql 경로 안에 기록되고 있는 로그 파일들을 연동시키기 위해 아래와 같이 직접 등록한다.

/opt/splunkforwarder/bin/splunk add monitor /var/lib/proxysql/proxysql_audit.log* -index main -sourcetype proxysql:audit

리부팅 명령어로 재시작을 해준다.

/opt/splunkforwarder/bin/splunk restart

스플렁크 웹 페이지의 설정에서 전달 및 수신 들어간 뒤, 데이터 수신의 수신 설정 새로 추가 ⇒ 9997번 포트를 추가한다.

로그를 불러오는 데 쓰일 포워더의 포트인 9997번을 추가해 준다.

이제 개발/사무망 내 pc에서 프록시를 통해 입력하는 쿼리들의 로그를 뽑아서 스플렁크에서 확인할 수 있다.

예1)

DB 접근이 허가된 PC에서 인가되지 않은 쿼리를 입력했을 때

예2)

어떤 IP를 가진 PC에서 언제 어느 계정으로 DB에 접속하여 어떤 비인가 쿼리를 날렸고, 그 차단 사유가 무엇인지를 전체적으로 종합하여 보고 싶을 때

예3)

어떤 허가되지 않은 PC에서 DB에 접속해 내용 조회나 데이터 수정 등을 시도하였고, 그 쿼리의 내용은 어떤지를 종합하여 보고 싶을 때

대시보드 만들기

검색 결과 창에서 다른 이름으로 저장 => 새 대시보드를 눌러 우리가 새롭게 관제(?)할 대시보드 틀을 만들어 준다.

이후 대시보드의 이름을 짓고, 유형을 고른 뒤 저장하면 된다.
(본인은 좀 더 시각적으로 풍부해 보일 것 같은 대시보드 스튜디오를 골랐다.)

한 번 대시보드를 만들었으면, 이후엔 추출한 검색 결과를 추가할 때 '기존 대시보드'를 눌러 먼저 추가한 대시보드 안에 넣으면 된다.

이후 해당 대시보드에 들어가서 편집을 누르면, 추출한 검색 결과를 커스텀할 수 있는 옵션들이 다양하게 나온다.

되는 대로 얼추 다듬어 본 끝에, 본인은 아래 사진과 같이 대시보드를 커스텀화 해보았다.

(비인가 쿼리, 외부 접근 시도 횟수, DB 이용자 수 숫자 표시 및 시간대별 그래프, 쿼리 내용 상세 로그 등)

전체 DB 쿼리 이력 부분 사진은 해당 쿼리에 대한 로그 기록 전체를 긁어 온 보드이다.

이런 느낌으로 실제 보안 관제에서 어떤 방식을 이용해 실시간으로 들어오는 로그를 분석하고 대처 방안을 강구하는지에 대해 살짝이나마 체험을 해 보고 실습하는 과정을 가졌다.

스플렁크 설치하기

ispini — Sat, 31 Jan 2026 05:41:08 +0900

먼저 스플렁크가 어떤 시스템인지를 설명하자면,

스플렁크는 ESM(Enterprise Security Management) 시스템에 속하는 솔루션으로, ESM을 전사적 보안 관리 시스템이라고도 부른다고 한다.

방화벽이나 IDS/IPS 등 여러 보안 솔루션들의 로그와 운영을 통합해 관리하는 솔루션으로 로그 중앙 집중 관리 및 로그를 이용한 통합분석과 연관분석을 지원하는 것이 특징이다.

보안 관제의 효율성 높이기 등 다양한 이유로 ESM이 쓰인다.

그럼 스플렁크(Splunk)는?

위에서 말한 ESM 솔루션 중 하나로, AI 바탕의 통합 보안 및 능동적 모니터링(옵저버빌리티) 기능을 제공하는 것이 특징인 보안 솔루션이다.

로그 수집 및 분석, 실시간 모니터링 및 경보, 관리 및 인증 기능 등을 같이 제공한다고 한다.

전 게시글에서 기록한 로그들을 스플렁크에 연동 및 커스텀화하기 위해 먼저 스플렁크를 구축하는 작업을 진행할 예정이다.

먼저 Splunk 홈페이지에 들어가 회원가입을 해 준다.

정보 입력 뒤 아래와 같은 화면이 나오면 이메일이 왔는지 확인해 인증을 진행한다.

근데 본인은 안 왔다. 이메일을 여러 개 제공해 봤지만 단 한 번도 인증 메일이 오지 않아서, 팀원의 도움을 받아 간신히 로그인할 수 있었고, 로그인 한 뒤 Enterprise 다운로드에 들어가면 나오는 wget 링크를 이용하여 서버에 스플렁크를 설치하였다.

wget -O splunk-10.0.2-e2d18b4767e9-linux-amd64.deb "[https://download.splunk.com/products/splunk/releases/10.0.2/linux/splunk-10.0.2-e2d18b4767e9-linux-amd64.deb](https://download.splunk.com/products/splunk/releases/10.0.2/linux/splunk-10.0.2-e2d18b4767e9-linux-amd64.deb)"

그 다음엔 아래 명령어를 입력해 패키지를 설치한다.

dpkg -i splunk-10.0.2-e2d18b4767e9-linux-amd64.deb

설치가 끝났으면, 아래 명령어로 스플렁크를 실행해 준다.

/opt/splunk/bin/splunk start

이후 아래와 같은 화면이 뜨면, 무사히 접속에 성공한 것이다.

이후 방화벽에서 포트포워딩 기능을 이용해 스플렁크 웹 페이지에 들어갈 수 있도록 포트를 열어준다.

(위 사진에서 8000번 포트를 이용해 웹 페이지가 열렸으므로 똑같이 8000번 포트와 매칭시키기)

잘 연결이 되었다면 위와 같이 메인 페이지가 뜰 것이다.

설치 과정에서 입력한 ID/PW를 입력한 뒤, 아래와 같이 관리 페이지가 뜨면 준비는 끝났다.

다음 게시글에선 프록시SQL 로그와의 연동 등을 작성할 예정이다.

ProxySQL 쿼리 필터링 실습하기

ispini — Sat, 31 Jan 2026 05:12:25 +0900

ProxySQL을 맛보기로나마 다뤄보면서 느낀 것은, 쿼리 필터링 기능 하나로 안 되는 게 없다는 것이다.

특정 쿼리 실행을 막는 것부터 시작해서 반대로 특정 쿼리만 실행할 수 있게 한다든지, 원하지 않는 테이블의 데이터는 가려서 출력되도록 만든다든지, 계정별로, DB 서버 별로 규칙을 커스텀할 수 있다든지...

물론 이 프로젝트를 진행하면서 내가 다뤄본 건 새발의 피 수준일 것이고, 프로젝트가 개발 쪽이 아닌 보안 기능 구현이었기 때문에 제대로 활용한 것은 아닐테지만, 그래도 직접 솔루션을 써보면서 겪은 경험들이 조금이나마 도움이 되지 않을까 싶어 쿼리 필터링 실습 부분도 같이 써 본다.

TLS/SSL 적용하기

먼저 프록시 서버에서 /etc/ 경로의 proxysql.cnf 파일을 편집기로 연 뒤, 'mysql_variables' 구역 안에 아래와 같이 명령어를 추가한다.

(프록시 서버에 기본으로 내장된 CA 및 개인키를 활용할 예정)

have_ssl=true
ssl_ca=”/var/lib/proxysql/proxysql-ca.pem”
ssl_cert=”/var/lib/proxysql/proxysql-cert.pem”
ssl_key=”/var/lib/proxysql/proxysql-key.pem”

그런 다음 프록시 서버를 재시작한 뒤, tmp 경로에서 각 DB 계정마다 연결에 쓸 인증서를 만들어준다.

openssl genrsa -out [DB 계정이름].key 2048 && \
openssl req -new -key devel.key -out [DB 계정이름].csr -subj "/CN=[계정이름]" && \
sudo openssl x509 -req -in [DB 계정이름].csr -CA /var/lib/proxysql/proxysql-ca.pem -CAkey /var/lib/proxysql/proxysql-key.pem -CAcreateserial -out [DB 계정이름].crt -days 3650

얘네들이 한 줄이다.

이후 테스트할 PC(개발서버 등)에서 /etc/mysql/ssl 경로 안에 디렉터리를 만들어준 뒤, 프록시 서버에서 scp 명령어 등을 이용해 전송한 인증서를 경로 안에 한 묶음으로 넣는다.

(플젝에서는 그냥 한 개발서버 안에 모든 DB 서버의 인증서를 넣어 테스트했기 때문에 한 서버 안에 디렉터리를 여러 개 만들어 모든 DB에 접근할 수 있도록 했지만, 실제로는 이러면 안 될 것이다..)

아래 사진과 같이 디렉터리 안에 넣는다.

사실 csr 파일은 필요 없다.

각 DB 접속 계정의 SSL 통신을 활성화하기 위해 아래처럼 명령어를 입력한다.

update mysql_users set use_ssl=1 WHERE username IN ('계정이름1', '계정이름2', ...);

모든 작업을 할 때마다 아래 명령어로 적용 및 저장을 해 주는 것을 잊지 말자.

load mysql users to runtime;
save mysql users to disk;

이제 테스트용 PC에서 프록시SQL에 접속할 때마다 아래와 같이 쳐야 하는데..

mysql -u devel -p -h 192.168.120.10 -P 6033 \
--ssl-ca=/etc/mysql/ssl/ca-cert.pem \
--ssl-cert=/etc/mysql/ssl/devel/devel.crt \
--ssl-key=/etc/mysql/ssl/devel/devel.key

이건 너무 길으므로.. 홈 디렉터리의 .my.cnf 파일을 좀 건드려서 계정 이름만 쳐도 접속할 수 있도록 바꿔줄 예정이다.

이렇게 추가했다. 이러면 이제 각각의 DB에 접속할 때 쓰는 계정 이름인 'devel', 'prsq'만 쳐도 곧바로 계정 비밀번호 입력창이 뜨게 되므로 저 긴 명령어를 일일이 치지 않아도 된다.

(대괄호 안에 계정 이름만 치면 인식을 못 한다. 그래서 앞에 client도 같이 쳐 줘야 한다.)

이후 키들에 대한 권한 정책을 수정해준다.

sudo chown -R gaebal:gaebal /etc/mysql/ssl/
sudo chmod 755 /etc/mysql/ssl/ 
sudo chmod 755 /etc/mysql/ssl/devel/ 
sudo chmod 755 /etc/mysql/ssl/prsq/

소유자를 해당 서버의 계정으로 바꿔주었으며, 디렉터리 권한을 위와 같이 설정하여 폴더 목록을 보는 것 자체는 가능하게 수정했다.

그 다음 각 키들에 대한 권한 정책은 아래와 같이 바꿔준다.

sudo chmod 600 /etc/mysql/ssl/devel/* 
sudo chmod 600 /etc/mysql/ssl/prsq/*
sudo chmod 600 /etc/mysql/ssl/ca-cert.pem

키들의 경우 소유자만 읽고 쓸 수 있게, 나머지 사용자들은 조회도 못 하게 바꿔주는 작업이다.

이후 DB에 접속하여 SSL 상태를 확인해보면 아래와 같이 적용이 되어 있는 것을 볼 수 있다.

실습해 본 쿼리 규칙들

이번 플젝 시간이 그리 길지 않아서, 많은 것들을 실습해보진 못했지만, 일단 크게 3가지의 규칙을 설정해 보았다.

(비인가 쿼리 막기, 개인정보 마스킹, 특정 IP만 DB에 접근 허용하기 등)

살짝 하드코딩 느낌이 없잖아 있긴 하지만, 일단은 경험을 해 봤다는 것에 의의를 두기로 했다.

먼저 미리 쓰고 가자면, 프록시SQL에서 쓰이는 포트 번호는 크게 두 개가 있다.

6032: 프록시SQL의 관리자 계정을 관리하기 위한 포트(공유기 게이트웨이 느낌)

6033: 클라이언트에 접속하기 위해 쓰이는 트래픽 송/수신용 포트

쿼리 규칙들을 추가할 땐 6032번 포트를 이용해 관리자 계정에 접속하여 추가할 예정이며, 이후 테스트용 PC에서의 접근 및 테스트는 6033번 포트를 이용해 이루어진다.

(위에서도 쓰였지만, 모든 규칙을 추가한 뒤엔 항상 load mysql query rules to runtime; 및 save mysql query rules to disk;를 치는 것을 잊지 말자.)

1. where 조건 없는 delete문, drop문, truncate문 등

(1) where 조건이 붙지 않은 delete문 차단하기

INSERT INTO mysql_query_rules (rule_id, active, username, match_pattern, error_msg, apply) 
VALUES (100, 1, '[db 계정 이름]', '(?i)^DELETE\s+FROM\s+[^\s]+$', '[경고 메시지 자유롭게]', 1);

위와 같이 쓰면 delete문으로 시작하는((?i): 대소문자 구분 무시) 쿼리문 가운데 테이블 이름 뒤에 아무 것도 오지 않는, 그러니까 where절이 쓰이지 않는 delete문을 잡아낸다는 뜻이다.

이후 해당 서버에서 쿼리를 입력해보면, 차단이 되는 것을 볼 수 있다.

(2) drop문 차단하기

기본 구조는 delete문과 비슷하다.

INSERT INTO mysql_query_rules (rule_id, active, username, match_pattern, error_msg, apply) 
VALUES (102, 1, '[DB 계정 이름]', '(?i)^DROP', '[경고 메시지 자유롭게', 1);

(3) truncate문 차단하기

drop 부분만 바꿔주면 된다.

INSERT INTO mysql_query_rules (rule_id, active, username, match_pattern, error_msg, apply) 
VALUES (104, 1, '[DB 계정 이름]', '(?i)^TRUNCATE', '[경고 메시지 자유롭게]', 1);

그 밖에 union select문((?i)^union\s+SELECT)이나 or 1=1.. 같은 SQL Injection문에 대한 차단 규칙들도 모두 적용시킬 수 있다. 물론 인젝션 구문 같은 건 앱 단계에서 막는 게 정석이고, 요즘 웬만해선 다 막혀있긴 하지만, 다층 방어 느낌으로 추가해둬서 나쁠 것은 없다고 생각한다.

2. 개인정보 마스킹

간단하게나마 테이블 안의 특정 정보를 비공개 처리하여 출력하는 마스킹 테스트를 해 보았다.

DB에서 직접 테이블을 들어간 뒤 내용을 조회해보면, 아래와 같이 닉네임이나 비밀번호 등이 모두 적나라하게 노출된다.

나중에 유지보수 등을 위해 개발 서버 등에서 DB에 접속할 때, 불필요한 정보 공개를 막기 위한 용도라는 느낌으로 특정 정보를 마스킹 해보면 어떨까 하는 느낌으로 아래와 같이 명령어를 작성해 봤다.

INSERT INTO mysql_query_rules (rule_id, active, username, match_pattern, replace_pattern, destination_hostgroup, apply, comment) 
VALUES (110, 1, 'devel', '(?i)^SELECT\s+\*\s+FROM\s+users', 'SELECT id, username, "****" AS password, mc_nickname, created_at FROM users', 2, 1, '[코멘트 자유롭게]');

비밀번호(password) 부분을 강제로 "****"로 바꿔 출력되도록 규칙문을 추가해 주었다.

실전에서는 이름의 경우 가운데 글자만, 주민번호는 8자리부터 그 뒤로만 마스킹을 하는 등으로 더 세세하게 마스킹을 하는 규칙 같은 게 정해져 있다고 한다. 물론 쿼리 규칙을 이용해 그런 것도 가능할 것이다.

이후 테스트용 개발pc에서 프록시 통해 해당 db 접속 및 테이블 내용을 확인하면..

잘 작동한다.

3. IP 바탕 화이트리스트로 내부 조회 및 수정 제한하기

각각의 DB 계정을 통해 접속하는 것은 모두 인가된 특정 서버에서만 접속할 수 있도록 하고, 그 밖의 IP에서 접속할 때 DB의 조회 및 수정 자체를 불가능하게 만들기 위한 쿼리 규칙이다.

먼저 혼동을 막기 위해 각 DB 계정이 어느 DB와 연결되어 있는지를 한 번 확인해 준다.

(prsq는 30.11 DB(계정DB), devel은 30.10 DB(웹DB)에 연결되어 있음)

우리가 진행한 플젝에선 2개의 DB가 있었고, 각각 접속할 수 있는 DB 계정이 나뉘어져 있다. 두 DB 모두 하나의 개발PC에서만 접속할 수 있도록 규칙을 생성할 예정이며, 그 밖의 PC에서 접속하면 조회/수정을 할 수 없도록 짜려고 한다.

아래와 같이 각 계정마다 조회 및 수정을 허용할 IP 규칙을 만든다.

INSERT INTO mysql_query_rules (rule_id, active, username, client_addr, match_pattern, destination_hostgroup, apply, comment) 
VALUES (200, 1, '[DB 계정 이름]', '[허용할 IP]', '.*', 2, 1, '[코멘트 자유롭게]');

(여기서 apply 값을 1로 지정해 줘야 규칙을 그냥 지나치지 않는다.)

이번엔 아래와 같이 그 밖의 모든 IP에서의 내부 조회 및 수정을 틀어막을 쿼리 규칙을 만든다.

INSERT INTO mysql_query_rules (rule_id, active, username, match_pattern, error_msg, apply) 
VALUES (298, 1, '[DB 계정 이름]', '.*', '[경고 메시지 자유롭게]', 1);

(주의할 점은, 화이트리스트의 규칙 번호가 차단 규칙 번호보다 낮아야 먼저 허용된 IP인지를 검사한 뒤 나머지를 거를 수 있다. 그 이유는 마지막에 설명)

이후 테스트용 비인가 서버를 하나 만든 뒤, 그 곳에서 DB 접속을 시도해 보면..

미리 생성한 규칙에 따라 조회 자체가 안 되는 것을 볼 수 있다. 물론 위에서 차단 규칙의 매치 패턴을 '.*'로 설정했으므로 조회, 수정은 물론 그냥 그 어떤 글자를 넣어도 저렇게 뜰 것이다.

4. 접속 및 쿼리 입력 로그 남기기

먼저 아래 명령어를 프록시SQL의 관리자 계정(6032)에서 추가해 커스텀 로깅 규칙을 활성화한다.

update mysql_query_rules SET log = 1;

그 뒤 일반적인 모든 쿼리 출력에 대한 로그도 남기기 위해 아래와 같이 명령어를 입력한다.

INSERT INTO mysql_query_rules (rule_id, active, username, match_pattern, log, apply, comment)
VALUES (999, 1, '.', '.*', 1, 0, 'Log All Queries');

(규칙 번호를 가장 낮게 설정해 주기)

위처럼 규칙을 지정하면 select는 use든 show든 모든 쿼리 입력에 대한 로그가 남게 된다.

다음 작성글에서 쓸 내용이지만, 위 로그들을 이제 스플렁크에 연동시켜 스플렁크에서 작업할 수 있도록 할 예정인데, ProxySQL의 로그 파일 형식은 바이너리이다보니, cat 명령어로 불러오면 글자가 모두 깨져서 나온다.

이를 해결하기 위해 아래와 같은 명령어를 입력해 파일 형식을 JSON으로 바꿔준다.

SET mysql-eventslog_format = 2;

로그를 기록할 파일 이름도 본인이 알아볼 수 있게끔 바꿔주자

SET mysql-eventslog_filename = '로그_파일_이름_대충_아무렇게나.log';

이제 로그가 저장되는 /var/lib/proxysql/ 경로에 들어가보면, 위처럼 이름을 지정한 로그 파일이 생기며, 테스트용 서버나 ProxySQL에서 쿼리를 날렸을 때 로그가 쌓이는 걸 볼 수 있다. (tail 명령어로 실시간으로 볼 수도 있고)

이런 식으로

플젝에서는 상관 없겠지만, 실전에선 아마 실시간으로 들어오는 로그의 양이 어마어마할텐데, 파일의 최대 용량 크기를 지정하여 유연하게 관리할 수도 있을 것 같다.

SET mysql-eventslog_filesize = 104857600;(100MB)

이런 식으로.

p.s.

아까 위에서 허용 IP 규칙을 차단 IP 규칙보다 낮은 규칙 번호로 지정하라고 했는데, 그 이유는 ProxySQL의 경우 방화벽 규칙과 비슷하게, 위의 규칙부터 먼저 순서대로 읽어 내려가는데 그 순서가 낮은 번호 => 높은 번호 순이기 때문이다. 차단 IP 규칙을 선순위로 지정해버리면 당연히 어떤 IP에서 접근하든 일단 틀어막아 버리기 때문에, 먼저 통과시킬 IP를 윗단계에서 지정해 준 뒤 나머지 IP들을 막아야 제대로 된 화이트리스트를 운영할 수 있을 것이다.

p.s.(2)

apply 값이 0이면 해당 규칙 매칭을 체크한 뒤 아래 규칙으로 넘어가는 것이고, 1이면 해당 규칙과 매칭되었을 때 더 이상의 규칙 검사를 멈추고 그 규칙에서 지정한 행동을 수행하도록 만드는 것이다.

ProxySQL 설치하기

ispini — Sat, 24 Jan 2026 05:35:12 +0900

우리 프로젝트에서는 개발/사무망의 각 PC에서 내부망의 DB 서버로 접속하려 할 때 중간에서 검사? 및 보안 기능을 수행하는 역할로 ProxySQL을 골랐다.

원래는 DB세이퍼? 라고 하는 좋은 솔루션이 있다고 하길래 찾아봤으나 매우 비싸며 기업 대상이라는 정보를 보고 단념한 뒤 대체용으로 해당 솔루션을 고르게 되었다.

ProxySQL이란?

MySQL 및 MySQL 바탕의 포크 데이터베이스(MariaDB) 등을 대상으로 호환되는 솔루션이며, 애플리케이션과 DB의 중간에 위치하는 중계기 역할을 맡는다.

DB에 연결되어 이용하는 서비스의 수가 늘어나면 복잡도가 늘어나고 관리하기도 힘들어지는데, 이를 해결하기 위해 ProxySQL을 사용한다고 한다. 쿼리 라우팅이나 로드 밸런싱, 헬스 체크 기능 등을 통해 효율적인 연결 및 고성능/고가용성 서비스를 보장해주는 것이 바로 ProxySQL이란 오픈소스 프록시 솔루션이다.

일단 우리가 조사하면서 알아본 정보 한에서 최대한 활용하기 위해 노력해 봤으나, 부족한 부분이 많을 수 밖에 없으므로 감안이 필요하다.

설치하기

우분투에서 진행하였다.

프록시를 운용할 서버를 하나 만든 뒤, 레포지토리 키를 추가하고 등록한다.

sudo apt install -y gnupg2 xmlstarlet
wget -O - 'https://repo.proxysql.com/ProxySQL/proxysql-2.6.x/repo_pub_key' | sudo apt-key add - 
echo "deb https://repo.proxysql.com/ProxySQL/proxysql-2.6.x/$(lsb_release -sc)/ ./" | sudo tee /etc/apt/sources.list.d/proxysql.list

이후 ProxySQL을 이용하기 위한 패키지를 설치한 뒤 실행해 준다.

sudo apt-get update 
sudo apt-get install proxysql 
sudo systemctl start proxysql 
sudo systemctl enable proxysql

SQL 관리 계정으로 접속한 뒤, 연결할 DB 정보를 넣는다.

이후 불러오기와 저장을 실행한다;.

mysql -u admin -padmin -h 127.0.0.1 -P 6032
insert into mysql_servers(hostgroup_id, hostname, port) VALUES (1, ‘DB_IP', 3306);
load mysql servers to runtime;
save mysql servers to disk;

각 개발/사무PC에서 DB에 접근할 때 쓸 사용자 계정을 만든다.

(values 뒤에 DB의 ID/PW를 넣는다)

insert into mysql_users(username, password, default_hostgroup) values ('user_이름', 'user_비밀번호', 1);

우리는 서비스의 방대성보다는 각각의 기능 구현에 중점을 뒀으므로 DB는 2개를 만들었다.

각 DB마다 접근할 수 있는 계정을 나누기 위해 2개를 만들었다.

(여기서 지정하는 호스트그룹 번호랑 proxy에서 지정하는 호스트그룹 번호는 같아야 함)

추가한 계정들의 설정은 반드시 불러오기 및 저장을 해 준다.

load mysql servers to runtime;
save mysql servers to disk;
load mysql servers to runtime;
save mysql servers to disk;

연결할 DB서버로 가서 똑같이 계정을 만들어 준다.

(프록시에서 만든 계정이랑 똑같이)

create user 'user_이름'@’WAN_IP' identified by 'user_비밀번호';

접근할 수 있는 데이터베이스 권한을 부여한다.

(일단 여기선 모든 DB 목록에 접근할 수 있도록 만듦)

grant all privileges on *.* to ‘user_이름’@‘WAN_IP’;
flush privileges;

기본 세팅하기

우리는 DB를 비롯한 내부망은 PFsense 아래, DB에 접속할 개발/사무PC들은 OPNsense 아래 물려있다. 두 UTM 사이를 왔다갔다 해야 하므로, 서로의 WAN IP를 게이트웨이로 추가하는 작업을 진행했다.

(1) PF에서

(2) OPN에서

이후 db에서 외부 접속을 허용해 주기 위해 db서버의 콘솔창에서 /etc/mysql/mariadb.conf/ 경로로 들어간 뒤, bind-address 값을 127.0.0.1 =>0.0.0.0으로 바꿔주었다.

각 방화벽에서 서로를 향한 규칙을 열어준다.

(1) PFsense에서

하위에 DB가 있으므로 WAN 룰에서 DB로 들어오는 방화벽 규칙을 설정
- 개발망 쪽에서 프록시에 접속할 땐 6033번 포트를 쓰지만, 프록시에서 db로 갈 땐 본래의 3306번 포트를 쓰므로 도착지 포트를 3306으로 지정해 준다.

(왜 WAN IP?: 각 방화벽이 서로의 WAN IP를 게이트웨이로 지정 + 서로의 방화벽으로 갈 때 NAT를 쓰게 되어있기 때문에 ProxySQL IP에서 출발해 OPN을 빠져나가도 PF쪽에선 그 프록시가 속해 있는 WAN IP가 출발지로 찍히므로 OPN의 WAN IP만 인식하게 됨.

그 때문에 DB 쪽이나 PF 쪽에서 개발/사무망 쪽 계정 생성 및 권한 부여를 할 때 IP를 ProxySQL로 잡으면 인식을 못 함)

DB 쪽 룰에서도 프록시 방향으로 룰을 열어준다.

(2) OPNsense에서

하위에서 Proxysql이 개발pc에서 요청하는 db 접근 및 수정 요청을 대신 받을 것이므로 개발망 vlan에서 db로 향하는 규칙을 열어준다.

관리자 계정인 6032 포트는 프록시서버에서만 접속할 수 있도록 제한했다.

서로를 실제로 인식하는지 확인하기 위해 proxysql에서 ping과 nc 테스트 진행해 봤다.
(ping 192.168.30.xx<DB IP 대역> / nc -zv 192.168.30.xx 3306)
(주의: 이 땐 DB서버에서 쓰는 포트를 통해 테스트하기 때문에 pf에서 룰의 포트를 잠깐 모두 열어줘야 함, 테스트가 잘 끝나면 다시 6033만 열어두기

이번엔 DB 쪽에서 ProxySQL과의 계정 연동이 잘 되어있는지 확인했다.

(아까 위에서 등록한 계정 및 WAN IP가 잘 적혀있는지 확인하기)

이번엔 다시 Proxy 쪽에서 각 db와 연결된 프록시들의 상태를 확인한다.
상태 확인 쿼리

select hostgroup_id, hostname, status from runtime_mysql_servers;

(만약 ONLINE이 아닌 SHUNNED 등으로 떠 있다면 아래 사진처럼 load mysql servers to runtime; / save mysql servers to disk; 를 순서대로 친 뒤 다시 확인하기)

이제 테스트용 개발pc에 접속하여, 프록시를 통해서 db에 접속이 되는지 확인해 본다.
mysql -u (접속할 계정 이름) -p -h 192.168.120.10 -P 6033
(proxysql의 IP를 거쳐가야 하므로 프록시 서버의 IP를 입력, 포트는 프록시 포트인 6033)

proxysql 서버에서도 접속할 수 있다.
자신의 ip를 통해서 db에 접근하므로 명령어는 아래와 같이 치기(ip를 루프백으로)
mysql -u (접속할 계정 이름) -p -h 127.0.0.1 -P 6033

모니터링

각 DB들의 서비스 정상 가동 여부 등을 확인하는 모니터링 계정도 만들어 주자.

먼저 각 DB에서 아래와 같이 쿼리를 입력해 DB를 헬스체크할 모니터링 계정을 만든다.

# 권한을 최소화하기 위해 usage, repliccation client 쿼리문을 이용함
create user '모니터링 계정 이름'@'프록시SQL의 IP' identified by '모니터링 계정 비밀번호';
grant usage, replication client on *.* TO '모니터링 계정 이름'@'프록시SQL의 IP';
flush privileges;

(usage: 로그인만 가능하며, 데이터에 대한 조회 및 수정 권한은 없음)

(replication client: 백엔드 DB가 Master인지 Slave인지, 정상 가동 중인지, 로그 상태가 어떤지 등을 모니터링만 하는 권한)

그런 다음 이번엔 프록시 서버의 관리자 계정(6032번 포트)에 접속하여 아래와 같이 입력해 모니터링 계정을 인식시킨다.

SET mysql-monitor_username='모니터링 계정 이름';
SET mysql-monitor_password='모니터링 계정 비밀번호';

언제나 그렇듯이 설정을 해 준 다음엔 서버에 적용과 저장하는 것을 잊지 말자.

LOAD MYSQL VARIABLES TO RUNTIME;
SAVE MYSQL VARIABLES TO DISK;

실전에선 매우 빠른 주기로 DB의 헬스체크를 한다고 하지만, 우리는 서버 자원의 한계에 따른 UTM 부하 고려, 직접 눈으로 천천히 보며 모니터링 여부를 체크해보고 싶어 헬스체크 주기를 10초(10000ms)로 설정하였다.

# 백엔드 DB의 헬스체크 주기를 10000(10초)로 설정하기
UPDATE global_variables SET variable_value='10000' WHERE variable_name='mysql-monitor_ping_interval';

그런 다음 모니터링 주기가 잘 설정되었는지 확인한다.

# 헬스체크 주기 설정 상태 살펴보기
SELECT * FROM global_variables WHERE variable_name='mysql-monitor_ping_interval';

이제 두 가지 쿼리문을 이용해 각각 DB로 접속이 잘 되는지, DB와 통신이 잘 되는지를 체크해보면 된다.

# DB로의 접속 테스트 현황 살펴보기
# 최근 10번 동안의 접속 헬스체크 결과 확인
select * from monitor.mysql_server_connect_log order by time_start_us desc limit 10;

# DB와의 통신 테스트 현황 살펴보기
# 최근 10번 동안의 통신 헬스체크 결과 확인
select * from monitor.mysql_server_ping_log order by time_start_us desc limit 10;

만약 연결이나 핑이 잘 이뤄지지 않는다면, 아래와 같이 쿼리문을 입력하여 통신 에러 기록을 확인해 볼 수 있다.

# 연결 실패 기록
SELECT hostname, port, connect_error, time_start_us 
FROM monitor.mysql_server_connect_log 
WHERE connect_error IS NOT NULL 
ORDER BY time_start_us DESC;

# 통신 실패 기록
SELECT hostname, port, ping_error, time_start_us 
FROM monitor.mysql_server_ping_log 
WHERE ping_error IS NOT NULL 
ORDER BY time_start_us DESC;

예시

딱히 연결 과정에서 문제가 생기지 않아서 지금은 기록이 비어 있다.

만약 각 모니터링 기록을 관리하는 테이블의 컬럼명을 모르겠다면 아래와 같이 입력하여 어떻게 지정되어 있는지 확인하면 된다.

# 서버 연결 로그 테이블 안의 컬럼들 확인하기
show create table monitor.mysql_server_connect_log;

# 서버 핑 로그 테이블 안의 컬럼들 확인하기
show create table monitor.mysql_server_ping_log;

ProxySQL과 연결된 UTM에서도 모니터링 통신 현황을 확인해 볼 수 있다.

트러블

(1)

프록시나 개발pc에서 db로 접속할 때 접속만 되고 조회가 안 되는 경우가 있었다.(timeout이 뜬다든지)

이럴 땐 유저의 호스트그룹 번호와 서버의 호스트그룹 번호가 맞게 짝지어져 있는지 확인해 본다.
(프록시 서버의 관리자 계정<6032>에서 확인할 수 있음)

select username, default_hostgroup from mysql_users;
select hostgroup_id, hostname, status from mysql_servers;

예를 들어 prsq는 현재 192.168.30.10 db 서버와 같은 1번으로 묶여 있음, 그런데 저 번호가 서로 다르게 부여되어 있으면 db의 내용을 조회할 수가 없게 되는 것이다.

본인의 경우 prsq 계정의 호스트그룹 번호가 뜬금 없이 10번으로 지정되어 있는 바람에 db의 내용을 전혀 조회할 수가 없었음.

이를 해결하기 위해 아래와 같이 호스트그룹을 재지정 해주면 된다.

set mysql_users set default_hostgroup=1 WHERE username='prsq';

(2)

각 방화벽에 서로의 ip를 게이트웨이로 지정한 뒤에도 프록시가 db의 내용을 불러오지 못하는 경우

위를 통해 호스트그룹의 미스 매칭을 해결한 뒤에도 계속해서 DB의 내용을 불러오지 못 했다.

이를 해결하기 위해 각 방화벽에서 정적 라우팅을 지정해 주었더니 해결 되었다.

(예를 들어 아래와 같이 OPM에서 DB 서버로 가는 네트워크 대역에 DB 서버가 거쳐가는 PF의 게이트웨이를 붙여주면 정상적으로 통신이 이루어짐)

OPNsense 설치 및 VLAN 구성하기

ispini — Sat, 24 Jan 2026 04:46:50 +0900

ESXI 안에 OPNsense를 설치하면, 아래와 같은 창이 뜬다.

처음엔 설치를 해야 하므로, ID는 installer / PW는 opnsense로 입력한다.

이후 엔터를 치면 다음 화면이 나오는데, zfs 고르고

RAID 따로 안 쓸 거니 Stripe 선택,

스페이스바 누른 뒤 엔터,

이후 yes를 누른 뒤 기다리다보면 설치가 완료된다.

그런 다음 리부팅한 뒤

ID: root / PW: opnsense를 입력하면, 아래처럼 화면이 뜬다.

WAN 쪽이 아무리 DHCP를 잡아봐도 IP가 안 잡히고, 정적으로 잡아봐도 LAN 서버에서 안 붙길래,

뭔가 하고 한참을 찾아봤는데, 알고 보니 LAN과 WAN이 서로 반대로 잡혀 있었다.

WAN이 em0 어댑터로 잡혀야 하는데 LAN 대역인 em1로 잡혀버리니 안 됐던 것.

아래처럼 WAN 어댑터를 맞게 지정하는 작업을 지정해준다. (1번의 Assign interfaces에서 작업)

그럼 이제 아래처럼 어댑터가 서로 바껴 있는 것을 볼 수 있다.

이제 따로 설치한 LAN 접속용 우분투 서버에서 위의 LAN 게이트웨이 주소를 치면

OPNsense에 들어갈 수 있다.

비번은 위랑 똑같다.

처음 들어가면 초기 세팅창들이 뜨는데, 일단 설정된 대로 넘어가면 된다.

세팅을 마친 뒤, 왼쪽의 메뉴창에서 Firewall => Rules로 들어가 wan 대역에서도 접속할 수 있도록(내 로컬pc에서도 opnsense 관리 페이지에 접속할 수 있도록) 만들어 준다.

일단 처음엔 any로 전체를 열어주자.

아래 사진처럼 규칙이 추가되어야 한다. 규칙을 추가했으면 오른쪽 위의 Apply changes 버튼은 꼭 눌러주자.

이렇게 추가한 뒤 위에서 지정한 WAN 어댑터의 IP를 입력하면 이제 로컬PC에서도 접속할 수 있다.

VLAN 설정하기

VLAN을 OPNsense에서 추가하려면, 먼저 ESXI에서 각 스위치마다 용도별로 쓸 VLAN 포트 그룹들을 추가해줘야 한다.

이런 식으로.

그런 뒤 먼저 PF나 OPN 등 UTM의 OS 설정 편집 메뉴에 들어가서 VLAN이 쓰이는 LAN 어댑터들을 추가해 준다.

그런 다음 각 서버마다 용도별로 추가한 VLAN들을 추가해 준다.

이제 OPN의 콘솔창에 들어가보면, 아래처럼 기존의 LAN 뿐만 아니라 그 각각 LAN 아래의 VLAN들도 추가가 되어 있다.

이제 OPN 웹페이지로 들어가서, 왼쪽 메뉴의 Interfaces => Devices => VLAN 순으로 접속한다.

그 다음 + 버튼을 눌러서 LAN 대역 안에 아까 만든 VLAN 대역들에 맞게 만들어 준다.

이유는 모르겠으나, Device 안에 'vlan.0.x---' 이런 식으로 저장해야만 한다. 많이 쪼개 쓰라고 그러는 건가?

아무튼 앞의 0.x는 같은 LAN 대역을 묶는 용도로, 뒤의 120 등은 각 VLAN ID를 가리키는 용도로 쓴다. Parent에 VLAN으로 나눠 관리할 LAN 어댑터를 고른 뒤, 설명은 알아서 알아볼 수 있게 쓴 다음 저장한다.

이후 Interfaces ⇒ Assignments로 들어간 뒤, 아래와 같이 추가한 vlan 구역들을 인터페이스에 추가한다.

그런 다음 Interfaces의 각 vlan 메뉴에서 IPv4를 정적(Static)으로 주겠다고 선택한 뒤, IP 대역을 충돌만 안 나게 알아서 지정한다.

VLAN의 부모 어댑터인 각 LAN 어댑터에서 VLAN들을 알아먹어야 하므로 ESXI에서 VLAN ID를 4095로 바꾼다.

이후 각 서버에서 그 VLAN 구역에 맞게 IP를 할당해준 뒤, apt update 등이 잘 되면 성공한 것.

수정 필요) 써 놓고 나중에 확인해 보니 순서가 바꼈다. OPN에서 먼저 작업을 한 뒤에 나중에 ESXI에서 VLAN 어댑터 만들기 등 작업이 이뤄져야 했는데 횡설수설했다.

나중에 수정 예정

SWIMMER OSINT CTF(by DIVER OSINT CTF) Write-up

ispini — Wed, 21 Jan 2026 05:14:18 +0900

팀 이름이 한글이라 그런지 안 보인다..

2026년 1월 17일 12:10부터 18일 00:10(일본시각 기준)까지 개최된 주니어 대상 Swimmer OSINT CTF에 참가하였다.

본인은 '너의집주소는' 이란 팀에 'Ispini'로 참가하여 팀원들과 함께 OSINT 문제들을 풀었다.

본인이 맡았던 주 파트는 tgt_rain이었으며, 그 밖에도 tgt_debeyohiru의 hidden2나 meal 등을 같이 풀었고, ops_swimmer 문제는 아쉽게 정답을 맞추진 못했지만 정답에 거의 근접하는 등 많은 성과를 얻어내는 데 성공하였다.

지금부터 아래에 이번 OSINT의 라이트업을 쓰려 한다.

Our Team: 너의집주소는(Your Address)

Points: 3514

Rank: 95/687

Challenges the team solved: 37/38

tools: Google Image Search, Google Maps, Jimpl, OpenStreetMap, Wikimedia, Japanese National Diet Library Ditigal Collection(国立国会図書館デジタルコレクション), SNS(X/Bluesky), Archive.Today

tgt_rain

1. rain_01_social

문제)

rain은 2026년 시점에서 X(옛 트위터)의 계정을 소지한 것으로 보입니다.

우리는 이 인물의 투고 스크린샷을 입수하였습니다.

스크린샷에서 계정을 특정해, 이 계정의 ID를 알아내 답하십시오.

예를 들어, @gov_online이 대상의 계정인 경우, Flag는 Swimmer{@gov_online}입니다.

라고 한다.

같이 첨부된 스크린샷은 아래와 같다.

여기서 얻을 수 있는 힌트는, Rail Magazine (レイル・マガジン)이다.

저 계정으로 들어가서 12월 1일날 작성한 게시글을 찾으면,

저렇게 리트윗을 한 사람을 보여주는(引用を表示) 기능이 있는데 저걸 누르면,

저렇게 brutorain(@bruto_rain)이란 사람이 리트윗을 했다는 것을 알 수 있다.

2. rain_02_region

문제)

rain은 자신의 블로그에 취미 투고를 하는 것으로 보입니다. 투고에 쓰이는 사진 대부분이 이 인물이 촬영한 것이 아닌 가짜로 보이지만, 1장만이, 실제로 이 인물이 촬영했다고 생각되는 사진이 존재합니다. 그 사진을 특정하여, 촬영지를 지도 위에서 찾아 답하시오.

먼저 방금 알아낸 해당 유저의 투고글을 확인해 블로그를 들어가보면..

이렇게 뭔가 많이 쓰셨다.

글 내용들은 대부분이 일본의 다른 지방으로 원정을 떠나 열차 사진을 찍었다는 것인데,

사진들을 자세히 보면 AI를 돌린 것이 티가 난다.

예를 들어..

도호쿠 지방으로 원정(東北遠征)을 갔다는 게시글을 들어가 사진들을 한 번 보면..

오른쪽의 역명 표지판을 보면, 이상한 점이 여럿 있다.

먼저 해당 역은 코고타역(小牛田駅)의 사진인 거 같은데, 일단 한자랑 로마자 표기는 잘 되어 있다.

그런데 빨간 동그라미를 보면, 미야기(宮城) 어쩌고 역이라고 써져 있다.

내가 알고 있는 게 맞다면, 저 위치엔 보통 히라가나로 한자를 읽는 법이 써져 있는데, 한자가 써져있을 뿐더러 한자의 모양도 좀 뭉개져 있다.

또한 그 아래의 西口(서구)란 한자 밑에, 정확히는 안 보이지만 Matoda? Matoka? 라고 써져 있는 거 같은데,

이전에 일본어를 조금 배워서 기초적인 한자들의 독음법은 얼추 알고 있다. 저걸 Matoda 따위로 읽는 건 본 적이 없다. 보통은 Nishiguchi(니시구치)라고 읽을텐데..

그래서 위 사진은 AI가 만든 사진이겠거니 하고 넘겼다.

다른 지방 원정 사진도 마찬가지다.

간사이원정(関西遠征) 글에 나와있는 사진 중 아래 사진 역시 글씨들이 이상하다. 산노미야역이라는데, 역(駅) 글자가 좀 이상할 뿐더러, 왼쪽 동그라미는 아예 글자도 아니고 점으로 도배되어 있다.

이런 식으로 내 나름의 AI 사진 구분을 진행하였다.

그러다가 딱 한 장, 매우 유력해 보이는 사진을 발견했다. 같은 간사이원정 게시글의 사진이다.

우선 글씨가 뭉개지는 게 없다. 오른쪽 위의 비상통보 버튼(非常通報ボタン)이라든지, 왼쪽 광고판의 글자나 숫자가 뭉개지지 않고 또렷이 보인다. 그래서 이 사진은 실제로 찍은 사진일 것이란 강한 의구심과 함께 조사를 시작했다.

(1) 먼저 해당 철도는 케이한(京阪) 전기철도에서 운영한다고 한다. 사진 이름에도 나와 있다.

또한 케이한의 10000번대 열차는 검색 결과 가타노선에서 운영되고 있다고 한다.

(2) 왼쪽의 광고판에 나와 있는 상호명을 구글에서 검색해본다. 먼저 お家困ったさくらに電話 저걸 먼저 그대로 검색해 본다.

주택 리모델링 하는 업체인가 보다. 아무튼 검색을 해보면 주식회사 사쿠라(株式会社さくら)라는 업체의 위치가 나온다. 전화번호도 광고판이랑 똑같이 나오는 걸 보니 맞는 것 같다.

가타노시(交野市)의 호시다(星田)란 곳에 있다고 한다.

이번엔 그 옆의 제니야치과의원(銭谷歯科医院)을 검색한다.

오호.. 바로 나온다. 히라카타시(枚方市)의 인다초(印田町)란 동네에 있다는데, 그 바로 위에

무라노역(村野駅)이라고 나온다. 그래서 지도에서 무라노역을 찍었는데..

틀렸다고 한다.

뭐지? 싶어서 구글지도에서 무라노역 사진을 확인해보니..

뭔가 확실히.. 위 사진보다 플랫폼이 좀 짧긴 하다.

그래서 다시 찾아보기로 했다. 일단 무라노역 바로 다음역이 호시가오카역(星ヶ丘駅)이란 곳인데, 같은 히라카타시에 있으므로 한 번 둘러보기로 했다.

느낌이 온다. 위의 사진과 구조물의 위치가 같고, 잘려서 보이진 않지만 정황상 클리닉(クリニック)이라 써져 있을 것으로 보이는 간판 위치도 똑같다. 비상통보 버튼 표지판도 똑같다.

그리하여 호시가오카 역을 찍었더니, 맞았다.

3. rain_03_source1

상당히 애를 먹었던 문제이다. 거의 막바지에 이르러서야 풀었다.

문제)

rain은, 눈길을 끄는 타이틀 기사를 쓰면 열람수가 많아질 것이라 생각한 거 같습니다.

이 인물은 이를 계기로 가짜 정보 작성 및 유포에 푹 빠져버린 것으로 보입니다.

이 인물이 가장 먼저 투고한 가짜 기사에선, 어떤 사진과 전혀 관련 없는 캡션(사진 정보)이 쓰여져 있습니다. 원래의 출처를 찾아, 이 사진이 어디 시구정촌(한국의 시군구)과 관련된 자료에 게재된 것인지를 찾아 답하시오.

예를 들어, 히라츠카시(平塚市)의 자료에 게재된 경우, Flag는 SWIMMER{平塚市}입니다.

먼저 해당 기사를 들어가보면, 아래처럼 나와있다.

위 사진을 다운받아 구글 이미지 검색 등을 해봤으나, 제대로 된 정보가 나오지 않았다.

그래서 사실 이 문제는 좀 미뤄두고 있었는데, 후반부 공지에 힌트가 올라왔다.

바로 고문서들을 모아놓는 데이터베이스 사이트를 뒤져보라는 것이었다.

그래서 찾아보던 도중, 일본의 국립국회도서관 디지털 컬렉션(国立国会図書館デジタルコレクション)이라는 일본의

국가문서 DB? 사이트를 찾게 되었다. 같은 팀원이 찾아내었다.(감사합니다..)

어찌저찌하여 위 사진을 검색해 본 결과...

원본 사진이 그대로 나와있다. 그리고 오른쪽 위 도시 이름을 보니, 도요하시시(豊橋市)라고 나와있다.

답은 도요하시시였다.

4. rain_04_source2

오히려 source1보단 쉬웠다.

문제)

rain이 2번쨰로 작성한 가짜 기사에선 'rain이 미공개 정보를 찾아냈다'라고 써져 있다고 합니다. 그러나, 이것은 허위로 보입니다.

이 인물의 거짓을 들춰내기 위해선, 정확한 출처를 찾을 필요가 있습니다.

이 사진의 출처가 되는 오래된 서적은 전자화되어 있어, 상세히 참조할 수 있을 것입니다.

그 자료의 디지털 오브젝트 식별자(DOI)를 찾아 답하십시오.

예를 들어, 답이 12.34567/890123인 경우, Flag는 SWIMMER{12.34567/890123}입니다.

마찬가지로 해당 게시글을 들어가본다.

이번에도 구글에서 이미지 검색을 해 보면...

source1과는 다르게, 꽤나 정보들이 뜨는데, 위키미디어에 해당 사진의 정보가 자세하게 나와 있다.

(https://commons.wikimedia.org/wiki/File:National_Diet_Building_Competition_Submission_Watanabe_Fukuzo.jpg)

스크롤을 아래로 내리다 보면, 출처 소스가 나오는데, 일본의 서적 관련 사이트로 보인다.

들어가 보면, 아까랑 마찬가지로 국립국회도서관 사이트가 나온다.

여기서 스크롤을 내려보면..

바로 식별자 번호가 뜬다. 저게 정답이다.

5. rain_05_date

문제)

rain은 2025년 12월 25일(일본 표준시), 어떤 장소에 간 것을 X에 투고했습니다.

그러나, 그 사진은 2025년의 다른 날에 촬영한 사진으로, 사실과는 다른 것으로 보입니다. 이 사진이 정말로 촬영된 날을 YYYY/MM/DD 형식으로 답하시오.

다만, 촬영일은 일본시간(JST)을 기준으로 합니다. 예를 들어, 답이 2025년 6월 8일인 경우, Flag는 SWIMMER{2025/06/08}입니다.

해당 투고글에 올라간 사진이다.

해당 사진만 뽑아서 다시 올려보면 아래와 같다.

건물 윗 부분을 보니, OSAKA-JO HALL(大阪城ホール)이라 써져 있다. 오사카성 홀이라고 한다.

일단 사람들이 옷을 두껍게 차려입고 있고, 나무 잎도 많이 떨어져 있다.

같은 겨울은 맞는 거 같은데, 풍경만으로는 정확한 날짜를 알 수 없을 것 같다.

첫 번째로 확대해서 찾아본 정보는 아래 사진인데, 솔직히 알아볼 수가 없었다.

그래서 다른 부분을 찾아보다, 그나마 알아볼 수 있는 부분이 아래와 같았다.

10000 어쩌고 써져 있는데, 일단 저거 밖에 못 알아보겠다.
(아래엔 그냥 초대, 보도접수<남쪽 사무소 입구>라고 써져 있다.)

일단 검색해 보니, 오사카홀이 우리나라의 KBS홀처럼 여러 공연들이 열린다는 것 같다.

그래서 구글링을 통해 2025년 오사카홀에서 열린 공연 목록들을 찾아보았다.

그렇게 찾아보던 중, 12월 공연 목록에서 아래와 같은 정보를 찾았다.

산토리 1만인 제구(サントリー１万人第九)라고 써져 있는데, 무슨 공연인지는 모르겠고

아무튼 1만이라 써져 있으니, 해당 날짜를 넣어봤는데, 맞았다.

12월 7일이었다.

6. rain_06_ai

아.. 이 문제.. 쉽지 않았다. 얘도 거의 막바지에 풀었다.

문제)

rain의 블로그엔, 도쿄역의 사진이 있습니다. 그러나, 이 것은 실제로 촬영한 것이 아닌, AI로 작성된 사진으로 보입니다.

이 사진이 어떤 툴로 작성된 것인지 특정하여, 답을 찾아 쓰십시오.

예를 들어, 답이 Adobe Firefly인 경우, Flag는 SWIMMER{Adobe Firefly}입니다.

마찬가지로 블로그에서 최신 글을 찾아 들어가본다.

해당 사진이다. 솔직히 처음엔 AI 사진인줄도 몰랐다. 기술의 발전이 새삼 놀랍다.

아무튼, 사진을 다시 자세히 보니, 가장 앞쪽에 있는 사람의 손가락이 6개로 보인다. AI가 맞았다.

이제 어떤 AI로 만들어졌는지를 알아야 하는데, 솔직히 감이 안 잡혔다.

EXIF(메타데이터)를 볼 수 있는 사이트에서 사진을 돌려봐도, 딱히 이렇다 할 정보가 나오질 않았다.

대중적인 AI 이름들은 다 넣어봤는데, 다 틀렸다. 괜히 난이도 HARD가 아니다.

사진의 확장자가 webp로 되어있었는데, 저러면 메타데이터가 제대로 안 나온다는 것 같다.

지푸라기라도 잡는 심정으로, 해당 게시글에서 Ctrl + U를 눌러 페이지의 상세 내용을 확인해 봤다.

여기서도 딱히 이렇다 할 정보가 안 나와서 실망하다가.. 혹시 몰라 사진 이름을 검색해보니,

사진처럼 나왔다. 어쩌면 jpeg로 다운받을 수도 있을 것 같다.

tokyo_0003을 검색한 뒤 몇 번 뒤적여보니, 아래 사진처럼 해당 파일에 들어갈 수 있는 src 링크가 있다.

들어가면 주소창에 다음과 같이 뜨는데, 사진을 보기 위해 view source를 지워준다.

지우고 사진을 출력한 뒤, 다시 다운을 받으려 했는데 여전히 webp로 뜬다.

이유를 생각해보다, 혹시 저 뒤에 w=1024의 w 때문에 webp로 출력되는 건가? 라는 무식한 생각이 들어 물음표부터 뒤쪽을 지운 뒤 출력해보니, 사진이 확실히 전보다 선명하게 나온다.

처음엔 사진 아래의 Jetpack을 쳐봤는데, 아니라고 해서 혹시나 싶어 한 번 더 EXIF Viewer 사이트에서 돌려봤다. 그랬더니..

그렇다. dreamina라는 AI로 만든 사진이었던 것이다.

개인적으로는 뒤에 쓸 더러운 오므라이스 문제보다 더 어려웠던 것 같다.

tgt_debeyohiru

7. debeyohiru_06_hidden2

먼저, tgt_debeyohiru 파트의 경우 나는 중간에 끼어들었다 보니 초반 부분의 정보를 팀원으로부터 제공 받고서 시작했다. debeyohiru가 예전에 쓰던 ID 이름이 후라이고(ふらいご)라든지, 블루스카이/Note/개인 프로필 사이트를 운용하고 있다든지...

아무튼 문제는 아래와 같다.

문제)

debeyohiru가 2025년 12월 시점에서 사용했다고 생각되는 스마트폰 기종을 알고 싶습니다.

덧붙여, 복수(여럿)의 단말을 사용했다고 생각되는 경우엔, 밑줄(_)로 이어서 전체(기종)의 답을 찾아 쓰십시오.

이런 경우, 정답순서는 묻지 않습니다.

또한, 제조사 이름은 불필요합니다.

예를 들어, Xperis 10 VII과 iPhone 17을 사용한 경우, Flag는 SWIMMER{Xperia 10 VII_iPhone 17}입니다.

먼저 debeyohiru의 개인 프로필 홈페이지에 들어가보면, 사용 기종이 다음과 같다고 뜬다.

스마트폰: Xiaomi 15 Ultra / iPhone 13 mini

그러나, 위 답을 입력하면 틀렸다고 뜬다. 저 폰을 쓰기 이전의 폰으로 찍은 듯 하다.

debeyohiru의 블루스카이 투고글들을 보다 보면, 본인이 찍은 것으로 보이는 사진들이 나온다.

이런 사진이라든지..

근데 EXIF 뷰어 사이트에서 돌려보면, 모토로라 라고 뜬다.

문제는 다른 사진들도 죄다 모토로라 라고만 뜬다.

이런 식으로.(당연히 모토로라 넣으면 틀렸다고 뜬다.)

그래서 이 부분도 한참을 찾다가, 리타이어 직전에 주최 측에서 올린 최종 힌트를 보았다.

힌트) archive.today에, 무언가 남아있을지도 모릅니다.

아.. 아카이브 사이트에서 찾아야 하는 거였구나.

정황상 프로필 페이지에서 예전에 쓰던 기종을 찾아야 하는 것 같았다.

바로 archive.today에 들어가 해당 프로필 페이지의 URL를 넣어 검색해본다.

1월 2일 스냅샷이 남아있었다. 들어가서 확인해 보면..

그렇다고 한다. Pixel 8 Pro랑 iPhone 13 mini가 정답이었다.

솔직히 이건 저 최종 힌트(archive.today 살펴보기)가 없었으면 끝까지 못 풀었을 것 같다.

전혀 생각을 못 했기 때문에..

8. debeyohiru_04_meal

오므라이스.. 너무 힘들었다.

문제)

debeyohiru는 어떤 요리를 좋아하여, 자주 먹는다고 합니다. 최근에 2026년 1월 10일 저녁밥으로 그 요리를 먹은 것이 확인됩니다. 이 인물이 그 날 저녁으로 먹은 메뉴를 특정하여, 점포의 매뉴에 기재된 이름으로 답을 찾아 쓰십시오.

예를 들어, 맥도날드에서 빅맥을 먹은 것이 특정된 경우, Flag는 SWIMMER{ビックマック}입니다. 메뉴 이름의 표기는 점포 메뉴의 일본어 표기를 준수해 주십시오.

SNS의 투고글들을 확인해 보면, 최근에 먹은 요리는 오므라이스였다. 1월 10일에도 먹은 것을 볼 수 있다.

일단 그릇에 POMME's라고 써져 있어서 검색해 보니, 일본의 오므라이스 프랜차이즈인 것 같다.

메뉴를 찾아보니, 똑 닮은 걸 하나 발견했다.

특제 데미소스 더블치즈(特製デミソースのダブルチーズ) 오므라이스

바로 입력해 봤다.

근데 틀렸단다.

기본? 오므라이스(定番オムライス)가 그나마 비슷해 보여서 입력해 봤는데.. 얘도 아니랜다.

우리 팀원 모두 혼란에 빠졌다. 그럼 대체 뭐란 말이지?

이후 주최 측에서 힌트가 하나 날아왔는데, 데미소스는 아니라고 한다.

이후 구글 맵에서 리뷰를 확인해 보라는 최종 힌트가 날아왔고, 우린 바로 확인 절차에 들어갔다.

우선 debeyohiru의 프로필 페이지에 시부야(渋谷)가 거주지라고 나와 있었으므로, 시부야의 Pomme 가게를 찾아본다.

검색해 보니, 시부야 스페인 어쩌고 가게가 하나 있었다. 해당 가게의 리뷰를 살펴보다 보니..

후라이고가 남긴 리뷰를 찾을 수 있었다.

번역) 1월 10일: 겨울 한정 메뉴를 먹었습니다. 집에선 이렇게 오므라이스를 잘 만들지 못 해서, 언제나 감사하고 있습니다. 오늘도 맛있었습니다.

겨울 한정 메뉴라고 한다.. 나와 팀원들이 눈에 불을 켜고 겨울 한정 메뉴란 키워드로 찾기 시작했다.

그러다가 굉장히 비슷해 보이는 겨울한정 메뉴 하나를 발견할 수 있었다.

돼지고기와 사과(가 들어간) 가리비 토마토 크림 오므라이스(豚肉とリンゴのホタテトマトクリームオムライス)란 이름을 가진 메뉴였다. 길기도 하다.

위 메뉴 이름을 넣어서 입력했더니, 정답이었다.

ops_swimmer

9. ops_swimmer

결과 먼저 쓰자면, 풀진 못했다. 정확히는 정답의 문턱에서 좌절하고 말았다.

대회가 끝나기 한 1시간 반? 이 되어서야 해당 문제가 새로 추가되었다는 것을 알았다.

2025년 어느 날, rain, debeyohiru, lilica가 처음으로 3명이서 모였답니다. 이 날 이후, 이 집단은 활동을 서서히 활발하게 하였습니다.

그게 언제, 어디에서였나요?

(중략)

3명의 정보를 모두 수집해야 할 것 같다.

먼저 rain의 X를 확인해 보았다.

이런 게시글이 있었다. 16:54로 시각이 써져 있다. 정황상 rain이 두 명을 마중 나가기 위해 표를 끊은 것 같다.

다음은 lilica의 x 게시글을 찾아봤다. 아래와 같은 사진을 확인했다.

컵을 보니 Denny's라고 적혀있다.

그렇다면 rain의 사진에 나와있는 오이마치(大井町)에 있는 Denny's란 이름의 식당에서 만났다는 것까진 알 수가 있다.

실제로 오이마치역 근처에 Denny's란 식당이 있다.

근데 문제는 시간이다. 표에 있는 시각도 적어보고, lilica의 게시글 중에 코미케 참가 관련 게시들도 있어서, 저 날(12월 30일)의 코미케 영업부스 운영시각인 5시도 적어봤는데, 다 틀렸다. 마지막엔 시간이 다 돼서 결국 6시 정각으로 찍어봤으나.. 역시 실패했다.

추후 다른 사람들의 라이트업을 보니, debeyohiru가 공개한 이메일을 이용해 debe의 구글 캘린더에서 만남 일정을 확인할 수 있다고 한다. 시각을 보니 18시 30분이었다고 한다.. 혼자 아무 글도 안 올리더만.. 괜히 HARD가 아니었다.

결국 해당 문제는 마지막에 시각을 알아내지 못해 안타깝게 풀지 못했으나, 팀원들 모두가 고생이 많았다.

후기

최종적으로 우리 팀은 95등을 기록했다. 본인은 'Ispini'란 이름으로 참가했다.

사실 완전히 처음 참가하는 CTF는 아니다. 이전에 NullCTF 2025란 이름의 종합형 주니어 CTF 대회에도 '치즈도적단' 팀원으로서 참가하였고, 거기서 'What Does The Fox Say?' 란 이름의 문제를 풀었으며 OSINT쪽 문제도 몇 개를 알아내기도 했으나, 내가 대회에 정식으로 참가하기 이전에 풀었다보니 얻어낸 플래그를 다른 팀원에게 전달하는 방식으로 간접 참가했고, 나는 내 부족한 실력 때문에 폐가 될 거 같아 참가를 미루다가 대회가 끝나기 직전 막바지에야 계정을 만들어 정식 참가를 했기에 최종적으로 나는 0점이었다. 게다가 라이트업을 쓰는 걸 미루고 미루다가 사이트가 닫혀버리는 바람에, 여우 문제나 오신트 문제의 라이트업을 쓸 수도 없게 되었다.. :(

아무튼 이번엔 처음부터 정식으로 참가해 팀원들과 함께 열심히 문제를 풀었고, 최종적으로 우리 '너의집주소는' 팀은 3514 Points를 얻어 95위의 성적으로 마무리 하였다. 다들 정말 열정을 가지고 열심히 참가한 덕분에 굉장히 높은 성적을 기록할 수 있었다. 개인적으로는 굉장히 만족하는 결과이다. 앞으로도 더 자주 CTF 대회들을 둘러보고 참가해서 부족한 내 실력을 키울 수 있는 발판으로 삼을 수 있었으면 좋겠다.

모두 수고 많으셨습니다. 앞으로도 같이 참가해요!

What is Networking?

ispini — Mon, 12 Jan 2026 05:21:19 +0900

Careers in Cyber

ispini — Mon, 12 Jan 2026 05:20:25 +0900

그냥 정보보안의 여러 직업들을 소개하는 룸이었음

・주요 개념: 사이버 보안이 왜 중요한지, 다양한 정보보안 관련 직종들 소개

・핵심 키워드: 각 직종들..?

기술적인 내용은 딱히 없고, 정보보안의 현황 및 세부 직종들 소개

1. 보안 분석가

- 회사의 전반적인 사이버 보안체계 분석 및 보안 체계 수립, 팀 사이 연계 수립

- 보고서 작성 및 문서화 담당

2. 보안 엔지니어

- 보안 솔루션 개발 및 구현, 보안 조치 테스트 및 스크리닝, 모니터링 후 업데이트 및 취약점 개선

3. 사고 대응자

- 보안 침해 발생 시 공격 탐지 및 복구 작업 수행, 사고 보고 및 추가 공격 대비, 대책 수립 지원 등

4. 포렌식 분석가

- 공격 범인에 대한 디지털 증거 수집과 복구 및 상황 분석, 사건의 진행 확인 및 대책 수립 지원

5. 소프트웨어 분석가

- 리버스 엔지니어링을 통해 프로그램 분석 및 의도 파악, 악성 프로그램의 목적 및 대처 방법 탐지

6. 침투 테스터

- 사내 시스템 및 소프트웨어 모의 테스트, 결함이나 취약점 발견 및 평가, 감사 수행 및 피드백 제공

7. 레드 팀

- 사내 취약점 발견, 공격 대상의 탐지 및 대응 평가, 모의 공격과 은닉을 통한 침투 및 시스템 장악 테스트