:)

윈도우 먹통 사태 - 크라우드 스트라이크

Mon, 22 Jul 2024 11:06:12 GMT

사건 발생

19일 오후부터 시작된 미국 사이버 보안 기업 ‘크라우드 스트라이크(CrowdStrike)’의 보안 소프트웨어의 업데이트 오류로 인해 항공, 은행, 방송 등 전 세계 시스템이 마비

발생 원인

크라우드 스트라이크의 보안 플랫폼 ‘팔콘(Falcon)’의 보안 업데이트 오류 → 기기들이 부팅 루프에 빠져 정상 작동 불가 - Falcon: 100% 클라우드 기반, 하드웨어나 추가 소프트웨어 등 구성요소 불필요, 호스트 방화벽 관리, 위협 인텔리전스 기능 함께 제공

이로 인한 문제점

해당 사고는 보안 또는 사이버 공격이 아니나 이를 악용한 사례 발생 가능 (기술 문제를 복구시켜 준다며 악성코드를 유포하고, 크라우드 스트라이크의 지원을 가장한 피싱 이메일을 통해 개인정보 입력을 유도한 사례가 발견)

긴급 조치 방법 (KISA)

안전 모드에서 문제가 되는 SW 파일을 삭제하는 것
- 조치 순서: 먼저 안전 모드로 부팅 → 복구 화면에서 ‘고급 복구 옵션 보기’를 클릭 → 고급 복구 옵션 메뉴에서 ‘문제 해결’을 선택 → ‘고급 옵션’을 선택 → ‘시작 설정’을 선택하고 ‘다시 시작’을 클릭 → 재부팅 후 4 또는 F4 키를 눌러 안전 모드에서 PC를 시작
- 두 번째로 안전 모드에서 명령 프롬프트(관리자) 또는 Windows PowerShell(관리자)를 실행한다. 다음으로 C:Windows-System32-drivers-CrowdStrike 디렉터리로 이동한 후, C-00000291*.sys 패턴과 일치하는 파일을 검색해 삭제

참고 기사

https://m.boannews.com/html/detail.html?idx=131501 https://m.boannews.com/html/detail.html?tab_type=1&idx=131506 https://www.dailysecu.com/news/articleView.html?idxno=157917 https://www.crowdstrike.com/statement-on-falcon-content-update-for-windows-hosts-kr/

[2024] 비전공자의 네트워크 관리사 2급 - 2차 합격 정보 공유

Tue, 02 Jul 2024 02:04:58 GMT

국비 수업을 들으며 병행했던 네트워크 관리사 2급 시험에 붙게 되어 기록 겸 정보 공유를 위해 글을 작성해봅니다. 수업에서는 linux, network +기초 보안에 대해 들었으며 수업에서 공부한 내용들은 블로그에 정리되어 있습니다.

1차 시험 및 기본 정보

1차 시험 및 기본 정보는 이전 게시글로 대체합니다. (과목, 시험일정 등)

시험

시험 장소는 일주일 전 홈페이지에 공개되고 수험표는 별도로 필요하지 않습니다. 랜툴의 경우 시험 장소에서 대여가 가능하다고 하였으나 상태가 안좋을 수도 있다는 공지를 보고 저는 개인적으로 챙겨갔습니다. 케이블 제작 - ICQA - 라우팅 순으로 시험이 진행됩니다. 각 시험 시작마다 비밀번호가 필요하며 감독관이 일정 시간이 지나면 알려주니 입력하시면 됩니다.

공부 방법

https://www.icqa.or.kr/cn/board/dataroom?sca=%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC%EA%B4%80%EB%A6%AC%EC%82%AC

공식 사이트에서 올려준 연습 프로그램을 이용해서 실습을 진행했습니다. ICQA 문제 내용들은 대부분 하나하나 눌러가며 설명을 읽고 처리하면 충분히 풀 수 있으실겁니다. 해당 프로그램의 풀이 영상 링크입니다. https://www.youtube.com/watch?v=8LW96hLqXCo&list=PLrTFeWWAg1ciqrQ8hQ-42fotXi3AGz-aC&index=11

아래는 제가 여러 자료들을 취합해서 정리한 내용입니다.

합격 인증

kubernetes

Mon, 01 Jul 2024 04:27:17 GMT

https://kubernetes.io/ko

개념

컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장 가능한 오픈소스 플랫폼
선언적 구성과 자동화를 모두 용이하게 함
쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용가능

기능

서비스 디스커버리와 로드 밸런싱

  - 쿠버네티스는 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너 노출 가능
  - 컨테이너에 대한 트래픽이 많으면, 쿠버네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 안정적 배포 가능

스토리지 오케스트레이션

  - 쿠버네티스 사용시 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템 자동 탑재

자동화된 롤아웃과 롤백

  - 쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술가능, 현재 상태를 원하는 상태로 설정한 속도에 따라 변경 가능
      → 쿠버네티스 자동화로 배포용 새 컨테이너 생성, 기존 컨테이너 제거, 모든 리소스를 새 컨테이너에 적용 가능

자동화된 빈 패킹(bin packing)

  - 컨테이너화된 작업을 실행하는데 사용할 수 있는 쿠버네티스 클러스터 노드를 제공
  - 각 컨테이너가 필요로 하는 CPU와 메모리(RAM)를 쿠버네티스에게 지시
  - 쿠버네티스는 컨테이너를 노드에 맞추어서 리소스를 가장 잘 사용할 수 있도록 함

자동화된 복구(self-healing)

  - 실패한 컨테이너 재시작, 컨테이너 교체, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너 죽임 → 서비스 준비가 끝날 때까지 과정 보여주지 않음

시크릿과 구성 관리

  - 쿠버네티스를 사용시 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장, 관리 가능
  - 컨테이너 이미지를 재구성하지 않고 스택 구성에 시크릿을 노출하지 않고도 시크릿 및 애플리케이션 구성을 배포 및 업데이트 가능

종류

Flannel

  - 가장 단순한 쿠버네티스
  UDP나 VxLAN을 사용하여 가상 네트워크를 구성
  물리적인 네트워크 인프라 변경없이 쿠버네티스 클러스터를 구성할 때 사용
  신속함, 고도 확장 불가, 일부 환경 성능 문제 발생.

Calico

  - 고성능 솔루션
  BGP 프로토콜을 사용(네트워크 라우팅)
  IP-in-IP, VXLAN, 또는 BGP 통해 가상 망 구성가능
  네트워크 정책 엔진을 제공
  대규모 환경 적합, 다중 클러스터 환경에도 사용.

WeaveNet

  - 가벼우면서 유연한 쿠버네티스전용 네트워킹
  가상 네트워크구성가능
  UDP 또는 VXLAN 사용
  노드 간에 가상 네트워크를 자동으로 연결
  쿠버네티스 클러스터 설정이 간단
  다중 클러스터 환경에서도 사용
  네트워크 정책을 정의

설치(Calico)

도커 로그인 docker run -it ubuntu bash hostnamectl set-hostname k8s-master-00 ufw disable swapoff -a

vi /etc/fstab
스왑부분 주석
vi /etc/containerd/config.toml 주석 cri

cat << EOF | tee /etc/docker/daemon.json { "exec-opts": ["native.cgroupdriver=systemd"], "log-driver": "json-file", "log-opts": { "max-size": "100m" }, "storage-driver": "overlay2" } EOF

cat << EOF | tee /etc/sysctl.d/sevas.conf net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call-iptables = 1 EOF

cat << EOF | tee /etc/modules-load.d/sevas.conf overlay br_netfilter EOF

확인 lsmod | grep br_netfilter 설정로드 sysctl --system

레포지터리 설치

apt-get install -y apt-transport-https
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.28/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.28/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list apt-get update apt-get install -y kubelet kubeadm kubectl apt-mark hold kubelet kubeadm kubectl

docker login kubelet --version apt-get install nfs-kernel-server

systemctl daemon-reload systemctl enable docker systemctl enable kubelet systemctl enable containerd systemctl restart docker systemctl restart kubelet systemctl restart containerd systemctl status kubelet

containerd config default | tee /etc/containerd/config.toml sed -i 's/SystemdCgroup = false/SystemdCgroup = true/g' /etc/containerd/config.toml

service containerd restart service kubelet restart service NetworkManager restart nslookup google.com

마스터에서만 실행

kubeadm init --pod-network-cidr=192.168.0.0/16

메세지 → 해시 기록해둘 것

      Your Kubernetes control-plane has initialized successfully!
      To start using your cluster, you need to run the following as a regular user:
      mkdir -p $HOME/.kube
      sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
      sudo chown $(id -u):$(id -g) $HOME/.kube/config
      Alternatively, if you are the root user, you can run:
      export KUBECONFIG=/etc/kubernetes/admin.conf
      You should now deploy a pod network to the cluster.
      Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
      https://kubernetes.io/docs/concepts/cluster-administration/addons/
      Then you can join any number of worker nodes by running the following on each as root:
      kubeadm join 192.168.10.100:6443 --token t74935.2sk3buhm764uwkbi \
      --discovery-token-ca-cert-hash sha256: 해시 출력

vi /root/.bashrc export KUBECONFIG=/etc/kubernetes/admin.conf (추가)

bash set |grep KUBE

calico 설치 (kubectl 쿠버네티스 명령어도구)

kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.4/manifests/tigera-operator.yaml
      kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.4/manifests/custom-resources.yaml
      kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.27.2/manifests/tigera-operator.yaml
      kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.27.2/manifests/custom-resources.yaml
칼리코 삭제할때는 find / -name calico 다 지우고 ipvsadm --clear / rm -rf /etc/cni/net.d 도 지움 확인 watch kubectl get pods -n calico-system

노드에서만 실행

mkdir -p $HOME/.kube scp 172.16.10.100:/etc/kubernetes/admin.conf $HOME/.kube/config cp -a $HOME/.kube/config /etc/kubernetes/admin.conf

vi bashrc export KUBECONFIG=/etc/kubernetes/admin.conf

토큰

쿠버네티스에서 사용할 인증정보(secret) 를 생성 docker login cat /root/.docker/config.json

생성 kubectl create secret generic master --from-file=.dockerconfigjson=/root/.docker/config.json --type=kubernetes.io/dockerconfigjson 확인 kubeadm token list 접속 kubeadm join <192.168.0.10:6443> --token --discovery-token-ca-cert-hash sha256:

JWT

Thu, 27 Jun 2024 06:10:58 GMT

JWT

토큰 사용 목적

단일 토큰
1. 로그인 성공 JWT 발급 서버 측 → 클라이언트로 JWT 발급
2. 권한이 필요한 모든 요청 : 클라이언트 → 서버 측 JWT 전송 권한이 필요한 요청은 서비스에서 많이 발생 클라이언트 측 xxs나 http통신을 가로채서 토큰을 훔침 → 대비하기 위한 로직 필요

다중 토큰 : refresh 토큰

access/Refresh 토큰

생명주기를 짧게 발급 (약10분) , 토큰이 만료 되었을때 함께 받은 Refresh 토큰 (24시간) 토큰 재발급

 1. 로그인 성공시 2개 토큰
     - Access 토큰 : 권한이 필요한 모든 헤더에 사용될 JWT 생명주기를 짧게 함
     - Refresh 토큰 : 재발급을 위한 토큰으로 24시간 생명주기
 2. 권한이 필요한 모든요청은 Access 토큰을 사용
 3. Access 토큰이 만료될경우 Refresh 토큰을 검증 후 Access 토큰을 재발급

포인트

로그인이 완료되면 successHandler에서 Access/Refresh 토큰 2개 발급해 응답
Access 토큰을 요청을 검증하는 JWTFilter에서 Access 토큰이 만료된 경우 상태 코드와 메시지를 응답
프론트 측 API 요청 시 Access 토큰 만료 요청이 오면 예외문을 통해 Refresh 토큰을 서버 측으로 전송 → Acccess 토큰을 새로 받는 로직 수행
서버측에서는 토큰을 받을 엔드 포인트 구성 Refresh 검증 후 Access를 응답
- 단일 → 다중으로 전환되면 Access 토큰이 탈취되더라도 생명 주기가 짧아 피해가 줄어듬 ⇒ Refresh 토큰에 대한 보호 방법이 필요
- Refresh 토큰 Rotate 에 대한 부분 ( Access 토큰 갱신 시 Refresh 토큰도 재발급 )
  - Access/Refrsh 토큰 저장 위치
    - 기존 저장 로직
      - 로컬 스토리지 : xss 공격에 취약 : Access 토큰 저장
      - httpOnly 쿠키 : CSRF 공격에 취약 : Refresh 토큰 저장
        고려 사항
JWT의 탈취는 XSS 공격으로 로컬스토리지에 저장된 JWT를 가져감 쿠키방식은 CSRF공격에 취약하기 대문에 저장소가 중요
Access 토큰 보통 로컬 스토리지에 저장되고 짧은 생명주기
Refresh 토큰 주로 쿠키에 저장 httpOnly를 설정하면 방어 가능
Refresh 토큰은 Rotate를 통해서 Access 토큰 발급 시 Refresh토큰도 갱신하여 방어 조치를 함

가장 강력한 보안

로그아웃을 할 때 Access/Refresh 토큰을 초기화하고 제거함
Refresh 토큰 블랙리스팅

[Linux] Docker

Mon, 24 Jun 2024 12:09:17 GMT

개념

리눅스의 응용 프로그램들을 프로세스 격리 기술들을 사용해 컨테이너로 실행하고 관리하는 오픈 소스 프로젝트

container =emulator

명령어

포트 포워딩 상태로(백그라운드) 최초 실행 후 진입 docker run -d -p 80:80 --name sevas_web ID docker exec -it sevas_web /bin/bash
- 최초 시작 전 반드시 로그인 docker login
- 환경 확인 docker system info
- 저장소 확인 docker system df
- 최초 이미지 불러오기
  1. 도커 이미지 찾기
  -Docker search [이미지명] docker search oraclelinux
  1. 도커 이미지 가져오기
  -Docker pull [이미지명] [기본 latest] 웹에서 직접들어가서 tag까지 가져오기 - docker pull oraclelinux:8
  1. 도커 이미지 확인
  -Docker image ls
  1. 도커 이미지 삭제
  -Docker image rm [IMAGE_ID]
- Container
  1. 실행 run, attach ,exec
    1. run : 새로운 컨테이너를 생성해 실행하는 명령어 (보통 최초한번만 실행-명령이 끝나면 종료)
      1. docker run --name [컨테이너 이름 지정] [Repository]:[TAG] → 포어그라운드= 웹페이지 접속x / ctrl +c만 가능
      - 명령어
        
        옵션 설명 -i --interactive 컨테이너의 표준 입력(stdin)을 활성화. (주로 -it 함께 사용) -t --tty tty (가상 터미널)을 할당, 리눅스에 키보드를 통해 표준 입력(stdin)을 전달할 수 있게한다. (주로 -it 함께 사용) --name 컨테이너 이름을 지정. -d --detach 컨테이너를 백그라운드로 실행. --rm docker run 명령어가 끝나면, 컨테이너 자동 삭제. -p --publish 호스트와 컨테이너의 포트를 연결 (포트포워딩). -p <호스트 포트>:<컨테이너 포트> ex) -p 80:8888 → 호스트에 8888로 접속하면, 컨테이너 내부의 80포트로 자동 접속. -v --volume 호스트와 컨테이너의 디렉토리 연결(마운트) -v <호스트 절대경로>:<컨테이너 절대경로> ex) -v /Users:/usr. → 컨테이너 /usr에 저장하는 파일은 호스트의 /Users 디렉토리에 저장. --restart 컨테이너 종료시, 재시작 정책 설정 --restart="always" 항상 재시작 --restart="on-failure" 종료 스테이터스가 0이 아닐 때 재시작
        
        --privileged 컨테이너 안에서 호스트의 리눅스 커널 기능을 모두 사용
        
        --rm 옵션과 --restart 옵션은 동시 사용 x
        
        상태 Exited 비활성화 / UP 활성화
      - 실습
        
        확인: docker container ps -a
        
        docker run --name sevas_web nginx:latest → 포어그라운드 ctrl+p,ctrl+q 안됨 , ctrl+c (EXIT상태됨) docker run -it --name sevas2_web nginx:latest → 포어그라운드+가상터미널할당 ( -it ) ctrl+pq 로 나가서 유지
        
        docker run -d --name sevas3_web nginx:latest → 백그라운드실행 docker run -d --name sevas4_web -p 80:80 nginx:latest → 백그라운드실행 + DNAT설정 (웹페이지 출력됨)
    2. exec : 실행 중인 컨테이너에 명령어를 전달(외부 -> 내부)
      1. 진입해서 명령 실행 docker exec -it
      2. 명령만 실행 docker exec
      3. exec로 실행한 도커(Exited 상태) 실행 : docker start sevas_web uname -a
    3. attach : 실행 중인 컨테이너에 직접 들어가 명령어를 실행 (내부 접근) → 로그 내용 볼 때 사용, 잘 안씀
      1. docker attach docker attach sevas_web
        
        -it (접속유지)
      -d: 백그라운드
      
      연결 종료 후 나가기: ctrl +c 연결 유지한 채 나가기: ctrl +pq
  2. 확인
    1. 동작 중인 컨테이너: docker container ls
    2. 시작한 컨테이너: docker container ps -a
    3. 컨테이너 ID: docker container ps -a -q
  - 보통 최초 실행 시 run 사용 docker exec -it /bin/bash로 들어가서 작업
  1. 멈추기 docker stop [container ID] / 모두 멈추기 docker stop $(docker ps -a -q)
  2. 지우기 docker rm [container ID] / 모두 지우기 docker rm $(docker ps -a -q)
  3. 도커 내부에서 명령어 사용
    
    apt update apt install bet-tools apt install vim index 찾기 find / -name index.html -> /usr/share/ngnix/html
- image
  - 호출 docker image ls
  - 저장 docker image save -o export.tar nginx:latest
```
   docker image save -o export.tar [IMAGE ID]
```
  - 로드 docker image load -i export.tar
  - 빌드 docker container commit -a "계정명" web_01 헤드:버전
```
   docker container commit -a "sevas2" web_01 web_01:1.0
```
  - 삭제 docker image rm [이름]
- docker hub이용
  1. 회원가입
  2. create repositories
  3. docker image tag 이름:버전 계정/이름:버전 -> 태그 부여 ex) docker image tag sevas_web:1.0 sevas2/sevas_web:1.0
  4. docker push sevas2/sevas_web:1.0
  - repositories의 이름과 허브의 repositories이름이 같아야 함

[Linux] ubuntu 설치

Mon, 24 Jun 2024 09:04:35 GMT

실습을 위한 설치 환경입니다.

1. 우분투 다운

https://ubuntu.com/ iso 바로 다운 링크

2. VM웨어 생성

(기본시작: custom/ 이미지에 없는 설정은 기본 설정) 최종

3. 우분투 설치

(이미지에 없는 설정은 기본 설정) 설치 완료 후 재시작 -> 생성한 계정으로 접속

4. 싱글부트

전원을 껐다가 킨 후 바로 ESC (아래 그림이 뜨기 전)
떠야하는 화면 -> e
해당 부분을 지운 후 rw init=/bin/bash로 변경 -> ctrl+x
passwd 명령어를 통해 root 비밀번호 변경
3가지 파일 수정 (루트 로그인 허용) /저장명령어:wq
수정 완료 후 exec/sbin/init (재부팅)
재부팅 완료 후 목록에 없습니까? 누른 후 사용자이름 : root로 로그인

5. 네트워크 설정

6. 한글화

![] 추가로 한영버튼을 눌러서(Alt_R로 뜸)을 넣은 후, 이외에 것은 제거 - 적용 - 확인 - 이후 재부팅

IDS, snort

Wed, 19 Jun 2024 01:36:59 GMT

IDS

IDS (Intrusion Detection System) 침입 탐지 시스템
- 시스템에 대한 원치 않은 조작을 탐지 → 내부 패킷을 주로 감지
- 설치 위치와 목적에 따라 호스트 기반과 네트워크 기반의 침입 탐지 시스템으로 나뉨
- 역할
  1. IPS를 우회하는 공격에 대한 탐지
  2. 내부 공격 및 보안 내용 탐지
  3. 제로데이 공격 유형 파악
  4. 오용 탐지
- 장점
  - 해킹에 대한 좀 더 적극적인 보안대책
  - 내부 사용자의 오남용 탐지 및 방어 가능
  - 사고 발생시 근원지 및 사고 분석 가능
- 단점
  - 대규모 네트워크에서는 사용이 어려움
  - 관리 및 운영이 어려움
  - 새로운 침입 기법에 즉각적인 차단 어려움
  - 보안 사고에 대한 근본적인 해결책은 되지 못함

1. 호스트 기반 ( HIDS : Host-based IDS )

컴퓨터 시스템의 내부를 감시하고 분석하는 데 중점을 둠
개인의 work station, server에 설치될 수 있으며, 컴퓨터 자체를 제한
운영체제에 설치된 사용자 계정에 따라 어떤 사용자가 어떠한 접근을 시도하고 작업을 했는지에 대한 기록을 남기고 추적
네트워크에 대한 침입 탐지는 불가능하며, 스스로가 공격 대상이 될 때만 침입을 탐지하는 방식
트로이 목마, 논리 폭탄, 백도어 탐지
ex) Tripwire
1-1. Tripwire
tripwire 무결성 점검도구 -> 기존 데이터와 비교하여 변조된 내용 확인(모니터링 도구)
설치 yum install epel* yum install tripwire

-키세팅 tripwire-setup-keyfiles <<<<<<<<<엔터엔터엔터 cat /etc/tripwire/twcfg.txt -> 키세팅 파일 생성

cd /etc/tripwire cp twpol.txt twpol.txt.bak

vi twpol.txt

/bin -> $(ReadOnly); /etc -> $(IgnoreNone)-SHa; /var -> +pug; /dev -> +pug; /back -> +pug;

p 퍼미션 u uid g gid

정책적용 twadmin --create-polfile twpol.txt
구동 tripwire --init
확인 tripwire --check useradd korea passwd [비번설정] cp /backup/ping /usr/bin/ping

2. 네트워크 기반 ( NIDS : Network-based IDS )

네트워크를 통해 전송되는 패킷 정보 수집 및 분석하여 침입을 탐지하는 시스템
감지기를 사용하며, 무차별모드(Promiscuos mode)에서 동작하는 네트워크 인터페이스에 설치되어있음
IP 주소를 소유하지 않아 직접적인 해커 공격은 거의 완벽하게 방어 가능
설치 위치에 따라 감시 대상 네트워크 범위 조절 가능, 별도 서버를 스위치에 연결
공격 당한 시스템의 공격에 대한 결과는 알 수 없으며, 암호화된 내용 탐지 불가 ex) Snort

2-1. Snort

무료 오픈 소스 네트워크 침입 탐지 시스템이자, 침입 방지 시스템으로 실시간으로 트래픽 분석 및 패킷을 기록 ( IDS & IPS )
와이어샤크+ 필터
- 패킷 스니퍼 모드
  - Tcpdump와 같은 네트워크의 TCP/IP 패킷을 읽어 보여주는 기능
- 패킷 로거 모드
  - 모니터링한 패킷을 저장하고 로그를 기록하는 기능
  - 트래픽 디버깅에 매우 유용하게 사용
- 네트워크 IDS 모드
  - 네트워크 트래픽(패킷) 분석 및 공격 탐지 기능을 제공
- Snort Inline
  - 침입방지시스템으로, 패킷 분석, 공격 차단 기능을 제공
- nc → 메세지 주고 받는 창 (간단한 실습)
  
  nc -l 8080
  
  nc 10.10.10.10 8080
- 시작 snort -i ens33 -c local 혹은 데몬 실행
- snort 정책
```
  alert icmp  any any <> 10.10.10.10 any (msg:"ICMP PING";sid:50001;)
  alert tcp any any -> 10.10.10.10 80 (msg:"SEVAS_HTTP";sid:50002;)
```
  [action] [protocol] [src_ip] [src_port] -> [Dst_ip] [Dst_port] [option]
  
  액션 action : alert , pass ,drop , reject ,log 프로토콜 protocol : TCP,UDP , IP , ICMP 출발지 IP Src_ip : any , 10.10.10.10 , 10.10.10.0/24 ! 출발지 port src_port : any , 22, 80 ,...... ! , : (1:1000) 패킷 흐름 방향 : -> , <> 도착지 IP Dst_ip : any , 10.10.10.10 , 10.10.10.0/24 도착지 port Dst_port : any , 22, 80 ,...... 침입 탐지 옵션 option : msg ,content ,flow , rev......
  - src → 공격자의 출발지를 ip 추적하고 싶을때 유용
  - dst → (여러 ip로 부터)공격 받고 있는 대상 서버나 네트워크를 보호하고자 할 때 유용
    
    rev : 규칙 수정버전 classtype : 유형별 정의 priority : 우선순위 reference : url로 정책 정의
  - 옵션 ( <> 양방향 | -> 단방향 <- ) → 오탐 (IPS에서 중요), 미탐 방지 (IDS에서 중요)
    - content 글자를 잡아낸다 ex) content:"sevas"; → 16진수의 경우 “| |” 로 감싸야함
    - msg 메세지 내용 출력 ex) msg:"메롱";
    - nocase 대소문자를 구분하지 않는다 ex) nocase;
    - sid 규칙 식별자(정책 순서 지정) ex) dis:50005;
    - offset 매칭 시작 문자열 위치 0으로 설정 시 1부터 검색
    - depth 문자열 범위를 지정 0으로 설정 시 1부터 검색
    - distance 옵션 값 이후 탐색 위치 지정 (이후) ex) content:”abc”; content:”test”; distance: 10;
    - within 옵션 값 이후 탐색 범위 지정 (이내) (distance, offset, depth)
      - abc | within (이내) 10 (이후) distance |
    - pcre 문자열 (URL 검사)
      - 정책 예시
        
        depth , offset → 123문자가 들어간 내용이 4바이트 이후부터 7바이트안에 존재하는지 알림 alert tcp 20.20.20.20 any -> 10.10.10.10 8080 (msg:"depth_TEST"; content:"123";offset:4; depth:7; sid:50008;)
        
        distance alert tcp 20.20.20.20 any -> 10.10.10.10 8080 (msg:"distance_TEST"; content:"abc"; content:"test"; distance:10; sid:50009;)
        
        within alert tcp 20.20.20.20 any -> 10.10.10.10 8080 (msg:"within_TEST"; content:"abc"; content:"test"; within:10; sid:50009;)
        
        pcre alert tcp 10.10.10.0/24 any -> any 443 (msg:"SNS_ACCESS"; pcre:"/facebook.com|instargram.com/"; sid:50010;)
        
        telnet → 문구가 다르게 나오는 것을 와이어샤크로 확인 후 content로 작성 alert tcp 10.10.10.10 23 -> any any (msg:"Telnet OK"; content:"|6c617374206c6f67696e|"; nocase; sid:50007;) alert tcp 10.10.10.10 23 -> any any (msg:"Telnet Fail"; content:"|4c 6f 67 69 6e 20 69 6e 63 6f 72 72 65 63 74|"; nocase; sid:50006;)
        
        ICMP 20 →10 으로 ping alert icmp 20.20.20.20 any -> 10.10.10.10 any (msg:"REQUEST_ICMP"; itype:8; sid:50011;) alert icmp 10.10.10.10 any -> 20.20.20.20 any (msg:"REPLY_ICMP"; itype:0; sid:50012;)
        
        threshold (5개마다 탐지) alert icmp any any -> 10.10.10.10 any (msg:”THRESHOLD”; threshold: type threshold, track by_src, count 5, seconds 10; sid: 50013;)
        
        limit (5개까지 탐지) alert icmp any any -> 10.10.10.10 any (msg:”limit”; threshold: type limit , track by_src, count 5, seconds 10; sid: 50013;)
        
        both (1개만 탐지) alert icmp any any -> 10.10.10.10 any (msg:”limit”; threshold: type limit , track by_src, count 5, seconds 10; sid: 50013;)
http에서
- 간략한 링크들
  1. 클릭 시 웹페이지 이동 click here
  2. 이미지 클릭 시 웹페이지 이동
  3. 사이트 링크 넣기
  4. 응용 유튜브 올리기
  5. xxs 공격 (바로실행되도록 하기) [ Stored XSS (Persistent XSS, 저장 XSS)]
기능 확인
무조건 외우기

종류

Stored XSS (Persistent XSS, 저장 XSS)

  - 웹 서버에 악성 스크립트를 영속적으로 저장해 놓는 방법
  - 클라이언트는 저장된 스크립트를 통해서 공격자의 의도대로 실행됨

Reflected XSS (반사 XSS)

  - 지정된 파라미터를 사용할 때 발생하는 취약점을 이용하는 공격
  - 매개체를 통해서 공격 되는 XSS 공격

DOM-based XSS (문서 객체 모델-기반 XSS) → SSRF
```
  - 문서 내에 있는 태그나 링크들을 클릭하여 전달되는 XSS
```
- ssrf https://www.lgcns.com/blog/cns-tech/security/3202/
- 취약한 서버를 이용하여 공격자가 내부 서버에 원하는 요청을 보내도록 하는 방법
- 보통 공격자가 과도한 정보나 기능을 요청할 경우, 방화벽에서 필터링하거나 웹 서버에서 원하는 정보를 보내주지 않습니다. 하지만 인터넷 앞단의 웹서버가 입력된 URL 값을 충분하게 검사하지 않고 내부 서버로 전달한다면 이야기가 달라집니다. 이것을 이용해서 내부 서버의 정보를 노출시키거나 서비스 거부 공격할 수 있는 것입니다. 이처럼 SSRF는 웹페이지 번역 서비스, PDF 문서 생성기의 잘못된 구현이나, 퍼블릭 클라우드 환경에서 메타서버 접근통제가 미흡한 경우 발생할 수 있습니다.
- SSRF는 ‘CSRF(Cross Site Request Forgery)’와 비슷한 이름을 가지고 있습니다. 이 두 공격은 비슷한 방식을 사용하지만 이용하는 매개체가 다릅니다. 원하는 정보를 얻을 때 SSRF가 서버의 요청을 이용한다면, CSRF는 사용자의 요청을 이용하는 것이죠. 두 공격 모두 공격자가 접근할 수 없는 정보나 시스템에 접근할 수 있도록 만들어줍니다. 하지만 공통적으로 내부에서는 ‘정상 요청’이라고 인식하게 됩니다.
- 해당 링크 주소를 변경하여 내부의 자원을 서버가 직접 출력하도록 만듬, 자원을 끌어옴
- 로컬 호스트를 사용할 수도 있음(직접 들어가서 가져오는 것도 가능) http://192.168.10.10/down_file.php?file_name=../../../../../../../etc/passwd

Universal XSS

  - 브라우저 안에서 실행하는 XSS - 주로 URL 이용(input, form, GET)

실습

실습 순서
1. 로그인한 페이지의 쿠키값 메모장 저장
2. 프록시의 오픈 브라우저로 로그인하지 않은 상태에서 프록시 설정
3. 쿠키값을 저장한 값으로 교체
4. 페이지가 열릴때마다 메모장에 저장된 쿠키로 바꿔줌
5. 회원정보수정으로 가서 비밀번호 1로 변경해봄

쿠키와 세션의 차이

쿠키 = 사물함 KEY
```
  - 맨 처음엔 서버가 클라이언트에 제공하는 값, 이후엔 클라이언트에 저장되는 값이자 서버에서 클라이언트를 식별하는 값 (식별 값)
  - 쿠키를 받았을 때 해당하는 세션 정보를 서버는 제공
  - 즉 쿠키는 클라이언트에 저장 서버 접속 시 서버는 쿠키를 확인 후에 해당 클라이언트 이전 접속 정보를 전송
```
- 세션 = 사물함
  - 요청자와 서버 간의 연결
  - 세션 정보를 가지고 있음
- 세션 : 실제 사용자의 연결된 정보 쿠키 : 세션을 받기 위한 클라이언트 인식값
- 세션: 서버나 서비스에 별도로 저장되는 연결값 또는 연결정보 쿠키: 서버가 저장하고는 있는 세션정보를 넘겨주기 위한 인식값
- 쿠키는 텍스트 형식으로 클라이언트 하드에 저장됨 서버의 정보를 받기위한 인식값 세션은 서버에 서비스나 기타 주제에 따라 별도로 저장되는 연결값 또는 연결정보
  세션 탈취 방지 위한 방법 (세션 만료, 재사용 불가)

중요한 단계나 사이트 갱신 시 쿠키를 재갱신하여 이전 쿠키를 세션 정보를 사용할 수 없도록 함 (JWT 토큰 인증)
쿠키에 대한 세션 유효시간 설정 (JWT 토큰 인증)
중복 로그인 방지(약한 보안, 내가 안쓸때 들어올 수 있음)
로그아웃과 같은 수단 활용 쿠키를 사용 후 세션만료를 할 수 있도록하여 세션 재사용 불가
```
 결론 : 쿠키 재사용X
```

세션 하이재킹 (session hijacking) → 운용 중인 세션을 가로챔

공격 측에서 만든 코드

 - vi /var/www/html/getcookie.php

웹서버에서 공격 (게시글 작성)
칼리의 /sevas/cookie.dat 에서 세션 쿠키를 확인하고 확인된 쿠키로 로그인 시도
```
 ``
```
- 이외의 공격 코드
  - http://192.168.10.10/board_view.php?b_no='>
  - http://192.168.10.10/board_view.php?b_no=%27)>
  - http://192.168.10.10/board_view.php?b_no=%27>
    - %27 = '

쿠키 토큰 세션 - JWT
- 쿠키: 클라(cookie 요청 내용 추가) => 서버(set-cookie 저장소 세션 호출을 저장 )
  
  세션: 서버에 저장 (식별 값에 의한 연결 값 저장), 계정 정보 연결
  
  토큰: 토큰 안에 유저 정보가 저장 ( 사용자 정보 암호화 ) , 쿠키/세션 방식을 보안하기 위해서 나옴
- header payload와 verify signature의 암호화 방식 , type등 정보가 저장 payload ID/PW와 같은 사용자 정보 verify signature : base64 인코딩한 header,payload,secret key를 더하여 서명

로그인
ID및 PW 계정 정보를 payload에 입력
토큰 유효기간 설정 (JWT) json web token - refresh token
암호화할 secret key 를 사용해 access token 발급
사용자는 access token 을 저장하고 인증때마다 헤더에 실어서 보냄 → refresh_token을 통해 새로운 access_token 갱신
서버는 해당 토큰의 서명값을 secret key로 복호화 하여 조작 여부 유효 기간 판단

검증이 완료 되면 payload 디코딩하여 사용자 정보를 가져옴

 - 장점 : 간편 확장성 뛰어남 , 쿠키의 단점인 재사용을 보완
 - 단점 : payload 자체에는 base64 디코딩이 가능함 , 길이가 길어져서 인증이 많아질수록 서버의 자원 낭비 심해짐

xss 대응 방안 http://blog.plura.io/xss-대응방안/

CSRF

사용자 의지와 무관하게 공격자가 의도한 행위를 특정 웹사이트에 요청(서버의 자원을 사용)

xss와 CSRF의 차이

xss → 쿠키나 정보 탈취, 자바스크립트 사용

csrf → 사용자의 비정상 행위 발생, 서버에서 제공하는 기능 사용 , 서버에서 자원 동작

 
                        xss                                 CSRF
공격수행          클라이언트                         서버
기능구현          공격자 script                         서버 제공 기능
script사용여부              필수                             선택
공격시 준비              취약점 발견시 즉시 사용                     동작 원리/request/response의 로직 분석
공격감지 가능              감지 가능                      구분이 어려움

이벤트 당첨 확인바랍니다

보안 대책

'<' 와 같은 웹스크립트 사용 불가 → GET 사용 x
기존의 내용과 비교할 수 있는 검증 수단 마련 or OTP 와 같은 2차 인증
- 2019년 이후 자바 스크립트자체에서 file:/// 로 이동하는 내용 막힘

script 방어
- 글자 방어
  - $subject=preg_replace("/

:)