은닉서명 ① D.Chaum에 의해서 제안된 서명 방식이다. ② 서명자가 서명문 내용을 알지 못하는 상태에서 서명하는 것을 수식으로 표현한다. ③ 서명문의 내용을 서명자로부터 숨기는 서명방식으로 서명을 받는 사람의 신원과 서명문을 연결시킬 수 없기 때문에 익명성을 유지한다. ④ 전자화폐에 사용한다.
대리(위임)서명 ① 본인이 부재 시 자신을 대신하여 다른 사람이 서명을 수행한다. ② 제3자가 서명할 수 있어야 하고 검증자는 서명자의 위임 사실을 확인할 수 있어야 한다. ③ 완전위임, 부분위임, 보증위임
그룹서명 ① D.Chaum과 Evan Heyst에 의해서 제안된 방법이다. ② 특성상 소속원의 익명성을 보장하는데 응용된다. ③ 그룹의 소속원만이 서명할 수 있다. ④ 검증자는 그룹의 서명문을 확인할 수 있으나 서명자의 신원을 알 수 없다.
다중서명 ① 전자결제시스템 혹은 전자계약시스템에 응용 가능한 방식이다. ② 동시 다중서명 : 전자서명시스템의 경우 동시 다중서명을 사용해서 서로 간에 안전한 계약을 수행한다. ③ 순차 다중서명 : 전자결제의 경우 순차다중성 방식을 이용해 서명한다.
수신자 지정 서명 ① 특정 수신자만 검증 가능, 서명자도 검증 불가능하다. ② 특정 수신자는 필요 시 제3자에게 서명의 정당성을 확인 가능하다. ③ 지정된 수신자만 서명을 확인할 수 있어야 하며 서명자조차도 서명을 확인할 수 없어야 한다.
이중서명 ① 사용자의 지불정보는 상점에 숨기고 주문정보는 은행에 숨김으로써 사용자의 프라이버시가 보호되도록 한다. (SET)
어원은 root(유닉스/리눅스 권한) + kit(도구).유닉스 계열 시스템에서 해커가 시스템 툴을 rootkit으로 바꾸는 데서 유래
악성코드의 존재를 감추기 위해 설치하는 소프트웨어
루트킷 (rootkit)은 컴퓨터 소프트웨어 중에서 악의적인 것들의 모음으로써, 자신의 또는 다른 소프트웨어의 존재를 가림과 동시에 허가되지 않은 컴퓨터나 소프트웨어의 영역에 접근할 수 있게 하는 용도로 설계되었다.[1] 루트킷이라는 용어는 "루트"(유닉스 계열시스템에서 권한을 가진 계정의 전통적인 이름)와 "kit"(툴을 구현하는 소프트웨어 구성 요소를 가리킨다.)의 합성어이다. "루트킷"이라는 용어는 악성 소프트웨어와의 연관으로 인해 부정적인 의미를 함축하고 있다.[1]
루트킷의 설치는 자동으로 이루어지거나 공격자가 루트 권한이나 관리자 접근을 획득하였을 때 설치될 수 있다. 이 접근을 획득하는 것은 알려진 취약점(권한 확대같은)을 공격하는것이나 암호(크래킹 또는사회공학을 통해 획득한)를 통한 직접적인 권한의 결과이다. 한 번 설치되면, 권한을 가진 접근을 유지할 뿐만 아니라 침입을 숨길 수도 있다. 중요한 점은 루트 또는 관리자 접근이다. 시스템에 대한 완전한 제어는 존재하는 소프트웨어가 수정되었을 수 있다는 것을 의미한다.
루트킷 탐지는 이것이 자신을 찾으려 하는 소프트웨어를 뒤집어 엎을 수 있기 때문에 어려운 일이다. 탐지 방법은 대체적이고 신뢰성 있는운영 체제나 행동 기반 방식, 특징(signature) 스캐닝 그리고 메모리 덤프 분석 등이 있다. 제거는 복잡하거나 심지어 실질적으로 불가능할 수 있는데 특히 루트킷이커널에 거주할 때 더 그렇다; 운영 체제의 재설치가 문제 해결의 유일한 해결법이 될 수 있다.[2]펌웨어루트킷의 경우, 제거하기 위해서 하드웨어 교체나 특별한 장비가 필요할 수 있다.
스턱스넷(Stuxnet)은 대단히 정교한 컴퓨터 웜으로, 기존에 알려진 여러 가지 윈도우 제로데이 취약점을 이용해 컴퓨터를 감염시키고 확산된다. 목적은 단순히 PC를 감염시키는 것이 아니라 물리적인 피해를 입히는 데 있다. 구체적으로, 스턱스넷은 핵무기와 원자로를 가동하는 농축 우라늄을 생산하는 데 사용되는 원심분리기를 타격한다.
Hamed Saber (Creative Commons BY or BY-SA)
스턱스넷은 2010년 정보보안 커뮤니티가 처음 발견했지만, 개발은 2005년부터 시작된 것으로 추정된다. 엄청난 확산 능력과 광범위한 감염율에도 불구하고 우라늄 농축에 관여하지 않는 컴퓨터에는 거의 해를 입히지 않는다. 일단 컴퓨터를 감염시키면 그 컴퓨터가 지멘스(Siemens)에서 제조한 특정 PLC(Programmable Logic Controller)에 연결되어 있는지 여부를 확인한다. PLC는 컴퓨터가 산업용 장비와 상호작용하고 이를 제어하는 데 사용된다. 문제의 PLC에 연결된 것을 확인하면 스턱스넷은 PLC의 프로그램을 변경하여 원심분리기가 장시간 동안 지나치게 빠른 속도로 회전하게 하고, 이로 인해 장비는 고장 나거나 파괴된다. 이 과정이 진행되는 동안 PLC는 컨트롤러 컴퓨터에 모든 부분이 정상 가동 중이라고 알리므로 문제를 알아차릴 때면 이미 너무 늦은 시점이 된다.
스턱스넷 제작자 스턱스넷을 만든 주체는 미국과 이스라엘의 정보 당국이라는 것이 중론이다. 스턱스넷 웜을 개발하기 위한 기밀 프로그램은 “올림픽 게임 작전(Operation Olympic Games)”이라는 코드명으로 불렸다. 조지 W. 부시 대통령 시절 시작돼 오바마 정부에까지 이어졌다. 두 정부 모두 스턱스넷 개발을 공식적으로 인정한 적은 없지만 2011년 이스라엘 방위군 참모총장 가비 아슈케나지의 은퇴 기념식 동영상을 보면 스턱스넷을 재임 시절 성공적 작전 중 하나로 거론하는 장면이 나온다.
스턱스넷을 개발한 개별 엔지니어들은 확인되지 않았지만 이들이 매우 뛰어난 기술을 갖췄으며 그 수도 많다는 것을 알 수 있다. 카스퍼스키 랩(Kaspersky Lab)의 로엘 쇼웬버그는 최종 형태의 스턱스넷 웜은 코더 10명으로 구성된 팀이 2~3년 정도 걸려 만들었을 것으로 추정했다.
두쿠(Ducu)와 플레임(Flame) 등 스턱스넷과 비슷한 감염 능력을 가진 다른 웜도 발견되었으나 이러한 웜의 목적은 스턱스넷과는 전혀 다르다. 전문가들은 스턱스넷과의 유사성을 근거로 동일한 개발진이 만든 것으로 추정한다.
스턱스넷의 목적 미국 및 이스라엘 정부는 스턱스넷을 이란의 핵무기 개발을 와해하거나 최소한 지연시키기 위한 도구로 만들었다. 부시 및 오바마 행정부는 이란의 핵무기 개발이 현실화될 경우 이스라엘이 이란 핵 시설을 공습하고 이로 인해 중동 지역에 전쟁이 일어날 가능성이 있다고 판단했으며 올림픽 경기 작전을 비폭력적 대안으로 봤다. 물리적 인프라에 대한 이러한 사이버 공격이 가능한지조차 불확실했지만 부시 행정부 당시 백악관 상황실의 한 회의에서 파손된 원심분리기 조각이 공개됐고 이를 기점으로 미국은 스턱스넷 맬웨어 작전에 본격적으로 착수했다.
스턱스넷의 목적은 오로지 나탄즈에 위치한 이란 핵시설이었으므로 그 외의 시스템 감염은 염두에 두지 않고 개발됐다. 정보 요원이나 내부 직원이 USB 스틱을 시설 안으로 가져가 감염시켜야 했다. 즉, 의도대로 흘러갔다면 감염이 통제를 벗어나 확산될 일은 없었다. 그러나 어찌어찌해서 스턱스넷은 인터넷에 연결된 컴퓨터에 설치됐고, 극도의 정밀함과 공격적인 속성 탓에 겉잡을 수 없이 퍼지기 시작했다. 다만 앞서 언급했듯이 핵시설 외부의 컴퓨터는 감염시킨다 해도 거의 아무런 피해도 입히지 않았다. 많은 미국인들은 스턱스넷이 광범위하게 확산된 것은 이스라엘이 코드를 수정했기 때문이라고 생각한다. 당시 부통령 바이든은 이스라엘의 이 같은 행동에 특히 분노했던 것으로 전해진다.
스턱스넷 소스 코드 시만텍의 보안 기술 및 대응 그룹 이사이며 스턱스넷을 처음 규명한 팀에 있었던 리암 오머추는 스턱스넷이 “우리가 지금까지 본 코드 중에서 단연 가장 복잡한 코드였다. 기존의 다른 코드와는 아예 차원이 달랐다”고 말했다. 또한 오머추는 스턱스넷 소스 코드를 다운로드로 제공한다고 주장하는 웹사이트는 많지만 이를 믿으면 안 된다고 말했다. 오머추는 미국과 이스라엘 정보 기관의 코더들이 작성한 스턱스넷 웜의 원본 소스 코드는 공개되거나 유출된 적이 없으며, 현재 떠도는 바이너리에서 코드를 추출하는 것도 불가능하다고 강조했다. (전체 패키지의 아주 작은 일부분인 한 드라이버용 코드는 리버스 엔지니어링을 통해 재구성됐지만 이는 원본 코드와는 다르다.)
그러나 오머추는 바이너리의 작동을 살펴보고 리버스 엔지니어링하는 것으로 코드의 많은 부분을 이해할 수 있다고 말했다. 예를 들어 오머추는 “이 앱을 처음 분석했을 때부터 특정 지멘스 장비를 찾는다는 점은 명확히 알 수 있었다”며, “3~6개월에 걸친 리버스 엔지니어링 이후 이 코드에서 수행하는 모든 작업의 99%를 파악할 수 있었다”고 말했다.
스턱스넷의 목적을 드러낸 것은 철저한 코드 분석이다. 오머추는 “이 코드가 각각 168개의 주파수 변환기로 구성된 8개 또는 10개의 어레이를 찾아 탐색한다는 것을 알아냈다. 우라늄 농축 시설을 점검하는 방법에 관한 국제 원자력 에너지 협회의 문서를 온라인으로 볼 수 있는데, 이 문서를 통해 주파수 변환기가 몇 개인지, 원심분리기가 몇 개인지 등 우라늄 시설의 구성을 구체적으로 볼 수 있다. 문서에 따르면 우라늄 시설은 8개의 어레이로 구성되고 각 어레이에 168개의 원심분리기가 있다. 스턱스넷 코드에서 탐색하는 구조와 정확히 일치했다”고 말했다.
오머추는 “이 사실을 밝혀내고 우리는 무척 흥분했지만, 곧 이것이 국제적인 첩보 작전일 가능성을 인식하고는 큰 두려움을 느꼈다”고 덧붙였다. 시만텍은 2010년 9월 이 정보를 공개했다. 서방 세계 분석가들은 2009년 말부터 이란이 원심분리기 문제를 겪고 있음을 알았지만 그 이유까지 아는 사람은 극소수였다.
스턱스넷 다큐멘터리 ‘엔론: 세상에서 제일 잘난 놈들(The Smartest Guys In The Room)’, ‘고잉 클리어(Going Clear)’와 같은 작품을 만들고 오스카상 후보에도 올랐던 다큐멘터리 제작자 알렉스 기브니는 스턱스넷의 역사와 이 사건이 이란과 서방 세계 간의 관계에 미친 영향을 분석한 다큐멘터리 ‘제로 데이(Zero Days)’를 만들었다. 제로 데이에는 오머추 및 그 동료들과의 인터뷰가 포함되어 있으며 유튜브에서 전체를 볼 수 있다.
이 다큐멘터리에서 극적인 한 장면은 스턱스넷이 실제 물리적 세계를 파괴할 수 있음을 시만텍 팀이 납득시키는 장면이다. 시만텍 팀은 풍선에 공기를 넣도록 지멘스 PLC를 프로그램한 다음 스턱스넷으로 이 PLC를 조작하는 PC를 감염시켰다. 결과는 극적이었다. 컨트롤러는 단 5초 동안 풍선을 불도록 프로그램되었지만 그 시간을 지나 계속 공기를 불어넣었고 결국 풍선은 터졌다.
이란 우라늄 원심분리기 파괴(풍선과 동일한 논리로, 과도한 속도로 회전해 결국 파괴됨)의 경우 시각적 효과는 풍선이 터지는 것만큼 강하진 않겠지만 최종 결과가 극적임은 마찬가지다. 이 다큐멘터리에서도 언급하듯이 우리는 지금 컴퓨터 맬웨어 코드가 물리적 수준에서 파괴를 일으키는 세계에 살고 있다. 앞으로 이와 비슷한 일이 더 많이 생길 것임은 분명하다.
스카다(Supervisory Control And Data Acquisition, SCADA)는 일반적으로 작업공정, 시설, 설비 등을 모니터링하고 제어하는 산업 제어 시스템의 한 종류입니다. 실제로 발전소, 철도, 상수도, 도로 신호 체계, 전기, 통신 시스템, 공항 등 현대사회의 기반시설입니다. 이러한 사회 기반시설을 노리는 공격을 스카다 공격이라고 합니다.
핵티비스트는 악성코드를 이용해 정치적 메시지를 전달하고 관심을 호소하는 수준에 머물기도 하지만 특정 국가의 사회기반시설에 대한 사이버 공격으로 나타나는 경우도 있습니다. 특히 적대 국가나 테러 단체에 의한 사회기반시설 공격은 사회적 혼란을 야기하거나 시민들의 생명과 국가 안보에 심각한 위협이 될 수 있다.
물리적으로도 보호된 상태고 폐쇄된 네트워크 망에서 사용되기 때문에 안전하다는 생각이 있지만, 스카다 시스템에도 보안 취약점이 분명 존재합니다. 제어 소프트웨어의 접근 권한과, 스카다 네트워크 패킷에 대한 접근 권한의 보안 등이 주요 취약점으로 손꼽힙니다.
- 공격 방식
1) 이메일
공격 대상자를 정해 악의적인 이메일을 보내는 것이 가장 일반적인 공격 방식이다. 보통 개인 메일이나 업무 메일로 가 장하여 메일 본문에 악성코드를 다운로드하는 웹 페이지의 주소(URL)를 포함하거나 악성코드가 포함된 파일을 첨부한 다. 공격 대상자가 악성코드에 감염되면 이를 통해 네트워크로 연결된 내부 시스템을 하나씩 장악해 갈 수 있다.
2) 워터링홀(Watering hole) 기법
워터링 홀(Watering hole) 기법은 사람들이 관심을 가질만한 웹사이트를 해킹한 후 해당 사이트를 방문한 사용자의 시 스템을 감염시키는 방법이다. 사용자의 시스템이 인터넷에 연결되어 있을 경우에 가능한 방식으로, 망분리가 되어 있을 경우 한계가 있을 수 있다.
3) 업데이트 서버 변조
공격 대상이 주로 사용하는 소프트웨어의 업데이트 서버를 해킹해 해당 프로그램이 업데이트될 때 악성코드를 감염시 키는 방식이다. 공격 대상 시스템의 IP에서 접속할 때만 악성코드가 다운로드되도록 하는 경우가 많아 외부에서는 감염 사실을 파악하기 어렵다. 그러나 대부분의 사회기반시설은 폐쇄망으로 구축되어 있고 인터넷에 연결된 일부 시스템에 서만 업데이트 서버에 접속할 수 있기 때문에 이러한 공격은 거의 나타나지 않는다.
4) 이동식 저장매체
폐쇄망을 사용하는 곳에서도 자료 전달 등을 위해 USB와 같은 이동식 저장매체 사용이 필요한 경우가 있다. 대부분 보 안 심사를 거친 USB를 이용하지만 이 경우에도 USB 내부의 파일이 안전하다고 보장할 수는 없다. 예를 들어, 시스템 유지 보수를 위해 USB를 반입할 때 이 USB에 존재하는 악성 파일이 시설 내부로 유입될 수 있다. 실제로 지난 2010년 발견된 스턱스넷 악성코드도 USB를 통해 감염되었으며, 2016년 4월 독일 원전에서 발견된 다수의 악성코드도 USB를 통해 전파되는 악성코드였다.
5) 설치 프로그램 변조
공격 대상 조직이 내부적으로 사용하는 프로그램의 제작 업체를 해킹해 배포 파일에 악성코드를 포함해 공격 대상 내 부로 침입할 수 있다. 정식 업체에서 제공되는 파일이기 때문에 별 다른 의심없이 내부로 반입되기 쉽다. 하벡스(Havex) 악성코드가 이런 방식으로 침입했다.
6) 협력 업체 또는 유지 보수 업체 해킹
일반 기업은 물론 사회기반시설에서도 유지 보수 업체를 통해 시스템을 관리한다. 대부분 협력 업체에서 반입하는 소프 트웨어에 대해서는 별다른 검사를 하지 않고 있다. 공격 대상의 유지 보수 업체나 협력 업체를 해킹해 공격 대상 내부 로 반입되는 프로그램에 악성코드를 포함시켜 내부에 침입하는 방법을 사용할 수 있다. 또는 협력 업체가 공격 대상 시 설의 내부에서 사용할 프로그램을 제작하는 업체를 해킹해 침입 경로로 이용할 수 있다.
특히 지하철, 교통 제어 시스템 등 의외로 인터넷과 연결되어 있는 스카다 망이 많아 언제든 해커의 표적이 될 수 있으므로 주의해야 합니다.
Stack ① 프로그램 내에 함수에 의해서 선언된 변수에 할당되는 영역으로 시스템이 특정 함수를 실행하는 경우 함수 내에 선언된 변수와 값을 저장하기 위해서 할당되고 함수의 실행이 종료되면서 해제되는 영역 ② LIFO로 나중에 입력된 것이 먼저 나옴 ③ Stack에 저장될 내용은 컴파일 단계에서 결정 ④ 지역변수, 복귀 주소를 저장
Heap ① 인위적으로 할당하고 해제할 수 있음 ② JAVA에서 new 키워드로 메모리를 생성(C언어는 malloc으로 할당) ③ 실행 중에 메모리 영역이 할당됨
Code(Text) ① 프로그램이 실직적으로 실행될 명령어가 저장되는 공간 ② 기계어 프로그램의 실행 코드가 저장됨
alert tcp any any -> any 7070 (msg:"IDS411/dos-realaudio"; flags:AP; content:"|fff4 fffd 06|"; reference:arachnids,IDS411;) alert tcp any any -> any 21 (msg:"IDS287/ftp-wuftp260-venglin-linux"; flags:AP; content:"|31c031db 31c9b046 cd80 31c031db|"; reference:arachnids,IDS287; reference:bugtraq,1387; reference:cve,CAN-2000-1574;)
현재4가지 기본 우선 순위로 기재하였으며1(높음)은 가장 심각하고4(매우 낮음)는 가장 덜 심각함.
Classtype
설명
우선순위
attempted-admin
관리자 권한 획득 시도
high
attempted-user
사용자 권한 획득 시도
high
inappropriate-content
부적절한 컨텐츠 감지
high
policy-violation
잠재적인 개인 정보 침해
high
shellcode-detect
실행 코드 감지
high
successful-admin
관리자 권한 획득 성공
high
successful-user
사용자 권한 획득 성공
high
trojan-activity
네트워크 트로이목마 탐지
high
unsuccessful-user
사용자 권한 획득 실패
high
web-application-attack
웹 응용 프로그램 공격
high
attempted-dos
DoS시도
medium
attempted-recon
정보 유출 시도
medium
bad-unknown
잠재적인 나쁜 트래픽
medium
default-login-attempt
기본 사용자 이름과 암호로 로그인 시도
medium
denial-of-service
DoS탐지
medium
misc-attack
기타 공격
medium
non-standard-protocol
비표준 프로토콜 또는 이벤트 감지
medium
rpc-portmap-decode
RPC쿼리 디코드
medium
successful-dos
DoS
medium
successful-recon-largescale
대규모 정보 유출
medium
successful-recon-limited
정보 유출
medium
suspicious-filename-detect
의심스러운 파일 이름 탐지
medium
suspicious-login
의심스러운 사용자 이름을 사용하여 로그인 시도 탐지
medium
system-call-detect
시스템 호출 탐지
medium
unusual-client-port-connection
클라이언트가 비정상적인 포트 사용
medium
web-application-activity
잠재적으로 취약한 웹 응용 프로그램에 대한 액세스
medium
icmp-event
일반적인ICMP이벤트
low
misc-activity
기타 활동
low
network-scan
네트워크 스캔 탐지
low
not-suspicious
의심스러운 트래픽 아님
low
protocol-command-decode
일반 프로토콜 명령어 디코드
low
string-detect
의심스러운 문자열 탐지
low
unknown
알 수 없는 트래픽
low
tcp-connection
TCP연결 탐지
very low
classtype옵션은 구성 분류 옵션(config classification option)을 이용한snort.conf에 정의된 분류만 사용할 수 있음.
Snort는classification.config파일에서 제공하는 규칙에 따라 사용되는 기본 분류 집합을 제공함.
4.7 priority
priority키워드는 규칙에 심각도 레벨을 지정함.
classtype키워드는 구성 분류 옵션(config classification option)에 의해 정의된 기본적인 우선순위를 할당함.
각 경우의 예는 아래와 같음.
priority:<priority integer>;
<형식>
alert tcp any any -> any 80 (msg:"WEB-MISC phf attempt"; flags:A+; content:"/cgi-bin/phf"; priority:10;) alert tcp any any -> any 80 (msg:"EXPLOIT ntpdx overflow"; dsize:>128; classtype:attempted-admin; priority:10 );
<사용예>
4.8 metadata
metadata키워드를 사용하면 규칙 작성자가 규칙에 대한 추가 정보를 일반적으로 키-값 형식으로 포함시킬 수 잇음.
특정 메타데이터 키와 값은Snort에 의미가 있으며 아래 표에 나열되어 있음.
키
설명
값 형식
engine
공유 라이브러리 규칙 표시
"shared"
soid
공유 라이브러리 규칙 생성기 및SID
gid|sid
service
목표 기반 서비스 식별자 (service메타데이터 키는 호스트 속성 테이블이 제공될 때만 의미가 있음)
"http"
< Snort Metadata Keys >
표에 나열된 것 이외의 키는Snort에서 효과적으로 무시되며 키와 값을 사용하여 자유 형식이 될 수 있음.
"HTTP"문자열에 대한 다음 경고(alert) : alert tcp any any <> any 80 (msg:"MD5 Alert"; protected_content:"293C9EA246FF9985DC6F62A650F78986"; hash:md5; offset:0; length:4;) alert tcp any any <> any 80 (msg:"SHA256 Alert"; protected_content:"56D6F32151AD8474F40D7B939C2161EE2BBF10023F4AF1DBB3E13260EBDC6342"; hash:sha256; offset:0; length:4;)
<사용예>
!수정자(modifier)는 해당 수정자가 포함된 전체 내용 검색 결과를 무효화함.
예를 들어content:!"A"; within:50;규칙일 경우 페이로드가5바이트 뿐이며 해당5바이트에“A”가 없으면 결과는 일치로 리턴함.
유효한 일치를 위해50바이트가 있어야 하는 경우isdataat을 내용의 선행자(pre-cursor)로 사용해야 함.
5.3 hash
hash키워드는protected_content규칙과 일치할 때 사용할 해싱 알고리즘을 지정하는 데 사용됨.
Snort설정에 기본 알고리즘이 지정되지 않은 경우protected_content규칙에 반드시 사용할 알고리즘을 지정해야 함.
현재MD5, SHA256, SHA512가 지원됨.
hash:[md5|sha256|sha512];
<형식>
5.4 length
length키워드는protected_content규칙 요약(digest)에 지정된 컨텐츠의 원래 길이를 지정하는데 사용됨.제공된 값은0보다 크도65536보다 작아야 함.
length:[<original_length>];
<형식>
5.5 nocase
nocase키워드를 사용하면 규칙 작성기(rule writer)가Snort에서 대소문자를 무시하고 특정 패턴을 찾도록 지정할 수 있음. nocase는 규칙에서 이전content키워드를 수정함.
nocase;
<형식>
alert tcp any any -> any 21 (msg:"FTP ROOT"; content:"USER root"; nocase;)
<사용예>
5.6 rawbytes
rawbytes키워드를 사용하면 규칙이 원시 패킷 데이터를 보고 전처리기(preprocessors)에 의해 수행된 디코딩을 무시함.이는content키워드 옵션의 수정자(modifier)역할을 함.
HTTP Inspect는 원시HTTP요청 및 응답의 특정 부분과 일치하는http_raw_cookie, http_raw_header, http_raw_uri등과 같은 원시 데이터를 사용하기 위한 키워드 세트가 있음.
rawbytes가 명시적으로 지정되지 않은 경우 대부분의 다른 전처리기는 기본적으로 컨텐츠 일치를 위해 디코딩/정규화된 데이터를 사용함.따라서 패킷에서 임의의 원시 데이터를 검사하려면rawbytes를 지정해야 함.
rawbytes;
<형식>
이 예제는 컨텐츠 패턴 일치자(content patten matcher)에게 Telnet 디코더가 제공한 디코딩된 트래픽 대신 원시 트래픽을 보도록 지시함.
alert tcp any any -> any 21 (msg:"Telnet NOP"; content:"|FF F1|"; rawbytes;)
<사용예>
5.7 depth
depth키워드를 사용하면 규칙 작성자(rule writer)가 지정된 패턴을 검색해야 하는 거리를 지정할 수 있음.
예를 들어"depth:5;"는 페이로드의 처음5바이트 내에서만 지정된 패턴을 찾도록 지시함.
depth키워드는 이전content키워드에 대한 수정자이므로depth키워드를 지정하기 전에content키워드가 있어야 함.
이 키워드는 검색되는 패턴 길이보다 크거나 같은 값을 허용하며 허용 범위는1 ~ 65535임.
동일한 규칙에서byte extract키워드로 추출된 변수를 참조하는 문자열 값으로 설정할 수도 있음.
depth:[<number>|<var_name>];
<형식>
5.8 offset
offset키워드를 사용하면 규칙 작성기(Rule Writer)가 패킷 내에서 패턴 검색을 시작할 위치를 지정할 수 있음.
예를 들어"offset:5;"는 페이로드의 처음5바이트 이후에 지정된 패턴을 찾도록Snort에 지시함.
offset키워드는 이전content키워드에 대한 수정자이므로offset키워드를 지정하기 전에content키워드가 있어야 함.
해당 키워드의 값 허용 범위는-65535 ~ 65535임.
동일한 규칙에서byte extract키워드로 추출된 변수를 참조하는 문자열 값으로 설정할 수도 있음.
offset:[<number>|<var_name>];
<형식>
다음 예제는 결합된content, offset및depth키워드를 사용하는 예제임. alert tcp any any -> any 80 (content:"cgi-bin/phf"; offset:4; depth:20;)
<사용예>
5.9 distance
distance키워드를 사용하면 규칙 작성자가 이전 패턴 일치의 끝을 기준으로 지정된 패턴 검색을 시작하기 전에Snort가 무시해야 하는 패킷의 거리를 지정할 수 있음.
이는 패킷의 시작이 아닌 마지막 패턴 일치의 끝과 관련이 있다는 점으로offset키워드와 정반대임.
해당 키워드의 값 허용 범위는-65535 ~ 65535임.
동일한 규칙에서byte extract키워드로 추출된 변수를 참조하는 문자열 값으로 설정할 수도 있음.
distance:[<byte_count>|<var_name>];
<형식>
이 규칙은/ABC.{1,}DEF/의 정규표현식과 매핑됨. alert tcp any any -> any any (content:"ABC"; content:"DEF"; distance:1;)
<사용예>
5.10 within
within키워드는content키워드를 사용하여 패턴 일치 사이에 최대N바이트가 되도록 하는content수정자임. (5.1참조)
distance키워드와 함께 규칙 옵션으로 사용하도록 설계됨.
해당 키워드는 검색되는 패턴 길이보다 크거나 같은 값을 허용하며 최대값은63335임.
동일한 규칙에서byte extract키워드로 추출된 변수를 참조하는 문자열 값으로 설정할 수도 있음.
within:[<byte_count>|<var_name>];
<형식>
이 규칙은ABC일치한 후10바이트를 넘지 않도록EFG검색을 제한함. alert tcp any any -> any any (content:"ABC"; content:"EFG"; within:10;)
alert tcp any any -> any any (msg:"UTF8/UEncode Encoding present"; http_encode:uri,utf8|uencode;)
alert tcp any any -> any any (msg:"No UTF8"; http_encode:uri,!utf8;)
<사용예>
5.22 fast_pattern
fast_pattern키워드는 빠른 패턴 일치자(matcher)와 함께 사용할 규칙 내의 컨텐츠를 설정하는content수정자임.
빠른 패턴 결정의 기본 동작은 가장 긴HTTP버퍼 컨텐츠를 사용하는 것임.
HTTP버퍼가 없으면 빠른 패턴이 가장 긴 컨텐츠임.
이 동작이 주어지면 짧은 컨텐츠가 긴 컨텐츠보다"고유한"경우 유효함.
즉,더 짧은 컨텐츠가 긴 컨텐츠보다 패킷에서 발견될 가능성이 적음.
빠른 패턴 일치자(matcher)는 선택을 위해 규칙의 컨텐츠를 사용하고 컨텐츠가 페이로드에서 발경되는 경우에만 해당 규칙을 평가하여 일치 가능성이 있는 규칙만 선택하는데 사용됨.
이는 오버헤드로 보일 수 있지만 평가해야 하는 규칙 수를 크게 줄여 성능을 향상시킬 수 있음.
빠른 패턴 일치자(matcher)에 사용되는 컨텐츠가 좋을수록 규칙이 불필요하게 평가될 가능성이 줄어듬.
이 키워드는 이전content키워드에 대한 수정자이므로fast_pattern을 지정하기 전에 규칙에content규칙 옵션이 있어야 함.
fast_pattern옵션은 규칙당 한 번만 지정할 수 있음.
노트:
fast_pattern수정자는 다음http컨텐츠 수정자와 함께 사용할 수 없음. (http_cookie, http_raw_uri, http_raw_header, http_raw_cookie, http_method, http_stat_code, http_stat_msg)
fast_pattern수정자는 해당 내용이offset, depth, distance및within내에서 수정되지 않은 경우에만 부정된(negated)컨텐츠과 함께 사용할 수 있음.
빠른 패턴 일치자(matcher)는 항상 대소문자를 구분하지 않음.
fast_pattern옵션은 단독으로 사용하거나 선택적으로 인수를 사용할 수 있음. 단독으로 사용하는 경우 단순히 지정된 컨텐츠를 규칙의 빠른 패턴 컨텐츠로 사용한다는 의미임.
fast_pattern;
선택적 인수는 컨텐츠가 빠른 패턴 일치자(matcher)에만 사용되어야 하며 규칙 옵션으로 평가되지 않도록 지정하는 데만 사용할 수 있음. 예를 들어,알려진 컨텐츠가 페이로드의 위치와 관계없이 페이로드에 있어야 하는 경우에 유용함. 규칙 옵션을 평가하는 데 필요한 시간을 절약하기 때문임. 1.패턴이 대소문자를 구분하지 않는 방식으로 패턴 일치자(matcher)에 삽입되므로 수정된 컨텐츠는 대소문자를 구분하지 않아야 함. 2.부정된(negated)컨텐츠는 사용할 수 없음. 3.컨텐츠에는offset, depth, distance또는within와 같은 위치 수정자가 있을 수 없음.
fast_pattern:only;
선택적 인수<offset>, <length>를 사용하여 컨텐츠의 일부만 빠른 패턴 일치자(matcher)에 사용되도록 지정할 수 있음. 이는 패턴이 매우 길고"고유성"을 충족시키기 위해 패턴의 일부만 필요한 경우에 유용하므로 빠른 패턴 일치자(matcher)에 전체 패턴을 저장하는 데 필요한 메모리가 줄어듬.
fast_pattern:<offset>,<length>;
<형식>
노트:
선택적 인수<offset>, <length>는 상호 배타적임.
이 규칙은"IJKLMNO"패턴이 이전 패턴"ABCDEFGH"보다 짧더라도fast_pattern일치자와 함께 사용되도록 함. alert tcp any any -> any 80 (content:"ABCDEFGH"; content:"IJKLMNO"; fast_pattern;)
이 규칙은fast_pattern일치자에content:"IJKLMNO";를 사용하고content가fast_pattern일치자만 사용되어야 하며content규칙 옵션으로 평가되지 않아야 함. alert tcp any any -> any 80 (content:"ABCDEFGH"; content:"IJKLMNO"; nocase; fast_pattern:only;)
이 규칙은"JKLMN"을fast_pattern content로 사용하지만content규칙 옵션을“IJKLMNO”로 평가함. alert tcp any any -> any 80 (content:"ABCDEFGH"; content:"IJKLMNO"; fast_pattern:1,5;)
기본적으로 문자열은 하나의 큰 문자 줄로 처리됨. ^및$는 문자열의 시작과 끝으로 일치함. m이 설정되면^및$는 버퍼의 모든 개행 바로 뒤 또는 바로 앞과 버퍼의 맨 처음과 맨 끝을 일치함.
x
패턴의 공백 데이터 문자는 이스케이프되거나 문자 클래스 내부의 경우를 제외하고 무시됨.
A
패턴은 버퍼의 시작 부분에서만 일치해야 함. (^와 동일)
E
제목 문자열의 끝에서만 일치하도록$를 설정하십시오. E가 없으면$는 개행 문자인 경우 최종 문자 바로 앞과도 일치함. (다른 개행 앞이 아님)
G
한정자(quantifier)의“탐욕”(greediness)을 반전하여 기본적으로 탐욕스럽지(greedy)않지만“?”가 뒤따르면 탐욕스러워짐.
R
마지막 패턴 일치의 끝을 기준으로 일치함. (distance:0;과 유사)
U
디코딩된URI버퍼를 일치시킴. (uricontent및http_uri와 비슷) 이 수정자는 동일한 컨텐츠에 대해 정규화되지 않은HTTP요청uri버퍼 수정자(I)와 함께 사용할 수 없음.
I
정규화되지 않은HTTP요청uri버퍼와 일치함. (http_raw_uri와 유사) 이 수정자는 동일한 컨텐츠에 대해HTTP요청uri버퍼 수정자(U)와 함께 사용할 수 없음.
P
정규화되지 않은HTTP요청 본문과 일치함. (http_client_body와 유사) SIP메시지의 경우 요청 또는 응답에 대해SIP본문을 일치시킴. (sip_body와 유사)
H
정규화된HTTP요청 또는HTTP응답 헤더와 일치함. (http_header와 유사) 이 수정자는 동일한 컨텐츠에 대해 정규화되지 않은HTTP요청 또는HTTP응답 헤더 수정자(D)와 함께 사용할 수 없음. SIP메시지의 경우 요청 또는 응답에 대해SIP헤더를 일치시킴. (sip_header와 유사)
D
정규화되지 않은HTTP요청 또는HTTP응답 헤더와 일치함. (http_raw_header와 유사) 이 수정자는 동일한 컨텐츠에 대해 정규화된HTTP요청 또는HTTP응답 헤더 수정자(H)와 함께 사용할 수 없음.
M
정규화된HTTP요청 방법과 일치함. (http_method와 유사)
C
정규화된HTTP요청 또는HTTP응답 쿠키와 일치함. (http_cookie와 유사) 이 수정자는 동일한 컨텐츠에 대해 정규화되지 않은HTTP요청 또는HTTP응답 쿠키 수정자(K)와 함께 사용할 수 없음.
K
정규화되지 않은HTTP요청 또는HTTP응답 쿠키와 일치함. (http_raw_cookie와 유사) 이 수정자는 동일한 컨텐츠에 대해 정규화된HTTP요청 또는HTTP응답 쿠키 수정자(C)와 함께 사용할 수 없음.
S
HTTP응답 상태 코드와 일치함. (http_stat_code와 유사)
Y
HTTP응답 상태 메시지와 일치함. (http_stat_msg와 유사)
B
디코딩된 버퍼를 사용하지 마십시오. (rawbytes와 유사)
O
이 표현식에 대해 구성된pcre일치 제한 및pcre일치 제한 재귀를 재정의함. 지정된pcre패턴을 평가하는 동안 제한을 완전히 무시함.
< pcre용Perl호환 수정자>
노트:
수정자R(상대)과B(원시 바이트)는U, I, P, H, D, M, C, K, S및Y와 같은HTTP수정자와 함께 허용되지 않음.
이 예제는HTTP URI foo.php?id=<some numbers>에 대해 대소문자를 구분하지 않는 검색을 수행함.
alert tcp any any -> any 80 (content:"/foo.php?id="; pcre:"/\/foo.php?id=[0-9]{1,10}/iU";)
<사용예>
노트:
pcre를 사용하는 규칙에 하나 이상의content키워드가 있는 것이 좋음.
이를 통해fast_pattern일치자가 일치하지 않는 패킷을 필터링하여 회선을 통해 들어오는 각 패킷에 대해pcre평가가 수행되지 않도록 할 수 있음.
노트:
Snort가PCRE를 사용하여 여러URI를 처리하는 것이 예상대로 작동하지 않음.
uricontent없이 사용되는PCRE는 첫 번째URI만 평가함.
pcre를 사용하여 모든URI를 검사하려면content또는uricontent를 사용해야 함.
5.27 pkt_data
이 옵션은 감지에 사용되는 커서(cursor)를 원시 전송 페이로드로 설정함.
규칙에서pkt_data뒤에 오는 상대 또는 절대 컨텐츠 일치(HTTP수정자 또는 원시 바이트 없음)및 기타 페이로드 감지 규칙 옵션은 커서(탐지에 사용)가 다시 설정될 때까지 원시TCP/UDP페이로드 또는 정규화된 버퍼(telnet,정규화된smtp경우)에 적용됨.
이 규칙 옵션은 규칙에서 여러 번 사용할 수 있음.
pkt_data;
<형식>
alert tcp any any -> any any(msg:"Absolute Match"; pkt_data; content:"BLAH"; offset:0; depth:10;)
alert tcp any any -> any any(msg:"PKT DATA"; pkt_data; content:"foo"; within:10;)
alert tcp any any -> any any(msg:"PKT DATA"; pkt_data; content:"foo";)
alert tcp any any -> any any(msg:"PKT DATA"; pkt_data; pcre:"/foo/i";)
<사용예>
5.28 file_data
이 옵션은 감지에 사용되는 커서를 다음 버퍼 중 하나로 설정함.
1.탐지되는 트래픽이HTTP일 때 버퍼를 설정함:
a. HTTP응답 본문(chunking/압축/정규화 제외)
b. HTTP dechunked응답 본문
c. HTTP압축해제 응답 본문(inspect_gzip이 켜져 있는 경우)
d. HTTP정규화된 응답 본문(normalized_javascript가 설정된 경우)
e. HTTP UTF정규화된 응답 본문(normalized_utf가 설정된 경우)
f.모두 포함(All of the obove)
2.감지되는 트래픽이SMTP/POP/IMAP인 경우 버퍼를 다음으로 설정함:
a. SMTP/POP/IMAP데이터 본문(디코딩이 해제된 이메일 헤더 및MIME포함)
b. Base64디코딩된MIME첨부 파일(b64_decode_depth가-1보다 큰 경우)
c.인코딩되지 않은MIME첨부 파일(bitenc_decode_depth가-1보다 큰 경우)
d.인용 인쇄 가능한(Quoted-Printable)디코딩된MIME첨부 파일(qp_decde_depth가-1보다 큰 경우)
e. Unix-to-Unix디코딩된 첨부 파일(uu_decode_depth가-1보다 큰 경우)
3. 1과2번 항목으로 설정하지 않으면 페이로드로 설정됨.
상대 또는 절대 컨텐츠 일치(HTTP수정자 또는rawbytes없음)및 규칙에서file_data를 따르는 페이로드 감지 규칙 옵션은 다른 규칙 옵션에 의해 명시적으로 재설정될 때까지 이 버퍼에 적용됨.
이 규칙 옵션은 규칙에서 여러 번 사용할 수 있음.
file_data에 대한mime인수는 더 이상 사용되지 않음.
규칙 옵션file_data는 자체적으로 디코딩된MIME첨부를 가리킴.
file_data;
<형식>
alert tcp any any -> any any(msg:"Absolute Match"; file_data; content:"BLAH"; offset:0; depth:10;)
alert tcp any any -> any any(msg:"FILE DATA"; file_data; content:"foo"; within:10;)
alert tcp any any -> any any(msg:"FILE DATA"; file_data; content:"foo";)
alert tcp any any -> any any(msg:"FILE DATA"; file_data; pcre:"/foo/i";)
다음 규칙은file_data버퍼 내에서 컨텐츠"foo"를 검색하고 전체 패킷 페이로드 내에서 컨텐츠"bar"를 검색함. 규칙 옵션pkt_data는 탐지에 사용되는 커서를TCP페이로드로 재설정함. alert tcp any any -> any any(msg:"FILE DATA"; file_data; content:"foo"; pkt_data; content:"bar";)
bytes = 1 - 10 offset = -65535 to 65535 mult_value = 0 - 65535 post_offset = -65535 to 65535 bitmask_value = 1 to 4 bytes hexadecimal value
<형식>
옵션
설명
bytes_to_convert
패킷에서 가져올 바이트 수임. dce없이 사용할 경우 허용되는 값은1-10임. dce와 함께 사용하는 경우 허용되는 값은1, 2및4임. from_end인수와 함께 사용하면bytes_to_convert는0이 될 수 있음. bytes_to_convert가0이면 추출된 값은0임.
offset
처리를 시작할 페이로드의 바이트 수임.
relative
마지막 패턴 일치에 상대적인 오프셋을 사용함.
multiplier <value>
계산된 바이트 수에<value>을 곱하고 해당 바이트 수를 앞으로 건너뜀.
big
데이터를 빅 엔디안으로 처리함. (기본값)
little
데이터를 리틀 엔디안으로 처리함.
string
데이터는 패킷에 문자열 형식으로 저장됨.
hex
변환된 문자열 데이터는16진수로 표시됨.
dec
변환된 문자열 데이터는10진수로 표시됨.
oct
변환된 문자열 데이터는8진수로 표시됨.
align
변환된 바이트 수를 다음32비트 경계까지 반올림함.
from_beginning
패킷의 현재 위치에서가 아니라 패킷 페이로드의 시작 부분부터 앞으로 건너뜀.
from_end
점프는 페이로드의 끝에서 시작됨.
post_offset <value>
다른 점프 옵션이 적용된 후<value>바이트 수만큼 앞으로 또는 뒤(음수 값의 양수)로 건너뜀.
dce
DCE/RPC 2전처리기(preprocessor)가 변환할 값의 바이트 순서를 결정하게 하십시오.
bitmask
bytes_to_convert인수에AND연산자를 적용함. 결과는 마스크의 후행0수와 동일한 비트 수만큼 오른쪽 시프트됨.
alert udp any any -> any 32770:34000 (content:"|00 01 86 B8|"; \ content:"|00 00 00 01|"; distance:4; within:4; \ byte_jump:4, 12, relative, align; \ byte_test:4, >, 900, 20, relative; \ msg:"statd format string buffer overflow";)
alert tcp any any -> any any (content:"Begin"; \ byte_jump:0, 0, from_end, post_offset -6; \ content:"end.."; distance:0; within:5; \ msg:"Content match from end of the payload";)
alert tcp any any -> any any (content:"catalog"; \ byte_jump:2, 1, relative, post_offset 2, bitmask 0x03f0; \ byte_test:2, =, 968, 0, relative; \ msg:"Bitmask applied on the 2 bytes extracted for byte_jump";)
alert tcp any any -> any any (content:"catalog"; \ byte_jump:1, 2, from_end, post_offset -5, bitmask 0x3c; \ byte_test:1, =, 106, 0, relative; \ msg:"Byte jump calculated from end of payload after bitmask applied";)
<사용예>
5.33 byte_extract
byte_extract키워드는 길이 인코딩 프로토콜에 대한 규칙을 작성하는 데 유용한 또 다른 옵션임.
bytes_to_extract = 1 - 10 operator = ’<’ | ’=’ | ’>’ | ’<=’ | ’>=’ | ’&’ | ’ˆ’ value = 0 - 4294967295 offset = -65535 to 65535 bitmask_value = 1 to 4 byte hexadecimal value
<형식>
옵션
설명
bytes_to_convert
패킷에서 가져올 바이트 수임.
offset
처리를 시작할 페이로드의 바이트 수임.
name
변수의 이름임. 다른 규칙 옵션에서 변수를 참조하는 데 사용됨.
relative
마지막 패턴 일치에 상대적인 오프셋을 사용함.
multiplier <value>
패킷에서 읽은 바이트에<value>을 곱하고 그 숫자를 변수에 저장함.
big
데이터를 빅 엔디안으로 처리함. (기본값)
little
데이터를 리틀 엔디안으로 처리함.
dce
DCE/RPC 2전처리기(preprocessor)가 변환할 값의 바이트 순서를 결정하십시오. 이 옵션이 작동하려면DCE/RPC 2전처리기가 활성화되어야 함.
string
데이터는 패킷에 문자열 형식으로 저장됨.
hex
변환된 문자열 데이터는16진수로 표시됨.
dec
변환된 문자열 데이터는10진수로 표시됨.
oct
변환된 문자열 데이터는8진수로 표시됨.
align <value>
변환된 바이트 수를 다음<value>바이트 경계까지 반올림함. <value>은2또는4일 수 있음.
bitmask
인수를 추출하기 위해 바이트 값에AND연산자를 적용함. 결과는 마스크의 후행0수와 동일한 비트 수만큼 오른쪽 시프트함.
byte_extract규칙 옵션은 자체적으로 아무것도 감지하지 않음.
다른 규칙 옵션에서 사용할 패킷 데이터를 추출하는 데 사용됨.
다음은byte_extract변수를 사용할 수 있는 위치 목록:
규칙 옵션
변수를 취하는 인수
content/uricontent
offset, depth, distance, within
byte_test
offset, value
byte_jump
offset
isdataat
offset
<바이트 추출 변수를 사용하는 기타 옵션>
이 예에서는 두 개의 변수를 사용하여 다음을 수행함.
• 오프셋0의 바이트에서 문자열의 오프셋을 읽음. • 오프셋1의 바이트에서 문자열의 깊이를 읽음. • 이 값을 사용하여 패턴 일치를 더 작은 영역으로 제한함.
alert tcp any any -> any any (byte_extract:1, 0, str_offset; \ byte_extract:1, 1, str_depth; \ content:"bad stuff"; offset:str_offset; depth:str_depth; \ msg:"Bad Stuff detected within field";)
alert tcp any any -> any any (content:"|04 63 34 35|"; offset:4; depth:4; \ byte_extract: 2, 0, var_match, relative, bitmask 0x03ff; \ byte_test: 2, =, var_match, 2, relative; \ msg:"Byte test value matches bitmask applied on bytes extracted";)
<사용예>
5.34 byte_math
추출된 값과 지정된 값 또는 기존 변수에 대해 수학적 연산을 수행하고 결과를 새 결과 변수에 저장함.
bytes_to_extract = 1 - 10 operator = ’+’ | ’-’ | ’*’ | ’/’ | ’<<’ | ’>>’ r_value = 0 - 4294967295 | byte extract variable offset_value = -65535 to 65535 bitmask_value = 1 to 4 byte hexadecimal value result_variable = Result Variable name
<형식>
옵션
설명
bytes_to_extract
패킷에서 가져올 바이트 수임. dce없이 사용할 경우 허용되는 값은1-10임. dce와 함께 사용하는 경우 허용되는 값은1, 2및4임. <<또는>>연산자와 함께 사용하는 경우 허용되는 값은1-4임.
oper
추출된 값에 대해 수행할 수학적 연산이 허용된 연산자: +, -, *, /, <<, >>
rvalue
수학적 연산을 사용할 값임.
offset
처리를 시작할 페이로드의 바이트 수임.
relative
마지막 패턴 일치에 상대적인 오프셋을 사용함.
endian
읽고 있는 번호의 엔디안 유형: •big -데이터를 빅 엔디안으로 처리함. (기본값). •little -데이터를little endian으로 처리함.
string
데이터는 패킷에 문자열 형식으로 저장됨.
number type
읽을 번호 유형: •hex -변환된 문자열 데이터가16진수로 표시됨. •dec -변환된 문자열 데이터가10진수로 표시됨. •oct -변환된 문자열 데이터가8진수로 표시됨.
dce
DCE/RPC 2전처리기(preprocessor)가 변환할 값의 바이트 순서를 결정하게 하십시오.
bitmask
추출된 바이트에AND연산자를 적용함. 결과는 마스크의 후행0수와 동일한 비트 수만큼 오른쪽 시프트됨.
규칙 옵션
결과 변수를 받는 인수
content
offset, depth, distance, within
byte_test
offset, value
byte_jump
offset
isdataat
offset
<바이트 수학 결과 변수를 사용하는 기타 규칙 옵션>
alert udp $EXTERNAL_NET any -> $HOME_NET any \ (msg:"Perform Arithmetic Operation on the extracted bytes"; \ content:"|00 04 93 F3|"; \ content:"|00 00 00 07|"; distance:4; within:4; \ byte_math:bytes 4, offset 0, oper +, rvalue 248, result var, relative; \ byte_test:4, >, var, 2, relative;)
alert tcp $EXTERNAL_NET any -> $HOME_NET any \ (msg:"Bitwise shift operator"; \ content:"|00 00 00 07|"; distance:4; within:4; \ byte_extract: 1, 0, extracted_val, relative; \ byte_math: bytes 1, offset 2, oper >>, rvalue extracted_val, result var, relative; \ byte_test:2, =, var, 0, relative;)
alert udp any any -> any 1234 \ (content: "Packets start"; \ byte_math: bytes 2, offset 0, oper -, rvalue 100, result var, relative, bitmask 0x7FF0; \ content: "Packets end"; distance: 2; within var; \ msg:"Content match with bitmask applied to the bytes extracted";)
alert udp any any -> any 1235 \ (byte_extract: 4, 3, extracted_val, relative; \ byte_math: bytes 5, offset 0, oper +, rvalue extracted_val, result var, string hex; \ byte_test:5, =, var, 4, string, hex; \ msg:"String operator used with math rule option";)
<사용예>
5.35 ftpbounce
ftpbounce키워드는FTP bounce공격을 감지함.
ftpbounce;
<형식>
alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP PORT bounce attempt"; \ flow:to_server,established; content:"PORT"; nocase; ftpbounce; pcre:"/ˆPORT/smi";\ classtype:misc-attack; sid:3441; rev:1;)
표준 버퍼보다 큰 이중ASCII인코딩을 감지함. 이것은Microsoft에서 악용 가능한 기능으로 알려져 있지만 현재 어떤 서비스가 악용될 수 있는지는 알 수 없음.
oversize_length <value>
ASN.1유형 길이를 제공된 인수와 비교함. 구문은"oversize_length 500"과 같음. 즉, ASN.1유형이500보다 크면 이 키워드가true로 평가됨. 이 키워드에는 비교할 길이를 지정하는 하나의 인수가 있어야 함.
absolute_offset <value>
이것은 패킷 시작으로부터의 절대 오프셋임. 예를 들어snmp패킷을 디코딩하려면"absolute_offset 0"이라고 말하면 됨. absolute_offset에는 오프셋 값이라는 하나의 인수가 있음. 오프셋은 양수 또는 음수일 수 있음.
relative_offset <value>
이것은 마지막 컨텐츠 일치, pcre또는byte_jump의 상대적 오프셋임. relative_offset에는 오프셋 번호라는 하나의 인수가 있음. 따라서 콘텐츠"foo"바로 다음에ASN.1시퀀스 디코딩을 시작하려면'content:"foo"; asn1:bitstring_overflow, relative_offset 0'를 지정함. 오프셋 값은 양수 또는 음수일 수 있음.
alert udp any any -> any 161 (msg:"Oversize SNMP Length"; \ asn1:oversize_length 10000, absolute_offset 0;)
alert tcp any any -> any 80 (msg:"ASN1 Relative Foo"; content:"foo"; \ asn1:bitstring_overflow, relative_offset 0;)
<사용예>
5.37 cvs
CVS감지 플러그인은Bugtraq-10384, CVE-2004-0396, "Malformed Entry Modified and Unchanged flag insertion"를 감지하는 데 도움이 됨.
기본CVS서버 포트는2401및514이며 스트림 재조립을 위한 기본 포트에 포함됨.
노트:
이 플러그인은 암호화된 세션은 감지할 수 없음.
예를 들어SSH서비스와 일반적으로 포트22번에 대해서 감지할 수 없음.
cvs:<option>;
<형식>
옵션
설명
invalid-entry
CVS 1.11.15및 이전 버전에서 힙 오버플로우 및 잘못된 포인터 역참조를 유발하는 잘못된 항목 문자열을 찾음. (CVE-2004-0396참조)
alert tcp any any -> any 2401 (msg:"CVS Invalid-entry"; \ flow:to_server,established; cvs:invalid-entry;)
<사용예>
5.38 dce_iface
생략
5.39 dce_opnum
생략
5.40 dce_stub_data
생략
5.41 sip_method
생략
5.42 sip_stat_code
생략
5.43 sip_header
생략
5.44 sip_body
생략
5.45 gtp_type
생략
5.46 gtp_info
생략
5.47 gtp_version
생략
5.48 ssl_version
생략
5.49 ssl_state
생략
5.50 Payload Detection Quick Reference
키워드
설명
content
content키워드를 통해 사용자는 패킷 페이로드에서 특정 컨텐츠를 검색하고 해당 데이터를 기반으로 응답을 트리거하는 규칙을 설정할 수 있음.
rawbytes
rawbytes키워드를 사용하면 규칙에서 전처리기가 수행한 디코딩을 무시하고 원시 패킷 데이터를 볼 수 있음.
depth
depth키워드를 사용하면 규칙 작성기가 패킷Snort가 지정된 패턴을 검색해야 하는 거리를 지정할 수 있음.
offset
offset키워드를 사용하면 규칙 작성기가 패킷 내에서 패턴 검색을 시작할 위치를 지정할 수 있음.
distance
distance키워드를 사용하면 규칙 작성자가 이전 패턴 일치의 끝을 기준으로 지정된 패턴을 검색하기 전에Snort가 무시해야 하는 패킷의 거리를 지정할 수 있음.
within
within키워드는content키워드를 사용하여 패턴 일치 사이에 최대N바이트가 있는지 확인하는 내용 수정자임.
uricontent
Snort규칙 언어의uricontent키워드는 정규화된 요청URI필드를 검색함.
isdataat
isdataat키워드는 페이로드의 지정된 위치에 데이터가 있는지 확인함.
pcre
pcre키워드를 사용하면perl호환 정규식을 사용하여 규칙을 작성할 수 있음.
byte_test
byte_test키워드는 특정 값(연산자 포함)에 대해 바이트 필드를 테스트함.
byte_jump
byte_jump키워드를 사용하면 규칙이 데이터 일부의 길이를 읽은 다음 패킷에서 해당 길이를 건너 뛸 수 있음.
ftpbounce
ftpbounce키워드는FTP bounce공격을 감지함.
asn1
asn1탐지 플러그인은 패킷 또는 패킷의 일부를 디코딩하고 다양한 악성 인코딩을 찾음.
cvs
cvs키워드는 유효하지 않은 항목 문자열을 감지함.
dce_iface
생략
dce_opnum
생략
dce_stub_data
생략
sip_method
생략
sip_stat_code
생략
sip_header
생략
sip_boy
생략
gtp_type
생략
gtp_info
생략
gtp_version
생략
<페이로드 감지 규칙 옵션 키워드>
( 6 ) Non-Payload감지 규칙 옵션
6.1 fragoffset
fragoffset키워드를 사용하면IP조각 오프셋 필드를10진수 값과 비교할 수 있음.
IP세션의 모든 첫 번째 조각을 포착하려면fragbits키워드를 사용하고fragoffset 0과 함께More fragments옵션을 찾을 수 있음.
fragoffset:[!|<|>]<number>;
<형식>
alert ip any any -> any any \ (msg:"First Fragment"; fragbits:M; fragoffset:0;)
이 키워드는 특정 흐름에 대해 지정된 비트를 지우거나 그룹의 모든 비트를 지움. (그룹이 있어야 함)
이 키워드는 항상true를 반환함.
flowbits:unset,bats flowbits:unset,all,group
<형식>
bit1을 지움. flowbits: unset, bit1
bit1및bit2를 지움. flowbits: unset, bit1&bit2
doc그룹의 모든 비트가 지워짐. flowbits: unset, all, doc
<사용예>
toggle
flowbit가 설정되어 있으면 설정을 해제함.
설정되지 않은 경우 설정하십시오.
지정된 모든 비트를 토글(toggle)하거나1그룹의 모든 비트를 토글함. (그룹이 있어야 함)
이 키워드는 항상true를 반환함.
flowbits:toggle,bats flowbits:toggle,all,group
<형식>
이 규칙 이전에bit1이0이고bit2가1이면 이 규칙 이후에bit1은1이고bit2은0임. flowbits: toggle, bit1&bit2
위에서 설명한대로doc그룹의 모든 비트를 토글함. flowbits:toggle,all,doc
<사용예>
isset
이 키워드는 설정되었는지 확인하기 위해 비트 또는 여러 비트를 확인함.
다음 구문에 따라true또는false를 반환함.
flowbits:isset, bits =>비트가 설정되었는지 확인 flowbits:isset, bats =>모든 비트가 설정되었는지 확인 flowbits:isset, any, group =>그룹의 비트가 설정되었는지 확인 flowbits:isset, all, group =>그룹의 모든 비트가 설정되었는지 확인
<형식>
flowbits:isnotset, bit1|bit2 => bit1또는bit2가 설정되면true를 반환 flowbits:isnotset, bit1&bit2 => bit1과bit2가 모두 설정된 경우true를 반환하고 그렇지 않으면false를 반환 flowbits:isnotset, any, doc => doc그룹의 비트가 설정되면true를 반환 flowbits:isnotset, all, doc => doc그룹의 모든 비트가 설정되면true를 반환
<사용예>
noalert
이 키워드는 항상false를 반환함.
이를 통해 사용자는 경고를 생성하지 않고 비트를 설정,설정 해제 및 토글하는 규칙을 작성할 수 있음.
이는 정상적인 트래픽에 비트를 설정하고 원치 않은 경고를 크게 줄이는flowbit규칙을 작성하는 데 가장 유용함.
이 키워드에 지정된 비트가 없음.
flowbits:noalert;
<형식>
reset
이 키워드는 지정된 그룹이 없는 경우 지정된 흐름의 모든 상태를 재설정하고 그렇지 않으면 그룹의 모든 비트를 재설정함.
이것은 항상true를 반환함.
이 키워드에 지정된 비트가 없음.
flowbits:reset[,group]
<형식>
flowbits:reset =>흐름의 모든 비트 재설정 flowbits: reset, doc => doc그룹의 모든 비트 재설정
<사용예>
6.11 seq
seq키워드는 특정TCP시퀀스 번호를 확인하는 데 사용됨.
seq:<number>;
<형식>
이 예에서는TCP시퀀스 번호0을 찾음.
seq:0;
<사용예>
6.12 ack
ack키워드는 특정TCP승인 번호를 확인하는 데 사용됨.
ack:<number>;
<형식>
이 예에서는TCP승인 번호0을 찾음.
ack:0;
<사용예>
6.13 window
window키워드는 특정TCP창 크기를 확인하는 데 사용됨.
window:[!]<number>;
<형식>
이 예에서는TCP창 크기55808를 찾음.
window:55808;
<사용예>
6.14 itype
itype키워드는 특정ICMP유형 값을 확인하는 데 사용됨.
icode:min<>max; icode:[<|>]<number>;
<형식>
이 예에서는30보다 큰ICMP유형을 찾음.
itype:>30;
<사용예>
6.15 icode
icode키워드는 특정ICMP코드 값을 확인하는 데 사용됨.
itype:min<>max; itype:[<|>]<number>;
<형식>
첫 번째 형식의<>연산자는 지정된 범위(배타적)내에서ICMP코드를 확인함.
즉,최소값보다 크거나 최대값보다 작음.
최소값은-1이 될 수 있으므로ICMP코드0이 범위에 포함될 수 있음.
숫자 값은0에서255사이의 허용되는ICMP코드 값 및 기타 기준과 관련하여 검증됨.
icode:min<>max
-1 <= min <= 254
1 <= max <= 256
(max - min) > 1
icode:number
0 <= number <= 255
icode:<number
1 <= number <= 256
icode:>number
0 <= number <= 254
이 예에서는30보다 큰ICMP코드를 찾음. icode:>30; 이 예에서는0보다 크고30보다 작은ICMP코드를 찾음. icode:-1<>30;
<사용예>
6.16 icmp_id
icmp_id키워드는 특정ICMP ID값을 확인하는 데 사용됨.
이것은 일부 비밀 채널 프로그램이 통신 할 때 정적ICMP필드를 사용하기 때문에 유용함.
이 특정 플러그인은stacheldraht DDoS에이전트를 감지하기 위해 개발됨.
icmp_id:<number>;
<형식>
이 예에서는ICMP ID 0을 찾음.
icmp_id:0;
<사용예>
6.17 icmp_seq
icmp seq키워드는 특정ICMP시퀀스 값을 확인하는 데 사용됨.
이것은 일부 비밀 채널 프로그램이 통신 할 때 정적ICMP필드를 사용하기 때문에 유용함.
이 특정 플러그인은stacheldraht DDoS에이전트를 감지하기 위해 개발됨.
icmp_seq:<number>;
<형식>
이 예에서는ICMP시퀀스0을 찾음.
icmp_seq:0;
<사용예>
6.18 rpc
rpc키워드는SUNRPC CALL요청에서RPC애플리케이션,버전 및 프로시저 번호를 확인하는 데 사용됨.
• 선택적noalert매개 변수를 사용하면 규칙이 일치할 때 경고를 생성하지 않음. • 선택적fastpath매개 변수를 사용하면Snort가 나머지 연결을 무시함.
<형식>
예를 들어, HTTP 200 Ok응답 메시지가 표시 될 때 클라이언트 트래픽에 대한TCP재조립을 비활성화하려면 다음을 사용함. alert tcp any 80 -> any any (flow:to_client, established; content:"200 OK"; stream_reassemble:disable,client,noalert;)
<사용예>
6.22 stream_size
stream_size키워드를 사용하면 규칙이TCP시퀀스 번호에 의해 결정된 대로 관찰된 바이트 수에 따라 트래픽을 일치시킬 수 있음.
노트:
stream_size옵션은 스트림 전처리기(Stream preprocessor)가 활성화된 경우에만 사용할 수 있음.
또한,규칙에packets이외의 메트릭을 사용하는 태그 옵션이 있는 경우seconds또는bytes개수에 관계없이 태그가 지정된 패킷 수를 제한하는 데tagged_packet_limit가 사용됨.
기본tagged_packet_limit값은256이며snort.conf파일에서 구성 옵션을 사용하여 수정할 수 있음.
태그 옵션에packets메트릭을 추가하고 개수를0으로 설정하여 특정 규칙에 대해 이 패킷 제한을 비활성화 할 수 있음. (이는snort.conf의tagged_packet_limit옵션을0으로 설정하여 글로벌 규모로 수행할 수 있음)
이렇게하면 패킷이seconds또는bytes의 전체 양에 대해 태그가 지정되고tagged_packet_limit에 의해 잘리지 않음. (tag_packet_limit는seconds또는bytes카운트가 높은 태그 규칙에 대해 고대역폭 센서에서DoS상황을 피하기 위해 도입됨)
이 예는 텔넷 세션의 처음10초 또는 태그가 지정된 패킷 제한(둘 중 먼저 오는 쪽)을 기록함. alert tcp any any -> any 23 (flags:S,CE; tag:session,10,seconds;)
tag:host에는 하나 이상의 개수와 메트릭이 필요하지만 메트릭없이 배타적인tag:session을 사용하여 이와 같은 전체 세션을 얻을 수 있음. pass tcp any any -> 192.168.1.1 80 (flags:S; tag:session,exclusive;)
<사용예>
7.6 replace
replace키워드는Snort가 이전에 일치하는 컨텐츠에 주어진 문자열로 바꾸도록 하는 기능으로 인라인 모드에서 사용함.
새 문자열과 교체할 내용은 모두 길이가 같아야 함.
규칙 내에서 컨텐츠당 하나번 여러 개의 교체가 있을 수 있음.
replace:"<string>";
<형식>
7.7 detection_filter
탐지 필터는 규칙이 이벤트를 생성하기 전에 소스 또는 대상 호스트가 초과해야 하는 비율을 정의함.
이 규칙은SID에서10개 이상의 이벤트가 발생하는 경우60초마다 최대 하나의 이벤트를 기록함. alert tcp $external_net any -> $http_servers $http_ports \ (msg:"web-misc robots.txt access"; flow:to_server, established; \ uricontent:"/robots.txt"; nocase; reference:nessus,10302; \ classtype:web-application-activity; threshold:type both, track \ by_dst, count 10, seconds 60; sid:1000852; rev:1;)
<사용예>
옵션
설명
type limit|threshold|both
시간 간격 동안 첫 번째m이벤트에 대해limit경고를 입력한 다음 나머지 시간 간격 동안 이벤트를 무시함. 시간 간격 동안이 이벤트를 볼 때마다threshold경고를 입력함. m개의 이벤트 발생을 확인한 후 시간 간격당 한 번씩both경고를 입력 한 다음 시간 간격 동안 추가 이벤트를 무시함.
track by_src|by_dst
속도는 소스IP주소 또는 대상IP주소로 추적됨. 즉,각 고유 소스IP주소 또는 각 고유 대상IP주소에 대해 개수가 유지됨. 포트 또는 기타 항목은 추적되지 않음.
count c
event_filter한계를 초과하게 만드는s초 단위의 규칙 일치 수임. c는0이 아닌 값이어야 함.
seconds s
실사가 발생하는 기간임. s는0이 아닌 값이어야 함.
< Post-Detection규칙 옵션 키워드>
( 9 )좋은 규칙 작성
효율성과 속도를 극대화하기 위해Snort규칙을 개발할 때 염두에 두어야 할 몇 가지 일반적인 개념이 있음.
9.1컨텐츠 매칭
Snort는 프로토콜(ip, tcp, udp, icmp),포트(ip와icmp는 약간 다른 로직 사용), content가 있는 것과 없는 것 별로 규칙을 그룹화함.
content가 포함 된 규칙의 경우 단일 컨텐츠를 기준으로 일치 가능성이 있는 규칙을 선택하기 위해 다중 패턴 매처(multi-pattern matche)가 사용됨.
이"빠른"패턴 일치기("fast" pattern matcher)를 통해 평가할 규칙을 선택하면 특히HTTP와 같은 대규모 규칙 그룹에 적용될 때 성능이 향상되는 것으로 나타남.
content가 길고 고유할수록 해당 규칙과 모든 규칙 옵션이 불필요하게 평가 될 가능성이 줄어듬. -일반적으로"나쁜"트래픽보다"좋은"트래픽이 더 많다고 말하는 것이 안전함(safe).
content가 없는 규칙은 항상 평가되어(상주하는 프로토콜 및 포트 그룹과 관련하여)잠재적으로 성능에 영향을 줌.
pcre및byte_test와 같은 검색 옵션은 패킷의 페이로드 섹션에서 검색을 수행하지만 고속 패턴 일치 엔진(fast pattern matching engine)에서는 사용되지 않음.
가능하면 규칙에 하나 이상의content(또는uricontent)규칙 옵션을 사용하십시오.
9.2익스플로잇이 아닌 취약점 파악(Catch the Vulnerability, Not the Exploit)
특정 익스플로잇 대신 취약점을 표적으로 삼는 규칙을 작성하십시오.
예를 들어,쉘을 바인딩하는 쉘코드 대신 인수가 너무 큰 취약한 명령어를 찾으십시오.
취약점에 대한 규칙을 작성하면 공격자가 익스플로잇을 약간 변경할 때 규칙이 회피에 덜 취약함.
9.3규칙에서 프로토콜의 이상한 점 파악
많은 서비스는 일반적으로 대문자로 명령어을 모냄.
FTP가 좋은 예임.
FTP에서 사용자 이름을 보내기 위해 클라이언트는 다음을 보냄.
user username_here
FTP root로그인 시도를 찾는 간단한 규칙은 다음과 같음.
alert tcp any any -> any any 21 (content:"user root";)
사용자 이름root를 찾는 규칙을 작성하는 것은 사소한 것처럼 보일 수 있지만,좋은 규칙은 사용자 명령을 수락할 때 프로토콜이 처리 할 수 있는 모든 이상한 일을 처리함.
예를 들어,다음은 대부분의FTP서버에서 허용됨.
user root
user root
user root
user root
user<tab>root
FTP서버가 처리 할 수 있는 모든 경우를 처리하려면 규칙에 단순한 문자열 일치보다 더 스마트 한 것이 필요함.
ftp에서 루트 로그인을 찾는 좋은 규칙은 다음과 같음.
alert tcp any any -> any 21 (flow:to_server,established; \
content:"root"; pcre:"/user\s+root/i";)
이 규칙에서 유의해야 할 몇 가지 중요한 사항이 있음:
• 규칙에는 설정된 세션에서 서버로 이동하는 트래픽인지 확인하는flow옵션이 있음.
• 규칙에는 공격에서 가장 길고 고유 한 문자열 인root를 찾는content옵션이 있음.이 옵션은 페이로드에서root컨텐츠가 발견되는 경우에만 평가를 위해 빠른 패턴 일치자가 이 규칙을 선택할 수 있도록 추가됨.
• 규칙에는pcre옵션이 있으며user를 찾고 적어도 하나의 공백 문자(탭 포함)와root가 이어짐. (대소문자 무시)
9.4규칙 최적화
검색 엔진의 컨텐츠 일치 부분에는 몇 가지 회피 사례를 처리하기 위한 재귀가 있음.
제대로 작성되지 않은 규칙으로 인해Snort가 검사를 복사하는(duplicationg)데 시간을 낭비 할 수 있음.
이제 재귀가 작동하는 방식은 패턴이 일치하는 경우이고 해당 패턴 이후의 검색 옵션이 실패하면 이전에 발견된 위치에서 다시 패턴을 찾음.
패턴이 다시 발견되지 않거나opt기능이 모두 성공할 때까지 반복하십시오.
처음 읽을 때,그것은 현명한 생각처럼 들리지 않을 수도 있지만 필요함.
예를 들어,다음 규칙을 따르십시오:
alert ip any any -> any any (content:"a"; content:"b"; within:1;)
이 규칙은"a"를 찾고 바로 뒤에"b"를 찾음.
재귀가 없으면 페이로드"aab"에"a"바로 뒤에"b"가 있음이 분명하더라도"aab"페이로드가 실패함.
왜냐하면 첫 번째"a"다음에"b"가 바로 뒤따르지 않기 때문임.
재귀는 탐지에 중요하지만 재귀 구현은 그리 똑똑하지 않음.
예를 들어 다음 규칙 옵션은 최적화되지 않음.
content:"|13|"; dsize:1;
이 규칙 스니펫(snippet)을 보면 규칙이 단일 바이트가0x13인 패킷을 찾는 것이 분명함.
그러나 재귀로 인해1024바이트의0x13패킷은1023너무 많은 패턴 일치 시도와1023너무 많은dsize검사를 유발할 수 있음.
왜?
컨텐츠0x13이 첫 번째 바이트에서 발견되면dsize옵션이 실패하고 재귀로 인해 컨텐츠0x13이 이전0x13이 발견된 위치부터 다시 발견되고 일단 발견되면dsize를 다시 확인함.페이로드에서0x13이 다시 발견되지 않을 때까지 반복함.
불연속 검사(예: dsize)가 규칙의 시작 부분으로 이동되도록 규칙 옵션을 재정렬하면Snort속도가 빨라짐.
최적화 된 규칙 스니핑(snipping)은 다음과 같음:
dsize:1; content:"|13|";
1024바이트0x13패킷은dsize검사가 첫 번째 옵션이고dsize가 재귀 없는 개별 검사이므로 즉시 실패함.
다음 규칙 옵션은 개별적이며 일반적으로 규칙의 시작 부분에 배치해야 함.
•dsize
•flags
•flow
•fragbits
•icmp id
•icmp seq
•icode
•id
•ipopts
•ip proto
•itype
•seq
•session
•tos
•ttl
•ack
•window
•resp
•sameip
9.5숫자값 테스트
규칙 옵션byte_test및byte_jump는 길이 인코딩 데이터가 있는 프로토콜에 대한 쓰기 규칙을 지원하기 위해 작성됨.
RPC는 데이터 전달에 간단한 길이 기반 인코딩을 사용하기 때문에RPC는 이 두 가지 규칙 옵션에 대한 요구 사항을 생성한 프로토콜임.
byte_test및byte jump가 유용한 이유를 이해하기 위해sadmind서비스에 대한 공격 시도를 살펴봄.
# $Id: local.rules,v 1.11 2004/07/23 20:15:44 bmc Exp $ # ---------------- # LOCAL RULES # ---------------- # This file intentionally does not come with signatures. Put your local # additions here.
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"SQL Injection"; content:"1' and '1'='1'"; nocase; sid:3000001; rev:1;)
lsof는 유닉스 시스템에서 동작하는 있는 프로세스에 의해서 열린 파일 정보를 보여주는 시스템 관리 명령이다.
옵션 ① -u : 특정 사용자가 사용하는 프로세스 확인 - 예) lsof -u $UID ② -p : 지정한 프로세스가 오픈한 파일 리스트 확인 - 예) lsof -p $PID ③ -i : 모든 네트워크에 연결되어 있는 프로세스와 파일 정보를 조회 - 예) lsof -i ④ -c : 지정한 데몬과 연결되어 있는 프로세스와 파일 정보를 조회 - 예) lsof -c 데몬명
① 하나의 애플리케이션 장비에 여러 가지의 보안 기능의 솔루션을 탑재하여 대응하고 관리할 수 있는 솔루션 시스템이다. ② 다양한 보안솔루션(Firewall, IDS, IPS, VPN 등) 기능을 하나로 통합하여 보안 문제를 쉽고 편리하게 관리 및 해결하는 통합 보안 관리 시스템이다.
① 임의적 접근 통제(DAC, Discretionary Access Control) : 신원 기반, 사용자 기반, 혼합방식의 통제이다. ② 강제적 접근 통제(MAC, Mandatory Access Control) : 보안 등급, 규칙 기반 접근 통제이다. ③ 역할기반 접근 통제(RBAC, Role-Based Access Control) : 직무를 기반으로 하는 접근 통제(사용자, 역할, 허가가 RBAC의 기본 구성 요소)
① debug : 프로그램을 디버깅할 때 발생하는 메시지이다. ② info : 통계, 기본 정보 메시지이다. ③ notice : 특별한 주의를 기하나 에러는 아닌 메시지이다. ④ warning : 주의를 요하는 경고 메시지이다. ⑤ err : 에러가 발생하는 경우의 메시지이다. ⑥ crit : 크게 급하지는 않지만 시스템에 문제가 생기는 단계의 메시지이다. ⑦ alert : 즉각적인 조정을 해주어야 하는 상황이다. ⑧ emerg : 모든 사용자들에게 전달되어야 할 위험한 상황이다.
에러 로그는 어느 레벨까지의 에러를 기록할지 여부를 8단계로 지정할 수 있다. 지정하려면 "LogLevel"로 사용하여 설정한다.
LogLevel 기록하는-레벨
설정 가능한 레벨은 다음과 같다.
emerg
서버가 가동 할 수 없을 정도의 심각한 오류
alert
crit보다 심각한 오류
crit
치명적인 오류
error
오류
warn
경고
notice
알림 메시지
info
서버 정보
debug
디버깅을위한 정보
레벨은 위에서 부터 심각하고, "error"로 설정하면 "error" 위의 "crit", "alert", "emerg" 에러도 모두 기록된다.
보다 낮은 수준으로 설정하면 많은 정보를 로그로 남길 수 있지만, 그 만큼 로그 파일 크기가 커지게 되므로 필요에 따라 설정을 변경한다.
"httpd.conf" 파일에 대한 "LogLevel"로 검색해 보면, 다음과 같은 내용을 찾을 수 있을 것이다.
#
# LogLevel: Control the number of messages logged to the error_log.
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
#
LogLevel warn
기본으로 LogLevel가 "warn"으로 설정되어 있다. 변경하려면 "warn"부분을 다른 수준의 값으로 변경하면 된다.
S/MIME(Secure Multipurpose Internet Mail Extension)
① MIME(Multipurpose Internet Mail Extension)에 전자서명과 암호화 기능을 추가한 보안 서비스로 RSA사에서 개발한 보안 프로토콜이다. ② 전자 메시지의 송신자와 수신자 인증, 메시지 무결성, 전자서명을 이용한 송신자 부인방지, 암호화를 제공한다. ③ CA(인증기관)으로부터 자신의 공개키를 보증하는 인증서를 받아야 한다. ④ 첨부 파일에 대한 보안 기능을 제공한다.
※ PGP(Pretty Good Privacy)는 기존 전자우편시스템과 통합이 용이하지 않으며, PEM(Privacy Enhanced Mail)은 구현이 복잡한 단점이 있다. 이러한 단점을 보완한 S/MIME(Secure Multipurpose Internet Mail Extension)은 X.509 인증서와 CA(인증기관)을 이용하며, MIME 형식의 메시지에 암호화 기능을 제공한다.
AH ① 데이터 무결성과 IP 패킷의 인증을 제공하며, MAC 기반이다. ② Replay Attack으로부터의 보호 기능(순서 번호 사용)을 제공한다. ③ 인증 시 MD5, SHA-1 인증 알고리즘을 이용하여 Key 값과 IP 패킷의 데이터를 입력한 인증 값을 계산하여 인증 필드에 기록한다. ④ 수신자는 같은 키를 이용하여 인증 값을 검증한다.
ESP ① 전송 자료를 암호화하여 전송하고 수신자가 받은 자료를 복호화하여 수신한다. ② IP 데이터그램에 제공하는 기능으로서 데이터의 선택적 인증, 무결성, 기밀성, Replay Attack 방지를 위해 사용한다. ③ AH와 달리 암호화를 제공(대칭키, DES, 3-DES 알고리즘)한다. ④ TCP/UDP 등의 Transport 계층까지 암호화할 경우 Transport 모드를 사용한다. ⑤ 전체 IP 패킷에 대해 암호화를 할 경우 터널 모드를 사용한다.
인증, 무결성, 기밀성, Reply 공격에 대한 방어와 안전에 취약한 인터넷에서 안전한 통신을 실현하는 통신 규약이다. 즉, 인터넷상에 전용 회선과 같이 이용 가능항 가상적인 전용 회선을 구축하여 데이터를 도청당하는 등의 행위를 방지하기 위한 통신 규약이다.
① 비연결형 무결성(Integrity), 기밀성(Confidentiality), 인증(Authentication), 재연 공격 방지(Protection Against Replays), 접근 통제(Access Control) ② AH(Authentication Header, 인증헤더) : 인증 데이터와 순서 번호를 가져서 송신자를 확인, 데이터 무결성 보장, 데이터 암호화는 제공하지 않는다. ③ ESP(Encapsulating Security Playload, 보안 페이로드 캡슐화) : IP 페이로드를 암호화하여 데이터 기밀성 제공, 스니핑을 방지한다. ④ IKE(Internet Key Exchange)로 키를 교환한다. ⑤ 터널 모드(Tunnel Mode) : 터널 게이트웨이 사이에서 터널이 생성되며 사설 IP 주소를 사용할 수 있고 IP 헤더를 포함한 전체 패킷에 대해서 암호화되어 전송되는 모드이다. ⑥ 전송 모드(Transport Mode) : 최종 단말 사이에서 터널이 생성되며, 출발지와 도착지 주소를 기반으로 QoS를 제공할 수 있고, IP 헤더를 제외한 Payload를 암호화하여 전송하는 모드이다.
① 디지털 콘텐츠를 안전하게 보호할 목적으로 암호화 기술을 이용하여 허가되지 않은 사용자로부터 콘텐츠 저작권 관련 당사자의 권리 및 이익을 지속적으로 보호 및 관리하는 시스템이다. ② 저작자 및 유통업자의 의도에 따라 디지털 콘텐츠가 안전하고 편리하게 유통될 수 있도록 제공되는 모든 기술과 서비스 절차 등을 포함하는 개념이다. ③ 디지털 콘텐츠의 불법복제 및 유통에 따른 문제를 해결하고 정당한 사용자(Right User)만 디지털 콘텐츠를 사용하며 과금을 통해 저작권자의 권리 및 이익을 보호하는 디지털 콘텐츠 보호기술이다.
DRM 기술 ① 암호화 : 대칭키 및 비대칭키 암호화 기술 ② 인증 : 정당한 사용자 식별을 위한 인증 ③ Watermarking : 원저작권 정보 삽입 및 식별 수행 ④ 사용자 Repository : 정당한 사용자 및 라이선스 정보 저장 ⑤ 사용자 권한 관리 : 열람 및 배포에 대한 권리, 편집, 복사, 다운로드 등의 권한 관리 ⑥ Temper Proofing : 불법 수정 여부를 검증, Cracking을 방지
① IEEE 802.11의 암호화 기법이다. AP(Access Point)와 단말 간의 송수신 데이터를 AP와 단말기가 약속한 공유 비밀키와 임의의 선택된 IV(Initial Vector) 값을 조합한 64Bit(40Bit의 WPKey, 24Bit IV) 혹은 128Bit를 이용하여 데이터를 암호화하는 방식으로 단방향 인증을 수행한다. ② RC4 암호화 알고리즘을 사용한다. ③ 무결성을 위한 CRC-32 Check Sum을 사용한다. ④ 사용되는 공유키는 40 또는 104Bit, Data Link 계층이다. ⑤ Initialization vector(IV)와 조합 시 키 길이는 64Bit 또는 128Bit이다. ⑥ 전송되는 프레임은 40Bit 키 길이와 24Bit Initialization(IV)로 조합된 64Bit 키를 이용한 RC4 스트림 암호방식을 사용한다. ⑦ 단말과 AP는 동일한 패스워드 문장으로부터 4개의 고정된 장기 공유키를 생성한 후 이들 중에서 하나를 선택하여 암호 및 인증에 활용한다. 하지만 선택된 공유키의 Key ID와 IV값이 평문으로 상대방에 전송되므로 위험하다.
WEP 보안 취약점 ① IV노출, RC4 암호화 알고리즘 취약점으로 인한 무작위 공격에 취약하다. ② WEP는 비밀키와 임의로 선택된 IV를 사용해서 4개의 키를 생성하고 생성된 키 중 하나를 선택하여 암호화를 수행한다. 이것을 돌아가며 키 스트림을 재사용하는 특성을 가진다. 24Bit의 IV는 5000개의 패킷마다 IV가 반복될 가능성이 50% 존재한다. ③ IEEE 802.11i가 확정되면서 표준에서 제외되었다.
PSK(Pre Shared Key) ① 인증서버 없이 단말기과 AP 간 미리 공유한 키를 기반으로 AP 접속을 인증한다. ② Personal Mode(WPA-PSK)와 Enterprise Mode(WPA-Enterprise)로 운영된다. ③ Layer 2 동작, 강력한 네트워크 접근 정책 구현이 가능하며 Port Control을 통한 비인가된 사용자들은 네트워크 접속이 차단된다. ④ IEEE 802.1x port Based Access Control
EAP(Extensible Authentication Protocol) ① 유선망에서 PPP 절차에 의한 사용자 인증을 위해 개발되었다. ② 모든 링크계층에 적용, 다양한 인증 방법을 사용할 수 있도록 설계되었다. ③ 단말과 인증서버 간 인증 프로토콜에 관여하지 않는 인증 메커니즘이다.
시큐어 코딩(Secure Coding)은 안전한 소프트웨어의 개발을 위해 소스 코드 등에 존재할 수 있는 보안 취약점을 최소화하고, 보안을 고려하여 기능을 설계하고 구현하는 등의 제작 방식을 의미한다. 인터넷 홈페이지나 소프트웨어를 개발할 때 보안 취약점을 악용한 해킹 등 내/외부 공격으로부터 시스템을 안전하게 보호할 수 있도록 코드를 작성하는 것이다.
① 대칭키 알고리즘 중 하나이다. ② 64Bit 평문 블록 길이에 키 길이(유효길이)는 56Bit이며 16Round 단순 회전하여 64Bit의 암호문을 생성한다. (64Bit에서 키 유효길이가 56Bit이며 8Bit는 Parity임). ③ 평문에 대치(Substitution)-치환(Permutation)을 16번 반복한다. ④ 커버로스에서 사용하며 키 길이가 짧아 쉽게 Crack(4회면 가능)이 가능하다. ⑤ DES의 안전성은 S-box에 의존, 무차별 공격에 취약하다.
※ 암호화 블록크기가 64Bit이고, 암호화 키 크기가 64 또는 56Bit이며 16Round를 거쳐 암호화가 가능한 대칭키 블록암호화 알고리즘이다. 호환성은 좋으나 키 크기가 작아 해독이 용이한 단점이 있다.
① 역상저항성 : 주어진 임의의 출력값 y에 대해 y=h(x)를 만족하는 입력 값 x를 찾는 것이 계산적으로 불가능 ② 두번째 역상저항성 : 주어진 입력값 x에 대해 h(x)=h(x'), x!=x'를 만족하는 다른 입력 값 x'를 찾는것이 불가능 ③ 충돌저항성 : h(x)=h(x')를 만족하는 임의의 두 입력 값 x, x'를 찾는 것이 계산적으로 불가능 ④ 충돌회피성 : h(M)=h(M')가 되는 서명문 쌍 (M, M')(M!=M')를 찾는 것이 계산적으로 불가능 ⑤ 약일방향성 : 해시 값 H로부터 h(M)=H가 되는 서명문 M을 찾는 것은 계산적으로 불가능 ⑥ 강일방향성 : 서명문 M과 그의 해시 값 H=h(M)이 있을 때 h(M')=H가 되는 서명문 M!=M'를 찾는 것이 계산적으로 불가능
ECKCDSA(Korea Certification-based Digital Signature Algorithm using Elliptic Curves)
① 전자서명 알고리즘 중 하나이다. ② KCDSA를 타원곡선을 이용하여 변형한 전자서명 알고리즘 ③ 다른 공개키 시스템의 키 길이에 비해서 훨씬 잛은 키를 사용하여도 동일한 안전도를 제공 ④ 스마트카드, 무선 통신 등과 같이 메모리와 처리 능력이 제한된 분야에서 매우 효과적 ⑤ 2001년 TTA에서 표준으로 제정(TTAS.KO-12.0015)
① 비대칭 알고리즘 중 하나 ② 타원 곡선 상에서 이산대수의 어려움에 기반을 둔 공개키 방식의 암호 알고리즘 ③ 강력한 암호화를 요구하는 컴퓨터들의 네트워크에서 원활하게 작동됨 ④ 짧은 키를 가지는 전자서명과 인증 시스템의 구성이 가능 ⑤ 하드웨어 및 소프트웨어 상에서 빠른 암/복호화를 제공 ⑥ 제한된 공간에 보다 많은 키를 줄 수 있기 때문에 스마트카드, 무선전화, 스마트 폰 등과 같은 작은 H/W의 인증 및 서명에 사용(스마트카드의 데이터 암호화는 AES)
※ 1985년 코블리츠(N, Koblitz)와 밀러(V.S. Miller)가 RSA 암호화 방식에 대한 대안으로 처음 제안한 알고리즘이다. 스마트 카드나 휴대폰 등 키의 길이가 제한적인 무선 환경이나 작은 메모리를 가지고 있는 시스템에 적용한다.
1xx (조건부 응답) : 요청을 받았으며 작업을 계속한다. 2xx (성공) : 이 클래스의 상태 코드는 클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으며 성공적으로 처리했음을 가리킨다. 3xx (리다이렉션 완료) : 클라이언트는 요청을 마치기 위해 추가 동작을 취해야 한다. 4xx (요청 오류)(클라이언트 오류) : 4xx 클래스의 상태 코드는 클라이언트에 오류가 있음을 나타낸다. 5xx (서버 오류) : 서버가 유효한 요청을 명백하게 수행하지 못했음을 나타낸다.
HTTP 200(OK) : 클라이언트의 요청(Request)이 성공적으로 수행되었다는 것을 의미한다. 클라이언트가 요청한 방법에 대해서 메시지가 출력된다. HTTP 400(Bad Request) : 클라이언트의 요청 메시지의 구문(Syntax)이 잘못되어 서버가 요청을 처리할 수 없다. 재접속에는 클라이언트가 반드시 올바른 요청 메시지를 보내야 한다. 문법상 오류가 있어서 서버가 요청 사항을 이해하지 못함. HTTP 401(Unauthorized) : 권한 없음-접속실패, 이 에러는 서버에 로그온 하려는 요청 사항이 서버에 들어있는 권한과 비교했을 시 맞지 않을 경우 발생. 클라이언트의 요청 메시지가 사용자 인증을 필요로 한다는 것을 응답 메시지로 보내주는 것이다. 이 코드를 전달받은 클라이언트는 다시 올바른 인증 메시지를 서버에 전달해야 한다. HTTP 403(Forbidden) : 클라이언트의 요청을 서버가 거절하는 것을 나타낸다. 클라이언트가 동일한 요청 메시지를 반복으로 보냈을 경우 서버는 무조건 거절 메시지를 보내게 된다. HTTP 404(Not Found) : 클라이언트의 요청된 자원을 찾을 수 없거나 가지고 있지 않을 때 응답 메시지로 보내는 것이다. 서버는 이 메시지와 함께 어떠한 정보도 클아이언트로 보내지 않는다. HTTP 500(Internal) : 서버 프로그램에서 예기치 않은 오류가 발생하여서 요청에 대한 메시지나 오류 메시지를 보낼 수 없음을 의미한다. 웹서버가 요청사항을 수행할 수 없을 경우에 발생함. HTTP 501(Not Implemented) : 클라이언트의 요청 메시지를 처리하기 위해서 서버가 필요한 기능을 가지고 있지 못한다. HTTP 502(Bad Gateway) : 게이트웨이나 프록시로 동작하는 서버가 사용하는 Status Code로 자신의 게이트웨이의 위쪽에 있는 서버로부터 잘못된 응답 메시지를 전송받았다는 것을 의미한다. HTTP 503(Service Unavailable, 서비스를 사용할 수 없음) : 클라이언트의 요청 메시지에 대해서 현재 서버의 과부하나 서버의 오류 동작 때문에 서버가 잠시 동안 요청을 받을 수 없거나 처리할 수 없는 상태임을 나타내는 Status Code이다. 서버가 오버로드 되었거나 유지관리를 위해 다운되었기 때문에 현재 서버를 사용할 수 없다. 이는 대개 일시적인 상태이다.
"서비스형(as-a-Service)"이라는 용어는 제3사에서클라우드 컴퓨팅서비스를 제공한다는 의미입니다. 따라서 사용자는 코드, 고객 관계 관리와 같은 더 중요한 업무에 집중할 수 있습니다. 각 유형의 클라우드 컴퓨팅을 활용하면 관리해야 할 온프레미스 인프라가 지속적으로 감소합니다.
온프레미스 IT 인프라를 관리할 책임은 대부분 사용자와 관리자에게 있습니다. 하드웨어와 소프트웨어가 모두 온프레미스에 위치하는 경우, 필요에 따라 각 구성 요소를 관리, 업데이트 및 교체하는 업무는 사용자 및 사용자 팀이 수행해야 합니다. 클라우드 컴퓨팅을 사용하면 인프라의 단일, 여러 또는 모든 부분을 제3사가 관리하도록 할당하여 다른 중요한 사안에 집중할 수 있습니다.
클라우드 컴퓨팅 서비스는 서비스로서의 인프라(Infrastructure-as-a-Service, IaaS), 서비스로서의 플랫폼(Platforms-as-a-Service, PaaS), 서비스로서의 소프트웨어(Software-as-a-Service, SaaS)의 3가지 기본 유형에 해당하는 서비스로서의 클라우드 컴퓨팅 옵션을 제공하며, 관리 수준이 저마다 다릅니다.
이 글에서는 각 모델 유형, 장점 및 그러한 유형의 일부 또는 전체를 사용하여 요구 사항을 충족하는 클라우드 컴퓨팅 환경을 구축하는 방법에 대해 알아봅니다. 또한, 쉽게 이해할 수 있도록 각각의 몇 가지 예도 알아봅니다.
IaaS
서비스로서의 인프라 또는IaaS는 온프레미스 인프라에서 한층 발전한 유형입니다. 이는 종량제 서비스로, 필요한 경우 제3사가 스토리지와 가상화와 같은 인프라 서비스를 인터넷을 통해 클라우드로 제공합니다.
사용자는 운영 체제 및 데이터, 애플리케이션, 미들웨어 및 런타임을 담당하고 제공업체는 사용자가 필요로 하는 네트워크, 서버, 가상화 및 스토리지의 관리와 액세스를 담당합니다.
제공업체가 사용자를 대신해 온사이트 데이터센터를 유지관리하거나 업데이트합니다. 대신, 사용자는 애플리케이션 프로그래밍 인터페이스(API) 또는 대시보드를 통해 인프라에 액세스하고 이를 제어합니다.
IaaS는 필요한 구성 요소만 구매하고 필요에 따라 확장 또는 축소할 수 있는 유연성을 제공합니다. IaaS는 간접비가 낮고 유지관리 비용이 들지 않는 매우 경제적인 옵션입니다.
IaaS는 개발 및 테스트 환경의 구축 및 제거가 빠르고 유연하다는 장점이 있습니다. 사용자는 개발 환경에서 구축해야 할 인프라만 사용하고 필요에 따라 확장 또는 축소하며, 개발이 완료되면 사용을 중단하고 사용량에 대한 비용만 지불합니다.
IaaS의 주요 단점은 제공업체의 보안 문제 가능성, 제공업체가 여러 클라이언트와 인프라 리소스를 공유해야 하는 멀티 테넌트 시스템 및 서비스 신뢰성입니다. 탄탄한 업력과 평판을 보유한 신뢰할 수 있는 제공업체를 선택하면 이러한 단점을 방지할 수 있습니다.
AWS, Microsoft Azure, Google Cloud와 같은 퍼블릭 클라우드 공급업체가 IaaS의 예시입니다.
PaaS
서비스로서의 플랫폼(PaaS)은 전체 온프레미스 인프라 관리가 조금 더 발전한 형태입니다. PaaS에서는 제공업체가 자체 인프라에서 하드웨어와 소프트웨어를 호스팅하고 이러한 플랫폼을 사용자에게 통합 솔루션, 솔루션 스택 또는 인터넷을 통한 서비스로 제공합니다.
주로 개발자와 프로그래머에게 유용한 PaaS는 보통 해당 프로세스와 관련된 인프라 또는 플랫폼을 구축하고 유지관리할 필요 없이 사용자가 자체 애플리케이션을 개발, 실행 및 관리할 수 있도록 해줍니다.
사용자는 애플리케이션 코드를 작성, 빌드, 관리하지만 소프트웨어 업데이트 또는 하드웨어 유지관리와 같은 번거로움이 사라집니다. 빌드 및 배포를 위한 환경이 사용자에게 제공됩니다.
PaaS는 개발자가 프레임워크를 개발하여 지속적으로 웹 기반 애플리케이션을 빌드 및 커스터마이징할 수 있는 방법입니다. 개발자는 기본 소프트웨어 구성 요소를 활용하여 자체 애플리케이션을 개발할 수 있으므로 자체적으로 작성해야 하는 코드의 양을 줄일 수 있습니다.
PaaS의 몇 가지 예로는 AWS Elastic Beanstalk, Heroku 및Red Hat OpenShift가 있습니다.
SaaS
서비스로서의 소프트웨어(SaaS) 또는 클라우드 애플리케이션 서비스는 가장 포괄적인 형식의 클라우드 컴퓨팅 서비스로, 모든 애플리케이션은 제공업체가 관리하며 웹 브라우저를 통해 제공됩니다.
제공업체가 소프트웨어 업데이트, 버그 수정 및 기타 일반 소프트웨어 유지관리 작업을 처리하며, 사용자는 대시보드 또는 API를 통해 애플리케이션에 연결합니다. 개별 시스템에 소프트웨어를 설치할 필요가 없으며 프로그램에 대한 그룹 액세스가 더욱 원활하고 안정적입니다.
Outlook이나 Gmail과 같은 웹 기반 서비스가 지원되는 이메일 계정이 있다면 어디서든 컴퓨터에서 계정에 로그인하고 이메일을 수신할 수 있다는 점에서 SaaS라는 형태가 이미 익숙할 것입니다.
SaaS는 소프트웨어 설치 및 업데이트를 처리할 인력이나 대역폭이 없으며 최적화가 그다지 필요하지 않거나 주기적으로 사용되는 애플리케이션이 있는 소기업에 매우 유용한 옵션입니다.
SaaS로 시간과 유지관리를 줄일 수 있지만 제어, 보안 및 성능과 관련한 비용이 소요되므로 신뢰할 수 있는 제공업체를 선택하는 것이 중요합니다.
Dropbox, Salesforce, Google Apps 및Red Hat Insights가 SaaS의 몇 가지 예입니다.
IP(Internet Protocol)에는 오로지 패킷을 목적지에 도달시키기 위한 내용들로만 구성되어 있음. 따라서 정상적으로 목적지 호스트에 도달하는 경우에는 IP로서 통신을 성공하고 종료되므로 아무런 문제가 없음. 그러나 만일 전달해야 할 호스트가 꺼져 있거나 선이 단절될 경우 같은 비정상적인 경우에 이 패킷 전달을 의뢰한 출발지 호스트에 이러한 사일을 알려야 하지만 IP에는 그러한 에러에 대한 처리 방법이 명시되어 있지 않음. 이러한 IP의 부족한 점을 보안하기 위하여 사용되는 것이 바로 ICMP 임.
ICMP는 해당 호스트가 없거나 해당 포트에 대기 중인 서버 프로그램이 없는 등 에러 상황이 발생할 경우 IP 헤더에 기록되어 있는 출발지 호스트로 이러한 에러에 대한 상황을 보내주는 역할을 수행함. 물론 이 외에도 메시지를 제어하는 추가적인 기능들이 있음.
( 2 ) ICMP 패킷 구조
8 바이트의 헤더와 데이터 부분으로 구성됨.
Type 필드 : ICMP 메시지 타입
Code 필드 : ICMP 메시지 타입별로 추가적인 코드 제공
Checksum 필드 : ICMP 헤더의 손상여부 확인
Data Section 필드 : 오류보고 및 질의에 따라서 다름
( 3 ) ICMP Type 유형
Type
Name
0
Echo Reply (Echo응답)
1
Unassigned
2
Unassigned
3
Destination Unreachable (목적지 도달 불가)
4
Source Quench (Deprecated) (출발지 억제)
5
Redirect (경로 변경)
6
Alternate Host Address (Deprecated)
7
Unassigned
8
Echo Request (Echo 요청)
9
Router Advertisement
10
Router Solicitation
11
Time Exceeded (시간 초과)
12
Parameter Problem (파라미터 문제)
13
Timestamp (타임스탬프 요청)
14
Timestamp Reply (타임스탬프 응답)
15
Information Request (Deprecated) (정보 요청)
16
Information Reply (Deprecated) (정보 응답)
17
Address Mask Request (Deprecated)
18
Address Mask Reply (Deprecated)
19
Reserved (for Security)
20-29
Reserved (for Robustness Experiment)
30
Traceroute (Deprecated)
31
Datagram Conversion Error (Deprecated)
32
Mobile Host Redirect (Deprecated)
33
IPv6 Where-Are-You (Deprecated)
34
IPv6 I-Am-Here (Deprecated)
35
Mobile Registration Request (Deprecated)
36
Mobile Registration Reply (Deprecated)
37
Domain Name Request (Deprecated)
38
Domain Name Reply (Deprecated)
39
SKIP (Deprecated)
40
Photuris
41
ICMP messages utilized by experimental mobility protocols such as Seamoby
42-252
Unassigned
253
RFC3692-style Experiment 1
254
RFC3692-style Experiment 2
255
Reserved
참고로 Type 은 그 기능에 따라 Qurey 와 Error 로 나뉘지며 몇몇 Type 은 고유의 필드 구조를 가짐.
