| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 |
- 보고서
- 모의침투
- rocky linux#siem#project#threat detection#soc#onpremise#ids#python#csv#pipeline#kali linux#DVWA#security monitoring
- CERT
- 인프라 활용을 위한 파이썬
- Foxyproxy#install#setting#firefox
- 클라우드 보안 기반
- Kali#Linux#Brute#Force#Attack#Test#DVWA#Hacking#Low#무차별#대입#공격#해킹
- Case Study
- 모듈프로젝트
- 애플리케이션 보안 기술
- 클라우드 기반
- 모듈 프로젝트
- Kali#Linux#KALI#LINUX#INSTALL#github#설치
- sk shieldus
- 개인정보보호
- 쉴더스
- 클라우드 보안 기술
- 29기
- VMWARE#INSTALL#설치
- AI #취업
- 루키즈
- DVWA#INSTALL#github#security#kali#linux
- 시스템-네트워크 보안 기술
- kisa #보안관제
- DVWA#Brute#Force#Attack#Test#Kali#Linux#Medium#Level#sleep
- 기술 특강 및 OT
- #루키즈
- sk 쉴더스 루키즈
- 클라우드기반 보안 시스템 구축/운영 실무
- Today
- Total
이것저것
[SK shieldus Rookies 29기] 36일차 본문
2025년 12월 31일이다. 어느덧 올 한해가 마무리가 된다. 한 것도 없는데 왜 이렇게 나이만 먹는 기분이 들지..?
사담이 이따가 하고 다시 모듈 프로젝트 이야기로 돌아가보자.
이틀 전에 구축한 아키텍처 날리고 어제는 새로 처음부터 끝까지 다 구축을 했다. 열심히 구축하고 이제 스샷 다 뜨고 과제를 제출한 뒤, 취약점 점검을 위해서 각종 서비스들을 내려야 되는데... 문제는 내리니까 정상적으로 동작이 안 된다. 사실 어제 혹시 모를 생각이 들긴 했는데...
왜 슬픈 예감은 틀린 적이 없나....
이것저것 건들다 보니까 이건 일부분만 날리는 시간이 더 길 것 같다는 생각이 들기 시작했다. 어쩌겠나... 그냥 다 날리고 새로 구축하는 게 더 빠를 것 같은데... 그래서 다 날렸다!!!ㅋㅋㅋㅋㅋ 이쯤 되니까 웃음 밖에 안 나와서 정줄 놓고 구축맨이 되어버렸다. 근데 구축하면서도 웃긴게 지금 한 3번째 만들다 보니까, 아키텍처를 안 보고도 그냥 생각이 나고, 구축하는데 오래 걸리는 서비스들을 체험해서 그런지 멀티플로 싹 다 돌리니까 처음에 구축할 때 한 6~7시간 걸리던게 2시간 반 정도만에 구축을 싹 해버렸다.
역시 노가다가 답인가..?
아무튼 구축을 싹 끝내고, 이제 진~~짜 인프라 취약점을 점검하려고 한다.
인프라 취약 점검 기준으로 삼은 것은 올해 따끈따근하게 발표 된 KISA의 주통기반 가이드이다.
주요정보통신기반시설 기술적 취약점 분석·평가 방법 상세가이드_2026
위 사이트에서 다운 받을 수 있다.
이와 별개로 클라우드 취약점 점검 가이드(2024)도 같이 보면 좋을 것 같아서 참조하였다. 주통 기반보다 UI가 좀 괜찮은 것 같아서 나같은 아마추어는 보면서 따라하면 좋을 것 같다.
그 밖에도 각종 취약점 점검을 진행할 때의 추진 근거로 국내 법령을 준수하였다. 다들 아는 개보법이나 정통망법 이하 하위 법률 및 규칙 등을 참고하였다.
내가 맡은 파트는 주통기반 가이드 기준으로 Linux Server의 서비스 관리이다.
살짝 시식용으로 하단에 작성 내용을 첨부한다.
3. 서비스 관리 (Service Management)
불필요한 서비스는 공격 표면(Attack Surface)을 넓히는 주된 요인이다. 제공된 아키텍처에 따르면 web-ec2는 웹 서버 역할을 수행하므로, 이와 무관한 서비스는 모두 비활성화되어야 한다.
U-34: Finger 서비스 비활성화
점검 내용: Finger 서비스 비활성화 여부 점검
점검 목적: Finger 서비스를 통해 네트워크 외부에서 해당 시스템에 등록된 사용자 정보를 확인할 수 있어 비인가자에게 사용자 정보가 조회되는 것을 방지하기 위함
보안 위협: Finger 서비스가 활성화되어 있을 경우, 비인가자가 Finger 서비스를 사용하여 사용자 정보를 조회한 후 비밀번호 공격을 통해 계정을 탈취할 위험이 존재함
진단방법:
dpkg -l | grep finger #finger 패키지 설치 여부 확인 systemctl list-units --type=service | grep finger #실행 중인 finger 서비스 확인 ss -lntp | grep :79 #포트 열림 여부 확인(finger는 TCP 79번 포트 사용)조치방법:
Finger 패키지를 삭제하거나 서비스를 중지한다.
sudo apt purge finger sudo apt autoremove근거: 「정보통신망 이용촉진 및 정보보호 등에 관한 법률」 제28조(정보보호조치)
- 결론 : finger 서비스 점검 결과, Ubuntu 시스템 특성상 finger 서비스 및 xinetd/inetd가 설치되어 있지 않으며, 관련 서비스 및 포트(TCP 79)가 활성화되어 있지 않음을 확인함. 따라서 finger 서비스는 비활성화 상태로 양호함.

그림 3-1 : Finger 서비스 비활성화
뭐 대충 이런 식으로 진행을 하였다. 근데 점검하다 보니까 아키텍처를 구축할 때 서비스를 올려놓은 게 없어.... 그래서 뭐랄까 싹 다 취약점이 없긴 하다. 근데 또 발표할 때 아래와 같이 말을 할 수는 없지 않은가.
"서비스 올려놓은 게 없어서 취약점 점검할 게 없어가지고 그냥 다 양호로 때렸는데요..."
사실 맞말이라 뭐라하기는 좀 그렇지만 회사 갔는데 이러면 바로 죽탱이 날아갈 것 같은 발언이라고 생각이 들어서 나름대로 진단 방법과 진단 방법에 따라서 진단 했을 시에 발견된 부분들에 대한 조치 방법을 기술하였다. 당연히 법 좋아하는 한국인들처럼 어떤 점검 항목을 진단하고 조치했으면 그에 대한 명확한 추진 근거가 있어야 되지 않은가. 그래서 근거도 삽입하고, 종합 선물세트처럼 우리가 진행하는 프로젝트에 대해서 이래이래해서 저렇게했더니 요래요래 나와서 해당 취약점 항목은 양호하다고 판단하였다는 플로우로 진행을 하였다.
이런 식으로 한 바퀴 돌려주고 구축한 EC2 접속해서 실후기를 남겨야지 또 신뢰가 가니까 기념사진도 한 방 찍어준다.
이렇게 열심히 하던 와중에, 카톡을 하나 받았다.
아주 기분이 좋았다!
지금 글 쓰고 있을 때는 이미 1월 1일 되어버렸으나, 글 읽는 사람 모두 신년에는 좋은 기운을 받았으면 좋겠다.
'SK Shieldus Rookies 29' 카테고리의 다른 글
| [SK shieldus Rookies 29기] 38일차 (1) | 2026.01.17 |
|---|---|
| [SK shieldus Rookies 29기] 37일차 (0) | 2026.01.17 |
| [SK shieldus Rookies 29기] 35일차 (0) | 2026.01.14 |
| [SK shieldus Rookies 29기] 34일차 (0) | 2026.01.14 |
| [SK shieldus Rookies 29기] 33일차 (0) | 2026.01.14 |