course Outline
- layer 4 transport protocol에 대해 이해
- transmission control protocol (TCP)에 대해 이해
- User Data Protocol (UDP)에 대해 이해
- ip datagram 전달에 대한 다양한 제어 프로토콜에 대해 이해
- firewall
- network address translation (NAT)
- dynamic Host configuration (DHCP)
※ 저번 시험에서 gateway많이 나왔었다
Layer 4 Overview
- end to end data 전송을 위한 logical communication 역할
- L3에서는 end to end 노드 사이에서 패킷 전달하기 위해서 IP를 사용
- end to end라고 하면 어플리케이션 간의 데이터 절달이 정확한 end to end
- Connection oriented (TCP) vs. connectionless (UDP)
- IP 및 port 번호로 식별
- IP계층에 대한 다양한 제어
- 동적 IP 주소 관리
- IP변환 → NAT에서 한다
- IP packet 흐름제어 (flow control): L4d에서 가장 많이 사용하는 제어기능, 패킷이 네트뭐크 상에서 많이 분비는 경우 흐름제어
- host A에서 host B로 가는 어떤 서비스 (23, 80, 5001, 12651 port)가 있는데 23번 포트에 연결된 어플리케이션과 5001번에 연결된 어플리케이션이 상위 레이어와 연동하려고 한다
- 상위 레이어끼리 logical commmunication을 맺어주기 위해 동작하는 것이 L4이다.
- end system안에서 원하는 애플리케이션을 찾아가는 것을 L4에서 수행
- 파란집에서 분홍집으로 편지가 간다
- L4는 파란 사람과 분홍 사람이라고 생각하면 된다.
- 우체통까지는 ip를 사용해서 전달. 도착을 하면 A라는 편지가 B에게 전달이 되야함
- host 대 host(건물 대 건물)은 네트워크 레이어(L3)로 전달하고 사람대 사람은 (우체동 안에 있는 여러개의 편지중 나에게 와야되는 것을 선별하는 역할) 은 transport 레이어가 한다
Transport Layer 종류
Application 에 따라 다음 두 프로토콜 중 한가지를 사용
UDP: unreliable, connectionless service, transparent
- 데이터를 중간의 흐름과 상관없이 지속해서 뿌려주는 프로토콜
TCP: reliable, connection oriented service, congestion control
- transmition controll 이 있다.
- congestion control을 한다는 것은 흐름제어를 한다는 것이다.
두 프로토콜이 L4에서 많이 사용하는 프로토콜
- 두가지 모두 IP 상위 계층 위치에서 end to end로 segment를 전달하는 역할을 가짐
- segment: L4 에서 만드는 PDU
- Best effort and unreliable delivery service (IP) 상에서 application process에게 적절하게 패킷 전달 (socket to secket) 하는 역할을 한다
Transport Layer Multiplexing
한 host 내 다양한 process(=application)로부터 data 전달 역할
- Multiplexing: 여러 socket을 통해서 sdu를 전달 받아 전송
- Demultiplexing: 수신된 pdu를 적절한 socket으로 전달
Multiplexing: Application layer 에서 패킷이 소켓에 의해 Transport layer 로 전달 될 때, 여러 소켓의 패킷을 수집하여 하나의 세그먼트에 캡슐화하여 Network layer로 전달하는 과정
Demultiplexing: Transport layer 에서 세그먼트가 Application layer 로 전달 될 때, 올바른 소켓으로 전달 하는 과정
- 각 프로세스 단위로 socket이 있다.
- socket: proess - transport layer간 sap
transport layer에서는 포트 번호로 식별
- transport layer에서는 포트를 기반으로 ip레이어(L3)랑 pdu를 주고 받는다.
- transport 레이어는 여러 소켓을 통해서 sdu를 받아서 전송하고 demultiplexing 같은 경우는 수신단에서 하는 역할.
- 수신측에서 아래에서 올라오는 pdu를 적절한 소켓으로 전달하는 역할을 한다.
- 트랜스포트 레이어에서는 나가는 데이터와 들어오는 데이터는 포트 번호로 식별한다.
Port Number
transport layer에서의 식별자 역할
- socket에 대한 식별
- 보통 source/destination 별로 port번호 존재
- Well-known port number
- 어플리케이션 별로 미리 지정된 포트가 있는 경우도 있고 사용자가 직접 사용할 수 있게끔 예약이 된 포트 번호도 있다.
- well known port 는 애플리케이션에 따라서 이미 알려진 port 같은 경우 0~1024까지 사용 (따라서 개발시 1024이후 포트 번호를 사용)
- registered port 같은 경우 from 1023 throught 49151정도 사용을 하고, dynamic of provate port 같은 경우는 from 49152 throught 655535 이런 포트 넘버를 사용한다.
- 일반적으로 많이 사용되는 웹서비스 라던지 http, ssh, ftp 같은 경우 포트 번호가 미리 지정되어 있다. → 이런 것들도 api를 사용하면 다 알아서 할당해준다.
- common port number라고 일반적으로 많이 사용되는 포트 넘버가 있다. 위키백과 참고
List of TCP and UDP port numbers - Wikipedia
en.wikipedia.org
UDP (User Datagram Protocol)
간단한 multiplexing / demultiplexing 기능의 프로토콜을 가지고 있다
- 포트 번호와 checksum만 header로 붙음
- 사실상 IP의 기능만 하며, application 계층에서 flow control 등 기타 기능을 구현해야한다.
segment 전송 방식도 심플
- 연결 과정 없이 바로 전송 가능
IP는 transport 레이어의 pdu를 받아서 여기에 IP 헤더를 붙여서 네트워크에서 나간다.
IP address는 헤더에서 쓰여지는 건 아니고 transport 레이어에서는 포트 번호가 source와 destination에 대해서 쓰여진다.
우리가 단순히 UDP를 사용한다고 하면 IP로 맺어진 컴퓨터에게 계속해서 데이터를 쏴주는 역할을 한다.
UDP 소켓 생성
- application process에서 socket 생성 즉시 transport 레이어에서 포트 번호가 부여된다.
- tcp 같은 경우 소켓이랑 트랜스포트 레이어에 대한 포트 번호가 바로 번호가 부여되는 것이 아니라 컨트롤 과정을 거쳐서 부여가 된다.
- udp 같은 경우에는 단순하게 포트번호가 바로 부여가 된다.
UDP segment 송수신
- two tuple: destination IP & port number
- UDP segment 송수신은 목적지의 ip address와 port number를 가지고 구분할 수 있다.
- 목적지로 갈때 위 두개가 중요하게 작용한다.
- udp 같은 경우 포트 번호가 우리가 알려진 포트번호로 잘 안씀 → 이유는 tcp에서 설명
- 상대방 host의 port가 열려 있으면 항상 전송 가능
- IP, port 번호를 지정해서 보내면 바로 전달이 된다.
- source port?
- return address 개념 → 답장을 보냈을 때의 return address
- 서버 b로 보내면 그대로 source포트로 들어오기 때문에 여기서는 단순히 1:1 전송을 수행한다고 생각하면 된다.
UDP의 장점
- application level에서의 data전송 제어가 손쉬움 (TCP에서는 연결 맺는 과정이 필요함..)
- Connection establishment 과정이 불필요함
- Connection state에 대한 관리 및 관련 동작 제한이 없음 → 재전송 관련 이야기가 없이 매우 심플함
- packet header overhead가 적음 → connection을 하지 않아서 헤더가 굉장히 짧다.
- udp같은 경우 실시간성이 필요한 경우 많이 사용된다. (아래 예 참고)
Remote file server에서 UDP를 사용한다.
- 파일을 계속 던지다가 어디가 잘못 됐다고 하면 잘못된 것을 그쪽에서 따로 다른 데이터 응답을 보내주는 형태
Streaming multimedia
- 음성이나 영상을 전송하는 스트리밍이다라고 하면 tcp같은 경우는 이것이 제대로 전달 될때까지 계속해서 버퍼에 쌓아놓는다
- udp 같은 경우에는 데이터가 만들어 질때마다 그 데이터를 즉시 보낸다.
- 제대로 전송이 안돼도 스트리밍 같은 경우 중간에 화면이 끊긴다고 하더라고 다음 화면을 실시간으로 보는것이 더 중요하므로..
Internet telephony
- 인터넷 전화
routing protocol
- 주기적으로 라우팅 정보들을 보내준다.
TCP (Transmission Control Protocol)
Connection oriented: connection establishment 과정 존재
- connection이 존재해야 segment전달이 가능
four tuple: source IP / prot numbr, destination IP / port number
- source에 대한 정보까지 대조하여 socket에 mapping
reliable data transfer 지원
- 재전송 및 ARQ 기능을 포함한다.
- 서비스 측면에서는 reliable transmition을 원한다고 하면 transport layer에다가 datagram(PDU)을 주면 트랜스포트 레이어에서 알아서 받은 정보는 receiver 쪽에다가 전달
b. service implementation 설명 (사진)
- 실제 구현상에서는 트랜스포트 레이어에서 어떤 데이터를 받아서 이런 데이터가 있구나 확인하고 데이터를 쪼개서 이런 데이터를 보낸다고 트랜스포트 레이어에서 헤더를 붙여서 보낸다
- destination 쪽에서도 그것이 내가 재조합해서 제대로 되어있는지 확인해서 위로 올려준다
- 이런 일련의 제어를 transport layer에서 한다.
Connection establishment
- process간 three way handshake를 통해 수행
- 3way handshake로 connection이 맺어져야 receiver 쪽에서는 실제로 어느 포트로 데이터가 전달 될지 알 수 있다.
- source에서 req하고 destination 쪽에서 res(응답)하고 complete이라는 메시지를 source 쪽에서 보내줘야지 reciver는 connecntion이 맺어졌다고 가정.
- 특정 port로 connection establishment 메시지를 수신하고 (connection이 맺어 졌다고 가정) 나서 socket과 port 번호가 연동된다.
- point to point: single sender / receiver 간 연결됨
- client process 에서 initiation을 한다
- 보내는쪽에서 initiation을 하고 server process라고하는 destination쪽에서는 ip address와 포트에 대해서 연결 승인을 한다.
- connection의 목적: 상대방의 존재를 알림, optional parameter 결정, transport entity resource할당
- https://mangkyu.tistory.com/15
예시
- 웹 서버 같은경우 tcp 프로토콜을 통해서 데이터를 요청한다는 상황이 있다
- host a는 캠퍼스 오시는 길 요청, host C는 학사요람 요청
- host a한테는 캠퍼스 오시는길을 답변을 해줘야하고 c에게는 학사요람 답변을 해줘야함. 웹 서버라고 하는 경우 공통된 포트를 사용(80번포트) → host A와 C의 dest. port를 보면 80이라고 되어 있음
- 80번 포트를 통해서 웹서버에 접근을 하는데 웹서버에 접근을 한 결과를 response를 보내줘야함 → http 같은 경우에는 http req와 http res 이 두가지 controll message를 주고 받게 된다
- C에서 80번 포트로 학사요람 page요청이 오고 host A에서도 요청이 오면 http는 이 정보를 기반으로해서 res를 해줄때 소스 id와 소스 포트 넘버를 다시 정확하게 전달을 해줘야만 정확한 요청자에게 돌아감
UDP와 TCP 차이
- udp같은 경우에는 destinaiton ip와 포트번호만을 기반으로 동작하므로 res을 어디다가 해야할 지 모름 → 한쪽으로 계속 전달을 하는 역할을 한다.
- tcp는 res를위한 일부의 기능을 남겨놓는것 → 우리가 request, responce하는 경우에 tcp를 사용해서 데이터 전달을 한다
Segment format
udp와 동일하게 source port(16bit = 2^16 = 6만 5천개 정도)와 dest port를 가지고 있음
- sequence nunber : Byte 시작점 → 내가 보내고자하는 세그먼트의 sequence numer
- ACK number : 다음번 수신을 해야할 Byte offset을 알려준다 .→ 오류 제어에서 사용할 수 있도록 tcp 헤더에서 ack number를 보낸다.
- internet checksum이 L4에도 있음: L2에서도 error control하고 L4에서도 한다.
Restransmission과 함께 flow control 수행 (윈도우 흐름 제어 같은 경우)
- transport entity A: 1001 ~ 2400 이렇게 A에게 할당된 윈도우가 있다면 1400개 octests를 보낼 수 있는 상태
- SN = 1001, SN = 1201, SN = 1401: 하나 보내는 길이가 200이라고 가정, 전체 길이는 600 octets (3개 보냈으므로) → segment number를 1401보냈다고 한다면
- transport entity B: B는 3개의 segments를 받았음을 알린다. B는 1401받고 1601부터 2600 까지의 octet를 받을 수 있다.
- AN = 1601 , W = 1000: B에서 다음에 받을 byte offset은 1601이고, 윈도우 1000까지 받을 수 있다는 걸 A에게 보내준다
- A adjusts its window with each credit: A에서 B가 2601까지 받을 수 있다는 걸 인지하고 윈도우 조정
- B acknowledges 5 segments: SN = 1601 ~ SN = 2401까지 5개의 세그먼크 받았다고 알리고 credit 크기 restores한다.
- AN = 2601, W = 1400: A에게 2601부터 보내면 되고 윈도우는 1400개 준비 되어 있으므로 1400개로 setting하라고 알린다.
- A receives new credit: B에서 보낸 ACK를 받고 윈도우 1400개로 setting한다.
Congestion Control
UDP와 다르게 TCP는 congestion control 수행
- network의 혼잡을 방지하기 위해 자체적으로 flow control 수행
- 일시적 delay가 커질 수 있으나 network 전체 관점에서 이득
Window management
일반적으로 window가 크면 congestion을 유발할 가능성이 크므로 아래와 같은 규칙하에 관리, 아래와 같은 알고리즘이 있다.
- slow start
- dynamic window sizing
Slow start & Dynamic window sizing
이런 알고리즘이 있다 정도로만 알아두자
- 정상적으로 전송 feedback 으로 주고 받는 상황에서 서서히 window 크기를 확장
- congestion상황에서 임의로 window size를 줄임
- 윈도우 size를 계속 증가하다가 혼잡 발생하면 윈도우 사이즈를 줄이는 알고리즘이 destination 쪽에서 돌아가고 있다.
- data를 제대로 전송하면 윈도우 사이즈 증가
- 처음에는 window를 작게해서 보내다가 계속 증가하면서 timeout occurs
- timeout 일어난 이후 다시 줄어든다.
- 줄어들었다가 다시 증가하는데 threshold를 지나면 1씩만 증가
- 이런 경우는 유선에서 이렇게 사용해도 무방 → 어딘가 문제가 발생하면 확 줄였다가 다시 증가
- 무선 같은 경우 혼잡에 의한 것보단 무선 채널에 문제 발생하는 경우는 더 복잡한 congestion controller나 flow controller가 필요
DHCP (Dynamic Host Configuration Protocol)
L4에서 프로토콜을 가지고 할 수 있는 다양한 동작 중 하나이다.
특정 host에 대해 IP를 동적으로 할당하기 위한 프로토콜
- 가능한 IP address pool내에서 선택해서 요청 host에게 할당 → host가 ip를 할당 요청하면 dhcp 서버란게 있어서 이 서버가 address pool 내에서 host에게 할당
- 사용되지 않는 IP는 자동으로 회수
- 원래는 IP address 수가 부족한 상황을 보완하기 위한 목적으로 만들어짐
- 최근에는 wifi나 subnet 내 불특정 다수의 host에 대한 IP address를 편리하게 부여하기 위한 용도로 사용된다.
- 일반적으로 home network나 이런데 있어서 자주 접속하는 애들 같은 경우 DHCP로 받는다고 하더라도 비슷한 IP address가 부여받게 되어있다.
- MAC address 기준으로 DHCP서버가 이런 것들을 스마트하게 할당해준다 → 만약 연결이 끊어졌다고 해면 그런 IP는 자동 회수
서비스 시나리오
- 특정 host가 새로 등장
- DHCP 서버로 IP 주소 요청
- IP 주소를 할당하는 responce msg 수신
- 서비스 시나리오를 보면 노트북이 네트워크에 접속하려고 한다
- 그럼 DHCP서버에게 자신의 ip address를 달라고 주소를 요청하면 그런 주소를 할당하는 res msg를 DHCP서버가 주면서 연결
- DHCP와 관련된 모든 메시지는 브로드캐스팅 해야한다.
DHCP messages
- DHCPDISCOVER과 DHCPOFFER 이 두개를 통해 DHCP 서버가 어딨는가를 감지하게 되어있다.
- DHCPPDISCOVER라는 메시지는 내가 어떤 무선에 접속되었다고 하면 무선으로 브로드캐스팅을 하고 유선이면 유선 채널로 브로드캐스팅
- 브로드캐스팅하면 유선이나 무선 안에 DHCP 서버가 있다면 그 서버가 자신의 위치를 알려주는 DHCPOFFE 메시지를 보내준다
- 그럼 DHCP에게 ip address를 달라고 요청 후, DHCP ACK를 보낸다.
4 step scenario
- DHCP server discovery
- DHCP server를 찾는 메시지 (UDP port 67)
- client가 DHCP 서버 어딨냐는 broadcasting을 한다
- dest: 255.255.255.255 → host 주소가 다 1 이라고 적혀있으면 브로드캐스팅이다.
- 브로드캐스팅이오면 자신의 것이 아니여도 상위 layer로 올려 보낸다
- ip: 255.255.255.255 이면 다 받아서 확인 해봐서 DHCP 서버가 packet을 열었더니 DHCP discovery이면 offer를 보내준다. → 자신의 존재를 알림
- DHCP server offer
- server가 자신의 존재를 broadcasting으로 알림
- 여러 DHCP 서버 중 먼저 받은 서버가 offer를 보낸다
- Lifetime: 3600secs → 3600초 (1시간) 동안 이걸 유효하게 만들어 주겠다는 정보를 보내준다.
- DHCP request
- DHCP가 pool내에서 DHCP offer가 위 사진 같은 정보는 같이 보내면서 이렇게 사용해볼래? 라고 보내고 client 측에서 그렇게 사용해 보겠다고하면 DHCP request를 서버가 받고 connection을 맺어서 다른 얘들이 못 쓰게 잡아 놓는 다는 응답을 보내준다
- DHCP ACK
NAT (Network Address Translation)
IPv4를 오늘날까지 생존하게 한 프로토콜
- 절대적으로 수가 부족한 ip address를 국지적으로 사용할 수 있게 해줌
- small office, home office subnet에 적합
- NAT라는 프로토콜이라는 것은 미리 주어진 ip address와 포트를 기반으로해서 내부 IP와 연동을 해주는 것이다.
Small Office Home Office (SOHO)
- 초기에는 ISP로부터 일정 IP 대역을 할당 받음
- 할당 받아서 IP 대역을 굉장히 많이 할당 받아서 그것을 나눠쓰고 그런 식으로 했었음
- 이 subnet이 점점 커지면서 IP 대역을 더 많이 요구하게 되면 연속된 IP를 못받을 수 있음.
- 실제로 IP를 못받는 문제가 발생
- 하나의 기관이나 집에는 공인 IP를 하나씩만 할당받음
- 큰 기업 같은 경우 subnet 크기를 더 키운 공인 IP를 할당 받게 된다.
Network Address Translation
- 하나의 IP를 할당 받아 내부의 subnet의 여러 host들에게 공통으로 서비스를 하는 방식
- 적은 IP address를 받아서 안의 여러개의 기기를 접속시킬 수 있는 기능을 가짐
- 내부적으로 IP를 따로 주면서 외부로 나갈 때 할당된 하나의 IP를 사용한다.
out going IP + port 번호와 내부 IP/port로 mapping
- NAT translation table을 통해 outer → internal routing을 수행
- outer와 internal routing은 edge gateway에서 수행한다. 그 일련의 동작을 NAT라고 한다.
- 초기 Outgoing packet에 대해 translation table 항목을 생성하고 port 번호 부여한다.
- 그림에서 1번은 10.0.0.1 에서 나가는 data가 3345 port를 통해서 나갔다고 했을때 게이트웨이의 subnet단의 ip address를 통해서 나간다 (10.0.0.4)
- 게이트웨이에서 NAT translation table을 보고 LAN side에서 10.0.0.1 이라는 얘가 3345 port로 보내는걸 WAN에서는 138.76.29.7에 5001 port에서 너한테 데이터를 보낸다를 게이트웨이가 보고 이걸 바꿔서 보내준다
- 그림에서 2번은 서버로 데이터가 나간다
- 데이터가 나간 서버에서는 게이트웨이를 보고 나간 데이터를 다시 돌려준다
- 그림에서 3번은 나간 데이터가 responce나 이런 신호를 통해 다시 돌아오면 D(destination)이 138.76.29.7(게이트웨이를 가리킴)에 5001 port로 데이터를 보낸다고 하고 데이터가 들어오면 게이트웨이는 그 데이터를 받는다.
- 그림에서 4번은 게이트웨이는 들어온 데이터를 해석해서 original source 쪽으로 데이터를 forwarding한다.
NAT의 역할
외부 ip 하나를 통해 여러 hsot들이 손쉽게 networking 할 수 있음
- 부족한 ip address 수에 대한 강력한 보완책이 된다
internal network내 host를 감추는 역할 → 직접적인 공역을 할 수 없다
- 외부에서는 어떤 host든 single ip로 밖에 보이지 않음
한계점
- In going packet으로 연결이 시작되는 서비스가 불가능
- source 쪽에서 게이트웨이 안쪽에 있는 subnet안에서 initiation이 된 서비스가 destination까지 갔다가 다시 돌아오는 것을 기반으로 서비스가 이루어지는데 In going pcket으로 연결이 시작되는 서비스가 불가능
- 예를들어서 5001번 포트로 들어간다고 하면 아직 nat에서 게이트웨이는 그걸로 시작되는 서비스가 없는데? 대응이 되는 애가 없는데? 라고 생각을 할 수 있음 → 이런 문제점을 해결하는 알고리즘이 있긴함(포트포워딩)
NAT의 Issue
port 번호의 용도가 잘못됨
- host를 지칭하는 것이 아닌, service를 지칭 해야함
- 네트워크 엔지니어 관점에서는 올바르지 않는 transport layer의 사용이지만 NAT가 효율적이고 좋은 프로토콜이므로 이 점은 network layer에서는 감안하고 사용
Layered architecture concept에 어긋난다
- IP header에 대한 관리는 L3에서만 해야함
- 레이어의 구조의 경계를 허물고 있다.
IP header에 대한 생성 / 조작은 end to end 단계에서만 다루어져야함
- 중간에 게이트웨이가 가로채기 한다.
IPv4의 다음 기술인 IPv6이 널리 퍼지는 것을 제대로 막음
- networking 기술이 다음 세대로 가지 못하고 있다.
UPnP (Universal Plug and Play)
L4에서 포트를 가지고 할 수 있는 응용
initiation가 되지 않아도 host가 주변 nat와 사전 configuration을 진행해서 내가 미리 나의 포트를 지정해 놓는것
- P2P file sharing 혹은 VoIP와 같이 외부에서 접속이 필요한 서비스를 NAT 환경에서 지원하기 위한 프로토콜
P2P: Peer to Peer의 줄임말로 중앙 서버를 거치지 않고 클라이언트 컴퓨터끼리 직접 통신하는 방식을 통칭한다.
- host가 주변 NAT와 사전 configuration 진행
- private IP/port와 public IP/port를 미리 지정
- outside node에서 해당 IP/port로 internal host에 접속 가능
- 나중에 외부에서 접속을 할 때 모르더라고 바로 접속을 할 수 있도록 포트와 id를 할당 해놓는것을 UPnP
Firewall (방화벽)
L4에서 포트를 가지고 할 수 있는 응용
외부의 네트워크와 내부의 네트워크를 게이트웨이(edge router)라고 하는게 서로 연결을 시켜준다.
바깥에서 subnet에 들어오려고 하면 gateway 하나를 거쳐야한다.
그 게이트웨이에서 동작을 하는 것이 방화벽이다.
internal network와 internet의 경계를 짓는 존재
- Allowing some packets to pass and blocking others
- Internal network - internet 간 대문(gateway) 역할
Network security 측면에서의 주요 역할
- Network 관리자가 외부 접속에 대한 관리를 가능하게 해줌
세가지 목적
- 모든 양방향의 traffic이 firewall을 통해서 지나가도록해서 흐름을 관리한다
- 외부 internet과 관리 대상인 내부망의 boundary 역할
- Local security policy에 의해 규정된 허용 트래픽만 통과시키므로써
- 유입/유출되는 traffic에 대해 관리자가 지정한 정책에 따라 흐름을 제어
- Firewall 자신은 보안에 매우 강해야 함
- firewall이 공격당하기 쉬우면 차라리 없는 게 더 좋음
Categories of Firewalls : Traditional Packet Filters
Traditional packet filters
Administrator-specific rule에 따라 gateway router에서 packet의 통과를 허용하거나 drop을 수행
보안적인 측면과 더불어 internal network의 용도 및 관리자의 의도에 맞게 적절히 filter를 수동으로 설정
- IP와 port 번호를 조합해서 규칙 생성 가능
- packet filter라는 걸 사용해서 ip와 port번호를 조합해서 규칙 생성가능
- 방화벽 규칙이 네트워크 function들을 기반으로 동작
- 실제 firewall rule은 access control list를 설정해서 구현
Categories of Firewalls : Stateful Packet Filter
connection 별로 filtering 규칙 적용
- 각 packet에 대해 별도로 filtering 규칙을 적용하는 Traditional packet filter와는 다름
- connection의 handshake 절차 등을 추적하면서 filtering을 할 수 있음
- 악성 site를 막겠다... 어떤 connection을 막겠다
Check connection
해당 연결에 대해 connection list까지 검토해야 함을 표시
filewall: 앞서 배운 내용에서 connection을 조정할 수 있는 기능
Categories of Firewalls : Application Gateway
Filtering이 packet 기반(IP, port number 등)이 아닌 application 수준의 상황에 따라 이루어져야 할 때가 있음
e.g.) 특정 internal user에게만 telnet service 허용
- Firewall과 협업해서 Packet filter를 함
- IP/TCP/UDP 보다 윗계층에서 application data를 확인
connection 기반이든 application기반이든 패킷기반이든 어떤 기반이든지 그것을 명시적으로 어떤 룰을 기반으로 맺고 끊는 것은 firewall이 수행한다.
'CS > 컴퓨터네트워크' 카테고리의 다른 글
| 13. Application Layer 2 (0) | 2023.06.04 |
|---|---|
| 12 Application Layer 1 (0) | 2023.05.28 |
| 9. Layer 3: Routing (0) | 2023.05.16 |
| 7. Layer 3: Internet Protocol (0) | 2023.04.15 |
| Layer 1 & 2 (0) | 2023.04.12 |
