• 네트워크 공격: 스니핑, 스푸핑, 세션 하이재킹
• 서비스 거부 공격: Dos, DDos, Drdos
• 네트워크 스캐닝 공격: TCP Scan, UDP Scan

DoS

• Dos(Denial of Service) 정의
  • 대상 시스템이 정상적인 서비스를 할 수 없도록 가용성을 떨어뜨리는 공격
• DDos 와의 차이점
  • Dos는 공격자가 단일 컴퓨터를 이용해 공격함
• Dos 의 목표
  • 네트워크 자원 소진: 네트워크 대역폭(BandWidth)를 소진시킴
  • 시스템 자원 소진: CPU, 메모리, 디스크 등 자원에 과도한 부하를 발생시킴 (가용 디스크 자원 고갈, 가용 메모리 자원 고갈, 가용 프로세스 자원 고갈)
  • 자원 파괴: 디스크, 데이터, 시스템을 파괴함

Dos 종류

Ping of Death

• Ping of Death 개요
  • Ping 을 이용하여 ICMP 패킷을 정상적인 크기보다 아주 크게 만들어진 패킷을 전송하면 네트워크를 통해 라우팅되어 공격 네트워크에 도달하는 동안 아주 작은 조각(Fragment)로 나뉘게 되어 공격대상 시스템은 이렇게 작게 조각화된 패킷을 모두 처리해야해서 정상적인 Ping 보다 훨씬 많은 부하가 걸리게 되고, 시스템의 성능 저하가 된다.
• Ping of Death 대응법
  • ICMP Ping에 대해 응답을 하지 않도록 설정한다. sysctl -w net.ipv4.icmp_echo_ignore_all=1

    Land Attack

• Land Attack 개요
  • 출발지와 목적지가 같은 패킷을 만들어 공격 대상이 자기 자신에게 응답하도록 해 부하를 발생시킨다.
• Land Attack 대응법
  • 침입차단시스템 또는 OS패치를 통해 출발지 주소와 목적지 주소가 동일한 패킷을 차단시킨다.

Smurf Attack

• Smurf Attack 개요

  • ICMP 프로토콜 취약점을 이용한 DoS공격 기법
  • ICMP 패킷 소스 주소를 공격 대상 호스트로 위조한 후, 해당 패킷을 브로드캐스트 하면 근처의 호스트가 다량의 Echo Reply 를 공격 대상 호스트로 보낸다.
  • ICMP Echo Request & ICMP Echo Reply

• Smurf Attack 대응법

  • 라우터에서 다른 네트워크에서 자신의 네트워크로 들어오는 IP브로드캐스트 패킷을 차단한다. (라우터에서 Direct Broadcast를 Disable시킨다.)
  • 호스트는 IP브로드캐스트로 전송된 ICMP패킷에 대해 응답하지 않게 설정한다. (유닉스) ndd -set /dev/ip ip_forward_directed_broadcasts 0 (리눅스) sysctl -w net.ipv4.icmp_echo_ignore_broadcast=1

Teardrop Attack

• Teardrop Attack 개요

  • 하나의 IP 패킷이 분할된 IP 단편의 offset 값을 서로 중첩되도록 조작하여 이를 재조합하는 공격 (Bonk, Boink와 유사)
  • Bonk는 순서번호가 1인 단편을 계속 보냄
  • Boink는 처음에는 정상적인 순서의 단편을 보내다가 점점 어긋난 순서번호의 패킷을 보냄(Bonk 개선된 버전)
  • Fragmentation 의 취약점을 이용함, 이러한 공격을 Inconsistent Fragmentation 공격 이라함

• IP Fragmentation

  • 패킷의 크기가 MTU(Maximum Transmission Unit)을 초과하면 한번에 전송할 수 없다.
  • 이 때문에 패킷을 MTU 이하의 작은 조각으로 분할하는 것을 단편화(Fragmentation), 분할된 조각을 단편(Fragment)라고 한다.
  • 4000바이트의 패킷을 전송하려고 하는데 MTU가 1500인 경우 예시는 아래와 같다.

tcpdump상의 datagram id:size@offset[+] ex) 41421:4000@8000+

DDoS

DDos(Denial of Service) 정의

• 대상 시스템이 정상적인 서비스를 할 수 없도록 가용성을 떨어뜨리는 공격

DDos-대역폭 소진 공격

UDP Flooding

• DNS 증폭 공격
  • DNS Amplification DDoS Attack
  • DNS를 이용한 UDP Flooding 서비스 거부 공격
  • DNS 질의는 DNS 질의량에 비하여 DNS 서버의 응답량이 훨씬 크다는 점을 이용
  • DNS 프로토콜에는 인증 절차가 없다는 점을 이용
  • DNS Query 타입을 'ANY'로 전송 → 정상패킷보다 크게 증폭됨
  • 요청 주소를 희생자의 주소로 위조하여 다량의 서버에 보내는 방법으로 공격
  • access-list 1 deny udp any any eq 53
• NTP 증폭 공격
  • NTP(123/udp)를 이용한 UDP Flooding 서비스 거부 공격
  • 해당 ntp 서버에 최근 ntp질의에 응답을 했던 목록을 보여주는 monlist 기능을 이용
  • monlist를 요청 할 경우 600개의 응답이 보여지며 약 4,000 byte 이상의 응답 패킷을 생성함
  • 요청 주소를 희생자의 주소로 위조하여 다량의 서버에 보내는 방법으로 공격

    NTP(Network Time Protocol): 시간을 동기화하여 정확하게 유지하는데 사용되는 프로토콜

    ICMP Flooding

    DNS Query Flooding

• DNS Query Flooding 개요
  • UDP 프로토콜 기반 서비스를 제공하는 DNS에 DNS 쿼리 데이터를 다량으로 서버에 전송하여 DNS의 정상적인 서비스를 방해하는 공격
• DNS Query Flooding 대응법
  • access-list 1 deny udp any any eq 53

    TCP SYN Flooding

• TCP SYN Flooding 개요
  • TCP의 3-Way-Handshake 취약점을 이용한 DoS공격
  • 다량의 SYN 패킷을 보내 백로그큐(Backlog Queue)를 가득 채우는 방법

    백로그큐 : 3-Way-Handshake를 위해 연결이 진행중인 요청을 담아두는 큐, 큐가 가득차면 다른 연결을 받아들일 수 없음

  • 다수의 클라이언트가 고의로 SYN만 보내고 아무런 동작을 하지 않는다면 SYN Backlog Queue는 가득참 → 더 이상 연결요청을 못 받음
• TCP SYN Flooding 대응법
  • TCP Connection Timeout 시간을 짧게 설정함 (너무 짧으면 정상적인 요청도 느리다는 이유로 연결이 거부될 수 있음)
  • 백로그 큐를 늘림 리눅스: sysctl -w net.ipv4.tcp_max_syn_backlog = 1024 유닉스: ndd -set /dev/tcp tcp_conn_req_max_q1 1024
  • 방화벽 설정: 의심 패킷에 대한 차단 정책을 추가 1초에 10회 발생시 차단: iptables -A INPUT -p TCP --dport 80 --syn -m limit --limit 10/second -j Drop
  • 라우터 설정
• 인터셉트 모드*: syn 패킷을 요청한 클라이언트와 방화벽에서 먼저 연결을 맺고 정상적이면 서버로 보냄
• 와치 모드*: syn 패킷을 통과시키고 일정시간 연결이 안되면 라우터에서 차단함
  • SYN COOKIE Syn Flooding 공격을 방지하기 위한 방어 기술 클라이언트에서 연결요청이 있을 경우 SYN/ACK 패킷에 특별한 쿠키값을 담아 보내고, ACK가 올 경우 쿠키값을하여 제대로 된 경우 연결을 형성한다. 연결 정보를 Cookie을 통해 보냄으로써 SYN Backlog Queue 를 사용하지 않는다. 연결 요청이 많을 경우 쿠기 값 생성/전송 과정만으로도 가용성이 떨어질 수 있다. # sysctl -w net.ipv4.tcp_syncookies=1

DDos-서비스 마비 공격

HTTP GET Flooding

• HTTP GET Flooding 개요
  • 동일한 HTTP GET 요청을 다량으로 발생시켜 서버가 요청을 처리하도록 하는 공격
  • 서버 자원을 과도하게 사용하도록 하여 정상적인 요청을 처리하지 못하도록 함
• HTTP GET Flooding 대응법
  • 임계치를 설정하고 비정상적 트래픽을 유발하는 IP를 방화벽 차단 목록으로 등록
  • 콘텐츠 요청 횟수에 대한 임계치 설정

CC Attack

• CC Attack 개요
  • HTTP GET Flooding with Cache Control
  • HTTP 캐시 옵션을 조작해 캐싱 서버가 아닌 웹서버가 직접 처리하도록 유도 → 웹 서버 자원 소진
  • Cache-Control 값이 no-store(캐시저장금지), must-revalidate(웹서버가 캐싱 서버에 저장된 캐시 데이터에 대한 검증 요구) 로 설정되어있으면 공격으로 판단
• CC Attack 대응법
  • HTTP Get Flooding 과 마찬가지로 일반적인 방어 기법인 임계치 기반의 DDoS 공격 방어가 효과적임. 즉, TCP 세션 요청과 HTTP 요청에 대한 임계치 기법으로 방어가 가능
  • HTTP Cache-Control 헤더 옵션 별 임계치 정책으로 방어해야지만 큰 효과를 얻을 수 있음 (방화벽에 캐싱공격 문자열을 포함하는 IP 차단)

Slow HTTP POST Dos

• Slow HTTP POST Dos 개요

  • R-U-Dead-Yet(RUDY) 라고도 부름
  • POST 메소드로 Content-Length 필드에 임의의 큰 값을 설정하여 전송함
  • 웹 서버가 클라이언트에서 해당 크기의 메시지를 전송할때까지 커넥션을 유지함
  • 대량의 데이터를 장시간에 걸쳐 분할 전송하여 연결을 장시간 유지함 → 웹서버 가용량을 소진하게함 → 다른 클라이언트들의 정상적인 서비스 요청을 처리하지 못함

• Slow HTTP POST Dos 대응법

  • 각 POST 폼에 메시지 크기를 제한함
  • 항시 TCP 상태를 모니터링하여, 평상시보다 Established 및 Time Wait 값이 많은지 확인함
  • 연결 타임아웃(Connection Timeout) 설정 : 클라이언트와 서버간 일정 연경 유지시간 초과시 자동 연결 종료
  • 읽기 타임아웃(Read Timeout) 설정 : 지정한 시간내에 body 정보가 모두 수신되지 않으면 오류코드 반환
  • 서버 방화벽 설정 : iptables와 같은 방화벽을 통해 동일한 소스 IP에서 동시 연결가능한 개수의 임계치를 설정하여 초과 시 차단

Slow HTTP Header Dos

• Slow HTTP Header Dos 개요

  • Slowloris 공격이라고도 부름
  • HTTP Header 정보를 비정상적으로 조작하여 웹서버가 온전한 Header정보가 올때 까지 기다리도록 한다. → 서버가 연결 상태를 유지할 수 있는 가용자원은 한계가 있으므로 임계치를 넘어가면 다른 정상적인 접근을 거부하게 된다.
  • HTTP에선 헤더의 끝을 /r/n 이라는 개행문자로 구분
  • 공격자는 이 마지막 개행문자를 보내지 않고 지속적으로 의미없는 변수를 추가한다.
  • 클라이언트가 PSH ACK 패킷으로 Keep alive 패킷을 지속적으로 보낸다
  • Header와 Body를 구분하는 문자가 0d0a0d0a 가 아닌 0d0a 에서 끝났다는 것은 아직 전송할 헤더가 남았음을 의미한다.
  • 공격자는 이렇게 연결을 유지하여 가용자원을 소진되게 만든다.

• Slow HTTP POST Dos 대응법

  • 공격자가 동시에 많은 세션을 유지하므로 방화벽 등을 통하여 세션 임계치 제한을 설정한다.
  • 공격자가 헤더를 천천히 전달하며 연결 시간을 지속시키므로 연결 타임아웃 시간을 적절히 짧게 두어 의심되는 연결이 종료되도록 한다

Slow HTTP Read DoS

• 정상트래픽 이라면 Window Size가 가변적이지만 공격 트래픽은 Window Size가 "0"으로 고정
• 매우 작은 윈도우크기로 서버에 응답을 보내면 서버는 더 이상 데이터를 전송하지 못하고 연결만 유지한 상태로 대기

Hash DoS

• Hash DoS 개요
  • 다량의 POST 파라미터('&'이용)를 보내서 Hash Table의 충돌을 유도하여 부하를 증가시킨다.
  • 해시 테이블에서 해시 충돌이 발생하여 해시 테이블에 접근하는 시간이 증가한다.
• Hash DoS 대응법
  • HTTP POST 파라미터 제한: 특정 발신지에서 IP로 연결할 수 있는 최대값 설정
  • POST 메시지 크기 제한

Hulk DoS

• Hulk DoS 개요
  • GET Flooding 공격 유형
  • http get 요청을 다량으로 하면서 접속대상주소를 지속적으로 변경하면서 공격
  • 파라미터를 계속 변경하면서 보냄 (DDos 차단 정책 우회)
  • 임계치 설정 기반 방어가 불가능 (임계치는 고정된 URL에서만 설정 가능함)
• Hulk DoS 대응법
  • 접속 임계치 설정
  • HTTP Request HOST 임계치 설정 (URL이 아닌 HTTP Request에 포함된 HOST 필드값을 카운트해 임계치 설정)

DRDos

• Distributed Reflection Denial of Service
• 취약점이 있는 외부의 정상적인 서버들을 이용하여 공격을 수행하는 분산 서비스 거부 공격
• IP Spoofing의 적극적인 사용 → 추적 방지
• 반사체(Reflector)의 사용 → 공격량의 증대(공격력 강화)

기출문제

1. 다음은 HTTP Request 메시지를 패킷 분석 도구로 캡쳐한 결과 중 일부이다. 각 물음에 답하시오. 1.1) 어떤 공격을 당하고 있는 것으로 추정할 수 있는가? 1.2) 이 공격의 원리는 무엇인가? 1.3) 대응방법을 2가지 이상 쓰시오. https://q.fran.kr/%EB%AC%B8%EC%A0%9C/19665

2. NTP DDos 에 대한 아래 보안 권고안의 의미를 설명하시오. 2.1) ntp -version 2.2) disable monlist 2.3) ntpdc-c monlist "점검 대상 NTP 서버 IP" 2.4) iptables -A OUT -p udp --sport 123 -m length --length 100 -j Drop https://information-security.tistory.com/269

https://ensxoddl.tistory.com/254 https://jeongchul.tistory.com/312 https://itwiki.kr/w/%EC%84%9C%EB%B9%84%EC%8A%A4_%EA%B1%B0%EB%B6%80_%EA%B3%B5%EA%B2%A9 https://itwiki.kr/w/IP_%EB%8B%A8%ED%8E%B8%ED%99%94 https://jjuromi.tistory.com/entry/%EC%9A%A9%EC%96%B4-%EB%B9%88%EC%B9%B8%EB%AC%B8%EC%A0%9C-%EC%A0%95%EB%B3%B4%EB%B3%B4%EC%95%88%EA%B8%B0%EC%82%AC-%EC%8B%A4%EA%B8%B0-%EB%8C%80%EB%B9%84-v6 https://repository.kisti.re.kr/bitstream/10580/6252/1/2015-083%20DDoS%20%EA%B3%B5%EA%B2%A9%20%EC%9C%A0%ED%98%95%EB%B3%84%20%EB%B6%84%EC%84%9D%EB%B3%B4%EA%B3%A0%EC%84%9C.pdf https://darksoulstory.tistory.com/326 https://skogkatt.tistory.com/138 https://itwiki.kr/w/DRDoS https://information-security.tistory.com/269

• Apache HTTP Server는 오픈 소스 소프트웨어 그룹인 아파치 소프트웨어 재단에서 만드는 웹 서버 프로그램

Apache 보안 설정

• 서버 실행 계정 확인: root 말고 apache라는 별도의 계정을 권한으로 만들어 아파치 웹 프로세스에 대한 권한으로 할당한다.
• ** Apache 설정파일 수정(httpd.conf)**: Timeout, MaxClient, Port, User, MaxSpareServer 등 설정 파일을 수정한다 (/etc/httpd/conf/httpd.conf)

httpd.conf

• 리눅스 아파치 웹서버의 메인 설정파일

• 위치 : /etc/conf/httpd/httpd.conf

• httpd.conf 세션 설정

  • TimeOut : 클라이언트의 요청에 서버가 대기하는 시간
  • KeepAlive (on/off) : on 으로 설정하면 클라이언트와 서버간의 tcp 연결을 keepalivetimeout 동안 유지하게 된다. 즉, 한 번의 연결에 대해 한 번의 요청만 처리하는 것이 아니라 또 다른 요청을 기다리게 된다. (일반적으로 on이 좋다), 한번 맺은 세션을 요청이 끝나더라도 유지해주는 기능
  • KeepAliveTimeout : KeepAlive 옵션이 on 이라면 클라이언트 최초 요청을 받은 뒤에 다음 요청이 전송될때까지 대기하는 시간(s)
  • MaxKeepAliveRequests : KeepAlive 옵션이 on 이라면 허용할 최대 요청 수를 정의함. 이 옵션을 0으로 설정하면 무한대의 요청을 허용함 (성능은 좋아짐), KeepAlive 를 허용하는 유저 수.
  • MaxClients : 아파치 서버 동시 접속자 수 (최대: 256)
  • DirectoryIndex : 웹 디렉토리 접근 시 인식되는 인덱스 파일의 순서 지정
  • Listen : 사용할 포트 지정
  • CustomLog : 엑세스 로그 파일 위치 지정
  • ErrorLog : 에러 로그 파일 위치 지정
  • Port : 아파치가 사용할 기본 포트 (일반적으로 80)
  • User : 보안상 절대 root 로 설정하지 말자

• httpd.conf 접근제어

  • Order Deny, Allow: Deny와 Allow 순서를 정한다.
  • Deny from All : 모든 트래픽을 막는다.
  • FollowSymLinks : 심볼릭 링크를 허용한다.
  • LimitRequestBody : 파일 업로드, 다운로드 시 파일크기를 제한한다.
  • Indexes : 웹 서버의 디렉토리에 접근 했을 때 DirectoryIndex 지시자로 설정한 파일이 없을 경우 디렉토리안의 파일목록을 보여준다. → '디렉토리 리스팅'이 가능하므로 해당 값을 삭제하는게 안전하다.
  • AllowOverride: 클라이언트의 디렉토리 접근 제어에 관한 설정, 어떻게 접근을 허락할 것인가? (None, ALL, AuthConfig, FileInfo...) → 'None' 이면 값을 'AuthConfig'로 변경해서 상위 디렉토리 접근을 금지할 수 있다.

- 시스템 루트( / ) 디렉토리에 대한 제어
<Directory />
Order Deny, Allow
Deny from All
LimitRequestBody 5000000
Options FollwSymLinks
AllowOverride None
</Directory>

- /usr/local/apache/htdocs 디렉토리에 대한 제어
<Directory  "/usr/local/apache/htdocs"/>
Order Deny, Allow
Deny from All
Allow from 127.0.0.1
LimitRequestBody 5000000
Options Indexes FollowSymLinks
AllowOverride AuthConfig
</Directory>

• IIS 용 : WebKnight (국내 인터넷진흥원이 권고하는 무료 웹 방화벽)
• 아파치 용: ModSecurity (국내 인터넷진흥원이 권고하는 무료 웹 방화벽), 아래와 같이 httpd.conf 파일에 적용 가능함

  <IfModule mode_security.c>
  정책내용
  </IfModule>

.htaccess

• .htaccess 파일을 사용하여 디렉토리별로 설정을 변경할 수 있다.

기출문제

1. htaccess 파일 설정의 의미에 대하여 답하시오. *1.1) *

<FileMatch "\.(ph|lib|sh|)">
Order Allow DENY
Deny From ALL
</FilesMatch>

1.2) ** AddType text/html .php .php1 .php2 .php3 .php4 .phtml **1.1 답) .ph, .lib, .sh 등의 서버 사이드 스크립트 파일에 대해 직접 URL 호출 금지 (업로드된 스크립트의 실행을 방지하기 위해) 1.2 답) 서버스크립트 확장자를 text/html MIME Type으로 재조정하여 업로드된 스크립트 실행 방지

https://q.fran.kr/%EB%AC%B8%EC%A0%9C/10005 https://q.fran.kr/%EB%AC%B8%EC%A0%9C/9721 https://q.fran.kr/%EB%AC%B8%EC%A0%9C/14779 https://q.fran.kr/%EB%AC%B8%EC%A0%9C/9998

참고사이트 https://namu.wiki/w/%EC%95%84%ED%8C%8C%EC%B9%98%20HTTP%20%EC%84%9C%EB%B2%84 https://zidarn87.tistory.com/364 https://peemangit.tistory.com/308 https://mosei.tistory.com/entry/apache-httpdconf-%EC%84%A4%EC%A0%95-%EB%B0%8F-%EC%84%A4%EB%AA%85 https://developer.mozilla.org/ko/docs/Web/HTTP/Connection_management_in_HTTP_1.x https://dukkoong.tistory.com/18 (13회 기출문제)

• 외부의 불법침입으로부터 내부의 정보자산을 보호하기 위한 정책/하드웨어/소프트웨어의 집합
• 컴퓨터의 정보보안을 위해 정보통신망 외부→내부, 내부→외부로의 불법 접근을 차단하는 시스템
• Access Control List(ACL)를 이용해 네트워크에 전송되는 트래픽에 대한 보안 정책을 설정함
• 주요기능: 접근제어, 사용자 인증, 감사/로깅, 프록시, 주소변환(NAT), 데이터 암호화 등

NAT(Network Address Translation): 사설 주소와 범용 주소를 매핑 시켜서 가상 사설 네트워크를 지원하는 기술, 외부 네트워크에서 내부 IP 주소를 숨김 Static NAT: [내부 IP 주소:외부 IP 주소] 1:1 맵핑 Dynamic Nat: [내부 IP 주소:외부 IP 주소] N:M 맵핑 PAT(Port Addres Translantion): 하나의 외부 IP 주소를 다수의 내부 IP 주소가 port 번호로 구분하여 사용함 Policy NAT: ACL을 이용, 출발지와 목적지에 따라 주소를 변환함

방화벽의 종류

1. 패킷 필터링 방화벽(Packet Filtering Firewall)

• 1세대 방화벽
• 동작구간: OSI Layer3(네트워크계층), 4(전송계층)
• 내우방/외부망 사이에 존재하여 특정 트래픽을 허용/차단하는 단순한 형태의 방화벽
• 패킷 헤더정보 조사: 발신지 주소와 포트를 검사하여 수신측 주소와 포트에 대한 접속 여부 결정
• 낮은 레이어에서 동작하기 때문에 비교적 속도가 빠르고, 기존 애플리케이션과 연동이 용이함
• 하드웨어에 의존적이지 않으나 강력한 로깅 기능/사용자 인증을 기대하기 어려움
• 연결 상태 추적을 하지 않음
• 패킷 필터링을 사용하는 라우터: 스크리닝 라우터/패킷 필터링 라우터

  라우터를 이용한 네트워크 보안 설정

• Ingress 필터링*: 라우터 외부에서 내부로 유입되는 패킷을 필터링, 인터넷 상에서 사용되지 않는 IP 대역은 공통적으로 필터링 해야함(출발지 IP 주소 유효성 검사)
• Egress 필터링*: 라우터 내부에서 외부로 나가는 패킷의 소스 ip를 체크하여 필터링, 라우터를 통과해 나가는 패킷 소스 ip는 반드시 라우터와 같은 대역이여야함
• Blackhole 필터링*: Null 라우팅, 특정한 ip대역에 대해서 Null이라는 가상의 쓰레기 인터페이스로 보냄
• Unicast RPF(Reverse Path Forwarding)*: 인터페이스를 통해 들어오는 패킷의 소스 ip 에 대해 라우팅 테이블을 확인하여 들어온 인터페이스로 다시 나가는지 확인 (패킷 출발지 ip 주소가 위변조 되었는지 확인함)

2. 프록시 방화벽 (Proxy Firewall)

• 2세대 방화벽
• 동작구간: OSI Layer7(어플리케이션계층)
• 클라이언트와 외부 네트워크와의 중개인의 역할을 하며 이상이 없는 패킷을 목적지로 전달
• 패킷 필터링보다 더 높은 수준의 보호 능력 제공
• 패킷 정보를 Application 계층까지 조사

3. 응용 게이트웨이 방식 (Application Gateway)

• 동작구간: OSI Layer7(어플리케이션계층)
• 외부망과 내부망의 완벽한 구분
• 내부의 IP 주소를 숨기는 것이 가능
• 데이터 부분 제어에 따른 높은 로깅 및 감사 기능

4. 서킷 게이트웨이 방식 (Circuit Gateway)

• 동작구간: OSI Layer5(세션계층) ~ 7(어플리케이션계층)
• 공용 Proxy 존재 (서비스별로 존재X)

5. 상태 기반 조사 방식 (Stateful Inspection)

• 3세대 방화벽
• 패킷 필터링 + Apllication Gateway
• 패킷으로부터 받은 전송상태, 연결상태, 다른 application 들과의 관계 검사
• 네트워크 계층에서 패킷을 처리하면서 프로토콜의 상태정보 테이블을 유지하여, 프로토콜의 특성에 따른 변화를 동적으로 대응함 (예로, 내부 사용자가 인터넷으로 ping request를 하면 이에 들어오는 ping reply는 허용하지만 인터넷으로부터 내부자의 request가 존재하지 않은 상태에서 불법적인 ping reply는 허용하지 않음)
• 연결의 시작부터 끝까지의 모든 활동을 모니터링 하여 관리자가 정한 규칙을 기반으로 필터링함
• 모든 통신 레이어에서 부석하므로 모든 채널에 대해서 추적 가능
• UDP, RPC 패킷도 추적 가능

방화벽의 구성방식

1. 스크리닝 라우터 (Screening Router)

• 망과 망 사이에 라우터를 설치하고 라우터에 ACL을 구성함
• 응용 프로그램 환경변화에 무관하게 동작하므로 투명한 구성이 가능
• 라우터에 부하를 줌
• 주로 방화벽 설치가 힘든 중소기업들이 많이 사용함

2. 베스천 호스트 (Bastion Host) / 싱글 홈드 게이트웨이 (Single Homed Gateway)

• OSI Layer 7에서 동작
• 방어 기능을 가진 호스트 시스템
• 인증기능/모니터링/로깅 등 기능 제공
• 베스천 호스트가 공격당하면 내부 네트워크 자원 보호 불가능

3. 듀얼 홈드 게이트웨이 (Dual Homed Gateway)

• 두 개의 네트워크 인터페이스를 가진 베스천 호스트를 이용해 구성
• 논리적으로만 구분하는 베스천 호스트와 달리 물리적으로도 구분이 되어 훨씬 안전함

4. 스크린드 호스트 게이트웨이 (Screened Host Gateway)

• 스크리닝 라우터 + 베스천호스트
• Layer 3, 4에서 스크리닝 라우터 1차 필터링
• Layer 7에서 베스천 호스트가 방어

5. 스크린드 서브넷 게이트웨이 (Screened Subnet Gateway)

• 스크리닝 라우터 2개 사이에 하나의 서브넷(망)을 구성함: DMZ
• 스크리닝 라우터 -> 베스천 호스트 서브넷 -> 스크리닝 라우터 -> 내부망
• 가장 안전하고 비싸며 느리다.

DMZ: 외부에서 서비스 제공 시 내부 자원을 보호하기 위한 네트워크 구간과 외부 네트워크 구간 사이에서 접근 제한을 수행하는 영역, 내부 네트워크 노출을 막기 위해 구성함

기출문제

1. 패킷 필터링 방화벽과 관련하여 다음 물음에 답하시오. (출처 참고)

1) 존재하지 않는 외부 IP를 이용한 Spoofing 공격에 대응하기 위한 패킷필터링 방화벽 기술의 이름과 원리 2) 공격자가 패킷을 소형 단편화하여 tiny fragment 공격을 수행하는 이유 3) Tiny fragment 공격 대응 방법 4) stateful 패킷필터링과 일반 패킷 필터링 방화벽의 차이점

2. 다음의 (A), (B)에 대해서 각각 기술하시오. (출처 참고) (A) : Standard 또는 Extended Access-List를 활용하여 라우터 내부로 즉, 사내 네트워크로 유입되는 패킷의 소스 IP주소를 체크하여 허용 또는 거부하도록 하는 것이다. (B) : 내부에서 라우터 외부로 나가는 패킷의 소스IP주소를 체크하여 허용 또는 거부하도록 하는 것이다.

3. 사이트 보안 담당자는 신규 도입된 보안장비(방화벽, IPS, IDS, VPN 등)에 대해 취약점 분석 평가를 실시하고자 한다. 보안장비의 계정관리 측면에서 조치해야할 사항 4가지는?

1) 관리자 계정 - 보안장비에 기본적으로 설정되어 있는 관리자 계정 변경 2) 관리자 계정의 패스워드 - 보안장비에 기본적으로 설정되어 있는 관리자 계정의 패스워드를 변경함 3) 계정별 권한 설정 - 보안장비에 등록된 계정별 권한을 설정 4) 계정 관리 - 보안장비에 등록되어 있는 계정 중 사용하지 않는 계정을 제거 또는 관리

https://itwiki.kr/w/%EB%B0%A9%ED%99%94%EB%B2%BD https://m.blog.naver.com/dang0616/220609594698 http://itnovice1.blogspot.com/2019/09/blog-post_46.html https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=wnrjsxo&logNo=221066364387 https://blog.naver.com/PostView.naver?blogId=stereok2&logNo=222587717690&parentCategoryNo=&categoryNo=28&viewDate=&isShowPopularPosts=true&from=search (기출1번) https://tistorysolution.tistory.com/194 (기출2번) https://information-security.tistory.com/269 (기출3번)

스노트 개요

• 네트워크상의 실시간 트래픽 분석 및 패킷 로깅을 수행할 수 있는 오픈소스 네트워크 침입 탐지 시스템(IDS)
• 1998년 SourceFire사의 CTO Martin Roesch에 의해 발표됨
• 침입탐지시스템(IDS) 중 가장 널리 사용됨
• 윈도우, 리눅스 버전이 있음

스노트 기능

• 패킷 스니퍼(Packet Sniffer) : 네트워크 상의 패킷 스니핑
• 패킷 로거(Packet Logger) : 모니터링한 패킷을 저장하고 로그에 남기는 기능
• 네트워크 침입탐지(IDS/IPS) : 네트워크 트랙픽 분석 후 침입탐지

스노트 룰

룰 헤더부분과 룰 옵션으로 구성된다.

1. 룰 헤더

2. 룰 바디

• 패킷 탐지 사용자 설정
• 세미콜론(;)을 이용하여 옵션과 옵션을 구분

  2.1. 일반옵션 설정

• msg : alert 발생 시 이벤트 명
• sid : 스노트 룰 ID

  99이하 : 시스템 예약 ID
  100 ~ 1000000 이하 : snort 자체지정 sid
  1000001 이상 : 사용자 정의 sid

• rev : 룰 수정횟수 수정 시 숫자가 증가

  2.2. 페이로드 범위 설정

• dsize : dzise:<바이트, dsize:바이트<>바이트 와 같이 상한선, 하한선, 범위를 지정할 수 있다.
• content : 문자, 바이너리로 패턴을 탐지한다.
  • content: "문자"
  • content: | 00 01 0A AA |
  • content: "| 90 90 90 | /bin/sh"
• offset : 검색을 시작할 byte수를 지정한다.
• depth : offset부터 시작하여 검색할 byte수를 지정한다.
• nocase : 대소문 자를 구별하지 않는다.
• flags : TCP 제어 플래그를 지정한다. F, S, FA, FSA 등으로 지정 가능하다.
• pcre : 정규식을 사용한다.
• threshold : 패킷의 발생량을 기반으로 탐지한다. 아직까지 흔히 사용 되고 있지만 공식적으론 사용을 권장하지 않는다. 비슷한 기능을 하진 detection_filter 사용이 권장된다.
  • type limit(로그발생기준: 임계값), threshold(로그발생기준: 패킷량), both(로그발생기준: IP)
  • track by_src , by_dst
  • count n : number events used by the thresholding
  • seconds m : time period over which count is accrued.

스노트 예제

1. 비정상적인 SSH 로그인 시도 탐지 시나리오 (Brute Force Attack : 30초안에 5번 로그인 시도 공격 탐지) alert tcp any any -> any 22 (msg:"SSH Brute Force Attack"; content:"SSH-2.0"; nocase; threshold:type both, track by_src, count 5, seconds 30; sid:1000001;)

*2. 모든 네트워크 대역에서 Telnet으로 접속하는 패킷 중 14번째 자리까지 'anonymous'가 포함된 트래픽에 대해서 'Dangerous' 메시지로 경고하는 snort rule을 만드시오. * alert tcp any any -> any 23 (msg:"Dangerous"; content:"anonymous"; depth:14; sid:1;)

3. 다음 보기를 보고 문제점과 해결방안을 제시하시오. tcp any any -> any any PCRE(/^POST.*Contentx2dLengthx2ax20evilstring) 3.1. 해당 Rule은 어떤 문제점을 가지고 있는가? Rule에는 HTTP프로토콜에 대한 정규식(POST, Content-Length가 포함)이지만 모든 포트 any로 설정되어 있어 HTTP서비스가 아닌 불필요한 트랙픽에 대해서도 감시를 수행함. 시스템에 오버헤드 유발. 3.2. 해결방안은 무엇인가? 목적지 주소와 포트를 웹서버주소, 80 포트로 설정하여 부하를 감소 tcp any any -> 웹서버IP 80

4. 다음의 snort 룰에 대한 물음에 답하시오. alter tcp any any -> 80 *msg "XSS"; ①content:"GET"; offset:1; depth:3; ②content:"/login.php?iD:<script?"; distance:1;)

4.1. content: "GET"; offset:1; depth:3; 무슨 뜻인가? 패킷 중 2번째 문자열 부터 3바이트 내에 GET 문자열 있는지 검사(=2번째 문자열부터 4번째 문자열까지 GET 문자열 패턴 검사) 4.2. content: "/login.php?iD"; distance:1; 무슨 뜻인가? 첫번째 content 패턴 검색 후 1바이트 떨어진 위치에서 "/login.php?iD" 문자열 있는지 검사 4.3. 문자열 " GET /login.Php?iD :<script? " 검색이 안된다면 어떻게 변형해야하는가? nocase 옵션을 사용, sid 추가 alter tcp any any -> 80 *msg "XSS"; content:"GET"; offset:1; depth:3; content:"/login.php?iD:<script?"; distance:1; **nocase; sid:100001;**)

5. 다음의 snort 룰에 대한 물음에 답하시오. alert tcp any any < > any ①[443,465,523] (②content:"|18 03 00|"; depth: 3; ③content:"|01|"; distance: 2; within: 1; ④content:!"|00|"; within: 1; ⑤msg: "SSLv3 Malicious Heartbleed Request V2"; sid:1;)

1. 목적지 포트는 443번, 465번, 523번 포트로 지정한다.
2. 3byte 내에 18 03 00 바이너리 값이 있는지 검사한다.
3. 첫번째 컨텐츠 2byte 떨어진 곳에서 1byte 범위 내에 01 바이너리 값이 있는지 검사한다.
4. 두번째 컨첸츠 끝난 위치에서 1byte 내에 00 바이너리 값이 없는지 검사한다.
5. alert 알림명으로 SSL~V2를 쓴다.
6. sid번호 (스노트 룰 번호)는 1로 지정한다.

6. 모든 네트워크 대역에서 Telnet으로 접속하는 패킷 중 14번째 자리까지 'anonymous'가 포함된 트래픽에 대해서 'Dangerous' 메시지로 경고한느 snort rule을 만드시오. alert tcp any any -> any 23 (msg:"Dangerous"; content:"anonymous"; depth:14; sid:1;)

7. 다음은 HTTP GET Flooding 공격에 대한 스노트 탐지이다. alert tcp any any -> any 80 (msg:'HTTP Get Flooding Detect'; content:"GET/HTTP1";( ); nocase; threshold: type threshold, track by src, count 10, seconds 1; sid:1000001) 7.1) 스노트 룰의 action 은 패킷이 탐지 되었을때의 처리 방식을 의미한다. 탐지된 패킷을 차단하고 로그를 남기는 action 2가지는? drop, reject 7.2) content를 첫번째 바이트로부터 13번째 바이트 범위안애서 검사하고자 할때 () 안에 들어갈 옵션은? depth 13 7.3) threshold 옵션은 특정 시간동안 발생하는 이벤트 수를 제한하여 과도하게 많은 이벤트가 발생하는 것을 방지하기 위한 옵션이다. 위에서 alert 이벤트 발생 수를 제한하는 기준과 방식은? 출발지를 기준으로 매 1초동안 10번째 이벤트마다 action을 수행

https://itwiki.kr/w/%EC%8A%A4%EB%85%B8%ED%8A%B8 https://goc1221.tistory.com/60 https://q.fran.kr/%EB%AC%B8%EC%A0%9C/9815

create extension postgis

• Servhe host는 localhost 혹은 원격 host ip를 입력 / '5432'는 PORT로 필요시 수정

5. SHP파일에 한국어가 포함되어 있으면 Options 에서 EUC-KR로 인코딩 변경

6. SHP파일 import

• dbf file (.dbf) can not be opened. Shapefile import failed. 에러가 발생하면 파일의 경로 중 한글이 포함되어 있는 경로가 있을 수 있음. 이 경우에는 바탕화면/C 로 파일들을 빼주자.
• SRID(공간 참조 식별자, Spatial Reference Identifier)는 필요시 설정해주자. (국토정보지리원 정밀지도의 SRID는 32652)

$ npm install jquery

2. main.js 에 아래 코드추가

import jQuery from 'jquery'
...
const app = createApp(App)
...
global.$ = jQuery

3. 여기서 global 을 정의해도 ESlint 때문에 아래와 같은 에러가 생길 수도 있다.

error '$' is not defined no-undef

• 원인 : ESlint의 'no-undef' 룰에 의해서 생기는 에러, 변수가 scope 안에 정의되어 있지 않거나 알려진 global(known global) 이 아닐 경우 에러가 생긴다.

• 해결 : eslint config에 global 옵션 추가

"eslintConfig": {
    "globals": {
        "todoEventBus": "readable"
    }
}

1) Vue-Cli 설치

$ npm install -g @vue/cli

버전 확인

$ vue --version
@vue/cli 4.5.13

2) 프로젝트 생성

frontend 는 프로젝트 이름으로 원하는 걸로 바꿔서 설치하자.

$ vue create frontend

2번째 라인의 'Default (Vue3) ([Vue 3] babel, eslint)' 선택

3) 프로젝트 실행(로컬 서버)

$ cd frontend
$ npm run serve

이제 'http://localhost:8080/'로 접속하면 생성된 Vue-Cli 페이지를 확인가능하다.

babel: 자바스크립트 컴파일러, 최신의 자바스크립트 코드를 이전단계의 자바스크립트 코드로 변환가능하게 해주는 개발 도구, 하위호환성, 트랜스파일러(Transpiler) ESLint: 자바스크립트 문법 에러 표시 도구

4) GUI 사용하기

$ vue ui

'vue ui' 커맨드를 이용해 GUI 를 통해 프로젝트 플로그인/의존성 관리가 가능하다.

• 뷰 : 로그인, 로그아웃, 회원가입, 관리자화면
• 회원의 Role에 따라 이용가능한 기능을 제한함 (페이지 접근 제어)

*** 현 포스트 목표 **

• Frontend(Vue-CLI 4.x)와 Backend(Node Express)의 생성
• Frontend, Backend 간의 통신 테스트
• [주의] Frontend, Backend 를 통합하지 않고 연동만 합니다.

* 환경설정

• Backend: Node Express
• Frontend: vue 3.0.4 vue-CLI 4.5.13 webpack 4.46.0

Backend, Frontend 폴더 위치는 상관 없습니다. 아래는 현 포스트에서 나오는 결과물의 디렉토리 구조입니다.

1. Backend(Node Express) 생성

백엔드를 생성할 폴더 생성 후, cmd에서 해당 디렉토리로 이동 후 아래 명령어 입력

$ npm install express-generator -g

$ express --view=pug backend

'backend' 부분은 express 앱 이름으로, 원하는 것으로 작성.

$ cd backend
$ npm init
$ npm start

npm init 을 입력했을때 콘솔창에서 'node ./bin/www' 가 출력되면 정상적으로 서버가 동작하고 있는것. 크롬에서 'http://localhost:3000/' 로 접속했을때 위와 같은 화면이 나오면 된다.

2. Frontend(Vue-CLI) 생성

프론트엔드를 생성할 폴더 생성 후, cmd에서 해당 디렉토리로 이동 후 아래 명령어 입력

1) Vue-Cli 설치

$ npm install -g @vue/cli

버전 확인

$ vue --version
@vue/cli 4.5.13

2) 프로젝트 생성

frontend 는 프로젝트 이름으로 원하는 걸로 바꿔서 설치하자.

$ vue create frontend

2번째 라인의 'Default (Vue3) ([Vue 3] babel, eslint)' 선택

3) 프로젝트 실행(로컬 서버)

$ cd frontend
$ npm run serve

이제 'http://localhost:8080/'로 접속하면 생성된 Vue-Cli 페이지를 확인가능하다.

babel: 자바스크립트 컴파일러, 최신의 자바스크립트 코드를 이전단계의 자바스크립트 코드로 변환가능하게 해주는 개발 도구, 하위호환성, 트랜스파일러(Transpiler) ESLint: 자바스크립트 문법 에러 표시 도구

정상적으로 vue-cli 프로젝트가 실행되는걸 확인했으면, 추가로 아래 모듈들을 설치한다. (프로젝트 폴더(frontend)에 설치) 해당 포스트만 참고하고 시리즈(JWT 회원관리)에는 관심없으시면 axios만 설치하시면 됩니다!!

npm install axios
npm install vue-router@4
npm install vuex@next --save
npm install vee-validate@next --save
npm install bootstrap jquery popper.js
npm install @fortawesome/fontawesome-svg-core @fortawesome/free-solid-svg-icons @fortawesome/vue-fontawesome@prerelease

4) GUI 를 사용해 의존성 확인하기 (선택)

$ vue ui

'vue ui' 커맨드를 이용해 GUI 를 통해 프로젝트 플러그인/의존성을 조회할 수 있다. 앞서 설치했던 모듈들을 확인해보자.

3. 백엔드-프론트엔드 통신 테스트

1) 백엔드 (Express)

1. 'routes/index.js' 파일 수정

GET, POST 두 가지의 방식을 이용해 통신해 볼 것이다. '/getTest' 로는 단순 응답을, '/postTest'에서는 클라이언트에서 보낸 parameter를 이용해 응답을 준다. index.js 파일을 아래처럼 수정하자.

var express = require('express');
var router = express.Router();

/* GET home page. */
router.get('/', function(req, res, next) {
  res.render('index', { title: 'Express' });
});

router.get('/api/getTest', async (req, res) => {
  try {
    res.send({
      msg: 'This my response : get'
    })
  } catch (err) {
    console.log(err);
    res.send({
      error: 'Can"t read api data',
    });
  }
});

router.post('/api/postTest', async (req, res) => {
  try {
    console.log(req.body)
    res.send({
      msg: 'Hi!' + req.body.name
    })
  } catch (err) {
    console.log(err);
    res.send({
      error: 'Can"t read api data',
    });
  }
});

module.exports = router;

그리고 백엔드를 재시작한 후 'http://localhost:3000/post/getTest' 에 접속하면 응답이 오는걸 확인 가능하다.

혹은 REST API를 테스트할 수 있는 도구를 이용하면 되는데, 나는 크롬확장프로그램인 'REQBIN'을 이용하여 테스트했다.

• post Test (매개변수 name 값인 'choco' 이용해 응답한다.)

2) 프론트엔드 (Vue)

1. 'vue.config.js' 파일 추가

프로젝트 루트에 'vue.config.js' 파일을 생성하고 아래 코드를 넣는다. 웹팩 개발 서버(프론트엔드)에서 Express(백엔드)로 프록시 요청을 함.

프록시(Proxy): 프록시는 '대리' 라는 뜻으로, 네트워크 통신에서 '대리 응답' 등에 사용하는 개념. 보안상의 문제로 직접 통신할 수 없는 두 지점 사이에서 프록시를 이용해 중계를 하는 개념.

module.exports = {
    devServer: {
        proxy: { 
            '/api': { 
                target: 'http://localhost:3000/api/', 
                changeOrigin: true, 
                pathRewrite:{ "^/api" : '' } 
            } 
        },
        headers: { "Access-Control-Allow-Origin": "*" }
    }
}

2. component 수정 (통신 test 용)

'src>components>HelloWorld.vue' 파일을 아래와 같이 수정한다. 아주 간단한 통신 테스트로, 반응형 변수로 선언된 'getMsg'와 'postMsg'에 통신 결과값을 대입해 화면에 보여준다.

<template>
  <div>
    <h1>{{state.getMsg}}</h1>
    <h1>{{state.postMsg}}</h1>
  </div>
</template>

<script>
import { onMounted, reactive } from 'vue'
import axios from 'axios'

export default {
  name: 'Test',
  setup () {
    const state = reactive ({
      getMsg: '',
      postMsg: ''
   })

    onMounted(() => {
      try {
        let urlGet = '/api/getTest';
        axios.get(urlGet, {
        })
        .then(function (response) {
          state.getMsg = response.data.msg
        })
        .catch(function (error) {
          alert(error);
        });


        let urlPost = '/api/postTest';
        axios.post(urlPost, {
          name: 'choco'
        }).then(function (response) {
          state.postMsg = response.data.msg
        })
        .catch(function (error) {
          alert(error);
        });
     } catch (err) {
        console.log(err);
      }
    });

    return {
      state
    }
  }
}
</script>

<style scoped>
</style>

통신 결과값이 정상적으로 출력되는걸 확인할 수 있다. 다음 포스트에서는 Vue router 를 이용해 화면 전환(로그인/관리자화면/일반유저화면)을 하는 방법을 포스팅하겠습니다.

참고: http://expressjs.com/ko/starter/generator.html (express) https://bezkoder.com/vue-3-authentication-jwt/ (회원가입) https://cli.vuejs.org/guide/installation.html (vue-cli) https://cli.vuejs.org/guide/creating-a-project.html#using-the-gui (vue-cli 프로젝트 생성) https://next.router.vuejs.org/installation.html (vue-router4) https://next.vuex.vuejs.org/installation.html (vuex4) https://vee-validate.logaretm.com/v4/ (vee-validate v4) https://milkye.tistory.com/202 (프록시)

저 역시 기술 포트폴리오 겸 개발 관련 지식을 공유하고 싶어 기술 블로그를 하나 만들기로 결심했는데, 요즘 괜찮은 블로그 플랫폼이 너무 많아 정하기가 너무 힘들더라구요.

그래서 네이버/티스토리/벨로그(Velog)/미디엄(Medium)/깃허브(Github)블로그/구글 블로거(Blogger)를 한번 비교해봤습니다.

1) 블로그 플랫폼 비교

플랫폼|특징/장점|단점|용도 |--|----|----|--| 네이버(Naver)|국내 검색엔진 특화
진입장벽 매우 낮음
이웃/소통에 좋음
패션/뷰티는 무조건 네이버|커스마이징 되긴 하지만 별로..
구글에서 검색 잘 안됨|일상,맛집,리뷰,뷰티 등 티스토리(Tistory)|진입장벽 매우 낮음
커스마이징이 쉬움(괜찮은 템플릿이 많이 풀려있음)
수익/통계/구독 있음|코드블럭이 그저그럼
개발친화적이라기엔 조금 애매함(다양한 주제로 글쓰기 가능)
카카오가 브런치를 많이 밀어주면서 포지션이 더 애매해짐|리뷰, 여행, 개발 벨로그(Velog)|프론트엔드 개발자 벨로퍼트님이 개발
편함 깔끔함 심플함
글 작성이 매우 직관적임
개발특화
조회수/통계/구독 기능 있음(최근 추가됨)
팀블로그로 좋음|마크다운으로만 작성 가능
수익은 추후 추가 예정
커스마이징 어려움
개인이 운영|개발 미디엄(Medium)|해외에서 많이 사용하는듯
구독 수익 통계 기능 있음
피드백이 좋음
개발특화
팀블로그로 좋음|글쓰기 개수 제한 있음(결제하면 업그레이드 가능)
한글 폰트가 별로라고함
커스터마이징 어려움|개발 깃허브(Github)블로그|확장성이 좋음
커스마이징 매우 좋음(Jekyll외 Ghost, Hexo 같은 정적 사이트 생성기와 연동 가능)
개발특화|초기세팅이 어려움
github를 안해봤거나, 개발자가 아니라면 접근성이 낮음 (불친절함)
Github Pages 트래픽 제한 (월100GB)
하나의 저장소가 1GB를 넘어가면 돈을 내고 사용해야함(이미지 블로깅엔 적합하지 않음)|개발 블로거(Blogger)|갓구글에서 서비스함
해외 친화적
1계정당 100개의 블로그 생성 가능(굳이)|검색 노출이 잘 안된다고함
마크다운 지원 안됨
커스마이징 어려움|다양한 주제/영어로 글쓰고 싶으신분

2) 기술 블로그

사실 velog/medium 이 개발자 친화적이고 (비교적) 사용이 간편해서 이 둘 플랫폼 중에서 고민하다가

• tistory는 마크다운이 가능하나, 전반적으로 개발친화적이라고 보기에는 어려워 개발자에겐 애매한 포지션
• medium은 포스팅 갯수 제한때문에 고민됨
• github는 초기 구축이 귀찮음

이런 이유로 velog에 글을 1개 작성해봤는데 웬걸!! 글 작성이 매우 쉽고 직관적이었다. 개발 글을 올리기에 정말 최적화가 잘되있었다.

이제 드디어 개발 플랫폼을 정했다고 신나하고 있었는데 누군가 정성스레 잘 만든 github 블로그를 보고나니 디자인에 대한 욕심이 생겨서 github 블로그로 결정했다.

만약 개발자라도 프론트엔드에 관심이 없거나, 블로그를 예쁘게 커스터마이징 하는데 관심이 없으면 velog/medium을 추천한다.

아니면 귀찮음을 감수하고서라도 나만의 예쁜 블로그가 갖고싶으면 github블로그를 추천함.

→ 돌아서 다시 velog로 정착함!!

어째서? 냐면 나는 이미지를 굉장히 많이 올리고 싶은데, 깃허브 블로그에 이미지를 올리려면 repo에 올린 후 가져오거나, url을 가져와야 하기 때문이다. 만약, 한 포스팅이 이미지 10개가 올라간다고 치면, 10개의 이미지를 또 업로그하고 그 URL을 가져와야한다는 소린데......

그때문에 다시 tistory도 고려해봤으나, 동일 주제로 구글에 검색하면 velog가 최상단에 있는걸 확인하고 SEO 최적화때문에 velog로 결정했습니다.

3) 결론

그래서 결론은

기술블로그는 velog로 운영하기로함

이 글은 모두 주관적인 기준에 의해 쓰여진 것입니다! 혹시 기술 블로그를 시작하고자 하는 분들께 도움이 됬으면 좋겠네요.