WEBVTT

00:00.270 --> 00:01.103
이번 수업에선

00:01.103 --> 00:03.690
모니터링과 감사에 집중할 겁니다

00:03.690 --> 00:05.343
모니터링부터 시작하죠

00:05.343 --> 00:06.930
네 모니터링에 대해 말할 때

00:06.930 --> 00:09.090
보안 분석가의 주요 업무 중 하나는 네트워크를

00:09.090 --> 00:11.130
모니터링하는 거죠

00:11.130 --> 00:12.150
우리는 탐정과 같습니다.

00:12.150 --> 00:13.350
네 뭔가 이상해 보이는

00:13.350 --> 00:14.970
걸 뿌리 뽑으려는 겁니다 수동으로

00:14.970 --> 00:18.180
하거나 자동화된 수단을 통해 할 수 있어요

00:18.180 --> 00:21.150
지금요 syslog는 다양한 어플라이언스와 소프트웨어

00:21.150 --> 00:23.820
앱이 로그나 이벤트 기록을 중앙 서버로 전송할

00:23.820 --> 00:26.520
수 있도록 하는 프로토콜입니다

00:26.520 --> 00:30.300
syslog는 표준 클라이언트 서버 모델을 따를 것입니다

00:30.300 --> 00:33.030
이는 네트워크를 통해 분산 시스템의 이벤트를

00:33.030 --> 00:35.490
기록하기 위한 사실상의 표준입니다.

00:35.490 --> 00:38.820
맞습니다 여러분이 매일 작업하게 될 많은 시스템에서 syslog가

00:38.820 --> 00:40.950
사용되는 걸 보게 될 겁니다

00:40.950 --> 00:43.590
이제 syslog는 대부분의 운영 체제와 대부분의

00:43.590 --> 00:45.270
네트워킹 장비에서 실행됩니다.

00:45.270 --> 00:47.310
네 그래서 시스코 라우터를 쓰든 Windows

00:47.310 --> 00:49.920
컴퓨터나 Linux 서버를 쓰든 모두 syslog를

00:49.920 --> 00:51.630
쓸 수 있습니다

00:51.630 --> 00:53.490
메시지를 다시 보낼 때 syslog

00:53.490 --> 00:55.920
메시지는 어떤 모습일까요?

00:55.920 --> 00:58.860
음, syslog 메시지에는 몇 가지 내용이 포함됩니다.

00:58.860 --> 01:01.530
Pri 코드가 포함돼 있어요 우선순위 코드죠

01:01.530 --> 01:04.410
헤더와 메시지 부분을 포함하고 있어요

01:04.410 --> 01:05.610
하나씩 얘기해 보죠

01:05.610 --> 01:08.040
먼저 이 pri 코드, 즉 우선순위가 있으며

01:08.040 --> 01:10.200
이는 시설과 데이터의 심각도 수준을

01:10.200 --> 01:12.450
기반으로 계산됩니다.

01:12.450 --> 01:13.710
다음 헤더가 있습니다 헤더는

01:13.710 --> 01:15.570
이벤트의 타임스탬프를 담을 것입니다

01:15.570 --> 01:17.190
호스트 이름도요 안 됩니다,

01:17.190 --> 01:20.160
어디서 왔는지 언제였는지 알 수 있죠

01:20.160 --> 01:22.230
그리고 마지막으로 이벤트의 소스 프로세스와

01:22.230 --> 01:24.360
관련 내용이 포함된 메시지 부분이 있습니다.

01:24.360 --> 01:27.330
기본적으로 어떤 데이터가 발생했으며 우리에게 무엇을 알리고

01:27.330 --> 01:28.560
싶은가요?

01:28.560 --> 01:30.570
이것이 메시지 부분에 대한 아이디어입니다.

01:30.570 --> 01:33.390
이 메시지의 핵심이 바로 이거죠

01:33.390 --> 01:34.800
원래 버전에서는

01:34.800 --> 01:37.770
몇 가지 단점이 있었어요

01:37.770 --> 01:40.230
원래 프로토콜은 udp에 의존했어요

01:40.230 --> 01:42.990
네 자 이제 udp는 프로토콜을

01:42.990 --> 01:45.510
잊게 하거든요

01:45.510 --> 01:46.920
응답과 인정을 기다리지

01:46.920 --> 01:48.270
않고 바로 보냅니다

01:48.270 --> 01:50.250
그래서 그것은 그것이 거기에 도달했다고 가정합니다.

01:50.250 --> 01:51.420
네 네트워크가 막히면

01:51.420 --> 01:53.051
데이터가 삭제될 수 있어요

01:53.051 --> 01:55.500
따라서 정보가 로그 서버에 도달하지

01:55.500 --> 01:57.630
않아 로그되지 않죠

01:57.630 --> 01:59.760
네 초기엔 괜찮았을 거예요 네트워크에

01:59.760 --> 02:00.930
있는 모두를 믿을 수 있다고

02:00.930 --> 02:02.520
생각했으니까요 하지만 요즘은

02:02.520 --> 02:04.080
그런 게 안 되죠

02:04.080 --> 02:05.760
우리는 데이터가 거기에 도착하는지 확인하고 싶습니다.

02:05.760 --> 02:07.920
그래서 해결책을 찾아야 해요

02:07.920 --> 02:09.690
두 번째는 기본적인 보안

02:09.690 --> 02:11.640
통제가 별로 없다는 겁니다

02:11.640 --> 02:14.070
syslog에는 기본적으로 암호화나 인증 같은

02:14.070 --> 02:16.080
것이 포함되어 있지 않았습니다.

02:16.080 --> 02:17.850
이것도 단점이죠

02:17.850 --> 02:20.250
따라서 최신 syslog 구현에서는 이러한

02:20.250 --> 02:21.750
사항을 수정했습니다.

02:21.750 --> 02:23.220
자 이러한 보안 문제 때문에

02:23.220 --> 02:25.590
새로운 syslog 구현들은 많은 다양한

02:25.590 --> 02:27.510
기능과 기능을 추가했습니다

02:27.510 --> 02:29.400
여기서 두어 가지에 대해 얘기할게요

02:29.400 --> 02:32.460
새로운 구현들은 tcp를 이용해 지속적으로

02:32.460 --> 02:34.170
전달됩니다

02:34.170 --> 02:36.360
이렇게 합니다 이렇게 하면 네트워크가 복잡해져서

02:36.360 --> 02:37.770
메시지가 전달되지 않아도

02:37.770 --> 02:39.600
tcp를 사용하기 때문에 반복해서

02:39.600 --> 02:41.220
전달할 겁니다

02:41.220 --> 02:43.470
두 번째 개선 사항은 새로운 구현은 tls,

02:43.470 --> 02:46.230
즉 트랜스포트 계층 보안을 사용해 서버로 전송되는

02:46.230 --> 02:49.050
메시지를 암호화할 수 있습니다

02:49.050 --> 02:50.760
네트워크의 다른 누군가가

02:50.760 --> 02:52.580
데이터를 읽을 수 없도록요

02:52.580 --> 02:55.200
보낸 사람과 받는 서버만

02:55.200 --> 02:57.510
읽을 수 있어요

02:57.510 --> 02:58.343
세 번째는

02:58.343 --> 03:02.130
새로운 구현들이 md5와 sha1을 이용해

03:02.130 --> 03:04.950
인증과 무결성을 제공합니다

03:04.950 --> 03:07.770
네 이렇게 하면 이렇게

03:07.770 --> 03:12.930
하면 안 그러면...

03:12.930 --> 03:14.730
다른 기능도 많죠

03:14.730 --> 03:16.920
네 이 세트에는 많이 집중하지 않아요

03:16.920 --> 03:19.290
왜냐하면 중요한 세 가지가 있는데 지속적인

03:19.290 --> 03:21.900
배송을 위해 tcp로 옮겼어요

03:21.900 --> 03:23.910
암호화를 위해 tls로 전환했으며,

03:23.910 --> 03:26.130
인증 및 무결성을 위해 md5 및 sha1을

03:26.130 --> 03:28.050
사용하기 시작했습니다.

03:28.050 --> 03:30.090
네 이제 이제 차세대 Syslog라고도

03:30.090 --> 03:35.490
하죠 rsyslog라고도 하고요

03:35.490 --> 03:37.470
네 자 마지막으로 말씀드릴 것은 syslog는

03:37.470 --> 03:40.560
종종 세 가지로 해석된다는 겁니다

03:40.560 --> 03:43.380
데이터를 보내는 프로토콜을 참조할 수 있어요

03:43.380 --> 03:46.410
이는 syslog 서버에서처럼 서버를 참조하거나

03:46.410 --> 03:48.690
syslog 데이터에서처럼 로그 항목

03:48.690 --> 03:50.430
자체를 참조할 수 있습니다.

03:50.430 --> 03:51.990
네 사람들은 종종 syslog라고

03:51.990 --> 03:54.090
하는데 셋 다라는 뜻이죠 이 셋 중 아무나요

03:54.090 --> 03:55.470
문맥에 따라서요

03:55.470 --> 03:56.700
따라서 업계 사람들이

03:56.700 --> 03:58.530
snmp에 대해 이야기하는 세 가지

03:58.530 --> 03:59.790
중 어느 것이 다음 snmp인지

03:59.790 --> 04:01.860
이해하기 위해 이야기하는 것을 들을

04:01.860 --> 04:03.810
때 주의하십시오.

04:03.810 --> 04:06.900
Snmp는 단순한 네트워크 관리 프로토콜입니다

04:06.900 --> 04:09.480
네트워크에 연결된 장치 및 컴퓨터를 모니터링하는

04:09.480 --> 04:12.000
데 도움이 되는 tcp 프로토콜입니다.

04:12.000 --> 04:14.520
Snmp는 네트워크 관리 및 모니터링 시스템에

04:14.520 --> 04:16.830
통합되어 있으며 관리 및 모니터링 개념에

04:16.830 --> 04:18.840
많이 사용됩니다 ??? 네.

04:18.840 --> 04:21.870
Snmp는 세 부분으로 나뉘어요

04:21.870 --> 04:24.030
관리되는 장치와 에이전트 그리고 스스로의

04:24.030 --> 04:26.370
네트워크 관리 시스템이 있죠

04:26.370 --> 04:28.020
관리되는 장치에 대해 얘기했죠

04:28.020 --> 04:30.510
이는 네트워크 관리 시스템에서 에이전트를 사용하여

04:30.510 --> 04:32.400
모니터링하는 컴퓨터 및 기타 네트워크

04:32.400 --> 04:34.380
연결 장치입니다.

04:34.380 --> 04:37.560
요원은 관리되는 장치에 로딩되는 소프트웨어예요

04:37.560 --> 04:39.450
그러면 정보를 모니터링 할 네트워크

04:39.450 --> 04:41.040
관리 시스템으로 리다이렉션

04:41.040 --> 04:42.510
할 수 있습니다

04:42.510 --> 04:44.700
그리고 네트워크 관리 시스템(nms)은

04:44.700 --> 04:47.100
네트워크를 통해 네트워크에 연결된 모든 장치와

04:47.100 --> 04:48.120
컴퓨터의 모니터링을

04:48.120 --> 04:52.230
제어하는 ​​하나 이상의 서버에서 실행되는 소프트웨어입니다.

04:52.230 --> 04:54.840
Snmp는 접착제로서 이 snmp 프로토콜을

04:54.840 --> 04:58.080
이용해 이 세 가지를 서로 통신하게 합니다

04:58.080 --> 05:00.570
그렇다면 네트워크 내부에서는 이 모든 것이 어떻게 보일까요?

05:00.570 --> 05:03.180
화면에 간단한 다이어그램이 있습니다

05:03.180 --> 05:05.910
네 왼쪽에는 nms라고 하는 네트워크 관리국이 있어요

05:05.910 --> 05:09.000
우리 네트워크 관리 시스템의 일부죠 , 우리 시스템이에요

05:09.000 --> 05:10.830
관리자로 작동해 네트워크에

05:10.830 --> 05:12.630
걸쳐 관리되는 모든 장치에

05:12.630 --> 05:15.060
메시지를 보내고 받을 겁니다 라우터,

05:15.060 --> 05:17.850
스위치 그리고 서버∙∙∙ 그렇죠

05:17.850 --> 05:19.290
네 이제 정보를 원할 땐 get

05:19.290 --> 05:20.860
request를 보내고

05:20.860 --> 05:23.970
그 장치들이 set request를 이용해 정보를

05:23.970 --> 05:25.890
다시 보내죠 ?

05:25.890 --> 05:27.960
트랩 요청입니다 트랩 요청이라는 것도

05:27.960 --> 05:29.910
있습니다 관리 장치로부터 청하지

05:29.910 --> 05:31.320
않은 정보를 받는 것입니다

05:31.320 --> 05:32.970
주기적으로 필요한 정보를 보내는

05:32.970 --> 05:34.440
장치입니다

05:34.440 --> 05:38.070
네 snmp를 이용해 네트워크 관리를 수행할 때 데이터가

05:38.070 --> 05:40.620
전송되는 옵션은 두 가지입니다

05:40.620 --> 05:42.690
사용 중인 네트워크(대역 내 통신이라고

05:42.690 --> 05:44.670
함)를 통해 보내거나 대역 외로

05:44.670 --> 05:46.830
보낼 수 있습니다.

05:46.830 --> 05:47.940
네 이제 대역은 관리

05:47.940 --> 05:49.890
데이터를 회사 정보와 일반 데이터를

05:49.890 --> 05:51.810
갖고 있는 같은 네트워크로 보낸다는

05:51.810 --> 05:54.120
의미죠 ?

05:54.120 --> 05:57.600
이게 더 싸고 쉽지만 안전하진 않아요

05:57.600 --> 05:58.710
더 안전하게 하려면

05:58.710 --> 06:00.930
대역 외 네트워크를 만들어야 해요

06:00.930 --> 06:02.760
네 모든 관리가 발생하는

06:02.760 --> 06:04.560
부차적 네트워크지만 여전히

06:04.560 --> 06:06.780
사용자가 얻는 모든 데이터가

06:06.780 --> 06:08.940
발생하는 주 대역 네트워크가

06:08.940 --> 06:10.050
있어요

06:10.050 --> 06:11.610
관리해야 합니다 보안을

06:11.610 --> 06:14.490
증가시키고 사용자가 만지거나 볼

06:14.490 --> 06:17.160
수 없는 곳에서 관리 기능을 제거해야

06:17.160 --> 06:18.993
하니까요