Security?

• 뭐가 위험한가, 공격자가 어떠한 능력을 가졌는가, 비용과 임팩트, 그리고 확률은 어떻게 되는가
• 리스크를 알기 위한 모든 도움과, 이 리스크를 피하기 위한 모든 노력들이 필요함

다양한 공격 방법들이 존재한다

• eavesdropping : 메세지 중간에 가로채서, 안에 내용 파악하는거 (passive)
• Intrusion: 기기를 공격해서 메세지를 변질 시킴 (active)
• Impersonation: identity fraud, 컨텐츠 파악, 내용물 면질 (active)
• Extortion: 서비스 방해 (active)

Vulnerabilities

• 공격 surface: 얼마나 많은 부분이 공격 가능한가, 이를 어떻게 아는가?
• single point of failure: 한 기기를 통해 공격 가능한가?
  • 라우터, 서버, 디렉토리, 데이터베이스, 파일 등 한가지 point로 날 공격 가능한지

결국 보안은 리스크 매니지먼트와 같은것

• 절대 완벽할 수 없고 (왜냐면 부족함을 증명하기 쉽지 않음)
• 단지 확률을 줄이기 위해 보안 모델을 확실히 할뿐
• 또한 보안은 가장 약한 링크만큼만 안전하다 (걔가 뚤리면 그냥 그만큼 안전한거)

여러가지 flaws들이 존재하는데

• Design Flaws: Law of unintended consequences (multi-component system)
  • 의도하지 않은 결과: “이러면 안되는데…?” 왜냐면 인터넷은 여러가지 시스템이 존재함
• Code Flaws: 항상 버그는 존재하지
• Somebody’s flaws: 사람이 (의도하던 아니던) 문제를 일으킬수도 있고 다른 이유도….

Wifi

• Old WEP cryptography - easy to snoop and decrypt
  • 64, 128 비트를 사용해서 키 값이 일정해서 보안에 취약함
• 802.11I came out to fix old WEP
  • Impossible to brute-force decrypt
  • Removed one threat but
    • 예상 가능한 SSID/Key - get attacker on the WLAN
      • 패스워드 예상 가능
    • wired LAN access to devices on WLAN - get attacker on the LAN/WLAN
      • 해당 인터넷에 접근 가능한 기기에 선 꽂으면….
    • 네트워크 디바이스 (access point)에 대한 물리적 접근 - AP boards 에 chip 설치 등등
      • 해당 인터넷에 접근 가능한 기기를 하드웨어적으로 바꾸는거

즉 하고자 하는 말은 우리가 아무리 무선을 암호화 해봐야, 해당 네트워크에 접근 하는 방법은 여전히 존재함

안일한 인터넷 디자인 (어플리케이션 계층 위주)

• 수년에 걸쳐 보안이 추가되었음
  • 처음 프로토콜들은 조그맣고, 서로 친밀한 커뮤니티 사이에서 쓰이도록 먼저 만들어졌었음
    • DNS, DHCP, HTTP 모두 요청하면 들어줬음
    • 즉 클라이언트와 서버가 서로 미리 알고 있던 관계였음
  • 메일이 친한 대학간에만 사용되었던것 처럼
• 초기 디자인은 이로 인하여 네트워크가 전달하는 내용에 대한 중요도를 고려하지 않았음
  • 서로 아는 사이인데 무슨 보안이야 (인터넷으로 대화하는거 자체가 신선했던 시기)
• 따라서 이후 보안을 추가하기 위해 굉장한 노력들이 필요해짐
  • 아예 처음부터 보안을 위해 다시 디자인을 하던가
  • 아니면 보안을 위해 다른 메커니즘을 추가하던가

아이피 패킷 (네트워크 계층)

• 종단간의 메세지 전달을 위해 다양한 방법, 경로를 통해 전달된다
• 헤더, 그리고 페이로드 또한 믿지 말아야 한다.

기본 가정들

• 누군가는 항상 나쁜 목적을 가지고 있다
• 모든 물리적 링크들은 여러가지 방법으로 방해될 수 있다 (스누핑, 미스다이렉트, 컷,등등)
• 프로토콜 디자인은 공공적이며 많은 헛점을 가지고 있다
• 와이어에 대한 보안은, 호스트에 대한 보안으로부터 뚫릴수 있다
• 기술은 해킹하기 쉽지만, 사람은 더 쉽다.

암호화는 다음과 같은 사항을 고려한다

• 고려해야할 데이터의 상태는
  • In motion: 움직이는 데이터의 보안 (네트워크 통과하는 중)
  • At rest: 저장되어 있는 데이터의 보안 (어플리케이션, 보관소)
• 반드시 eavesdropping 을 위해서만을 위한것이 아니다 (confidentiality/privacy)
• 다음과 같은 사항을 체크하기도 한다
  • 기다리던 기기로부터 도착했는지 (인증)
  • 기다리던 원격 파티로부터 도착한게 맞는지 (인증)
  • 해당 메세지가 정확하게 맞는지 (체크섬) - integrity
  • 해당 메세지가 전에 보내졌지 않은지 (중복인지?) - 이거 안하면 replay 공격 당함

암호화 방식

• Shared Secret: Both has the same key
  • 양쪽 모두 같은 알고리즘을 사용하며, 공격자가 이 알고리즘을 알고 있다고 가정하는게 좋다
  • 따라서 한 키를 공유하는것은 약점에 속한다
• Public Key: Key pair - public/private
  • 오너가 private key를 가지고, 아무나 public key를 사용할 수 있음
  • RSA 같이 복잡하고 비싼 (계산적으로) 암호화 형식을 사용한다
  • Public key Infrastructure (PKI)를 사용한다.

위와 같은 trade off를 좋게 이용하기 위해

1. public key를 이용하여 shared key를 보낸다 - private key를 가진 소유자만 decrypt 할 수 있으니까
2. shared key를 이용하여 추후 커뮤니케이션을 암호화 한다 (기밀성 보장)
   • 이 shared key = session key이다
     • 짧은 기간동안 매 패킷에 사용된다
     • 크기도 상관이 없다 (키 숫자 말하는듯)
     • 빠르게 키를 바꿀수도 있다.

즉 “야 나랑 이야기 하려면 이 shared key 통해서 암호화 해서 보내” 위에서 말했는 shared key가 계산적으로 싸고 빠르기 때문에, 이 shared key를 안전하게 보내는 비싼 계산 방법인 public private 은 처음에만 쓰는거.

세션 키

Authentication and Integrity

Authentication : 해당 사람에게서부터 해당 인원에게 도착한건지 (인증)

Integrity: 해당 메세지가 변질되지 않았는지 (무결성)

• Confidentiality 는 수동적인 빌런들에게 굉장히 효과적이다
  • 수동적인 빌런들은 패킷을 읽지 못하며, 자원들을 autheticate 할 수 있어서 안전
• 능동적인 빌런들은 메세지가 전달되는 과정을 노릴수 있다 (intruder)
  • 이로 인해 잘못되고, 오해되고, 혹은 고장난 메세지가 전달 될 수 있다
  • corrupt, replay, reorder packets.
    • WAIT DO NOT STOP —> STOP DO NOT WAIT 과 같이 말이다
• 이로 인해 message integrity가 필요한것
  • 세션 키를 사용한다 (PKI를 통해 세션키를 생성)
  • 메세지의 서머리를 계산한다 (시그네쳐, message digest, hash…)
    • 서머리를 세션키/개인키 를 이용하여 암호화 한다.

Freshness

Replay attack: 공격자가 해당 메세지를 가지고 계속해서 보내는식의 공격이 가능하다

• 예를 들어 A로 100불 보내기 를 여러번 보내는등

물론 이 공격은 timestamp를 메세지나, 시그네쳐에 적어두면 무력화 시킬수 있다 (물론 암호화 시켜야함)

암호화 사용하기

• 각 어플리케이션은 이제 스스로 다음과 같은 사항을 프로토콜에 적용할 수 있다
  • confidentiality
  • authetication
  • integrity
  • freshness
• 물론 우리는 개발자, 언어, 운영체제들을 믿지 않음으로 네트워크에도 적용한다

네트워크 보안

SSL - Secure Socket Layer

HTTP의 보안을 위해 만들어짐 → HTTPs

또한 Transport Layer Security (TLS) 를 generalize 하는데 공헌도 함.

→ Between transport and application layer: encrypts TCP payloads

• SSL/TSL (TSL is SSL 3rd version edited one) provides
  • 클라이언트에 의한 서버 확인 절차
  • 메세지 교환 (기밀성, 무결성, 인증, freshness)
• 인증 phase로 시작한다
  • 암호화된 채널과 세션키를 생성하기 위해 인증부터 시작
  • 그 전까지는 어느 한 메세지도 교환되지 않는다
• 클라이언트는 새로운 (랜덤한) 서버를 인증해야 한다
  • 네트워크 트래픽이 spoof and misdirected 될 수 있기때문
  • 서버 public key, 그리고 인증된 CA 가 필요하다

이 밑의 SSL의 간단한 순서를 보면 알 수 있다.

1. Handshake - 처음 세번은 TCP와 같이 똑같이 핸드셰이크를 한다 (세션 빌드)
2. 헬로 메세지를 보내고 상대방은 공개키와 인증서 (CA)를 보내온다
   1. 따라서 우리는 상대방이 올바른 사람이라는것을 알수 있다
3. master secret key (MS)를 생성후 받은 공개키를 이용해서 상대방에게 보낸다
   1. 상대방은 자신의 private key를 이용해 decrypt 한다

— 이제 양쪽 모두 MS를 가지고 있다 —> 모든 암호화와 데이터 무결성 검사를 위한 대칭 세션키로 사용된다.

물론 한가지만을 이용하면 위험하니, 특별한 방법을 거쳐서 암호화 키, 세션 MAC (무결성 검사) 키를 두개씩 총 네가지를 만들어낸다 —> 총 네가지의 세션키를 공유하고 있는것.

Public Key Infrastructures

• 인증서 발급, 인증서 관리
• 인증서 배포, 인증서 사용
• 인증서 저장, 인증서 취소
• CA = Certification Authority
• RA = Registration Authority
• VA = Validation Authority

단 한가지 Certificate Authority는 당연히

• 너무 많은 유저 (네트워크) 를 상대하기 쉽지 않으며
• 한번 실패하면 큰일나며
• 타겟 되기가 너무 쉽고
• 만약 이 authority가 corrupt 해서 독주체제로 가면 믿을수 없어짐

따라서 이를 방지하기 위해 레벨별 다양한 CA를 가진다

• 크롬의 경우 70여가지의 CA 를 가지고 있으며
• SSL/TLS initiation 의 server CA 또한 다양하게 확인한다.

물론 이러한 인증 절차는 상대방이 해킹을 당했으면 다 쓸모 없음 (이미 해킹해서 다 아니까)

• private key 가 이미 해커에게 털렸고
• Certificate 은 반려가 되어야 한다 (털렸으니)
• 이러한 상황을 위해 PKI는 Certifacite Revocation List (CRL) 을 소지하고 있으나, 이런 일은 자주 일어나지 않음

또한 DNS 는 UDP base 임에 따라 spoofing 이 쉽다.

DNS Poison (pharming)

DNS의 경우 Nameserver가 해당 도메인에 대해 아이피 주소를 물어보는 형식임

또한 DNS는 단 세가지만을 체크하는데,

1. 알려진 서버로부터 온 응답인가
2. 아이디가 동일 한가
3. 현재 물어본 쿼리에 대해 해결책을 제시하는가?

따라서 이 안의 내용에 대해서는 전혀 관여를 안한다. 즉 위 세가지 방식을 만족한다면, 잘못된 주소를 알려줘서 유저가 감염된 사이트로 방문하게 만들수 있는것.

이 응답은 여러곳에서 오는데, 제일 먼저 오는것만 채택하고 후의 것들은 무시한다.

따라서 해커의 응답이 제대로된 서버의 응답보다 먼저 도착 한다면, 제대로된 서버 응답의 경우 무시되는것.

DNS 보안은 기밀성에 대한것이 아닌 integrity and authentication 에 중점 (위 해킹이 authentication의 부족에서 온것을 기억하자)

내용의 기밀성은 상관이 없다. 맞기만 하면됨.

DNSSEC:

• RRSIG - 도메인 레코드 셋 (배운 A, AAAA, MX 등등)에 대한 디지털 서명
  • 즉 이 데이터 셋은 이 디지털 서명에 의해 보장됩니다! 이런거
• DNSKEY - RRSIG를 위한 public key
  • (Zone Signing Key (ZSK) and key signing key (KSK)
    • KSK >> ZSK 인데 이는 네임서버의 키-체크 부담을 줄여주기 위해서이다.
    • KSK, ZSK 둘중 하나를 사용한다. Zone 의 공개키로 사용된다.
  • ZSK : Zone 의 모든 RR 서명에 사용되며, 암호화 비트와 기간을 짧게 사용
  • KSK: ZSK를 서명하기 위해 사용한다. Zone의 Security entry point 로 사용됨 (암호화 비트와 기간을 길게 사용한다)
• DS (Delegation server key) - public key for delegated zones
  • 부모 자식간에 인증 사슬을 형성하며, KSK를 사용하여 신뢰사슬을 만들어 부모 zone 에 제출

다음과 같은 사항들을 필요로 한다

• 암호화 오버헤드 감소

  • DNS는 매우 유명한 프로토콜이며 항상 사용되기 때문에 딜레이를 최소화 해야함
  • 또한 다른 암호화 기술이 사용될수 있도록 해야함 (개방적)

• 다른 Resource Record (RR) - NSEC (next secure record)

  • DNSSEC의 일환으로, 해당 레코드가 non-existence 한지를 체크하기 위해서 사용된다 (즉 해당 레코드의 존재 확인을 위해 존이나, 타입 리스트에 대한 링크를 가지고 있는것)

    부정적 대답에 사용된다. 즉, 네임이 존재하는지에 대한 증명에 사용된다.

  • 실제로 질의한 도메인이 존재하지 않는 도메인이거나 레코드가 존재하지 않는 경우 zone내에 각 도메인들을 sorting하고 그 순서에 맞는 domain을 NSEC으로 응답

  • NSEC3는 Return되는 도메인을 Hash 함수처리

  • 이는 zone information을 유출한다.

DNSSEC 이 반영된 DNS 절차

• 똑같이 네임서버에 대해 쿼리 하는것으로 시작한다
• 온 답변들을 인증을 이용하여 validate 한다
  • Top to Bottom 형식이며 PKI chain of trust 이다
  • 또한 사실상 root 는 검증하기 불가능하므로, 검증되었다고 가정하고 질의를 시작한다
    • 이를 anchor on root public key 라고 말한다. root 공개키를 가정 (anchor) 해서 시작하니까
  • 각 도메인을 타고 내려가며 각 도메인또한 관련 키를 사용하여 검증한다.

모든 DNS 들이 사용하지는 않는다 → 늘어가는 추세이나 아직 100프로 아님

SSL/TSL 은 어플리케이션과 네트워크 계층 사이의 보안을 보통 담당하는데…

• 마찬가지로 여러번 이미 뚫렸음
• 코드, 암호, 혹은 프로토콜간의 접촉 등등 여러 이유로
• 모든 어플리케이션이나 다른 계층들이 모두 사용하는것도 아님

Firewall

패킷들을 막아내는 edge (보더) 라우터, 게이트웨이, 프로세서들

Middlebox

라우터는 보통 IP만 검사하지만, middle box역할도 겸하고 있다.

Packet Filter 는 다양한 방식의 정책으로 가능하다. 또한 각 패킷당 개별적인 검사를 시행한다 (stateless)

이는 연결에 대한 state가 아닌 각 패킷은 항상 검사 된다는것

• IP주소 기반
• UDP/TCP, ICMP, OSPF … 등등 프로토콜 기반
• 포트 넘버 기반
• TCP flag bits, ICMP message type 등등

Stateful packet filter:

state는 패킷이 아닌 연결에 대한것을 상기한다 (연결이 안에서 밖으로 시작되어야함)

⇒ 그래서 reverse_https 같은 기법들이 존재하는거.

• 패킷 플로우를 내/외부 차이점을 기준으로 검사하는 방법
• 예를 들어 NAT의 경우:
  • 내부에 있는 Y가 시작하여 만들어진 TCP 연결에 대해 외부의 X가 Y에 대해 패킷을 보내는것을 허용
  • 즉 TCP연결은 안에서 밖으로만 initiate가 가능하고, 바깥에서 안으로 들어올때는 해당 테이블을 보고 연결 검사를 진행해야 한다.
• 안에서 밖으로 연결 시행이 가능하기에 모든 연결은 테이블에 기록이 가능하다.

Application Firewall - Deep Packet Inspection

• 어플리케이션 프로토콜을 이해함
  • 메세지를 확인후 다시 재조립하여 해당 목적지로 보내줌
  • 컨텐츠를 이해한다 (즉 이메일, 웹페이지 바이러스 검사가 여기서 이루어지는것)
• 물론 해당 패킷을 열어보고 검사후 버리기때문에 (여태는 걍 버렸음) 퍼포먼스 하락이 이루어짐

왜 가능하냐면, 메세지 자체는 이미 최종 목적지, 어플리케이션에 도착해서 다 풀린 상태임. 이 방화벽이 하는 역할은 이 decrypt 되어서 우리한테 최종 전달되기 직전에 검사를 하는것.

또한 기기마다 중요도가 다르기 때문에 여러 단계로 나누어서 다른 레벨의 방화벽 설정도 가능하다. 방화벽 간의 사이를 DMZ라고 부른다

Firewall Implementation - 설정 방법

• 허용된 기기들 : 특히 어플리케이션/DPI 방화벽
• 라우터/ 모뎀
• Wireless access points
• OS based hosts - 리눅스 아이피테이블 (리눅스 기반 아이피 테이블) 패킷 필터

여러 방화벽을 사용할 경우 당연히 더 많이 신경써야 하고 느려지지만, 내부의 공격도 막을수 있으니 장단점이 존재

Firewalls = Islands of trust

• SSL 은 모든것을 숨기지 않는다
  • 중간 라우터들은 트래픽을 볼 수 있음 (활동에 대한 정보가 새는것)
• Leased Lines (내 개인망) - 이러면 트래픽을 숨길수 있음
  • 효과적이지만, 돈도 들고 (즉 크게 못함), 해당 라우팅에 대한 설정도 따로 필요함

따라서 SSL의 단점과 Leased lines의 단점, 즉 트래픽의 노출과 비용부담을 모두 보완하기 위해 아이피 (네트워크) 레벨에 보안을 적용해서 virtual leased line 을 만든다 ⇒ Virtual Private Network

Islands of trust - VPNs

사설망 (LAN) 처럼 공용 인터넷 망을 사용하는것. 하지만 ISP를 사용하되 이 ISP가 보지 못하도록 따로 암호화 기법과 해당 라우터안의 체계나 기법등을 비공개 하는것.

VPN은 그냥 각 컴퓨터나, 라우터가 IP 데이터그램을 암호화 시켜서 보내는거.

이 VPN으로 이루어진 암호화가 진행되는 기간이 터널링이다.

https://travelerstory.tistory.com/91#:~:text=IPSEC(Internet Protocol Security)은,된 인터넷 보안 표준입니다.

Modes

Tunnel (=encapsulation) IP packets across the internet (IP in IP)

물론 단순한 터널링은 아무런 보호성도 가지고 있지 않음, 그냥 헤더만 하나더 붙임

• No confidentiality, authentication, integrity

IP Security 을 이용해서 VPN connection 을 secure 하게 establishment 하는것

• 네트워크 레벨에서의 암호화
• 종단간의 (호스트, 라우터) 키 공유
• 패킷의 캡슐화및 보호화

VPN Endpoints 는 위에서 말했든 호스트, 라우터 두개의 종단간에 가능하다

• Tunnel Mode: Router and Router (with forwarding)
  • 모든 서브넷을 투명하게 연결시킴 (하나처럼 보이게 터널로)
    • 라우터간 연결되었으니 서브넷 두개가 하나처럼 보이는것.
  • NAT friendly (라우터가 관리 터널끝이니까, 요즘 NAT은 라우터에 같이 있음)
  • New IP header는 라우터의 주소이다 - 종단 라우터에 도착하면 (터널끝), 패킷 풀어서 해당 기기에 보내주는것 (즉 터널 밖으로 나오지 않는 이상 어디로 가는지 모름)
• Transport Mode: Host and Host (no forwarding)
  • 다른 포맷으로 오직 IP payload만 암호화 한다 (라우터 합침을 통한 서브넷간의 통합이 아닌 두 호스트간의 LAN 같이 사용하는거)
    • 이로 인해 트래픽이 어디서 어디로 가는지 경로가 유출됨 (최종 목족지)
  • 문제는 해당 아이피가 NAT 에서 사용되는 경우 사실과 다를수 있기 때문에, 이를 위한 PSK를 통한 인증이 필요하다. 그렇기 떄문에 NAT challenge

내가 헷갈려한 것은, VPN 서버를 이용할 경우 (나라 장벽떄문에) 이게 어떻게 진행되냐는건데,

VPN을 통해 나라 장벽을 우회하려면, 해당 VPN 서버에 대해 터널 모드를 만들어서, VPN 서버에 도착하면 내 원래 목적지 주소를 알려주고 거기에서 다시 목적지로 향하는것 (해당 VPN 서버에서는 무슨 모드이건 그건 이제 선택사항임).

장벽 우회같은 이유가 아니면, 그냥 공공망 바로 터널이던 전송이던 알아서 쓰면됨.

AH 는 기밀성을 보장하지 않음, ESP는 다 보장함.

ESP(Encapsulating Security Payload)

새로운 데이터 IP Packet을 만들고 기존 IP Packet을 Data Payload에 넣어 감싸는 방식

• AH (인증) 가 가진 무결성과, 인증도 제공하고 추가적으로 대칭키 암호화 (PSK) 를 통해 기밀성(Confidentiality) 제공

Tunnel Mode

즉 위의 터널 모드는 애초의 목적지인 IP header 까지 암호화 시키니, 미아가 되지 않도록 터널링을 담당하는 장비 (라우터) 의 아이피를 적어서 보낸다. 즉 라우터간 (터널) 동안에 기밀성이 보장된다 (물론 이 라우터로 가고 있다는 트래픽 경로의 경우 유출이 되니 - 어느정도의 기밀성이 보장된다 가 알맞다).

따라서 해킹을 위해서는 A, B 혹은 라우터 장비의 물리적 회선망 (A나 B로 향하는)에서나 가능하다.

터널내에서는 esp가 존재하므로 암호화에 따라 해킹이 매우 힘들다

Transport Mode

만약 해당 네트워크가 NAT를 이용하면, 수신자 측에서 검증시 인증에 실패 할 수 있기에, PSK를 사용하여 서로 인증을 해야함 (그래서 NAT Challenge )

또한 전송 모드는 단대단 간의 연결 (TCP 처럼) 을 보호해주기에 Transport layer의 보안으로도 사용될수 있다.

터널 모드와 다르게 전송 모드는 패킷 페이로드만 보호해주며, 이로인해 경로 유출이 일어난다.

아까 위에서 말한 헷갈린점은 VPN 사설 서버를 이용하는 경우에 터널 모드를 사용하니 결국 어디로 가는지 모름 공용망 시점에선.

VPN 주의점

• 이 종단 라우터 또한 반드시 해당 기기에 가장 가까운 라우터라는 법은 없음. 단지 그냥 터널링을 끝내는 라우터에 불과함 (즉 해당 라우터에서 해당 기기까지 가는데 다른 라우터를 지나갈수 있음)
• 따라서 end-point에서부터는 누가 누구에게 이야기 하는지 알수 있음
• 보통 아이피는 위치에 따라 지정된다

결국 터널링이 끝나는 순간 보호되지 않은 트래픽이 된다 → 여전히 보안의 위험성 존재

따라서 이러한 상황을 더 나아지게 하기 위해 더 많은 터널링을 하는식으로 보완한다.

Onion routing = onion encryption

• 랜덤하게 세가지 노드를 선택한다 - 가드/미들/출구
• 클라이언트는 해당 세가지 노드에 대한 public keys를 가지고 각각에 대해 세션키를 만든다.
• 클라이언트를 각각의 세션키를 이용해 모든 패킷들을 암호화 한다 + 서버가 필요한것 포함

물론 이 방식은 세가지의 중간 노드만 정확히 지정해 둔거고, 이 노드를 방문하는 라우팅 알고리즘은 공용망에 맡긴다 (알아서 데려가줄텐데, 이 세 가드 미들 출구만 정확히 지나가면됨)

따라서 이는 MPLS (multi protocol label switching) 과는 다음과 같은 이유로 다르다

MPLS는

• 미리 모든 경로를 지정해둠 (onion 의 경우 세개만 지정)
• 패킷들은 토큰으로 레이블되어 있음 (onion은 세션키로)
• 경로중 하나만 죽어도 다 실패함 (onion은 맨끝만 죽으면 실패한다 - 주는사람 or 받는사람)

Physical Security

Device Security

• 스위치와 라우터는 물리적이고 가상적인 인터페이스를 가지고 있음
• 원격 엑세스
  • SNMP agents (HTTP)
  • OS (Telnet ssh)
  • Port monitors and mirrors
    • 다른 포트에 대한 트래픽을 반영하며, 바깥에서는 알수 없는 정보
• 물리적 엑세스
  • 인터페이스 재정렬 (denial) 혹은 공격
  • 케이블 절단, 방해
  • 칩 레벨 스누핑

Copper Security

여기서 말하는 보안은 이를 이용한 데이터 보안이 아닌, 말 그대로 코퍼에 대한 보안임

attenuation등이 원래 발생하는 라인이기에, 문제가 생겼는지 발견하기가 쉽지 않음

자르기도 편하며, 누군가 케이블 자체를 (라인이던 쉴드던) 건드리면 denial of service (noise, antenna, energy loss) 등이 발생함

Fiber Security

코퍼에 비해서는 발견하기가 쉬운데 케이블 특성상 loss 가 발생하기 어렵기 때문

물론 선 절단이던 tapping (금가거나 등등) 은 코퍼와 마찬가지로 쉽게 발생한다. 그래서 NSA에서 해저 밑바닥에 깔아둠.

Wireless Security

• 무선은 특성상 브로드케스트 이기때문에
  • 좁은 beam 안테나와 짧은 wavelength 가 도움이 된다
• 빌런들이 듣고있으며, 적극적으로 intrude 할 수 있음
• 물론 access 에 관한 말이고, 해당 패킷이 암호화가 잘 되어있는거는 다른 이야기

802.11

기기와 wifi 사이 (무선연결) 의 payload에 대한 암호화를 책임지고, 해당 데이터가 와이파이 라우터에 성공적으로 전달되면, 해당 암호화를 풀고 선 (물리적)을 이용해서 목적지로 전달한다

즉 무선 기기간의 암호를 책임지는 프로토콜임

Wifi Network Keys

Layer 2

• 클라이언트가 AP에게 인증한다
  • 클라이언트가 AP에게 요청하면 AP가 수락하고, 등록후에 더 많은 키를 나누어준다
  • 각각 SSID password (pre shared key -PSK)로 부터 얻은 공유 세션키를 계산한다.
    • 이 공유 세션키를 이용해서 PMK, GMK 를 생성하고 이 마스터 키들이 이후의 PTK, GTK 유도하기 위해 사용되는 보조키 역할을 한다.
    • 여기서 만들어진 Pairwise Transient Key (PTK) 를 무선구간 암호화를 위해 사용한다
• AP to Clients (broadcast/multicast)
  • Group Temporal Key 를 이용하는데 마찬가지로 무선구간 암호화를 위해 사용한다.
  • PTK와 다르게 브로드캐스트, 멀티캐스트용이다.

1
2
3
4
5
6
7
8
9

구분 
     - 4-Way Handshake
        . Pairwise Key,Group Key 생성을 위함
     - Group Key Handshake
        . 이전에 4-Way Handshake을 통해서, PTK 및 GTK를 확보한 STA에게,
          Multicast/Broadcast용 데이터 암호화를 위한 GTK를 분배하기 위한 2-Way Handshake 임
        . 사실상, 위 4-Way Handshake에서 끝에 있는 2번의 메세지 교환 단계와 동일함
     - PeerKey Handshake 
     - TDLS PeerKey Handshake

원래는 Station - AP - Authentication server 로 이루어져야 한다.

1. AP 가 클라이언트에게 제공 가능한 서비스들을 알려줌
2. 먼저 서로 인증을 위해 EAP 를 이용해서 메세지를 전달한다. 클라이언트와 무선은 EAPOL을 통하고, 무선과 인증서버는 RADIUS라는 프로토콜을 이용해 인증한다. 이 과정중 마스터 세션 키를 생성한다
3. 마스터 세션키는 클라이언트와 인증 서버만 가지고 있는데, 이를 이용하여 PMK를 만들고, 인증서버가 이를 AP 에게 보낸다.
4. PMK를 이용하여 PTK를 생성한다.

802.11i [정보통신기술용어해설]

Wifi Encryption

WEP: 64 bit, 128bit 등을 이용해서 암호화키를 생성해 보안을 유지하지만, 이 키값이 일정한 값을 유지해서 취약점이 노출되었음

WPA: Use of PSK (password)

• 더 나은 integrity 체크가 가능함
• Temporal Key Integrity Protocol (TKIP) - 프레임별 키
• WPS로 인해 뚫릴수 있음

Denial of Service

• Ping of death (3)
  • Large ICMP packet, multiple fragments, modified headers.
  • 메모리 오버 플로우 일으킬 수 있음
  • 호스트에 대한 직접적 공격
• SYN Flood (4)
  • 서버에 TCP 연결 생성하고 해당 SYN/ACK 를 따르지 않고 마구잡이로 보냄
  • 이로 인해 서버는 connection state를 유지해야함 (왜냐면 얘가 뭔지 모르니까 각각 하나씩 생성)
  • 이 방식은 SYN 쿠키를 사용하면 피할수 있음 (즉 커넥션을 ACK이루어진 이후에만 생성하는것)
• Application layer messages:
  • 복잡한 쿼리들 (complex regex or big database queries) 보내기
  • 메모리 오버플로우
  • 다른 버그들
• Spoofing
  • 다른 컴퓨터를 이용해서 공격하는 방법
  • 예를 들어 공격자가, 나는 A이고 B야 메세지를 보내줘 하고 B에게 보내면 B는 A에게 메세지를 보내는 방식
  • Ingress filtering 은 중간에 이 공격자가 A인지 확인하는 절차를 넣는것이다.
    • 물론 소스는 확인 불가능하고, 단지 해당 네트워크에서 보내진것인지 확인하는것
    • 즉 내가 A (네트워크 1) 라고 주장하면서 해당 아이피가 네크워크2에서 오면??
    • 근데 아직 대중화는 안됨
  • Host multipliers: Zombie host 같은거
  • Packet multipliers: Small requests, big responses
    • DNS: “I want the entire list of this” - 리스트 크기가 큼
    • HTTP/FTP/NFS… : “Send me 10GB file”
    • Memcache servers: Database accelerators over UDP
  • SMURF:
    • 브로드캐스트 주소를 핑함
    • 목표물의 아이피 주소를 자원으로 삼음 (spoof)
    • 모든 사람들이 해당 아이피에 답변을 함 (many packets are back)
    • 물론 이 방식은 prevent 하기 쉬움

Mitigation - DoS 피하는 방법 (매우 어려움)

• Content Distribution Networks : Dont be a single target
• Edge Routers/Attacker Detection: 효율적인 패킷 드롭, 좋은 필터링 셋팅 (한명이 담당/ 공격감지)
• Upstream provider support: 다른 방향으로 돌려버리기 (re-route)
• Ingress Filtering: 네트워크 레벨 확인 절차