[ExpressRoute] 주요 네트워크 지점 설명
고객사 집선L3(VRF) – 회선사업자 ASR(Active-Active) – PE (Active-Standby) – MSEE – vHub
[ExpressRoute] 주요 네트워크 지점 설명
고객사 집선L3(VRF) – 회선사업자 ASR(Active-Active) – PE (Active-Standby) – MSEE – vHub
- /etc/syslog.conf, /etc/rsyslog.conf 파일로 로그형식 및 경로를 설정함
- syslogd 데몬이 OS 로그를 기록함
관련파일 | 설명 |
/etc/rc.d/init.rsyslog -rsyslogd | 데몬을 동작시키는 스크립트 |
/etc/init.rsyslog.conf -rsyslogd | 데몬 환경 설정 파일 |
/etc/sysconfig/rsyslog -rsyslogd |
데몬 실행과 관련된 옵션설정파일 |
/sbin/rsyslogd |
실제 rsyslog 데몬 |
● /etc/rsyslog.conf 파일
※기본 형식 : facility.priority action
형식 | 설명 | |
facility | .일종의 서비스를 의미 .메시지를 발생 시키는 프로그램의 유형 |
|
priority | .위험의 정도를 나타내며, 설정한 수준을 포함해서 높으면 메시지 보냄 .설정 앞에 = 사용의 경우 : 해당 수준(priority)의 위험도와 같은 경우에 메시지 보냄 .설정 앞에 ! 사용의 경우 : 해당 수준(priority)만 제외 시킬때 사용 |
|
action | .메시지를 보낼 목적지나 행동들에 관한 설정 .보통 파일명이나 아이디 들을 적음 |
|
규칙 | .facility : 콤마(,) 사용 .facility.priority의 조함 : 세미콜론 (;) 사용 |
1) severity : 메시지의 성격 또는 중요도 -0~7 사이의 숫자로, 숫자가 낮을수록 심각한 문제라는 것을 내포함
Code | Severity | Keyword | C code | Description |
0 | Emergency | emerg (panic) | LOG_EMERG | System is unusable. |
1 | Alert | alert | LOG_ALERT | Action must be taken immediately. |
2 | Critical | crit | LOG_CRIT | Critical conditions. |
3 | Error | err (error) | LOG_ERR | Error conditions. |
4 | Warning | warning (warn) | LOG_WARNING | Warning conditions. |
5 | Notice | notice | LOG_NOTICE | Normal but significant condition. |
6 | Informational | info | LOG_INFO | Informational messages. |
7 | Debug | debug | LOG_DEBUG | Debug-level messages. |
2) facility : 메시지를 발생시킨 프로그램의 타입(발생주체) -이벤트를 생성한 프로세스, 모듈, 프로토콜을 나타냄. 메일 시스템, 커널, 네트워크 등이 될 수 있음
Facility Number |
Keyword | C code | Facility Description |
0 | kern | LOG_KERN | kernel messages |
1 | user | LOG_USER | user-level messages |
2 | LOG_MAIL | mail system | |
3 | daemon | LOG_DAEMON | system daemons |
4 | auth | LOG_AUTH | security/authorization messages |
5 | syslog | LOG_SYSLOG | messages generated internally by syslogd |
6 | lpr | LOG_LPR | line printer subsystem |
7 | news | LOG_NEWS | network news subsystem |
8 | uucp | LOG_UUCP | UUCP subsystem |
9 | clock | LOG_CRON | clock daemon |
10 | authpriv | LOG_AUTHPRIV | security/authorization messages |
11 | ftp | . | FTP daemon |
12 | . | . | NTP subsystem |
13 | . | . | log audit |
14 | . | . | log alert |
15 | cron | . | clock daemon |
16 | local0 | LOG_LOCAL0 | local use 0 (local0) |
17 | local1 | LOG_LOCAL1 | local use 1 (local1) |
18 | local2 | LOG_LOCAL2 | local use 2 (local2) |
19 | local3 | LOG_LOCAL3 | local use 3 (local3) |
20 | local4 | LOG_LOCAL4 | local use 4 (local4) |
21 | local5 | LOG_LOCAL5 | local use 5 (local5) |
22 | local6 | LOG_LOCAL6 | local use 6 (local6) |
23 | local7 | LOG_LOCAL7 | local use 7 (local7) |
3) Priority : 심각도를 의미함
facility | 심각도 |
none | 저장된 facility제외 |
debug | 1 |
info | 2 |
notice | 3 |
warning | 4 |
error | 5 |
crit | 6 |
alert | 7 |
emerge | 8 |
4)설정 예시
*.emerg shutdown - h now //모든 장치의 emerg발생시 Shutdown
kern.* /dev/console //커널 관련 로그를 /dev/console에 남김
authpriv.* /var/log/sercure //xinetd접속 로그를 /var/log/sercure 남김
*.info;mail.none /var/log/message //모든 facility에서 발생하는 info이상 심각도(2-8)의
이벤트를 로깅하되 mail Facility에서 발생하는 로그는 로깅하지 않음
*.*;auth,authpriv.none,local0.none -/var/log/syslog
//모든 로그(*.*)를 /var/log/syslog에 기록하지만, 세미콜론(;) 이후의 facility들인
auth, authpriv, local0 은 제외(none)하라는 것임. 화일이름 앞의 - 는 로그를
파일에 바로 쓰지 말고 메모리에 로그를 가지고 있다가 디스크에 입출력 여유가
있을 경우 쓰라는 의미임
(http://shallowsky.com/blog/linux/rsyslog-conf-tutorial.html 의 Rules Section참조)
1.Routing 확인 (목적지까지 최대 30홉을 지원하고 각 구간의 네트워크 상태를 확인)
→tcproute 등 다른 Utility 사용도 가능
(예: tracert 127.0.0.1
wildcard-tistory-fz0x1pwf.kgslb.com [xxx.xxx.222.33](으)로 가는 경로 추적:
1 1 ms 1 ms 2 ms xxx.xxx.219.1
2 * * * Request Time Out )
→ * : 패킷의 Trace 결과가 5초 이내에 도달하지 않으면 해당 왕복시간은 *로 표시
* traceroute Option
-I(대문자 i) : traceroute의 옵션으로 UDP가 아닌 ICMP를 사용하여 라우팅 추적
-n : 빠른 명령을 위한 DNS lookup 비활성
-w seconds : 응답 패킷을 수신 받기 위한 시간(Default 5초)
-q number : hop단 traceroute query수행 횟수(Default 3회)
* tracert Option
-d : tracert의 옵션으로 주소를 호스트 이름으로 확인하지 않아서 빠른 결과 확인가능
-h maximum_hops 대상 검색을 위한 최대 홉 수(Default 30홉)
-j host-list host-list에 따라 원본 라우팅을 완화(IPv4만 해당)
-w timeout 각 응답의 대기 시간 제한(밀리초)
-R 왕복 경로를 추적(IPv6만 해당).
-S srcaddr 사용할 원본 주소(IPv6만 해당).
-4 IPv4를 사용
-6 IPv6를 사용
** trace결과(*로 표시) 대응 방법
IPS(침입차단시스템), 방화벽 등의 접근통제에 의해 trace의 UDP 또는 ICMP패킷이 보안상의 이유로 차단되었거나
실제 해당 구간에 문제가 발생한 경우임
- trace한 주소가 실제 존재유무 체크, 패킷이 멈춘 곳의 IP를 네트워크팀에 확인
- trace 수행속도가 느리면 어느 지점에서 시간을 많이 잡아먹었는지 확인
2.Network Interface 확인(TCP/IP 프로토콜 진단)
(예: netstat -ant // all, port by number, tcp
프로토콜, 로컬 주소, 외부 주소, 상태, 오프로드상태 등을 출력)
* Option
-a 모든 소켓 정보를 출력(모든 연결 및 수신 대기 포트를 표시)
-b 외부와 통신하는 실행파일([]안에표시)과 프로토콜, 내외부정보를 출력
(각 연결 또는 수신 대기 포트 생성과 관련된 실행 파일을 표시)
[관리자권한으로만 수행 가능, 출력시간이 오래 걸림]
-r 라우팅 정보를 출력
-i [interval] 네트워크 인터페이스에 대한 정보를 출력
(Windows는 -i 옵션없이마지막에 interval 숫자만 주면됨)
-s 프로토콜(IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP 및 UDPv6)에 대한 통계 정보를 출력
-n 외부 네트워크 정보(IP, Port)를 숫자로 출력
-e 이더넷 통계를 표시(인터페이스 통계, -s 옵션과 함께 사용가능)
-o 각 연결의 소유자 프로세스 ID를 출력
-t TCP만 출력
-u UDP만 출력
**State 필드정보
6.네트워크 > TCP Diagram 참조 (https://roby.tistory.com/category/6.%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC)
**상세활용 참조블로그
김선광의 IT블로그 : https://blog.naver.com/sunkwang0307/222601632550
3. Ping (접속할 host가 정상 운영되고 있는지 확인, ICMP 사용)
(예: ping 127.0.0.1 -t //수동으로 멈출때까지 반복 수행, Default 4회)
* Option
-t : Ctrl+C로 중지 할 때까지 패킷 전송
(예: ping 127.0.0.1 -t)
-i(interval) : Ping 주기 지정 옵션(Default 1초)
(예: ping 127.0.0.1 -i 0.5 //0.5초 주기 패킷 송부)
-s : 전송 패킷 Size를 지정 (Windows : -l)
(예: ping 127.0.0.1 -s 100 //100byte 크기 패킷 송부)
-w : 정한 시간동안 패킷 전송(Windows : 응답 대기시간-밀리초)
(예: ping 127.0.0.1 -2 10 // 10초동안 패킷 전송)
-c(count) : 전송할 패킷 수 지정 (Windows : 없음)
(예: ping 127.0.0.1 -c 10 // 패킷을 10번 전송)
-D : 결과 앞에 타임스탬프 출력 (Windows : 없음)
(예: ping 127.0.0.1 -D)
-f(flood mode) : 빠른 속도로 패킷 전송하여 상태 확인 (Windows : 없음)
(예: ping 127.0.0.1 -f)
-O : 전송한 패킷에 대한 응답 패킷을 출력, 어디서 오류 발생했는지 출력 (Windows : 없음)
(예: ping 127.0.0.1 -O)
1.TCP 3way-handshaking
4계층의 대표적인 TCP는 신뢰성을 기반으로 설계된 프로토콜로서 서비스의 논리적연결(Session)을 담당하며 신뢰성 확보를 위해 3way-handshaking 방식으로 통신한다.
※ Sync Flooding : TCP의 특성을 이용한 해킹기법
- 공격자가 다수의 패킷을 서버로 보내고 ACK는 보내지 않아서 연결은 종료되지 않고 서버의 리소스가 소비되어 정상적인 사용자가 연결을 시도할 때, 서버 접속이 불가능하게 된다.
▶Sync Flooding 방어 방법
- Syn Flooding 공격방어 및 완화를 위해서는 TCP프로토콕이 연결 지향성(Connection-Oriented)이라는 점을 이용하고
Handshake과정에 위배된 TCP 패킷이 유입될 경우 비정상적인 트래픽으로 구분하여 차단하는 방법이 가장 효과적임
1)임계치 기반의 Syn Flooding 차단
방화벽의 IP당 Syn요청에 대한 PPS 임계치를 단계적으로 조정하여 Syn Flooding을 차단함
2)First Syn Drop(Spoofed) 설정에 의한 차단
Syn패킷을 보내는 클라이언트가 진짜 존재하는지를 파악하여 차단하는 방법으로 클라이언트로부터
전송된 첫번째 Syn을 Drop하여 재요청 패킷이 도착하는지를 확인하여 Spoofing 여부를 판단하고 차단함
3)Syn이외의 Flooding 공격 방어
Syn이외의 Flooding 공격을 방어하기 위해서는 다음과 같은 다양한 형태의 DDoS 방어 기법을 사용
먼저 정상적인 TCP세션 연결이후 정상적인 트랜잭션이 수해되는지에 대해 검증하여 만약 정상적인 트랜잭션이
일루어질 경우 서버로 전달해야 하고, 정상적인 트랜잭션 없이 TCP세션 연결만 수행할 경우에는 서버로 전달하지
않아야 서버에 부하 증가 현상을 막을 수 있음
또한 네트워크의 정상적인 환경에서 설정된 각 트래픽 유형별 임계치를 통하여 과도한 TCP세션 연결에 대해 차단
**TCP/IP Overhead 참고 링크 : http://tech.kakao.com/2016/04/21/closewait-timewait/
[TCP Diagram]
TCP 기반의 네트워크는 connection의 요청이나 종료를 대기하거나 서로간에 negociate 하기 위한 상태를 가지고 있다
2. TCP Diagram 상태 설명
상태 | 의미 |
LISTEN | 서버 어플리케이션은 서비스를 위한 포트개설, 서버 TCP는 연결 요청을 기다리는 상태 *서버가 클라이언트의 접속요청 대기 |
SYN_SENT | 연결 요청을 하고(SYN 세그먼트 전송), 서버 응답을 기다리는 클라이언트의 상태 *클라이언트 → 서버로 접속 요청 |
SYN_RCVD | 클라이언트에게 SYN세그먼트를 받고, ACK/SYN 플래그가 설정된 응답 세그먼트를 보낸 후 클라이언트의 ACK 세그먼트를 기다리는 서버의 상태 *서버(클라이언트의 접속 요청을 받고)가 클라이언트에게 접속 요청 응답 |
ESTABLISHED | 3 Way-Handshake과정이 완료되어 연결이 완료된 상태 *클라이언트와 서버가 서로 세션 확립 상태 |
FIN_WAIT_1 | 클라이언트의 어플리케이션이 회선 종료를 요청하고 FIN 세크먼트를 서버에 전송한 클라이언트의상태 *접속을 끊기 위해 소켓을 close하고 close 요청(close 발생 주체는 서버 또는 클라이언트) |
CLOSE_WAIT | FIN 세크먼트를 수신하고 이에 대한 ACK 세그먼트를 클라이언트에게 전송한 서버의 상태 *close 요청을 받고 응답을 보냄 |
FIN_WAIT_2 | 서버에게 전송한 FIN 세크먼트에 대한 ACK 세그먼트를 수신했고, 서버로부터 FIN 세그먼트가 전송되기를 기다리는 클라이언트의 상태 *close 요청에 대한 응답을 받고 최종 응답 대기 |
LAST_ACK | 요청받은 회선 종료에 대해 클라이언트에게 FIN 세크먼트를 전송하고, 이에 대한 ACK 세그컨트를 기다리고 있는 서버의 상태 *소켓을 close하고 최종 close 응답 |
TIME_WAIT | 회선이 종료되었지만, 분실되었을지 모르는 세그먼트를 위해 당분간 회선을 유지하는 상태(회선 종료를 요청한 클라이언트에서만 나타나는 상태) *최종 close 응답을 받고 미처 처리되지 못한 데이터를 처리를 위해 일정시간 유지 상태 |
active open | 능동적으로 세션 확립에 대한 요청을 하는 과정으로 보통 클라이언트에서 이루어짐 (예: 클라이언트가 포트를 개방하고 서버에 접속 요청을 하는 것) |
passive open | 수동적으로 세션 확립에 대한 요청을 받는 과정으로 보통 서버에서 이루어짐 (예: 서버가 포트를 개방하고 클라이언트의 접속 요청을 대기하는 것) |
active close | 능동적으로 세션 해제를 발생시키는 과정으로 서버 또는 클라이언트가 될 수 있다 (예: 클라이언트가 접속을 끊거나 서버가 접속을 끊는것) |
passive open | 수동적으로 세션 해제에 대한 요청을 받는 과정으로 마찬가지로 서버 또는 클라이언트가 될 수 있다 |
3. TCP 상태 특징
1) TCP 연결은 양방향이므로, 양 측에서 각각 다른 상태를 관리하게 됨
- 즉, 다른 경로를 통해 `TCP 연결 설정` 및 `TCP 연결 종료`에 갈 수 있음
2) 2가지 다른 TCP 연결 설정 경로
- (능동 개방) Closed -> Listen -> SYN-Received -> Establshed
. 자발적으로 SYN 세그먼트를 보내며 연결 설정하는 경우
- (수동 개방) Closed -> SYN-Sent -> Established
. 수동적으로 SYN 세그먼트를 수신하며 연결 설정하는 경우
-> 주로, 서버 응용이 TCP에게 상시적 연결 수용 및 대기
3. 다른 연결 종료 경로
- (수동 종료) Eatablished -> Close-Wait -> Last-ACK -> Closed
. 상대로부터 FIN 세그먼트를 받고, 이에대해 응답하며 종료하는 경로
- (능동 종료) Eatablished -> FIN-Wait-1 -> FIN-Wait-2 -> Time-Wait -> Closed
또는, Eatablished -> FIN-Wait-1 -> Closing -> Time-Wait -> Closed
. 자발적으로 FIN 세그먼트를 보내고, 응답을 기다리며 종료하는 과정
4. 세그먼트(전송 계층에서의 데이터 전송 단위) 설명
명칭 | 의미 |
SYN(Synchronize) | 연결 시작, 회선 개설 요청에 사용되는 세그먼트이다. TCP 에서는 접속 요청을 하는 주체가 SYN 세그먼트를 전송하고 요청을 받는 주체는 여기에 값을 추가해서 응답한다. |
ACK(Acknowledgement) | 요청에 대한 응답 세그먼트이다. |
RST(Reset) | 연결 리셋에 대한 세그먼트로 유효하지 않은 연결에 대한 시도를 했다거나 통신의 연결 및 종료를 정상적으로 할 수 없을때 사용된다. |
FIN(Finish) | 연결 해제, 회선 종결 요청에 사용되는 세그먼트이다. |
MTU(Maximum Transmission Unit) | MTU는 그림에는 나와있지 않지만 MSS의 설명이 필요하기 때문에 언급하게 되었다. MTU란 TCP/IP 네트워크 등과 같은 패킷 또는 프레임 기반의 네트워크에서 한번에 전송될 수 있는 최대 크기의 패킷 또는 프레임을 말한다. 단위는 Byte이며 MTU 값은 네트워크 인터페이스나 대역폭 등 네트워크 환경에 따라 달라질 수 있는데 일반적으로 흔히 쓰이는 이더넷의 경우 MTU 값은 1500을 사용하고, FDDI는 4000, X.25는 576, Gigabit는 9000정도를 사용한다. |
MSS(Maximum Segment Size) | MTU에서 헤더를 제외한 TCP상에서 전송 할 수 있는 사용자 데이터의 최대 크기에 해당하는 세그먼트이다. 위 그림에서는 처음 접속 요청시 1460바이트에 해당하는 MSS를 전송하고 있다. 이것은 이더넷과같은 환경에서 MTU를 1500으로 사용했을 때 여기에 IPv4 헤더의 20바이트와 TCP 헤더의 20바이트를 뺀 값이다. 그리고 응답시에는 1024바이트로 응답하는데 이것은 1024바이트의 크기의 단위로 데이터를 전송하겠다는것을 의미한다. |
5. 비정상 종료 상황 예시
명칭 | 의미 |
CLOSE_WAIT | - 어플리케이션에서 close()를 적절하게 처리해주지 못하면, TCP 포트는 CLOSE_WAIT상태로 계속 기다림 - CLOSE_WAIT상태가 statement에 많아지게 되면 Hang이 결려 더 이상 연결을 하지 못하는 경우가 발생한다 따라서 어플리케이션 개발 시 여러 상황에 따라 close() 처리를 잘 해줘야 함 |
FIN_WAIT_1 | - 상대방 측에 커넥션 종료 요청을 했는데 ACK를 받지 못한 상태로 기다리고 있음 - 서버를 찾을 수 없는 것으로 네트워크 or 방화벽의 문제일 수 도있음 - FIN_WAIT_! 상태는 일정시간이 지나 Time Out이 되면 자동을 종료함 |
FIN_WAIT_2 | - 클라이언트가 서버에 종료를 요청한후 서버에서 요청을 접수했다고 ACK를 받았지만, 서버에서 종료를 완료했다는 FIN을 받지 못하고 기다리고 있는 상태 - 이 상태는 양방 간 두번의 통신이 이루어졌기 때문에 네트워크 문제는 아닌 것으로 판단되며, 서버 측에서 CLOSE를 처리하지 못하는 경우일 수도 있음 - FIN_WAIT_2 역시 일정시간 후 Time Out이 되면 자동을 종료함 |