1. 파일 다운로드 취약점

설명

파일 다운로드 취약점은 웹 애플리케이션이 사용자에게 파일을 다운로드할 때, 공격자가 악성 파일을 다운로드할 수 있는 취약점이다. 이는 파일 다운로드 기능이 적절히 보호되지 않거나 사용자의 입력을 제대로 검증하지 않을 경우 발생한다. 예를 들어, 공격자가 URL 매개변수를 조작하여 서버에서 중요한 시스템 파일을 다운로드할 수 있는 경우다.

취약점 실습

 
공격자는 파일 다운로드 기능의 URL 매개변수를 조작하여 서버의 민감한 파일에 접근할 수 있다.
 
예제 (리눅스 시스템)

http://example.com/download?file=../../../../etc/passwd

 
예제 (윈도우 시스템)

http://example.com/download?file=../../../../winnt/win.ini

이러한 요청을 통해 시스템의 중요 파일을 다운로드할 수 있다.

작동 원리

• 상대 경로(../)를 이용해 상위 디렉터리로 이동한 후, 민감한 파일에 접근한다.
• 서버가 사용자의 입력값을 제대로 검증하지 않으면, 공격자가 원하지 않는 경로를 지정하여 파일을 다운로드할 수 있다.
• 일부 경우, URL 인코딩(%2e%2e%2f)을 활용하여 필터링을 우회할 수도 있다.

• https://cafe.naver.com/crehacktive/203(해당 블로그에 자세히 설명 되어 있다)

대응 방안

1. 파일 경로 검증: 파일 다운로드 시 사용자로부터 입력된 경로를 그대로 사용하지 않고, 파일 경로를 안전하게 처리한다. 경로를 정해진 범위 내로 제한한다.
2. 파일 확장자 제한: 다운로드할 수 있는 파일 형식을 제한하여 악성 파일을 다운로드할 수 없도록 합니다.
3. 파일 다운로드 로그: 파일 다운로드 시 로그를 기록하여 악의적인 접근을 추적할 수 있도록 한다.

2. 파일 업로드 취약점

설명

파일 업로드 취약점은 공격자가 악성 파일을 서버에 업로드하여 시스템을 공격하는 취약점이다. 예를 들어, 서버에서 업로드된 파일을 실행하거나 특정 경로에 저장하면서 보안 취약점이 발생할 수 있다.

취약점 캡처

• 공격자는 악성 스크립트를 포함한 파일을 업로드할 수 있다. 예를 들어, .php, .exe와 같은 파일을 업로드하여 웹 서버에서 실행하게 할 수 있다.
• 이를 통해 시스템에 악성 코드가 실행되거나, 데이터가 유출될 수 있다.
• 사이트 검색해 본 결과 게시판 업로드 창에 제한 없이 아무 파일이나 올릴 수 있게 보안이 미흡한 웹 사이트들도 종종 보였다.

대응 방안

1. 파일 형식 검증: 업로드 가능한 파일의 확장자 및 MIME 타입을 엄격히 검증이 필요하다.
2. 업로드 경로 제한: 업로드된 파일이 실행되지 않도록 서버 측에서 파일 저장 위치를 제한하고, 업로드된 파일에 대한 실행 권한을 제거한다.
3. 파일 크기 제한: 업로드할 수 있는 파일의 크기를 제한하여 서비스 거부 공격(DoS)을 방지한다.
4. 파일 이름 변경: 파일 이름에 특수문자나 경로 조작을 방지하기 위해 파일 이름을 변경하여 저장한다.

3. 소스코드 내 중요정보 노출 취약점

설명

소스코드 내 중요정보 노출 취약점은 소스 코드 파일에 중요한 정보(예: DB 비밀번호, API 키 등)가 포함되어 있어 공격자가 이를 쉽게 접근하거나 추출할 수 있는 취약점이다. 개발자 실수로 코드나 설정 파일에 민감한 정보를 포함시킨 경우 발생한다.

취약점 캡처

• 예를 들어, GitHub와 같은 저장소에 비밀번호가 포함된 코드를 푸시한 경우 공격자는 해당 코드를 쉽게 검색하여 비밀번호를 얻을 수 있다.
• 코드 내에 API 키나 데이터베이스 자격 증명이 노출된 경우 이를 추출할 수 있다.
• 브라우저의 개발자 도구를 활용해서 html 내용을 본 결과 주석으로 활성화 되지 않은 경로를 추출했고 주소창에 url을 쳐 보니 숨겨진 페이지 창을 볼 수 있었다.

대응 방안

1. 민감 정보 외부 저장: 비밀번호와 같은 민감한 정보는 코드에 하드코딩하지 않고, 환경 변수나 안전한 설정 파일에 저장한다.
2. Gitignore 파일 사용: Git과 같은 버전 관리 시스템을 사용할 때 민감한 정보를 포함한 파일을 .gitignore에 추가하여 공개되지 않도록 한다.
3. 암호화: 민감 정보를 저장할 때 반드시 암호화를 적용하여, 만약 정보가 유출되더라도 안전하게 보호한다.

4. 공개용 웹 게시판 취약점

설명

공개용 웹 게시판 취약점은 유지보수 부족으로 인해 발생하며, 공격자는 알려진 보안 취약점을 악용하여 웹사이트를 변조하거나, 민감한 정보를 유출할 수 있다. 대표적인 취약점으로는 파일 업로드 취약점, SQL 인젝션, XSS(크로스 사이트 스크립팅), 권한 관리 취약점 등이 있다.
 

취약점 캡처

• 그누보드가 사용된 웹사이트를 확인할 수 있었다.
• inurl:board intitle:게시판, inurl:bbs intitle:게시판 등을 활용하여 특정 게시판이 사용된 웹사이트를 찾을 수 있다.
• 파일 업로드 취약점: 공격자가 악성 PHP 파일을 업로드하여 원격 명령을 실행할 수 있음.
• SQL 인젝션: 데이터베이스 질의문을 변조하여 관리자 계정을 탈취하거나 정보를 유출할 수 있음.
• XSS(크로스 사이트 스크립팅): 악성 스크립트를 삽입하여 사용자 세션을 가로채거나 피싱 공격을 수행할 수 있음.
• 권한 관리 취약점: 게시판 관리자 페이지가 보호되지 않아 비인가 사용자가 접근할 수 있음.

대응 방안

1. 최신 버전 유지: 보안 패치 및 업데이트를 정기적으로 수행한다.
2. 보안 설정 강화: 업로드 파일 확장자 제한, SQL 인젝션 필터링 적용, 관리자 페이지 접근 제한 설정을 적용한다.
3. 정기 점검 및 모니터링: 취약점 스캐닝을 수행하고, 웹 방화벽(WAF)을 적용하여 실시간 탐지 및 대응을 강화한다.

학교 과제로 매일 3개씩 경제 기사 읽고 요약하라고 하는데 너무 귀찮아서 코딩으로 해결함!

나중에 시간되면 클라우드로 배포해서 코드 실행 한번으로 매일 자동으로 파일 저장하게 만들어야겠다.

import requests
from bs4 import BeautifulSoup
import openai
import random
from datetime import datetime

# OpenAI API 설정
openai.api_key = ''

# 매일경제 메인 페이지 URL
main_url = 'https://www.mk.co.kr/news/ranking/economy/'

# 1. 인기 기사 링크 가져오기
def get_popular_articles():
    response = requests.get(main_url)
    soup = BeautifulSoup(response.text, 'html.parser')

    # 기사 링크 추출
    article_links = []
    for i in range(1, 11):
        article = soup.select(f'#container > section > div > section > div.sec_body > div > ul > li:nth-child({i}) > a')
        if article:
            article_links.append(article[0]['href'])
    return article_links

# 2. 기사 제목과 본문 추출
def get_article_details(url):
    response = requests.get(url)
    soup = BeautifulSoup(response.text, 'html.parser')

    # 제목 추출
    title_tag = soup.select_one('#container > section.contents > div.news_detail_head_group.type_none_bg > section > div > div > div > h2')
    title = title_tag.get_text().strip() if title_tag else '제목을 찾을 수 없습니다.'

    # 본문 추출
    content_tag = soup.select_one('div.news_cnt_detail_wrap')
    content = content_tag.get_text() if content_tag else '본문을 찾을 수 없습니다.'
    
    return title, content

# 3. OpenAI로 요약 요청
def summarize_article_with_openai(content):
    try:
        response = openai.chat.completions.create(
            model="gpt-3.5-turbo",  # GPT 모델 사용
            messages=[{
                "role": "user",
                "content": f"다음 기사의 본문을 보고 그 기사에 대한 내 생각을 만들어서 의견을 3~4줄로 요약해주세요:\n\n{content}"
            }]
        )
        ai_response = response.choices[0].message.content
        return ai_response
    except Exception as e:
        return f"Error: {str(e)}"

# 메인 함수
def main():
    # 인기 기사 링크 10개 가져오기
    article_links = get_popular_articles()

    # 3개 랜덤 기사 선택
    selected_links = random.sample(article_links, 3)

    # 문서 작성
    document = ""

    # 각 기사의 제목과 본문을 요약해서 출력
    for idx, url in enumerate(selected_links, 1):
        print(f"기사 {idx} URL: {url}")
        
        # 기사 제목과 본문 가져오기
        title, content = get_article_details(url)

        # 본문을 요약
        summary = summarize_article_with_openai(content)

        print(f"기사 {idx} 제목: {title}")
        print(f"기사 {idx} 요약: {summary}")
        
        # 문서에 추가
        document += f"기사 {idx} 링크: {url}\n"
        document += f"기사 {idx} 제목: {title}\n"
        document += f"기사 {idx} 요약: {summary}\n"
        document += '-' * 50 + '\n'

    # 현재 날짜를 가져와 파일명에 포함
    current_date = datetime.now().strftime("%Y-%m-%d")
    file_name = f"article_summary_{current_date}.txt"

    # 결과 문서를 텍스트 파일로 저장 (덮어쓰기)
    with open(file_name, 'w', encoding='utf-8') as file:
        file.write(document)

    print(f"\n결과가 '{file_name}' 파일에 저장되었습니다.")

if __name__ == '__main__':
    main()

https://eatitstory.tistory.com/80

위에 글 바탕으로 만든 악성코드 분석 보고서

1. 취약한 파일 존재 취약점

설명

웹 서버에 의도하지 않은 파일(내부 문서, 백업 파일, 로그 파일, 압축 파일 등)이 존재할 경우, 공격자가 파일명을 유추하여 직접 접근함으로써 민감한 정보를 획득할 수 있는 취약점이다.

취약점 실습

• 검색창에 filetype:sql backup 입력

  

• 공개된 SQL 덤프 파일을 찾아 개인정보가 포함되어 있는지 확인

대응 방안

• 웹 서버는 개발과 운영 환경을 분리하여 운영 환경에서 소스 코드 수정 또는 테스트 목적의 임시 파일을 생성하지 않도록 한다.
• 웹 서버의 디렉터리에 존재하는 기본 설치 파일, 임시 및 백업 파일을 조사하여 웹 사용자가 접근하지 못하도록 조치한다.
• 정기적으로 웹 서버의 불필요한 파일을 검색하여 제거한다.

2. 계정 관리 취약점

설명

회원가입 시 안전한 패스워드 규칙이 적용되지 않아, 취약한 패스워드로 회원 가입이 가능할 경우, 무차별 대입 공격(Brute Force)을 통해 패스워드가 누출될 수 있는 취약점을 의미한다.

취약점 실습

• 보안이 강한 사이트를 찾아보았다
• 국내 유명 게임 사이트의 회원가입 창을 확인
• 보안이 엄격한 사이트는 비밀번호에 특수문자+숫자 조합을 요구하는 창을 볼 수 있다

대응 방안

• 사용자가 취약한 패스워드를 사용할 수 없도록 패스워드 생성 규칙을 강제할 수 있는 로직을 적용한다.

3. 실명 인증 취약점

설명

사용자 본인 확인 과정에서 취약한 프로그램을 악용하여 사용자 정보를 변조할 수 있는 취약점을 의미한다. 이를 통해 관리자로 위장하여 개인정보를 수집하거나, 홈페이지 가입 시 제공하는 포인트 등을 악용하는 등의 공격이 발생할 수 있다.

취약점 실습

1. 실명인증 창 접근
   • 공격자는 웹사이트의 실명인증 페이지에 접속하여 타인의 개인정보(이름, 주민등록번호 등)를 입력 

     

2. 웹사이트 → (실명인증 요청) → 인증기관
   • 입력한 정보를 인증기관에 전달하여 실명 인증을 요청
3. 인증기관 → (실명인증 응답) → 웹사이트
   • 인증기관이 실명 인증 결과를 반환(나이, 성별, 연락처 등 포함)
4. 웹사이트 → (인증 성공) → 공격자
   • 웹사이트에서 인증 성공 메시지를 표시
5. 웹 프록시로 정보 변조
   • 공격자는 웹 프록시(Burp Suite 등)를 사용하여 요청을 변조
   • 실명 인증에서 받은 고정된 개인정보를 수정하여 웹사이트로 전송
6. 변조된 정보로 회원가입
   • 웹사이트가 변조된 정보를 검증 없이 신뢰하여 회원가입 허용

     

     

핵심

• 프록시가 웹사이트와 인증기관 간의 응답을 가로채고 변조하여 사용자가 인증받은 정보가 아닌 가상의 인물로 회원가입을 하도록 한다.
• 웹사이트는 변조된 정보에 대해 검증 없이 신뢰하고, 공격자는 원하는 이름과 정보로 회원가입을 완료하게 된다.

대응 방안

• 중요한 정보가 있는 홈페이지(실명 등)는 재인증을 적용하고,
• 안전하다고 확인된 라이브러리나 프레임워크(OpenSSL이나 ESAPI의 보안 기능 등)를 사용하여 홈페이지 개발 보안 조치를 수행한다.

4. 전송 시 주요 정보 노출 취약점

설명

웹 서버가 보안과 관련된 민감한 데이터를 평문(엄호화 되지 않은 ex: http)으로 통신 채널을 통해 송수신할 경우, 통신 채널 스니핑을 통해 인가되지 않은 사용자에게 민감한 데이터가 노출될 수 있는 취약점을 의미한다.

취약점 실습

1. HTTP 로그인 페이지 찾기
   • 보안이 취약한 사이트에서 http:// 접속 후 로그인 시도

     

     

     
     
     
2. Wireshark를 활용한 패킷 분석
   • Wireshark 실행 후 http 필터 적용
   • 로그인 요청 시 캡처된 패킷에서 아이디와 비밀번호가 평문으로 전송되는지 확인

대응 방안

• 웹 서버와 클라이언트 간의 통신에 SSL/TLS와 같은 암호화 프로토콜을 적용하여 데이터를 암호화한다.
• 민감한 데이터는 전송 전에 추가적인 암호화 과정을 거쳐 안전성을 높인다.

참고

https://itcase.tistory.com/entry/29-%EC%B9%A8%ED%95%B4%EB%8C%80%EC%9D%91CERT-7-%EC%9B%B9-%EC%B7%A8%EC%95%BD%EC%A0%90-%EC%8B%A4%EC%8A%B52

https://maker5587.tistory.com/34

https://skynarciss.tistory.com/35

1. 관리자 페이지 노출 취약점

🔹 왜 위험한가?
공격자가 관리자 페이지에 접근하면 무차별 대입 공격(Brute-force Attack)이나 SQL 인젝션을 통해 관리자 계정을 탈취할 수 있음. 이를 통해 웹사이트 변조, 데이터베이스 접근, 사용자 정보 탈취 등의 피해가 발생할 수 있음.
 
🔹 실제 사례
공격자가 노출된 관리자 페이지를 통해 로그인 시도를 반복하여 관리자 계정을 탈취하고 개인정보 데이터를 유출한 사례가 있음.
📌 출처: https://www.kinternet.org/_n_2007/0629/kisa.pdf?utm_source
 
🔹 실습
inurl:admin site:.kr 구글링으로 관리자 페이지 접속

• 기본 로그인 정보로 접근 가능한 취약점이 있음

  

• 로그인 화면 없이 관리자 페이지가 노출되는 경우도 있음

 
 
🔹 대응 방안

• 비밀번호 강도 강화: 관리자의 계정에 강력한 비밀번호를 설정하여 brute-force 공격을 방지한다. 비밀번호는 대소문자, 숫자, 특수문자를 포함해야 한다.
• 로그인 시도 제한: 일정 횟수 이상 로그인 시도를 실패하면, 계정을 잠그거나 CAPTCHA를 적용하여 자동화된 공격을 차단한다.
• 관리자 페이지 숨기기: 관리자 페이지 URL을 변경하거나, 관리자 접근을 제한할 수 있는 IP 화이트리스트를 설정한다.

2. 디렉터리 나열 취약점

🔹 왜 위험한가?
웹 서버에서 디렉터리 목록이 보이도록 설정되면, 공격자가 민감한 파일 목록을 확인하고 직접 접근할 수 있음. 이를 통해 소스 코드, 환경 설정 파일, 백업 파일 등이 유출될 수 있음.
 
🔹 실제 사례
디렉터리 목록화로 인해 내부 문서 및 개인정보가 쉽게 접근 가능한 상태였으며, 이를 통해 대량의 개인정보 유출 사고가 발생한 사례가 있음.
📌 출처: https://www.boannews.com/media/view.asp?idx=98929&utm_source
 
🔹 실습
intitle: "index of" "password" 구글링으로 디렉터리 목록 접근

• passwords.txt 파일을 통해 ZIP 파일 비밀번호를 추출할 수 있었음

 
🔹 대응 방안
 

• 디렉터리 나열 비활성화: 서버 설정에서 Options -Indexes를 추가하여 디렉터리 목록이 노출되지 않도록 설정한다.
• 파일 접근 제한: 중요한 파일(예: 백업, 설정 파일 등)을 보호하기 위해 파일 접근 권한을 제한한다.
• .htaccess 사용: .htaccess 파일을 사용하여 웹 서버의 접근을 제어하고, 특정 디렉터리에 대한 접근을 제한한다.

3. 시스템 관리 취약점

🔹 왜 위험한가?
phpMyAdmin, cPanel, RDP(Remote Desktop Protocol), SSH 등 서버 관리 도구가 외부에 노출되면 공격자가 직접 서버에 접근할 수 있음. 무차별 대입 공격(Brute-force Attack)을 통해 관리자 계정을 탈취하거나, 알려진 취약점을 이용해 서버를 장악할 수 있음. 서버에 악성코드를 심거나, 랜섬웨어를 감염시켜 데이터를 인질로 잡을 수도 있음.
 
🔹 실제 사례
RDP(Remote Desktop Protocol) 노출로 인한 랜섬웨어 감염 사례: 공격자가 인터넷에 노출된 RDP 포트를 스캔하여 관리자 계정의 패스워드를 무차별 대입 공격(Brute-force Attack)으로 탈취한 후, 랜섬웨어를 배포하여 피해 시스템을 감염시킨 사례가 있음.
📌 출처: https://asec.ahnlab.com/ko/39804/?utm_source
 
🔹 실습

• intitle:"index of" password 구글링을 통해 php 노출된 시스템 관리 인터페이스를 탐색. 공격자가 이를 이용하여 시스템의 취약점을 찾거나 공격을 시도할 수 있음.

  

• allow_url_fopen이 활성화되어 있는 경우 원격 파일 포함(RFI) 공격이 가능해져 외부 URL에서 악성 파일을 포함하거나 실행할 수 있음. 이를 통해 웹 쉘을 업로드하거나 서버 명령어를 실행할 수 있음.

  

• intitle:"index of" intext:"web.config.txt"를 통해 API 관련 키가 노출된 파일을 발견할 수 있었음.

 
 
 
🔹 대응 방안

• 원격 관리 도구 보호: phpMyAdmin, cPanel 등의 관리 도구는 외부 접근을 차단하거나 VPN을 통해 접근하도록 제한한다.
• 강력한 인증 적용: 관리자 계정에는 강력한 비밀번호를 설정하고, 2단계 인증을 활성화하여 보안을 강화한다.
• 포트 차단 및 모니터링: 불필요한 포트를 차단하고, RDP, SSH 등의 포트는 방화벽을 통해 외부 접근을 제한한다.
• 소프트웨어 최신화: 관리 도구와 서버 소프트웨어를 최신 버전으로 유지하여 알려진 취약점으로 인한 공격을 차단한다.

4. 불필요한 Method 허용 취약점

🔹 왜 위험한가?
HTTP 메서드(예: PUT, DELETE, TRACE 등)가 불필요하게 활성화되어 있으면 공격자가 악성 파일을 업로드하거나 중요한 파일을 삭제할 수 있음. TRACE 메서드가 허용된 경우, XST(Cross-Site Tracing) 공격을 통해 쿠키 탈취 및 세션 하이재킹이 가능함.
 
🔹 실제 사례
서버에서 필요하지 않은 HTTP 메서드가 활성화된 상태로 운영되었고, 공격자가 이를 악용하여 서버 내 파일을 변경하거나 삭제한 사례가 있음.
📌 출처: https://m.boannews.com/html/detail.html?idx=9791&utm_source
 
🔹 실습
inurl:"httpd.conf" "LimitExcept" "PUT DELETE" 구글링을 통해 PUT과 DELETE 메서드를 허용한 서버 설정을 찾음.

 
🔹 대응 방안

• 불필요한 HTTP 메서드 비활성화: PUT, DELETE, OPTIONS와 같은 불필요한 HTTP 메서드를 서버 설정에서 비활성화한다.
• HTTP 헤더 설정 강화: Access-Control-Allow-Methods와 같은 HTTP 헤더를 통해 허용할 메서드를 제한한다.
• 웹 방화벽(WAF) 사용: WAF를 사용하여 비정상적인 HTTP 메서드를 차단하고, 공격을 미리 방어할 수 있다.

 
참고
https://mpit.tistory.com/entry/%EC%B9%A8%ED%95%B4-%EB%8C%80%EC%9D%91-CERT-%EA%B3%BC%EC%A0%956%EC%A3%BC%EC%B0%A8
https://ogig0818.tistory.com/304
https://www.igloo.co.kr/security-information/%EB%B6%88%ED%95%84%EC%9A%94%ED%95%9C-%EC%9B%B9-method-%EC%A7%84%EB%8B%A8-%EC%8B%9C-%EB%B0%9C%EC%83%9D%ED%95%98%EB%8A%94-%EB%AC%B8%EC%A0%9C%EC%A0%90-%EB%B0%8F-%EB%8C%80%EC%9D%91%EB%B0%A9%EC%95%88/
https://itcase.tistory.com/entry/28-%EC%B9%A8%ED%95%B4%EB%8C%80%EC%9D%91CERT-5-%EC%9B%B9-%EC%B7%A8%EC%95%BD%EC%A0%90-%EC%8B%A4%EC%8A%B51
 
https://rybbit-life-debugging.tistory.com/50

Shodan은 인터넷에 연결된 다양한 IoT 기기들을 검색하고 분석할 수 있는 도구이다. 이를 통해 웹캠, CCTV, 네트워크 프린터, 산업제어시스템 등 다양한 기기들의 보안 취약점을 파악하고, 실시간으로 접근할 수 있는 정보들을 열람할 수 있다. 이번 시간에는 Shodan을 통해 검색할 수 있는 주요 IoT 기기들과 각 기기의 특징을 살펴보겠다.

1. CCTV

• 특징: 감시용 카메라. 아날로그 CCTV가 아닌 네트워크 연결형 카메라.
• 보안 위험: CCTV 영상 유출, 관리 부실로 인한 해킹 위험. 개인정보 유출 가능성 있음.
• 대표적 피해 사례: 영상 정보 유출 및 해킹 사례 발생.

 
 
검색 키워드: port:80 has_screenshot:true  (해당 ip를 웹브라우저 주소 창에 검색하면 이동한다)

• 포트 554는 **RTSP (Real-Time Streaming Protocol)**로, 웹 브라우저로 직접 접속할 수 없다.
• has_screenshot:true는 Shodan이 캡처한 화면이 있는 결과만 표시한다.
• RTSP 포트로 접속이 불가능하므로, HTTP 80 포트로 변경하여 접근할 수 있다. 이를 통해 CCTV 영상에 접근할 수 있다.

2. WebCam, IP Cam

• 특징: 화상 채팅이나 인터넷 방송 등으로 사용되는 카메라. 네트워크를 통해 직접 연결되는 웹캠에 대한 검색어는 다양한 종류가 존재함.
• 보안 위험: 사생활 침해 우려가 큼. 불법적으로 웹캠 화면을 엿보거나 유출될 수 있음.
• 대표적 피해 사례: 가정집에서 설치된 IP 카메라 해킹 사례가 보도된 바 있음.

IP 카메라

• 검색 키워드: title:"IPCam Client" port:80

  

  
  
  
  • 예를 들어, Foscam과 같은 브랜드에서 기본 비밀번호를 사용하는 웹캠은 쉽게 접근할 수 있을 수 있다.(사용자가 비밀번호를 안 바꿨다면)

WebCam

• 검색 키워드: title:"webcam" has_screenshot:true

  

  

  
  
  

  

  
  
  • 이 검색어를 통해 웹캠의 라이브 영상을 확인할 수 있다. Shodan은 각 기기의 화면을 캡처하여 결과로 표시하므로, 이를 통해 라이브 영상을 확인할 수 있다.

3. Network Printer

• 특징: 네트워크에 연결되어 모든 사용자들이 함께 사용할 수 있는 프린터.
• 보안 위험: 프린터 해킹으로 문서 엿보기, 인쇄 기록 훔쳐보기 등. 프린터 하드디스크에서 이전 인쇄 기록을 볼 수 있는 경우도 있음.
• 대표적 피해 사례: 프린터 해킹 사건으로 인해 문서 정보가 유출된 사례 있음.

• HP 프린터 검색 키워드: "HP-ChaiSOE" port:80

  

  

• Xerox 프린터 검색 키워드: ssl:"Xerox Generic Root"

 
일부 프린터는 기본 비밀번호가 걸려 있지 않거나, 취약한 비밀번호를 사용하여 보안에 취약할 수 있다. 예를 들어, 엡손과 캐논은 비밀번호가 걸려 있지만, 다른 프린터는 보안에 취약한 경우가 있다. Server: printer 포트 80을 통해 확인할 수 있다.

4. 산업 제어 시스템 (ICS)

• 특징: 산업 시설을 제어하는 시스템으로, 네트워크 기술을 통해 외부와 연결되며 생산성 향상에 기여함.
• 보안 위험: 해킹 시 산업 기밀 유출, 시설 셧다운, 재정적 피해, 국가 시설을 대상으로 한 테러 가능성.
• 사례: 과거 산업 제어 시스템이 해킹되어 큰 피해를 본 사례가 있음.

1. Nordex 관련 검색

• Nordex는 독일에 본사를 둔 풍력 발전기 제조업체.
• 검색한 결과, ICS(산업제어시스템) 관련 장비에서 실행 중인 시스템이 나타남.
• 이 시스템은 로그인으로 컨트롤 가능한 상태

2. ICS 검색

• ICS(산업제어시스템)와 관련된 장비를 검색하는 과정에서 특정 제품이나 시스템에 대한 정보를 찾음.
• ICS 관련 시스템은 보통 특정 산업 장비에 대한 제어를 담당하는 시스템으로, 해당 시스템은 리눅스 기반의 모니터링 대시보드를 활용하는 것으로 추측됨.

3. 제품 가이드북을 활용한 로그인 UI 우회 방법

• 목적: 로그인 UI 우회 방법 탐색
• 방법:
  1. ICS(산업제어시스템) 회사 이름을 Shodan에서 검색
  2. 검색 결과에서 제품(프로덕트) 이름을 확인
  3. 해당 제품 이름을 구글에서 검색하여 가이드북을 찾음
  4. 가이드북을 분석하여 로그인 UI를 우회할 수 있는 방법을 탐색

4. Siemens 제품의 VNC 서버 취약점 분석(raw data 분석)

• top automation vendors를 검색하면 Siemens가 나타났으며, Siemens 제품과 관련된 ICS 정보를 검색해봤다.

  

• Siemens 제품과 관련된 데이터를 추가 검색
  

  

• 

  

• Siemens의 제품과 관련된 데이터를 쇼단에서 이미지 탭에서 검색하고, 그 내부의 raw data를 분석한 결과 VNC 서버와 관련된 정보가 나타남.

• 발견된 취약점:
  • 인증이 비활성화된 VNC 서버가 존재하여 외부 공격자가 쉽게 접근할 수 있음
  • VNC 서버의 보안이 취약할 경우 공격자가 시스템에 접근할 가능성이 높음
• 기술적 제한:
  • 웹브라우저는 VNC 프로토콜(RFB)을 지원하지 않음
  • VNC 서버에 접속하려면 전용 VNC 클라이언트가 필요함

5. POS 시스템

• 특징: 상점에서 판매 거래를 처리하는 시스템으로, 결제 카드 정보와 고객 데이터를 처리하는 중요한 역할을 한다. POS 시스템은 카드 결제뿐만 아니라, 재고 관리, 매출 기록 등의 기능을 수행한다.
• 보안 위험: 카드 정보 및 고객 데이터를 처리하기 때문에 해킹 시 중요한 개인 정보가 유출될 수 있다. POS 시스템 해킹을 통해 신용카드 정보, 결제 내역, 고객 정보 등이 유출될 수 있으며, 이를 통해 금융 사기 및 데이터 도용이 발생할 수 있다.
• 대표적 피해 사례: POS 시스템이 해킹되어 카드 정보가 유출된 사건이 발생한 바 있으며, 특히 대형 상점 체인에서 발생한 사례가 보도된 적 있음. 해커는 POS 단말기를 통해 결제 정보를 훔쳐 불법적인 거래를 시도하기도 한다.

• pos 검색 키워드: pos

• Shodan을 통해 POS 시스템의 로그인 화면을 확인할 수 있다. 일부 취약한 POS 시스템은 보안에 취약하여 개인정보 유출의 위험이 있다.

개인정보 유출 원인

1. 취약한 기본 설정: 많은 IoT 기기가 기본 비밀번호나 설정을 그대로 사용하여 보안에 취약하게 노출된다.
2. 소프트웨어 취약점: 오래된 소프트웨어를 사용하거나 보안 패치가 적용되지 않은 경우 해킹에 취약할 수 있다.
3. 인증 및 암호화 부재: 일부 IoT 기기는 인증 기능이 없거나 암호화되지 않은 통신을 사용하여 개인정보 유출 위험이 있다.
4. 네트워크 보안 취약점: 공유기나 방화벽 설정이 취약한 경우, 외부 공격자가 내부 네트워크에 접근하여 IoT 기기를 공격할 수 있다.

보안 강화 방안

1. 기본 비밀번호 변경: 모든 IoT 기기의 기본 비밀번호를 강력한 비밀번호로 변경해야 한다.
2. 최신 소프트웨어 유지: IoT 기기의 소프트웨어를 최신 버전으로 유지하고 보안 패치를 정기적으로 적용해야 한다.
3. 강력한 인증 및 암호화: 인증 기능을 활성화하고 암호화된 통신을 사용하여 개인정보를 보호해야 한다.
4. 네트워크 보안 강화: 공유기와 방화벽 설정을 강화하여 외부 공격으로부터 네트워크를 보호해야 한다.

결론

Shodan을 활용하여 IoT 기기의 보안 취약점을 미리 파악하고 적절한 보안 조치를 취하는 것이 중요하다. Shodan에서 검색할 수 있는 IoT 기기들은 CCTV, 웹캠, IP 카메라, 네트워크 프린터, 산업 제어 시스템(ICS) 등이 있다. 각 기기는 기본 설정, 소프트웨어 취약점, 인증 및 암호화 부재 등의 이유로 보안에 취약할 수 있으며, 이를 해결하기 위한 보안 강화 방안을 적용하는 것이 중요하다.
 
참고
https://itstudycube.tistory.com/29

https://youtu.be/bZUnQR4bdT8?si=6oqM7OKZ2FS5zcHP

https://www.youtube.com/watch?v=Stxrz0timCg
 

Availability(고가용성) & Scalability(확장성) 정리

Availability(고가용성)

• 정의: 시스템 또는 애플리케이션이 항상 작동 가능하고, 장애 발생 시에도 지속적으로 서비스가 제공될 수 있는 능력.
• 특징
  • 일반적으로 **수평 확장(horizontal scaling)**과 함께 적용됨.
  • **다중 가용 영역(Multi-AZ)**을 활용하여 최소 2개 이상의 데이터 센터에서 운영함.
  • RDS Multi-AZ 배포는 패시브 방식(장애 발생 시 자동으로 다른 AZ로 전환).
  • EC2 Auto Scaling Group과 로드 밸런서를 사용하여 여러 AZ에 걸쳐 애플리케이션을 실행함​.

Scalability(확장성)

• 정의: 시스템이 증가하는 부하를 처리하기 위해 적절하게 확장될 수 있는 능력.
• 종류
  • 수직 확장(Vertical Scaling)
    • 단일 인스턴스의 크기를 증가시켜 성능을 향상시키는 방법.
    • 예: t2.micro → t2.large 업그레이드.
    • RDS, ElastiCache 같은 AWS 서비스에서 사용됨.
    • 하드웨어 한계로 인해 확장 가능 범위가 제한됨​.
  • 수평 확장(Horizontal Scaling)
    • 애플리케이션 인스턴스를 여러 개 추가하여 성능을 향상시키는 방법.
    • 분산 시스템 환경에서 자주 사용되며, AWS EC2 Auto Scaling Group과 로드 밸런서로 구현 가능.
    • 클라우드 환경에서 매우 일반적인 방식​.

고가용성과 확장성의 차이점

• 고가용성: 장애 발생 시에도 시스템이 지속적으로 운영될 수 있도록 설계.
• 확장성: 부하 증가에 대응하여 시스템을 확장할 수 있도록 설계.
• 예를 들어 콜센터를 운영할 때:
  • 고가용성: 뉴욕과 샌프란시스코 두 개의 센터를 운영하여 한 곳에 장애가 발생해도 계속 운영 가능.
  • 확장성:
    • 수직 확장: 기존 직원(오퍼레이터)에게 더 많은 콜을 받을 수 있도록 장비를 업그레이드.
    • 수평 확장: 더 많은 직원을 추가하여 콜을 처리​.

 AWS에서의 적용 예시

• EC2 고가용성 & 확장성
  • 수직 확장: 인스턴스 크기 조정 (예: t2.nano → u-12tb1.metal).
  • 수평 확장: Auto Scaling Group & Load Balancer 사용.
  • 고가용성: Multi-AZ Auto Scaling Group & Load Balancer 적용​.
• RDS 고가용성 & 확장성
  • 고가용성: RDS Multi-AZ 배포로 장애 발생 시 자동 전환.
  • 읽기 확장성(Read Scalability): RDS Read Replica를 사용하여 읽기 성능 향상​.
• EFS(Elastic File System)
  • 다중 AZ 지원으로 고가용성 보장.
  • 자동 크기 조정으로 확장성 제공​.

로드 밸런싱 (Load Balancing) 정리

로드 밸런서란?
로드 밸런서는 트래픽을 여러 서버(EC2 인스턴스)로 분산하여 부하를 관리하는 서비스이다. AWS에서는 Elastic Load Balancer(ELB)를 제공하며, 여러 유형이 존재한다.

로드 밸런서를 사용하는 이유

• 부하 분산 → 여러 서버에 트래픽을 분산하여 과부하 방지
• 단일 접속 지점 제공 → DNS를 통해 접근 가능
• 자동 장애 감지 및 복구 → 인스턴스 장애 발생 시 정상 인스턴스로 트래픽 우회
• 정기적인 헬스 체크 수행 → 인스턴스의 정상 상태 여부를 모니터링
• SSL 종료 (HTTPS 처리) → 보안 강화를 위해 HTTPS 트래픽을 ELB에서 처리
• 세션 유지(Stickiness) 지원 → 사용자가 동일한 인스턴스로 연결될 수 있도록 설정 가능
• 고가용성 지원 → 여러 가용 영역(AZ)에서 트래픽을 분산하여 가용성을 높임
• 퍼블릭 트래픽과 프라이빗 트래픽을 분리 가능

헬스 체크란?

• 헬스 체크(Health Check)는 로드 밸런서가 백엔드 EC2 인스턴스의 정상 상태를 확인하는 기능이다. 헬스 체크를 통해 비정상적인 인스턴스를 감지하고, 트래픽을 정상 인스턴스로 우회할 수 있다.

헬스 체크가 필요한 이유

• • 문제가 있는 인스턴스를 자동 감지하여 트래픽을 차단
  • Auto Scaling과 연동하여 비정상 인스턴스를 자동 교체 가능
  • 웹 애플리케이션, API 서버, 데이터베이스 등의 가용성을 높이는 핵심 기능

헬스 체크의 동작 방식

• 1. 로드 밸런서가 정해진 주기(Interval)마다 헬스 체크 요청을 보냄
  2. 지정된 포트와 엔드포인트(/health 등)에 접속하여 상태 확인
  3. 응답 코드가 200(OK)이면 정상(Healthy), 다른 응답이거나 응답이 없으면 비정상(Unhealthy)으로 판단
  4. 비정상 상태가 연속적으로 감지되면, 해당 인스턴스를 트래픽 분배 대상에서 제외
  5. 다시 정상 상태로 감지되면, 트래픽을 다시 전달

헬스 체크 설정 항목

• • 프로토콜(Protocol) → HTTP, HTTPS, TCP
  • 포트(Port) → EC2 인스턴스에서 헬스 체크를 받을 포트 (예: 80, 443, 8080)
  • 헬스 체크 경로(Path) → /health, /status 같은 엔드포인트 설정
  • 정상/비정상 임계값
    • Healthy Threshold → 정상 상태로 판단할 요청 성공 횟수
    • Unhealthy Threshold → 비정상 상태로 판단할 요청 실패 횟수
  • 체크 주기(Interval) → 헬스 체크 요청 간격 (초 단위)
  • 타임아웃(Timeout) → 인스턴스가 응답을 반환해야 하는 최대 시간

Elastic Load Balancer(ELB) 유형

Classic Load Balancer (CLB)   (시험x)

• 2009년 출시된 1세대 로드 밸런서
• L4 (TCP, SSL) & L7 (HTTP, HTTPS) 지원
• 고정된 DNS 이름 제공 (xxx.region.elb.amazonaws.com)
• 현재는 ALB/NLB 사용이 권장됨

Application Load Balancer (ALB)

• 2016년 출시된 2세대 로드 밸런서
• OSI 7계층 (Layer 7)에서 동작 → HTTP, HTTPS, WebSocket 트래픽 처리
• 고급 라우팅 기능 지원
  • 경로 기반 라우팅 (example.com/users → 사용자 서버, example.com/posts → 게시글 서버)
  • 호스트 기반 라우팅 (one.example.com → 서버 A, two.example.com → 서버 B)
  • 쿼리 문자열 및 헤더 기반 라우팅
• 마이크로서비스 및 컨테이너 환경(Amazon ECS)에서 적합
• 포트 매핑 기능 제공 → Amazon ECS에서 동적 포트로 트래픽을 라우팅 가능

Network Load Balancer (NLB)

• 2017년 출시된 2세대 로드 밸런서
• OSI 4계층 (Layer 4)에서 동작 → TCP, UDP 트래픽 처리
• 고성능, 초저지연 (millions of requests per second)
• 고정된 IP 할당 지원 → 특정 IP를 화이트리스트(허용 목록)로 등록 가능
• DNS 이름 및 Elastic IP 할당 가능
• 금융 서비스, VoIP, 게임 서버 등 실시간 연결이 필요한 애플리케이션에 적합

Gateway Load Balancer (GWLB)

• 2020년 출시된 3세대 로드 밸런서
• OSI 3계층 (Layer 3)에서 동작 → IP 패킷 기반 트래픽 처리
• 보안 장비(Firewall, IDS/IPS, Deep Packet Inspection 등)와 함께 사용
• Transparent Network Gateway 역할 수행 → 보안 어플라이언스와 트래픽을 연결

ELB와 보안 (Security Groups)

• 로드 밸런서는 보안 그룹을 활용하여 트래픽을 제어할 수 있음
• Load Balancer Security Group → 외부에서 오는 HTTP/HTTPS 트래픽을 허용
• Application Security Group → 로드 밸런서에서만 허용된 트래픽만 받도록 설정

Sticky Sessions (Session Affinity)

• 클라이언트가 항상 동일한 백엔드 인스턴스로 연결되도록 설정하는 기능
• CLB, ALB, NLB에서 지원됨
• 쿠키 기반 세션 유지
  • 커스텀 쿠키 (애플리케이션에서 설정 가능)
  • 로드 밸런서에서 자동 생성하는 쿠키 (AWSALB, AWSELB)
• 사용 사례 → 로그인 세션 유지가 필요한 애플리케이션 (예: 전자상거래, 채팅 앱)
• 단점 → 특정 인스턴스에 부하가 집중될 수 있음

Cross-Zone Load Balancing (AZ 간 부하 분산)

• 여러 가용 영역(AZ)에 걸쳐 트래픽을 균등하게 분산하는 기능
• ALB → 기본적으로 활성화 (비활성화 가능)
• NLB, GWLB → 기본적으로 비활성화 (활성화 시 추가 요금 발생)
• CLB → 기본적으로 비활성화 (활성화 가능, 추가 요금 없음)

로드 밸런서 활용 예시

• 웹 서버 여러 대를 운영하는 경우, 트래픽을 균등하게 분산
• 마이크로서비스 아키텍처에서 API 요청을 특정 서비스로 라우팅
• TCP/UDP 기반의 금융 거래 시스템에서 빠른 트래픽 분산이 필요할 때
• EC2 Auto Scaling과 함께 사용하여 트래픽 증가 시 자동으로 인스턴스를 추가/제거

SSL/TLS (보안 및 암호화) 정리

SSL/TLS란?
SSL(Secure Sockets Layer)과 TLS(Transport Layer Security)는 클라이언트와 로드 밸런서 간의 트래픽을 암호화하여 보안을 강화하는 프로토콜이다.

• SSL은 이전 버전이며, 현재는 TLS가 표준이지만 여전히 "SSL 인증서"라는 용어가 널리 사용됨.
• 공인된 **인증 기관(CA, Certificate Authority)**에서 발급한 인증서를 사용해야 함.
  • 예: Comodo, Symantec, GoDaddy, GlobalSign, Digicert, Let's Encrypt

AWS에서 SSL/TLS 관리

• AWS **Certificate Manager(ACM)**를 사용하여 인증서를 관리 가능
• 사용자가 직접 인증서를 업로드할 수도 있음
• HTTPS 리스너를 설정하면 기본적으로 하나의 인증서를 지정해야 하며, 여러 개의 인증서 추가 가능
• SNI(Server Name Indication) 기능을 활용하여 여러 도메인에 대한 SSL 인증서 적용 가능

Server Name Indication (SNI)

• 하나의 로드 밸런서에서 여러 개의 SSL 인증서를 사용할 수 있도록 지원하는 프로토콜
• 클라이언트가 SSL 핸드셰이크 시 접속하려는 도메인(hostname)을 전달하면, 서버가 해당 도메인에 맞는 인증서를 제공
• ALB, NLB, CloudFront에서 지원 (CLB에서는 지원되지 않음)

ELB와 SSL 인증서

로드 밸런서 유형SSL 인증서 지원SNI 지원

• CLB → 여러 개의 SSL 인증서를 사용하려면 여러 개의 CLB를 생성해야 함
• ALB, NLB → SNI를 사용하여 여러 SSL 인증서를 적용 가능

Connection Draining (Deregistration Delay)

로드 밸런서에서 연결 해제 중인 인스턴스가 진행 중인 요청을 마칠 수 있도록 대기하는 기능

• CLB → "Connection Draining"
• ALB & NLB → "Deregistration Delay"
• 기본값은 **300초(5분)**이며, 1~3600초(1시간)까지 설정 가능
• 짧은 요청이 많은 서비스의 경우, 대기 시간을 낮게 설정하는 것이 유리함

Auto Scaling Group (ASG) & Load Balancer 연동

**Auto Scaling Group(ASG)**은 트래픽 변화에 따라 EC2 인스턴스 수를 자동으로 조정하는 기능

• 트래픽 증가 시 → EC2 인스턴스를 자동으로 추가 (Scale Out)
• 트래픽 감소 시 → EC2 인스턴스를 자동으로 제거 (Scale In)
• 최소/최대 인스턴스 개수를 지정 가능
• 비정상 인스턴스가 감지되면 자동으로 교체

  

Auto Scaling Group (ASG) 주요 속성

• Launch Template → 인스턴스 유형, AMI, EBS 볼륨, 보안 그룹, IAM 역할 포함
• Scaling Policies (확장 정책)
  • Target Tracking Scaling → 예: 평균 CPU 사용률을 40%로 유지
  • Simple/Step Scaling → 예: CPU가 70% 이상이면 2개 추가, 30% 미만이면 1개 제거
  • Scheduled Scaling → 예: 매주 금요일 오후 5시에 최소 인스턴스를 10개로 증가
  • Predictive Scaling → AI 기반 트래픽 예측 후 사전 확장

CloudWatch Alarms와 Auto Scaling 연동

• CloudWatch 알람을 활용하여 ASG 확장 가능
• CPUUtilization(평균 CPU 사용률), RequestCountPerTarget(요청 수), 네트워크 트래픽(In/Out) 등을 기준으로 확장

Auto Scaling에서 고려할 좋은 메트릭(Good metrics to scale on)

1. CPUUtilization (CPU 사용률)
   • EC2 인스턴스들의 평균 CPU 사용률이 일정 임계값을 초과하면 인스턴스를 추가하고, 낮아지면 제거.
   • 예: 평균 CPU 사용률이 70%를 초과하면 2개 추가, 30% 미만이면 1개 제거
2. RequestCountPerTarget (타겟당 평균 요청 수)
   • 로드 밸런서(ALB, NLB)에서 각 백엔드 인스턴스가 처리하는 요청 수를 기준으로 확장.
   • 예: EC2 한 대당 평균 요청 수가 1000건을 초과하면 확장, 500건 미만이면 축소
3. Network In/Out (네트워크 트래픽)
   • 애플리케이션이 CPU가 아닌 네트워크 사용량이 많은 경우 트래픽 양을 기준으로 확장.
   • 예: EC2 한 대당 초당 500MB 이상의 네트워크 트래픽이 발생하면 확장
4. Custom Metrics (사용자 정의 메트릭)
   • CloudWatch를 통해 애플리케이션 맞춤형 지표를 추가하고 이를 기준으로 확장 가능.
   • 예: 웹사이트의 활성 사용자 수, DB 쿼리 응답 시간, 메시지 대기열(SQS) 길이 등을 기준으로 확장.

Auto Scaling Cooldown (확장 안정화)

• 새로운 인스턴스가 추가된 후 일정 시간 동안 추가 확장을 방지하는 기능
• 기본값은 300초(5분)이며, AMI 최적화로 부팅 시간을 단축하면 대기 시간도 줄일 수 있음

1. EBS (Elastic Block Store) - 네트워크 연결 스토리지

✅ EBS란?

EBS는 EC2 인스턴스에 네트워크를 통해 연결되는 저장 장치이다.
즉, EC2 인스턴스가 실행 중일 때, 하드디스크처럼 사용할 수 있는 AWS의 클라우드 기반 스토리지라고 보면 된다.

✅ EBS의 특징

• EC2와 독립적인 네트워크 저장소 → 인스턴스를 중지하거나 종료해도 데이터가 유지된다.
• AZ(가용 영역, Availability Zone) 종속적 → 한 AZ에서 생성한 EBS는 다른 AZ에서 사용할 수 없다.
• 하나의 EBS는 한 개의 인스턴스에만 연결 가능 → 다중 인스턴스 공유 불가 (다만 io1/io2 볼륨의 경우 멀티-어태치 기능을 제공).

✅ EBS의 활용 사례

• OS 및 애플리케이션 설치 공간
• 데이터베이스 저장소 (MySQL, PostgreSQL, Oracle 등)
• 지속적인 데이터 보관이 필요한 서비스

✅ EBS 삭제 정책

• 기본적으로 EC2 인스턴스를 삭제하면 루트 볼륨(EBS)도 삭제됨.
• 추가로 연결한 EBS는 삭제되지 않음(설정 변경 가능).

✅ EBS 스냅샷 (백업)

• 특정 시점의 데이터를 스냅샷(Snapshot) 형태로 백업 가능.
• 스냅샷을 활용하면 AZ나 리전 간 이동 가능 → 다른 리전에 복사하여 DR(재해 복구) 환경 구축 가능.

✅ EBS를 선택해야 하는 경우

• EC2에 일반적인 데이터 저장 공간이 필요할 때
• 인스턴스를 재시작해도 데이터가 유지되어야 할 때
• 데이터베이스 저장 공간이 필요할 때 (MySQL, PostgreSQL 등)

2. Instance Store - 로컬 디스크

✅ Instance Store란?

Instance Store는 EC2 인스턴스 내부에 직접 연결된 하드디스크 같은 저장소이다.
EBS와의 차이점은?

• 네트워크 스토리지(EBS)와 달리, 로컬 디스크이므로 속도가 매우 빠름.
• 하지만 인스턴스를 중지하거나 종료하면 데이터가 사라짐(휘발성).
• EC2가 새롭게 시작되면, Instance Store에 있던 데이터는 초기화됨.

✅ Instance Store의 특징

• 고속 데이터 처리 가능 (IOPS 성능 우수)
• EBS보다 지연시간이 짧고 성능이 뛰어남
• 데이터 유실 가능성이 있음 → 지속적인 저장이 필요한 데이터에는 적합하지 않음.

✅ Instance Store의 활용 사례

• 임시 파일 저장소 (캐시, 로그, 세션 데이터)
• 데이터베이스의 임시 저장 공간 (예: Redis, Memcached)
• 비디오 렌더링, 머신러닝 학습 데이터 저장

✅ Instance Store를 선택해야 하는 경우

• 고속 데이터 처리가 필요한 경우 (로깅, 캐시, 일시적인 데이터 저장)
• 데이터가 사라져도 상관없는 경우 (예: 웹서버의 캐시, 비디오 렌더링)

3.AMI (Amazon Machine Image)- EC2 인스턴스 템플릿

✅ AMI (Amazon Machine Image)란?

AMI(Amazon Machine Image)는 **EC2 인스턴스를 생성할 때 사용할 수 있는 "미리 구성된 템플릿"이다.
즉, 운영체제(OS), 애플리케이션, 설정 등을 포함한 EC2의 복제본으로, 동일한 환경을 여러 개의 인스턴스로 빠르게 배포할 수 있다.

✅ AMI의 특징

• EC2 인스턴스를 쉽게 복제 가능 → 동일한 설정을 가진 인스턴스를 여러 개 배포 가능.
• 운영체제(OS), 애플리케이션, 설정 포함 → 미리 패키징된 환경으로 빠른 배포 가능.
• 부팅 및 구성 시간 단축 → 소프트웨어가 사전 설치되어 있어 즉시 실행 가능.
• 리전에 종속됨 → 특정 리전에서 만든 AMI는 다른 리전에서 바로 사용 불가 (하지만 복사 가능).

✅ AMI의 유형

✅ AMI 생성 및 사용 프로세스

1. EC2 인스턴스를 실행하고 환경을 커스터마이징
   • 운영체제(OS) 설정
   • 애플리케이션 설치
   • 보안 및 네트워크 설정
2. EC2 인스턴스를 중지 (데이터 무결성 유지)
   • 실행 중인 상태에서 스냅샷을 찍으면 데이터 손상 가능성이 있으므로 중지한 후 진행.
3. AMI 생성 (EBS 스냅샷 포함)
   • AMI를 생성하면 루트 볼륨을 포함한 모든 데이터가 이미지로 저장됨.
4. 다른 인스턴스에서 해당 AMI를 사용하여 새로운 EC2 인스턴스 실행
   • 동일한 설정을 가진 여러 개의 인스턴스를 빠르게 배포 가능.

     

4. EFS (Elastic File System) - 공유 파일 시스템

✅ EFS란?

EFS는 여러 개의 EC2 인스턴스에서 동시에 접근할 수 있는 네트워크 파일 시스템(NFS)이다.
즉, 여러 서버가 하나의 파일 시스템을 공유할 수 있게 해준다.

✅ EFS의 특징

• 멀티 AZ 지원 → 한 리전 내 여러 가용 영역(AZ)에서 동시에 접근 가능.
• 자동 확장 → 저장 용량을 직접 설정할 필요 없이, 데이터 증가에 따라 자동 확장됨.
• POSIX 호환 (리눅스 지원) → 리눅스 기반의 파일 시스템을 사용.
• 비용이 EBS보다 비쌈 → 하지만, Infrequent Access(EFS-IA) 같은 티어를 사용하면 비용 절감 가능.

✅ EFS의 활용 사례

• 웹 서버의 정적 파일 저장소 (예: Wordpress, Drupal, Joomla)
• 다수의 서버에서 공유해야 하는 파일 시스템 (예: 개발 환경, 빅데이터 분석)
• 머신러닝 모델 및 로그 파일 저장

✅ EFS 성능 모드

• General Purpose(일반적인 웹/애플리케이션 서버용)
• Max I/O(빅데이터, 고성능 병렬 처리 작업용)

✅ EFS 저장소 티어

• Standard (기본값) → 자주 접근하는 데이터 저장
• Infrequent Access (EFS-IA) → 가끔 접근하는 데이터 (비용 절감)
• Archive → 거의 사용하지 않는 데이터 (저장 비용 50% 절감 가능)

✅ EFS를 선택해야 하는 경우

• 여러 개의 EC2 인스턴스가 동일한 데이터에 접근해야 할 때
• 웹 서버(Wordpress, Django, Flask 등)에서 공유 파일을 저장해야 할 때
• 데이터를 자동으로 확장하고 싶을 때

5. EBS vs EFS 비교 정리