Kevin Mitnick 의 TCP 시리 얼 번호 예측 공격 원리

Kevin Mitnick 의 TCP 시리 얼 번호 예측 공격 원리
TCP / IP 프로 토 콜 스 택 의 디자인 과 이용 이 너무 멋 있어 요!!
환경 분석
네 대의 기계 와 관련된다.

   ：Mitnick
   ：Shimomura
      ：Remote
  ISN    ：Tester

공격 입구
피 격 기기 S 와 원 격 서버 R 사이 에 R 은 TCP 513 포트 에서 rlogin 을 실행 해 S 에 접근 할 수 있다.그 중에서 rlogin 은 안전 하지 않 은 인증 방식 을 사용 합 니 다. 원본 IP 기반 입 니 다.
최종 목표
R 의 IP 신분 을 납치 하여 M 과 S 를 TCP 로 연결 합 니 다.
원리 소개
M 에 서 는 R 의 IP 신분 을 위조 해 S 에 접속 요청 (SYN · 첫 악수) 을 보 내 고 S 의 ACK + SYN 응답 (두 번 째 악수) 을 그대로 건 너 뛰 어 거짓 세 번 째 악 수 를 했다.이렇게 실행 한 후에 결 과 는 M 과 S 가 TCP 연결 을 만 들 었 고 그 중에서 M 이 사용 하 는 IP 신분 은 완전히 R 이다.쉽게 말 하면 S 는 자신 이 맞은편 에 연 결 된 것 이 R 이 라 고 생각 하지만 사실은 맞은편 은 M 이다.
구체 적 집행

1、      S  rlogin       R。
2、 R    。
3、  M  R IP  ， S  TCP     。
4、    T，    SYN   S，  S ISN  。    S     3       ISN。
5、    4   ISN ， S  TCP     。    。

POINTS
1 、 R 응답 불가
WHY: 뒤에 R 의 IP 를 사용 하여 S 에 게 위조 요청 (첫 악수) 을 보 내 고, 그 다음 에 S 에 게 신분 을 위조 한 세 번 째 악 수 를 보 내야 하기 때문에 진정한 R 이 악 수 를 하지 못 하 게 합 니 다.그래서 R 이 응답 하지 못 하 게 합 니 다.
tag: 여기 서 문제 가 생 겼 어 요.사실 위 에 있 는 WHY 는 개인 적 으로 만 이해 합 니 다. 제 가 본 책 에서 이렇게 말 했 습 니 다. 원 격 서버 에서 누군가가 서버 IP 주 소 를 사용 하여 가짜 연결 을 시도 하 는 것 을 발견 하면 TCP 리 셋 패 킷 을 보 내 연결 을 닫 습 니 다.나중에 이해 하고 다시 돌아 올 게 요.
DO: R 이 응답 하지 못 하도록 SYN Flood 를 주 고 입 을 다 물 게 합 니 다.
2. 예측 TCP 시리 얼 번호
WHY: R 이 응답 하지 못 하 게 한 다음 에 우리 가 해 야 할 일 은 M 에서 R 의 IP 신분 으로 S 에 게 TCP 연결 요청 (첫 번 째 악수) 을 보 내 는 것 입 니 다. 이때 S 는 정상적으로 응답 (두 번 째 악수) 하지만 정상 적 인 세 번 째 응답 을 받 지 못 합 니 다. 왜냐하면 진정한 R 은 우리 에 게 입 을 막 혔 기 때 문 입 니 다.이 어 우 리 는 M 에서 세 번 째 악수 응답 S 를 직접 만 들 었 다.이 과정 을 종합해 보면 우 리 는 M 에서 두 번 째 악 수 를 건 너 뛰 고 S 에 게 첫 번 째 악수 와 세 번 째 악 수 를 직접 주 며 M < = > S 의 TCP 연결 을 구축 하여 공격 을 완성 했다.
그 중의 어 려 운 점 은 모든 TCP 메시지 에 TCP 시리 얼 번호 가 있 기 때문에 우 리 는 SYN 메시지 에 대해 ACK 를 할 때 현재 의 TCP 시리 얼 번 호 를 1 로 추가 해 야 한 다 는 것 을 알 고 있다.이런 계 산 량 은 초등학생 이 모두 해결 할 수 있다 는 것 이다.문 제 는 우리 가 지금 '초기' 때의 TCP 서열 번 호 를 토론 하고 있다 는 것 이다.즉, 클 라 이언 트 가 TCP 연결 요청 SYN 을 시작 할 때 자신의 초기 번호 ISN 을 보 냅 니 다. 서버 가 이 SYN 에 응답 할 때 이 ISN 을 1 로 더 해서 ACK 를 해 야 할 뿐만 아니 라 서버 자신의 ISN 도 보 냅 니 다. 이것 은 클 라 이언 트 의 ISN 과 관계 가 없습니다.양쪽 의 ISN 은 모두 쌍방 이 자신의 선택 알고리즘 에 따라 선택 한 것 이다.
이 선택 알고리즘 에 구멍 이 있 습 니 다 (tag: 현재 대부분의 운영 체제 가 개선 되 었 습 니 다. 에 세이 화 되 었 습 니 다)!
예 를 들 어 RFC 793 [Postel 1981 c] 에서 설명 한 것 은 ISN 은 32 비트 의 카운터 로 볼 수 있 고 4 초 에 1 을 더 할 수 있다.4 초 에 1 을 더 하 는 간단 한 알고리즘 으로 만 생 성 된다 면 우 리 는 다른 호스트 에서 수 동 으로 S 연결 요청 을 한 다음 에 S 에서 돌아 오 는 응답 중의 ISN 을 분석 하면 우리 가 위 에서 세 번 째 악 수 를 할 때 주 는 ISN + 1 이 몇 인지 완벽 하 게 확인 할 수 있다.(사실 완벽 하지 도 않 습 니 다. 네트워크 트 래 픽 이 복잡 하기 때문에 S 가 다른 연결 이 있어 서 ISN 데 이 터 를 뒤로 옮 길 수 있 습 니 다. 그래서 제목 은 '예측' 이 라 고 합 니 다. just try it) 입 니 다.
DO: (우 리 는 S 에 'ISN 구멍' 이 존재 한다 고 가정 했다. 그러나 구체 적 인 상황 은 위 에서 말 한 '4 초 에 1 추가') 테스트 호스트 T 를 사용 하여 S 에 게 시스템 SYN 요청 을 보 냈 다. 그 응답 에 서버 측 (수 동적 연결 자) 에 속 하 는 ISN 을 분석 한 다음 에 예측 한 TCP 시리 얼 번호 값 을 제시 하여 위 에서 세 번 째 악 수 를 할 준 비 를 한다.