코골이 및 감지 할 수없는 값을 감지

네트워크가 해킹되거나 불법적으로 액세스되거나 효과적으로 비활성화되는 경우가 많이 있습니다. TJ Maxx 네트워크에 대한 악명 높은 2006 년 해킹은 TJ Maxx의 실사 부족과 그로 인해 회사가 겪은 법적 결과로 인해 잘 문서화되었습니다. 또한 수천 명의 TJ Maxx 고객에게 해를 끼치는 수준과 네트워크 보안에 대한 자원 할당의 중요성이 명백해졌습니다.

TJ Maxx 해킹에 대한 추가 분석을 통해 사건이 최종적으로 발견되고 완화 된 실질적인 시점을 가리킬 수 있습니다. 그러나 눈에 띄지 않는 보안 사고는 어떻습니까? 진취적인 젊은 해커가 시스템 관리자가 더 현명하지 않게하는 방식으로 네트워크에서 아주 중요한 정보를 숨길 수있을 정도로 신중하다면 어떻게해야할까요? 이러한 유형의 시나리오에 더 잘 대처하기 위해 보안 / 시스템 관리자는 Snort 침입 탐지 시스템 (IDS)을 고려할 수 있습니다.

코골이의 시작

1998 년 Snort는 Sourcefire 창립자 Martin Roesch에 의해 발표되었습니다. 당시에는 Unix 및 Unix와 유사한 운영 체제에서 주로 작동하는 가벼운 침입 탐지 시스템으로 청구되었습니다. 당시 Snort의 구축은 네트워크 침입 탐지 시스템의 사실상의 표준이 되었기 때문에 최첨단으로 간주되었습니다. C 프로그래밍 언어로 작성된 Snort는 보안 분석가가 구성 할 수있는 세분성에 중점을 두면서 빠르게 인기를 얻었습니다. Snort는 또한 완전히 오픈 소스이며 결과는 오픈 소스 커뮤니티에서 충분한 조사를 견뎌낸 매우 강력하고 널리 사용되는 소프트웨어입니다.

코골이 기초

이 글을 쓰는 시점에서 Snort의 현재 프로덕션 버전은 2.9.2입니다. 스니퍼 모드, 패킷 로거 모드 및 네트워크 침입 탐지 및 방지 시스템 (IDS / IPS) 모드의 세 가지 작동 모드를 유지합니다.

스니퍼 모드는 네트워크 인터페이스 카드 (NIC) Snort가 설치된 경로와 교차하는 패킷을 캡처하는 것 이상의 역할을합니다. 보안 관리자는이 모드를 사용하여 NIC에서 감지되는 트래픽 유형을 해독 한 다음 그에 따라 Snort 구성을 조정할 수 있습니다. 이 모드에서는 로깅이 없으므로 네트워크에 들어가는 모든 패킷은 콘솔에서 하나의 연속 스트림으로 간단히 표시됩니다. 대부분의 시스템 관리자가 tcpdump 유틸리티 또는 Wireshark와 같은 것을 사용하여 더 나은 서비스를 제공하므로 문제 해결 및 초기 설치 이외에는이 특정 모드 자체가 별 가치가 없습니다.

패킷 로거 모드는 스니퍼 모드와 매우 유사하지만이 특정 모드의 이름에는 한 가지 중요한 차이점이 있습니다. 패킷 로거 모드를 사용하면 시스템 관리자는 원하는 패킷을 원하는 장소와 형식으로 기록 할 수 있습니다. 예를 들어, 시스템 관리자가 네트워크 내의 특정 노드에서 / log라는 디렉토리에 패킷을 기록하려는 경우 먼저 해당 특정 노드에서 디렉토리를 작성합니다. 커맨드 라인에서, 그는 Snort에게 그에 따라 패킷을 기록하도록 지시 할 것입니다. 패킷 로거 모드의 값은 보안 분석가가 주어진 네트워크의 히스토리를 검사 할 수있게하므로 이름에 내재 된 레코드 보존 측면에 있습니다.

확인. 이 정보는 모두 잘 알고 있지만 값은 어디에 추가됩니까? Wireshark와 Syslog가 훨씬 더 예쁜 인터페이스로 실질적으로 동일한 서비스를 수행 할 수있을 때 시스템 관리자가 Snort를 설치하고 구성하는 데 시간과 노력을 투자해야하는 이유는 무엇입니까? 이러한 관련 질문에 대한 답은 NIDS (Network Intrusion Detection System) 모드입니다.

스니퍼 모드와 패킷 로거 모드는 Snort가 실제로해야 할 일인 NIDS 모드를 향한 발판입니다. NIDS 모드는 주로 snort 구성 파일 (일반적으로 snort.conf라고 함)에 의존합니다. 여기에는 일반적인 Snort 배포에서 시스템 관리자에게 경고를 보내기 전에 참조하는 모든 규칙 세트가 포함되어 있습니다. 예를 들어, 관리자가 FTP 트래픽이 네트워크에 들어 오거나 네트워크를 떠날 때마다 경고를 트리거하려면 snort.conf 및 voila!에서 해당 규칙 파일을 참조하면됩니다. 이에 따라 경고가 트리거됩니다. 상상할 수 있듯이 snort.conf의 구성은 시스템 관리자가 특정 네트워크와 관련이 있다고 생각하는 경고, 프로토콜, 특정 포트 번호 및 기타 휴리스틱 측면에서 매우 세분화 될 수 있습니다.

코골이가 짧은 곳

Snort가 인기를 얻기 시작한 직후, 유일한 단점은 그것을 구성하는 사람의 재능 수준이었습니다. 그러나 시간이 지남에 따라 가장 기본적인 컴퓨터는 여러 프로세서를 지원하기 시작했으며 많은 LAN이 10Gbps의 속도에 접근하기 시작했습니다. Snort는 역사상 "경량"으로 꾸준히 청구되었으며이 이름은 오늘날과 관련이 있습니다. 커맨드 라인에서 실행될 때, 패킷 레이턴시는 결코 큰 장애가되지 않았지만, 최근에는 멀티 스레딩 (multithreading)이라는 개념이 많은 애플리케이션이 위에서 언급 한 다중 프로세서를 이용하려고 시도함에 따라 실제로 채택되기 시작했습니다. 멀티 스레딩 문제를 극복하려는 여러 시도에도 불구하고 Roesch와 나머지 Snort 팀은 실질적인 결과를 얻을 수 없었습니다. Snort 3.0은 2009 년에 출시 될 예정이지만 아직 작성 당시에는 제공되지 않았습니다. 또한 Network World의 Ellen Messmer는 Snort가 Suricata 1.0으로 알려진 국토 안보부 IDS와의 경쟁에서 빠르게 자신을 발견했으며 제안자는 다중 스레딩을 지원한다고 제안했습니다. 그러나 이러한 주장은 Snort의 설립자에 의해 격렬하게 논쟁의 여지가 있음에 주목해야합니다.

스 노트의 미래

Snort는 여전히 유용한가요? 시나리오에 따라 다릅니다. Snort의 멀티 스레딩 단점을 활용하는 방법을 알고있는 해커는 특정 네트워크가 침입을 탐지하는 유일한 수단은 Snort 2.x라는 사실을 알고 기뻐할 것입니다. 그러나 Snort는 결코 모든 네트워크에 대한 보안 솔루션이 아닙니다. Snort는 항상 네트워크 패킷 분석 및 네트워크 포렌식 측면에서 특정 목적을 수행하는 수동 도구로 간주되었습니다. 자원이 제한적이라면, Linux에 대한 풍부한 지식을 갖춘 현명한 시스템 관리자는 나머지 네트워크와 함께 Snort를 배치하는 것을 고려할 수 있습니다. Snort는 단점이 있지만 최저 비용으로 최고의 가치를 제공합니다. (Linux의 Linux 배포판 : 자유의 요새에 대해)