네트워크 보안 요구조건
1) confidentiality
sender와 receiver 사이의 msg를 제 3자가 몰라야 한다.
이를 가능하게 하려면 암호화 기법을 사용한다.
2) authentication
sender와 receiver 사이의 관계를 확신시키기 위한 인증이 필요하다.
3) message integrity
sender가 보낸 msg가 변형되지 않고 receiver가 받는다
4) access and availability
서비스를 제공하는 사람은 사용자에게 서비스를 24시간 내내 제공가능해야 한다.
다음의 요구사항들은 굉장히 중요한데 인터넷 TCP ip프로토콜 스택에 하나도 들어있지 않는다. 이 개념들은 프로토콜 스택에 들어가지 않고 어떤 공격을 받을때마다 바로 처리를 하는 방식으로 알려져 있다.
1) confidentiality
Trudy는 모두가 될 수가 있다. wireshark 프로그램을 사용하면 동일 wifi에서 진행되는 모든 packet을 볼 수 있다. 현재 인터넷 상황은 모니터링에 노출되어 있다.
모든 packet을 볼 수 있다는 것은 결국 [ header | data ] 부분의 header의 src IP와 dest IP를 알 수 있다. 또한 DATA(TCP segment)의 [ header | data ] 에서 DATA에서도 어떤 msg가 있는지까지 TCP segment도 알 수 있다. 이제는 HTTPS 를 이용해서 TCP segment의 msg는 숨길 수 있다. 그래도 header의 src IP와 dest IP는 알 수 있다.
- 그러면 source와 dest IP는 어떻게 숨길 수 있을까?
TOR 프로그램에서 overlay relay circuit 방식을 이용하여 최종 목적지를 계속 감춰서 internet acitve를 숨기기가 가능하다. 이 프로그램을 사용하면 익명성을 완전히 보장할 수 있지만 굉장히 느리다는 치명적인 단점이 있다. 그 이유는 여러 서버를 거쳐서 탐색하기 때문에 매우 느리다.
- warning 서버는 왜 접근이 불가능한 것일까?
한국의 경우 접근이 불가능한 차단된 사이트들에 대해서 blacklist를 만들어서 warning을 보낸다. 예를 들어 해외로 접속되는 router에 blacklist 를 줘서 blacklist에 접근하려는 user에게 warning을 보내는 방식이다.
- 그렇다면 해외로 접근하는 방식이 아예 없을까?
1) 해외에 존재하는 open proxy server로 우회하여 접근한다.
우리나라는 해외에 존재하는 proxy server는 막지 않았기 때문에 접근이 가능하다.
해외 proxy server의 ip 주소도 알 수 있으므로 blacklist를 proxy server에게 넘기면 우회경로도 모두 통제된다.
2) ...
강력한 firewall이 있어도 우회가 가능한 server
- 그러면 어떻게 해외불법사이트에 접근하려고 할때 "warning"을 client에게 띄울까?
예를들어 A가 google에 접근하려고 하는데 google에 대한 접근이 차단됐다고 하자.
1) A는 google과 TCP connection을 맺어야 한다.
google의 packet에 srcIP: A의 IP, destIP: google의 IP가 담겨서 보내질 것이다. 그러면 한국의 gateway router 에선 해당 packet의 dest IP를 보면 해당 packet을 drop 시킨다.
그럼 A는 TCP connection이 연결되지 않는 error가 뜰 것이다. (404 , warning 모두 html로 TCP 연결 후에 나타나는 에러다.)
그러나 이렇게 차단하지 않는 이유는 1) 정부가 전달하고 싶은 Warning msg가 전달되지 않고 2) client는 그저 네트워크 오류라고 이해할 수도 있기 때문이다.
Warning msg를 전달하려면 애초에 TCP connection이 필요하다. 그럼 client A의 packet을 google에게 보내고 TCP connection을 client A와 google이 맺게끔 한다.
2) HTTP request
그럼 client A의 host field가 request인 것을 gate way router에게 걸리면 destIP: A의 IP srcIP: google의 IP로 (거짓)으로 두고 WARNING.html 파일을 client A에게 전달한다.
(클라이언트 A) warning 파일을 받음
(구글) timeout 이 발생하여 연결이 끊김
즉, 한국은 IP주소로 검열하는 것이 아닌 HTTP request를 이용하여 인터넷을 검열한다.
암호화 방법
elice는 plaintext를 ciphertext로 암호화 key를 이용해 암호화한다.
bob은 자신의 key를 이용하여 ciphertext를 plaintext로 해독한다.
여기서 암호화는 1) Symmetric key cryptography와 2) Public Key Cryprography
1) symmetric key
- 연산이 빠르다
- 문제점
- elice와 bob이 동일 key를 공유해야 한다.
elice와 bob이 사전에 만나지 않아도 key를 공유하는 문제점을 해결하는 방식이 나타났다.
2) public key
- 모든 사람이 각자 두가지 종류의 key를 가지고 있다.
1) public key 와 2) private key를 가지고 private key는 자기 자신만 가지고 public은 모두가 볼 수 있게끔 한다. 그러면 elice는 bob의 public key를 이용해 암호화한 text를 보내고 그에 해당하는 private key로 bob이 해독할 수 있다. (해당 암호화 방식은 RSA 알고리즘에 의해 구현되었다.)
- 어떤 키를 적용시키든 간에 그 결과는 동일하다.
public key방식은 연산이 너무 많아 간단한 msg 전송의 경우 먼저 public key로 symmetric key를 안담에 symmetric key로 그 이후의 msg를 소통한다. 두 방식을 혼합하여 사용한다.
2) Authentication
Bob은 Alice를 검증하기 위해 random # 를 보내고 Alice가 보낸 암호를 복호화하여 인증한다.
Alice는 private key를 이용하여 암호화하고 Bob은 Alice의 public key로 복호화하여 Alice임을 알아낸다.
digital signature
msg가 중간에 변형되지 않았음을 검증하려면
원래 msg를 Bob의 private key로 암호화한다.
Alice는 위의 msg를 Bob의 public key를 적용시켜 원래 msg를 알 수 있다.
여기서 msg의 private key는 Bob만 알고 있으므로 중간에 변형되지 않음을 확인할 수 있다.
msg의 전체를 암호화하는게 아니라 hash값을 암호화한다.
결국 Digital signature를 "signed message digest"로 이해할 수 있다.
- 그러면 Alice는 Bob의 public key가 맞아야 위의 인증과정이 정확하게 동작할 수 있다.
즉, Alice는 Bob의 public key인지부터를 확신할 수 있어야 한다.
현재는 public key를 인증하는 "공인 인증서"를 발행받는다. 인증서는 인증기관의 public key로 signed 되어 있고 그 인증서에는 누구의 public key 를 형식으로 알 수 있다.
그러나 인증기관의 public key는 internet browser 안에 내재되어 있어 공인인증서의 public key에 대한 검증은 필요하지 않다.
SSL 과 TCP/IP
인터넷을 사용한다는 것은 대부분 application layer에서 웹브라우징을 하는 것이다. HTTP 프로토콜은 TCP 기반의 통신이여서 TCP가 제공하지 않는 기능은 HTTP가 사용을 할 수 없다. HTTP 어플리케이션 메세지를 TCP 소켓으로 내려보내서 통신되는데 보안을 제공하지 않는다. 따라서 이 메세지는 TCP를 통해 제공할때 보호를 받을 수 없다.
- 이런 침해를 응급처치를 하기위해 제공한 기능이 SSL이다.
이 SSL은 그저 Application layer 에 있는 라이브러리이다. 사용자 계층에서 HTTP msg가 SSL 인터페이스로 전달되고 SSL 라이브러리에서 보안적인 기능을 한 이후에 TCP 소켓으로 통한다. 결국 TCP 사용하되 msg가 암호화돼 TCP로 내려오는 개념인 것이다. SSL(Secure Socket Layer)소켓으로 들어가는 하나의 layer같진 않은 layer 개념이다.
- 최근엔 SSL대신 TLS 용어를 많이 사용한다.
Transport Layer Securty라는 용어로 TCP 상의 통신임을 좀더 명시한다.
- HTTPS (HTTP + SSL)
HTTP 메세지를 TCP 소켓을 통해 전달하는 것이 기존에 알고있던 가장 basic한 개념이다. 여기에 보안적인 기능을 추가하여 SSL 라이브러리를 적용하여 HTTP request-response 메세지를 암호화하여 소켓을 내려보내는 것을 HTTPS라고 한다.
- SSL 통신의 과정
다음은 SSL 통신과정에 대해 정밀히 알아보자.
SSL 통신
- 1) 최초의 기본 동작으로 TCP connection이 이루어진다.
SSL은 TCP 기반이므로 TCP connection이 이루어져야 한다.
- 2) Bob이 공개키 인증서를 Alice에게 전달한다.
Alice는 여기서 받은 공개키를 인증기관의 private key로 암호화된 것을 확인하여 Bob의 공개키가 true인지를 확신한다.
- 3) Alice는 secret key를 만들어서 Bob의 public key로 암호화하여 보낸다.
Ks+(SK) = EMS
- 기타
추가적으로 SK(비밀키)를 공개된 function으로 4가지 키를 만들 수 있고 각각은 모두 용도가 다르다.
1번 key: client -> server로 가는 data를 encryption한다.
2번 key: client -> server 의 data integrity를 보장한다.
3번 key: server -> client로 가는 data를 encryption한다.
4번 key: server -> client 의 data integrity를 보장한다.
목적) 키가 유출되었을때 그 피해를 최소화하기 위해서 4가지 키가 필요하다.
서버가 자기자신의 인증서를 제공하는 방식이다.
- SSL 통신의 데이터 구조
application: msg, transport: segment, SSL: record
msg를 record로 만들고 TCP로 보낸다.
이 record 에는 MAC (Message Authentication Code) 필드가 추가로 붙는다.
H(data | Key(client <->server)) : receiver가 받았을때 중간에 변조되었는지나 수정되지 않았음을 보장하는 용도이다. 이를 MAC에 붙여서 보내는 것은 attacker가 할 수 없는 부분이다.
- SSL -> TCP
TCP의 segment는 다음과 같은 구조이다. [header | Data (record) ]로 보내면 데이터가 암호화되어 볼 수 없다. 이렇게 되면 IP packet과 segment는 볼 수 있으나 그 안에 msg는 record로 암호화돼있으므로 알 수 없다. Attacker는 결국 record를 알 수 없으므로 수정도 불가능하고 읽을 수도 없다.
- 그렇다면 attacker는 어떤 일을 할 수 있을까?
SSL 데이터가 담긴 패킷은 연속적으로 전송이 되는데 attacker는 1) 그 순서를 바꾸는 방해공작을 할 수 있고 2) 메시지가 도착하지 않았는데 SYN을 중간에 보내는 공격을 할 수 있다.
- 그럼 packet들의 순서 공격이 없게끔하려면?
SSL record의 순서를 구분하는 sequence #를 부여한다.
- 메시지가 도착하지 않았는데 scene을 중간에 보내는 공격을 할 수 있다.
데이터가 다 도착하지 않았는데 TCP SYN을 보내서 이미 데이터가 모두 도착한것처럼 꾸민다. Type (1bit)를 둬서 Msg Authenticated Code에 넣는다. 결국 Type이 0이 올때까지 기다리고 그 전에 끊기면 TCP SYN을 무효처리한다.
MAC은 사실 hash 함수를 통과한 후 그 결괏값이므로 아무리 필드를 늘린다고 해도 그 크기가 커지진 않는다.
실제 SSL은 각자 만드는 알고리즘에 대한 협상 정보가 담긴 cookie가 들어간다.
application msg를 datafragment(plain text)로 쪼개짐
-> MAC 을 붙임
-> MAC을 포함한 전체를 암호화함
-> recorded hdr + 위에 암호화된 부분 을 보냄
firewall
하나의 네트워크의 gateway에 자리하여 외부에 나가고 들어오는 packet을 감시하는 모니터링 필터링 디바이스이다.
네트워크를 가진 대부분의 기관에 firewall이 설치되어 있다.
일일이 모니터링하면서 어떤 packet을 통과시키고 필터링할지 결정하는데 이는 어떤 정책에 의해 네트워크 운영자가 결정한다.
다음은 firewall에 구현 가능한 여러 정책들에 관한 표이다.
위와 같은 내용들을 구현하려면 TCP header까지 알아야 한다. 원래 Router에서는 IP header까지 봐야하는데 Firewall이 등장하면서 TCP header까지 보고 행동하기 때문에 layering violation의 유명한 예시이다. (NAT, DHCP, DNS, Firewall 등이 포함됨)
- 두번째 행
외부로 들어오는 특정 서버로 들어오는 packet을 제외하고는 나머지 syn packet은 모두 drop 시킨다.
packet 하나하나를 봐서 firewall setting을 만족하는 packet들에 한해서 필터링하는 것이다.
아래는 firewall안에 들어가게 될 rule table의 예시이다.
1번 행은 웹브라우저로 나가는 것을 허용하는 것이고 그 다음은 들어오는 것을 허용하는 것이다. 즉 1번행은 request, 2번행은 1번에 대한 response, 3번행은 UDP로 request, 4번행은 3번 행에 대한 response이다.
- 그러면 위의 rule table을 사용한다고 SSH를 사용할 수 있을까?
아니다. SSH는 22번 포트를 사용하기에 사용하지 못한다. 그리고 TCP 기반에서 request, response가 오갈때 TCP connection이 존재해야 하는데 rule table은 TCP connection이 형성되지 않아도 허용해준다. 결국 모든 TCP connection 을 tracking하여 TCP connection이 있는 상황에서만 traffic을 허용한다.
