Packet 4

login

• 트위터의 로그인 방식
  트위터의 경우 https(SSL)로 연결로 인증 후 SSL 연결을 끊은 뒤 내부에서 http로 서치
  
  3-way handshake 후 TLSv1 프로토콜로 호스트의 키를 확인 한 후
  
  4-way handshake로 https의 연결을 종료하고, TCP 3-way로 http로 연결하여 사용

• HTTPS
  : 소켓 통신에서 일반 텍스트를 이용하는 대신, SSL이나, TLS 프로토콜을 통해 세션 데이터를 암호화, 인증과 기밀성

• SSL/TLS
  : 전송 계층 보안 암호 규약, TCP/IP 네트워크를 사용하는 통신에 적용, 통신 과정에서 전송계층 종단간 보안과 데이터 무결성 확보
  HTTPS 통해 통신 수행 할 때 세부적인 과정이 정의된 규약
  SSL/TLS 통신 시 도청, 조작, 메시지 변조를 방지

  • 작동방식
    Handshake: 통신 사이의 인증을 수행하고 암호화 필요한 버전 및 정보를 협의
    Record: Handshake 과정에서 공유된 정보를 이용하여 암호화를 수행, 한 번에 전송이 어려운 데이터를 여러 개로 나누어 암복호화를 수행하는 파트

• TCP Retransmission/Dup ACK
  
  Dup ACK: 목적지에 세그먼트 순서가 다르게 받아들인 경우
  총 3회에 걸쳐 확인되지 않은 경우 재전송을 진행 => Retransmission

• 페이스북의 로그인 방식
  페이스북의 경우 SSL로 연결한 후 SSL 연결을 끊지 않고 내부에서 3-Way handshake 없이 서치하게 함
  

지속적으로 PDU 전송과 ACK 시그널을 주고 받는 이유:재조립과정

모든 데이터를 받은 후 HTTP OK, 이후 4-way handshake으로 종료

• 우리가 사이트 접속 시 키를 묻지 않는 이유
  크롬의 경우
  설정> 개인 정보 보호 및 보안 > 기기 인증서 관리 > 인증서
  SSL로 접속 할 시 자동 Redirect되는데 이는 브라우저에 저장된 인증서 때문에 사용자가 별도의 키를 입력 할 필요가 없음

가상머신 BT의 Firefox로 SSL 접속 시 브라우저가 필요로 하는 키를 가지고 있지 않기 때문에 연결이 안 되거나, 신뢰할 수 없다는 내용의 동의해 주어야 함

Update

TCP 3-Way handshake 후 POST 명령으로 HTTP 프로토콜에 업데이트 함

POST명령어가 들어간 패킷의 TEXT DATA를 열어보면 해당 패킷의 내용을 확인 할 수 있음

message

메신저를 주고 받을 때 역시 3-way handshake 한 후 post하여 메신지 전송
해당 메시지는 Line-based text data로 확인 할 수 있음

외부로 접속이 안될 경우

인터넷은 라우터의 게이트웨이를 통해 접속, DHCP가 IP주소를 부여
위의 사진은 로컬에서 문제는 없음 외부에서 DNS 서버로부터 긴 시간 동안 응답을 받지 못함
두 개의 DNS 서버가 이름풀이를 할려고 시도 중 > Recursively

클라이언트의 IP주소 또는 게이트웨이 IP주소가 잘못 됨을 확인 할 수 있음
=> IP주소를 수동으로 설정하면 됨

외부 DNS 연결이 안되는 경우

172.16.0.102주소가 응답을 하지 못하는 중
102번이 웹서버가 아닌 것으로 판단할 수 있음 =>
102번이 죽었다면 RST 응답도 보내지 못하기 때문
연결이 안될 때 보통 이야기 하는게 reject(로그를 남기고 거부)와 drop(로그 없이 거부)

원인: 클라이언트의 웹서버에 대한 캐시가
로컬에서 HTTP를 요청하면서 DNS를 없다면 내부 웹 서버와 연결할려는 것
외부로 갈려면 DNS가 필요
DHCP 서버의 웹 주소가 바뀌었다고 판단 할 수 있음

윈도우의 경우: WINDOWS> SYSTEM32> Drivers > hosts
윈도우의 도메인 주소를 ip주소와 도메인 이름을 변경

• 외부에 호스트 이름 풀이 할 때

1. /etc/hosts : IP주소와 Domain name
2. local DNS server
3. Global DNS server (recursively)

• 내부 호스트에 이름 풀이
  arp cache 메모리: IP 주소-MAC 주소

TCP 연결이 안되는 경우

DNS프로토콜을 이용하여 google의 ip주소를 전달받고 호스트가 google에 연결 요청
hand shake가 안되는 상황 > 내부에서 외부로 연결이 잘됨 > 구글 서버의 연결이 막음
의심스러운 노드로 확인하여 연결되는 것을 막음
외부 접속이니까 DNS가 있는것

일괄적이지 않은 프린터

3-Way handshake로 연결이 되고, 중간에 우선순위를 바꿀 경우 PSH
(PSH: 프린터에서 발생, 인쇄를 하는데 중간에 인쇄물을 끼워넣을때)

계속 인쇄를 보내다가, 데이터 스트링은 계속 보내고 받았다고 보내고
중간에

WINDOW UPDATE: 트래픽이 심해서 윈도우 사이즈를 조절할 경우, 프린터가 받아드려서 수용할 수 없을 때 (버퍼메모리의 양이 부족할 경우)

window가 꽉차서 더이상 출력이 되지 않음

server failure

101 클라이언트 251 서버, 어플리케이션 서버에 대해서 A 네트워크의 DNS 를 요청했으나, Failure
DNS 서버를 받았는데 어플리케이션 서버가 죽은걸로 확인 할 수 있음
서버 연결이 안되기에 failure가 뜸


TCP로 물어봄, 251번하고 250번 둘 다 DNS 서버
DNS 프로토콜을 사용해서 UDP는 순수하게 이름 풀이하는 것
TCP는 DNS 서버의 영역 전송 (백업전송_PUSH/PULL)
250번에는 DNS 정보가 있을 수 있기 때문에, 251이 영역전송
즉, DNS1에게 APPSERVER를 물어본거고 > DNS1이 없자, DNS1이 영역전송하여 확인 해본 것

프로그램 업로드 후 발생하는 네트워크 문제

3-way handshake로 128과 121이 통신한 뒤 FTP 프로토콜을 이용하여 서버 접속, user: salesxfer, password: p@ssw0rd

PASV:타겟이 서비스를 하고 있는 웰 노우 포트 제외한 임의의 포트 그때 할당 받을 때

ACTIVE PORT
내가 포트를 지정해서 보내는 해커가 백도어를 서버에 실어두고, 서비스 포트를 본인만 알 수도 있음
관리자가 특수한 일을 수행 할 때 지정하여 포트 사용

STATIC>FI>Graph

chmod 755
STOR: 저장 .csv 파일 저장
패스워드가 평문장으로 저장될 경우 패킷 분석에서 사용자와 패스워드에 대한 정보를 얻을 수 있음

TCP 재전송

10.3.30.1 > 10.3.71.7에게 ACK 응답을 요청했으나, 71.7로 부터 응답을 받지 못함

• Retransmission
  시그널 응답이 오지 않아서 재전송 요청

  • Packet lost: Packet이 수신측에 도달하지 못할 경우 수신자로부터 ACK응답을 받지 못하고 송신자의 Timer가 만료됨
  • ACK lost: ACK 응답이 유실되어 송신자에게 도착하지 못한 상태로 송신자의 Timer가 만료
  • Early Timeout: 네트워크 지연 발생으로 송신자의 Timer가 만료된 후 ACK 응답이 올 경우

• RTO With RTT(Round Trip Time)
  Timeout 시간 안에 ACK를 받지 못하는 것이 공통점 -> Timeout의 시간을 정의하면 재전송 패킷의 낭비와 패킷 손실을 제어할 수 있음 => RTO
  RTO: 운영체제 커널에 정의, 동적으로 변화가 있으며, RTT에 의해서 변화함
  RTT: 호스트 간 송신에 대한 응답을 받기까지 걸리는 시간을 의미

• 재전송 패킷 줄이는 방법
  Dealy ACK: 효율적인 ACK 전송 방식
  

• Tcp streamGraph _ time:
  시간에 대한 그래프를 볼 수 있음
  연결 시간이 늘어나는 것은 네트워크에 문제가 있음을 확인 할 수 있음
  

중복된 패킷

ACK 대해 Dup ACK 응답이 온 것을 볼 수 있음
사용자가 서버에게 continuation or non-HTTP traffic
:output stream 안에 담겨있는 Data를 해석하라는 의미

analysis > duplicate ack: ACK Fram1에 대해 중복되었을음 나타냄
즉 호스트는 서버에게 ACK응답을 받았으나, ACK 시퀀스 번호가 잘못되어
호스트는 응답을 받지 못했다고 생각> 세그먼트가 손실
서버는 호스트에게 여러 중복된 dup ACK 패킷을 전송

• Fast Retansmit : 타이머의 타임 아웃 기간이 상대적으로 너무 길어 타이머가 종료 되기 전, 중복된 ACK 3번 받으면 재전송 하는 기능, 손실된 패킷을 재전송하기 전 발생하는 긴 지연시간을 줄임
  
  서버가 다시 ACK 시퀀스 번호를 변경하여 호스트에게 전송

Zero Window Recovery

192.168.0.20으로부터 TCP Zerowindow 패킷을 받음
20번 IP는 Winodw Update 후 응답하여 30번 IP로부터 데이터 통신 받음

update 하기 전 window size 5840

update 한 후 window size 64240으로 변경된 것을 확인 할 수 있음

tcp zerodiwndow dead

서버가 호스트에게 데이터를 전송하고자 했으나, 수신자의 버퍼메모리가 없어 zero window 발생
keep-live : tcp 연결이 끊기지 않고 연결되어있음을 확인 할수 있음

이상적인 데이터 통신

2: 전체적으로 서바가 클라이언트와 통신할 때 시간이 다소 걸림을 확인 할 수 있음
이부에서 내부로 들어오는데 들어오는 시간
외부에서 내부로 들어올 때
외부에서 들어오는 패킷을 확인 하는 것으로 판단할 수 있음 (방화벽)

syscan

호스트가 계속 SYN 패킷 요청 중
확인해보면 https, imap, mysql 등 다양한 연결을 시도하는 것을 확인 해볼 수 있음
서버 RST로 연결을 끊음
계속 서버에서 SYN 보내는 중, 4-way로도 연결이 끊기지 않음
왜 syn 연결만 보냈나?
rst를 보냈는데도 syn 를 보내는 이유는 서버가 죽어있거나,
중간에 보면 https pop smtp 등등의 다양한 응용 프로토콜로 들어가 있는데, 열려있는 포트마다 공격하는 도스 공격의 가능성 있음

악성코드

3-way handshake로 TCP 통신 접근하고 HTTP 프로토콜로부터 302 메시지를 받고 리다이렉트 됨

• STUN Protocol
  
  P2P 통신을 위해 NAT를 탐색하기 위해 사용, WebRTC, VoIP 와 같은 실시간 통신을 위한 다른 프로토콜에서 사용됨
  client의 요청에 대해 NAT 통신에 해당 clinet의 public ip 주소와 포트 번호를 응답에 담아줌
  NAT 우회한다고 해서 Session Traverse라는 이름을 붙임
  • Malformed Packet : 비정상 패킷
    
  • html 문서가 악성코드로 확인 됨