[전재] SYN 쿠키 메커니즘에서의 연결 구축

정상적인 상황에서 서버 측은 클라이언트가 보낸 SYN 패키지를 수신하면 연결 요청 블록 (즉 request_sock 구조) 을 분배하여 연결 요청 정보를 저장하고 SYN+ACK 패키지를 클라이언트에게 보내고 연결 요청 블록을 반 연결 대기열에 추가합니다.클라이언트가 SYN+ACK 패키지를 수신하면 서버 측의 패키지를 확인하기 위해 ACK 패키지를 보냅니다.서버 측은 클라이언트의 확인을 받은 후 저장된 연결 정보에 따라 새로운 연결을 구축하여 플러그인을 감청하는 연결 대기열에 넣고 사용자층accept 연결을 기다립니다.이것은 정상적인 상황입니다. 그러나 합병이 너무 높거나 SYN flood 공격을 받은 상황에서 반연결 대기열의 슬롯 수량이 곧 소모되어 새로운 연결 요청을 버릴 수 있습니다. SYN 쿠키 기술은 서버가 반연결 대기열이 가득 찬 상황에서도 새로운 SYN 요청을 처리할 수 있습니다.
SYN 쿠키 옵션이 켜져 있으면 반 연결 대기열이 가득 차면 SYN 쿠키는 SYN 요청을 버리지 않고 원본 IP, 원본 포트 번호, 수신된 클라이언트의 초기 시퀀스 번호와 기타 보안 수치 등 정보를 해시 연산하여 암호화하여 서버 측의 초기 시퀀스 번호를 얻습니다. 이를 쿠키라고 합니다.서버 측은 초기 시퀀스 번호가 쿠키인 SYN+ACK 패키지를 보내면 할당된 연결 요청 블록을 방출합니다.클라이언트의 ACK 패키지를 수신하면 서버 측은 클라이언트의 ACK 시퀀스 번호를 1로 줄여 얻은 값을 상기 요소hash 연산에서 얻은 값과 비교하고 같으면 세 번의 악수를 직접 완성하여 새로운 연결을 구축한다.SYN 쿠키 메커니즘의 핵심은 공격으로 인해 대량의 구조가 쓸모없는 연결 요청 블록을 피하고 메모리가 소모되어 정상적인 연결 요청을 처리할 수 없게 하는 것이다.
SYN 쿠키 활성화는 시작 환경에서 다음 명령을 설정하여 수행됩니다.

echo 1 > /proc/sys/net/ipv4/tcp_syncookies

이 메커니즘을 켜는 것은 모든 연결이 SYN 쿠키 메커니즘을 사용하여 연결의 구축을 완성하는 것을 의미하지 않으며, 반연결 대기열이 가득 찬 경우에만 SYN 쿠키 메커니즘을 터치할 수 있습니다.SYN cookies 메커니즘이 TCP 프로토콜에 심각하게 위배되어 TCP 확장을 허용하지 않기 때문에 일부 서비스에 심각한 성능 영향을 미칠 수 있습니다(예를 들어 SMTP 전송). SYN flood 공격을 방어하는 데 확실히 효과가 있습니다.공격을 받지 않은 고부하 서버에 대해 이 옵션을 열지 마십시오. tcp_ 수정을 통해max_syn_backlog 、tcp_synack_retries 및 tcp_abort_on_overflow 시스템 매개 변수로 조절합니다.
다음은 커널에서 SYN 쿠키 메커니즘을 통해 연결을 어떻게 만드는지 살펴본다.
클라이언트의 연결 요청은 tcp_v4_conn_request () 함수 처리.tcp_v4_conn_request () 에 국부 변수 want_SYN 쿠키 메커니즘 사용 여부를 표시하는 쿠키입니다.want_쿠키의 초기값은 0입니다. 반연결 대기열이 가득 차고 tcp_가 켜져 있으면syncookies 시스템 매개 변수는 다음과 같이 값을 1로 설정합니다.

int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
{
#ifdef CONFIG_SYN_COOKIES
    int want_cookie = 0;
#else
#define want_cookie 0 /* Argh, why doesn't gcc optimize this :( */
#endif
 
...... 
 
    /* TW buckets are converted to open requests without
     * limitations, they conserve resources and peer is
     * evidently real one.
     */
      if (inet_csk_reqsk_queue_is_full(sk) && !isn) {
#ifdef CONFIG_SYN_COOKIES
             if (sysctl_tcp_syncookies) {
            want_cookie = 1;
        } else
#endif
       
        goto drop;
    }
 
......
 
drop:
    return 0;
}

SYN 쿠키 메커니즘이 켜져 있지 않으면 반 연결 대기열이 가득 차면drop로 넘어가 0으로 되돌아옵니다.tcp_ 호출 중v4_conn_request()의 tcp_rcv_state_프로세스()에서 SKB 패키지가 직접 해제됩니다.
우리가 앞에서 언급한 바와 같이 반연결 대기열은 두 가지 상황으로 가득 차 있다. 하나는 부하가 너무 높고 정상적인 연결 수가 너무 많다는 것이다.다른 하나는 SYN flood 공격입니다.첫 번째 경우, 연결을 계속 구축할지 여부는 연결 대기열의 상황과 반 연결 대기열의 재전송 상황에 따라 달라집니다. 아래와 같습니다.

if (sk_acceptq_is_full(sk) && inet_csk_reqsk_queue_young(sk) > 1)
        goto drop;

      sk_acceptq_is_full () 함수는 이해하기 쉽습니다. 글자의 의미에 따라 이 함수는 연결 대기열이 가득 찼는지 확인하는 것입니다.inet_csk_reqsk_queue_young() 함수는 반연결 대기열에서 SYN+ACK 세그먼트를 재전송하지 않은 연결 요청 블록 수를 반환합니다.연결 대기열이 가득 찼고 반 연결 대기열의 연결 요청 블록에서 1보다 더 많이 전송되지 않으면drop으로 이동하여 SYN 패키지를 버립니다.반연결 대기열에서 리셋되지 않은 요청 블록의 수가 1보다 많으면 앞으로 2개의 완료된 연결이 있을 수 있습니다. 새로 완성된 연결은 연결 대기열에 넣어야 하지만 연결 대기열이 가득 찼습니다.세 번의 악수에서 마지막 ACK를 받은 후 연결 대기열에 빈 위치가 없으면 수신된 ACK 패키지를 무시합니다. 연결 설정이 늦어지기 때문에 일부 새로운 연결 요청을 버리고 자원을 비워 현재 진행 중인 연결 프로세스를 완성하는 것이 좋습니다.이 판단은 반연결 대기열이 가득 찼는지 여부를 고려하지 않았다는 점도 주의해야 한다.여기서 알 수 있듯이 SYN 쿠키 메커니즘을 열었다고 해서 반드시 연결을 완성할 수 있는 것은 아니다.
연결 설정을 계속할 수 있다면, inet_ 호출reqsk_alloc () 는 다음과 같이 연결 요청 블록을 할당합니다.

req = inet_reqsk_alloc(&tcp_request_sock_ops);
    if (!req)
        goto drop;

여기를 보면 SYN 쿠키 메커니즘을 열었는데도 연결 요청 블록을 분배하는 것은 정상적인 연결 구축과 다를 바 없다는 의혹이 있을 수 있다.여기에 연결 요청 블록을 할당하는 것은 클라이언트에게 SYN+ACK 패키지를 보내는 데 사용되며, 발송 후 방출되며 반 연결 대기열에 들어가지 않습니다.
다음은 쿠키의 값을 계산하는 것입니다. 쿠키_v4_init_sequence () 함수는 다음과 같이 완료됩니다.

if (want_cookie) {
#ifdef CONFIG_SYN_COOKIES
        syn_flood_warning(skb);
        req->cookie_ts = tmp_opt.tstamp_ok;
#endif
        isn = cookie_v4_init_sequence(sk, skb, &req->mss);
    }

계산된 쿠키 값은 연결 요청 블록 tcp_에 저장됩니다request_sock 구조의 snt_isn 구성원 중 __ 호출됨tcp_v4_send_synack () 함수는 SYN+ACK 패키지를 보내고 앞에 할당된 연결 요청 블록을 다음과 같이 방출합니다.

if (__tcp_v4_send_synack(sk, req, dst) || want_cookie)
        goto drop_and_free;

서버 측에서 SYN+ACK 패키지를 보낸 후에 서버 측에서 이 미완성 연결에 대한 정보를 저장하지 않은 것을 보았기 때문에 클라이언트의 ACK 패키지를 받은 후 앞에서 보낸 SYN+ACK 패키지의 쿠키 값에 따라 연결 여부를 결정할 수 있습니다.
우리는 다음에 ACK 패키지를 받은 후의 처리 상황을 볼 것이다.ACK 패키지는 tcp_v4_do_rcv() 함수에서 호출된 tcp_v4_hnd_다음과 같이 req()에서 처리됩니다.

static struct sock *tcp_v4_hnd_req(struct sock *sk, struct sk_buff *skb)
{
    ......
 
#ifdef CONFIG_SYN_COOKIES
    if (!th->rst && !th->syn && th->ack)
        sk = cookie_v4_check(sk, skb, &(IPCB(skb)->opt));
#endif
    return sk;
}

서버에 연결이 완료되지 않은 정보를 저장하지 않았기 때문에 반 연결 대기열이나 ehash 산란 목록에서 대응하는 sock 구조를 찾을 수 없습니다.SYN 쿠키 메커니즘이 켜져 있으면 수신된 데이터 패키지가 ACK 패키지인지 확인합니다. 만약 그렇다면 쿠키_v4_check ()에서 쿠키가 호출됩니다_check () 함수는 ACK 패키지의 쿠키 값이 유효한지 확인합니다.유효하면 request_sock 구조를 구축하고 ACK 패키지에 따라 해당하는 구성원을 초기화하여 연결을 설명하는 sock 구조를 구축합니다.생성 프로세스는 정상적인 연결 생성 프로세스와 같습니다.