너무 방대한 로그를 다루는 종합시스템은...어찌보면 로그의 의미를 넘어서버리는거 아닐까요?
로그는 말 그대로 로그이니까요..저는 syslog + swatch 조합으로면 충분하던데...
실시간 모니터링의 경우엔 snmp를 이용하면 syslog와 연동시킬 수 있는 부분이 있구요,
상용프로그램을 쓰면 더 강하게 들어갈 수 있겠지만.......
내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.
내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.
실시간 감시란 결국 사람이 지켜봐야 할텐데, 쉽지 않은 일이죠. 몇몇 중요한 이벤트에 대해서만 '실시간 자동 대응'하도록 하는 것이 좋지 않을까 합니다(예: DOS 공격 대응, SSH 침입시도)
알람툴은 swatch에도 이메일로 알려주는 것 있지 않나요?
로그파일 필터링 툴은 사후조사시 필요한 툴을 말하는 건가요? 그게 아니라면 swatch류의 툴들이 하는 것이 필터링 하는 것 아닌가요?
왜 로그정보 DB화 해야 하나요? 대개의 경우 어플리케이션이 있어서 DB화 하는 것인데, 데이터가 충분히 많아지면 결국 로그파일이나 마찬가지로 되지 않을까 생각합니다.
개인적으로는 로그파일을 바탕으로 다음과 같은 일들을 할 수 있다면 충분치 않을까 합니다.
a. swatch류를 사용하여 가장 중요해 보이는 이벤트의 경우 바로 보고(email 등)
b. 매시간마다 덜 중요한 (그렇지만 감시가 필요한) 이벤트에 대한 보고(email 등)
c. 필요에 따라 로그파일을 이용한 어플리케이션 작성 (매우 긴급한 이벤트에 대해 자동 대처)
그외에 직접 관련은 없지만,
d. 매일 filesystem integration check, rootkit check
e. 매일 백업(6일 증가분 백업, 1일 풀 백업)
f. 매일 주요 자원에 대한 요약 보고서(메모리, 디스크사용, 방화벽 사항, 등등)
위에서 c, e, f를 제외하고는 대부분의 배포판에서 쉽게 설치가능한 걸로 압니다(우분투가 가장 쉬웠는데, 해당 패키지들을 설치하면 되었고, 일정기간 동안 필터링 룰을 email 최소로 받도록 수정하는 일만 필요하더군요). c는 직접 작성해야 하는 것이 대부분이고 (예를들면, 웹서버 공격자의 IP주소를 실시간으로 막는다던지 할떄), e는 백업용 스크립트 작성해서 cron 사용하면 될 것이고, f는 top, netstat 등 다양한 시스템 유틸리티 들을 이용하면 무리없습니다.
유사하겠지만, 개인적으로 사용하는 패키지는 -
syslog-ng(syslog라고 생각하면 됨), logcheck(swatch라고 생각하면 됨), chkrootkit, dar(백업), logrotate, 자체작성 실시간 ip 블로킹(ssh, web server 공격 등에 대한) 스크립트 등으로 구성해서 사용합니다.
이런 경우 문제점이라면, 즉시 대처해야 할 이벤트의 경우 email은 잘못되기 쉬운 통신수단이란 점입니다. 하지만, 즉시 대처해야 할 일은 사람의 관여없이 처리되어야 하는 것이 맞다고 보기 때문에 제 경우는 주로 사후처리용으로 이메일 보고만 받습니다.
전용 로그서버의 경우 가장 즉시 대처해야 하는 것은 로깅 기능이 항시 정상적으로 작동하는지 감시/복구 하는 것과 외부로 부터의 침입(혹은 침입시도)에 대한 대응 정도가 아닐까요? 그외에 다른 기능들은 액세서리 정도라고 보고 두가지에 중점을 둬야 할겁니다.
가장 중요한 것은 필터링 룰(대부분 regex)이라고 생각하는 데, 이게 잘못되면 엄청난 분량의 내용이 너무 자주 전달되므로 결국 무시하게 됩니다. 요는 정말 중요한 이벤트 위주로 최소한의 내용과 빈도로 사람이 직접 귀찮게 살펴보는 일을 줄이는 것이 로그감시에 키라고 생각합니다.
와우~ 실시간 Ip 블로킹에 대한 스크립트를 공개하실 의향은 없으신가요?? 히힛..
dar와 chkrootkit은 자동적으로 돌리고 있진 않고있는데 돌릴만할까요?
지금 이메일로 쌓이는 로그들도 '짱' 납니다..100여대의 머쉰에서 줄줄이 이메일이 날라오는것이란.......
crond로 자동화작업이 잘 돌아가고 있는지, 각 외부서비스별 접속시도들에 대한 내용,
sar를 통한 시스템자원에 대한 보고등을 받고 있지용...
로그백업은 잘 안하는 편이라 메일을 안지웁니다 흑....
내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.
내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.
그렇지 않아도 블로킹 프로그램은 (오픈소스화 하면 어떨까 해서) 현재 다시 손보고 있는 중입니다. 내부적으로 iptables 이용하며, 로그파일 감시하다가 룰 매치되면 (약간 복잡한 처리를 거쳐서) 블로킹 여부 결정하도록 되어있습니다.
한국정보보호협회인가로 자동 신고까지 할 수 있도록 되어있는데, 오픈소스화 하기 전에 그곳에 물어서 대량 신고 받을 준비 되어있는지 확인할 필요도 있습니다.
그동안은 주로 SSH 공격에 대해서만 돌려보았는데, 그동안 SSH 공격에 대한 여러가지 시험중 가장 효과가 좋더군요(이전에는 knocking 방법을 사용한 적이 있는데, 상당히 귀찮더군요). 설정에 따라 whois 질의 후, 해당 ISP에게도 보고할 수 있습니다(몇몇 ISP는 보고를 바탕으로 문제의 컴퓨터나 사용자를 처리하더군요. 이전까지는 실제로 그러리라고 생각지 않았는데).
한달 정도 후 오픈소스화 할까 하는 생각이 있긴 있는데, 이런 류의 프로그램이나 스크립트 이미 작성해서 사용중인 분들이 대부분이 아닐까 해서 확실한 결정은 아직 못내린 상탭니다.
로그라는 녀석은 보안과도 매우 밀접한 관계가 있기때문에 되도록이면 자기 혼자서 폐쇄적으로 확인해야 한다고
생각되는데요....웹으로 보시면 쉽게 보고 편하게 볼 수 있겠지만 접근성에 대해선 열려있게 되는것이죠...
위험요소를 한가지라도 포함하고 있는 것이라면 최대한 자제하는 것이 좋을것같습니다..( 너무 폐쇄적인가요? 그래요..전 ㅂㅌ입니다 :) )
내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.
내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.
syslog + swatch 사용시
syslog + swatch 사용시 무엇이 부족하고 어떠한 것(기능 등)을 원하나요?
음..
실시간으로 감시할수 있는 모니터링, 알람툴이나
많은 양의 로그 파일을 필터링 하는툴
로그정보를 DB화시키는툴
등등 제가 알지 못하는 기능에 대해서 알고 싶습니다. ^^
IT를 강하게 하는 프레임워크 Cobit 4.1
너무 방대한 로그를
너무 방대한 로그를 다루는 종합시스템은...어찌보면 로그의 의미를 넘어서버리는거 아닐까요?
로그는 말 그대로 로그이니까요..저는 syslog + swatch 조합으로면 충분하던데...
실시간 모니터링의 경우엔 snmp를 이용하면 syslog와 연동시킬 수 있는 부분이 있구요,
상용프로그램을 쓰면 더 강하게 들어갈 수 있겠지만.......
내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.
내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.
실시간 감시란 결국
실시간 감시란 결국 사람이 지켜봐야 할텐데, 쉽지 않은 일이죠. 몇몇 중요한 이벤트에 대해서만 '실시간 자동 대응'하도록 하는 것이 좋지 않을까 합니다(예: DOS 공격 대응, SSH 침입시도)
알람툴은 swatch에도 이메일로 알려주는 것 있지 않나요?
로그파일 필터링 툴은 사후조사시 필요한 툴을 말하는 건가요? 그게 아니라면 swatch류의 툴들이 하는 것이 필터링 하는 것 아닌가요?
왜 로그정보 DB화 해야 하나요? 대개의 경우 어플리케이션이 있어서 DB화 하는 것인데, 데이터가 충분히 많아지면 결국 로그파일이나 마찬가지로 되지 않을까 생각합니다.
개인적으로는 로그파일을 바탕으로 다음과 같은 일들을 할 수 있다면 충분치 않을까 합니다.
a. swatch류를 사용하여 가장 중요해 보이는 이벤트의 경우 바로 보고(email 등)
b. 매시간마다 덜 중요한 (그렇지만 감시가 필요한) 이벤트에 대한 보고(email 등)
c. 필요에 따라 로그파일을 이용한 어플리케이션 작성 (매우 긴급한 이벤트에 대해 자동 대처)
그외에 직접 관련은 없지만,
d. 매일 filesystem integration check, rootkit check
e. 매일 백업(6일 증가분 백업, 1일 풀 백업)
f. 매일 주요 자원에 대한 요약 보고서(메모리, 디스크사용, 방화벽 사항, 등등)
위에서 c, e, f를 제외하고는 대부분의 배포판에서 쉽게 설치가능한 걸로 압니다(우분투가 가장 쉬웠는데, 해당 패키지들을 설치하면 되었고, 일정기간 동안 필터링 룰을 email 최소로 받도록 수정하는 일만 필요하더군요). c는 직접 작성해야 하는 것이 대부분이고 (예를들면, 웹서버 공격자의 IP주소를 실시간으로 막는다던지 할떄), e는 백업용 스크립트 작성해서 cron 사용하면 될 것이고, f는 top, netstat 등 다양한 시스템 유틸리티 들을 이용하면 무리없습니다.
유사하겠지만, 개인적으로 사용하는 패키지는 -
syslog-ng(syslog라고 생각하면 됨), logcheck(swatch라고 생각하면 됨), chkrootkit, dar(백업), logrotate, 자체작성 실시간 ip 블로킹(ssh, web server 공격 등에 대한) 스크립트 등으로 구성해서 사용합니다.
이런 경우 문제점이라면, 즉시 대처해야 할 이벤트의 경우 email은 잘못되기 쉬운 통신수단이란 점입니다. 하지만, 즉시 대처해야 할 일은 사람의 관여없이 처리되어야 하는 것이 맞다고 보기 때문에 제 경우는 주로 사후처리용으로 이메일 보고만 받습니다.
전용 로그서버의 경우 가장 즉시 대처해야 하는 것은 로깅 기능이 항시 정상적으로 작동하는지 감시/복구 하는 것과 외부로 부터의 침입(혹은 침입시도)에 대한 대응 정도가 아닐까요? 그외에 다른 기능들은 액세서리 정도라고 보고 두가지에 중점을 둬야 할겁니다.
가장 중요한 것은 필터링 룰(대부분 regex)이라고 생각하는 데, 이게 잘못되면 엄청난 분량의 내용이 너무 자주 전달되므로 결국 무시하게 됩니다. 요는 정말 중요한 이벤트 위주로 최소한의 내용과 빈도로 사람이 직접 귀찮게 살펴보는 일을 줄이는 것이 로그감시에 키라고 생각합니다.
와우~ 실시간 Ip
와우~ 실시간 Ip 블로킹에 대한 스크립트를 공개하실 의향은 없으신가요?? 히힛..
dar와 chkrootkit은 자동적으로 돌리고 있진 않고있는데 돌릴만할까요?
지금 이메일로 쌓이는 로그들도 '짱' 납니다..100여대의 머쉰에서 줄줄이 이메일이 날라오는것이란.......
crond로 자동화작업이 잘 돌아가고 있는지, 각 외부서비스별 접속시도들에 대한 내용,
sar를 통한 시스템자원에 대한 보고등을 받고 있지용...
로그백업은 잘 안하는 편이라 메일을 안지웁니다 흑....
내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.
내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.
그렇지 않아도
그렇지 않아도 블로킹 프로그램은 (오픈소스화 하면 어떨까 해서) 현재 다시 손보고 있는 중입니다. 내부적으로 iptables 이용하며, 로그파일 감시하다가 룰 매치되면 (약간 복잡한 처리를 거쳐서) 블로킹 여부 결정하도록 되어있습니다.
한국정보보호협회인가로 자동 신고까지 할 수 있도록 되어있는데, 오픈소스화 하기 전에 그곳에 물어서 대량 신고 받을 준비 되어있는지 확인할 필요도 있습니다.
그동안은 주로 SSH 공격에 대해서만 돌려보았는데, 그동안 SSH 공격에 대한 여러가지 시험중 가장 효과가 좋더군요(이전에는 knocking 방법을 사용한 적이 있는데, 상당히 귀찮더군요). 설정에 따라 whois 질의 후, 해당 ISP에게도 보고할 수 있습니다(몇몇 ISP는 보고를 바탕으로 문제의 컴퓨터나 사용자를 처리하더군요. 이전까지는 실제로 그러리라고 생각지 않았는데).
한달 정도 후 오픈소스화 할까 하는 생각이 있긴 있는데, 이런 류의 프로그램이나 스크립트 이미 작성해서 사용중인 분들이 대부분이 아닐까 해서 확실한 결정은 아직 못내린 상탭니다.
오호....방화벽 관련
오호....방화벽 관련 룰 및 스크립트등은 자기가 이미 쓰고있는것 이외에도 여러가지 참조해서 쓰면 더 이득이라고 생각합니다.
빨리 오픈소스화 해주세요! :)
PS 그런데...tcpwrapper로 ssh접속 가능 아이디와 아이피를 지정해 놓아도 노킹을 사용해야할 만큼 위험성이 있습니까?
지금까지 tcpwrapper로 묶어놓은 경우엔 ssh접속시도는 전혀 보질 못해서....
내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.
내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.
감사합니다.
로그서버의 나아갈 길?에 대해서 대강 감이 오는군요
메일로 전달받는 기능은 이미 사용하고 있는데
내용이 워낙 방대해서 대충보거나 지워버리게 되더라고요 ^^;
역시 필터링에 대한 룰이 관건일것 같습니다.
그래서 웹에서 확인하는 방법이 가장 확실하지 않나 하고 생각하고 있습니다.
그래서 db화가 필요하다고 생각했고요
mrtg와 같이 전반적인 시스템 모니터링과 같이 웹에서 확인하는 것이 어떨까 하고 생각했습니다.
보는 화면이 좋아야 모니터링도 열심히 하게 되더군요..ㅎㅎ
swatch를 좀더 연마해야 겠습니다.
그런데 syslog, swatch, sar
위 3가지 말고 다른 툴은 없을까요?
관련 방화벽 관련 스크립트의 공개도 기대해 봅니다. ^^/
IT를 강하게 하는 프레임워크 Cobit 4.1
로그라는 녀석은
로그라는 녀석은 보안과도 매우 밀접한 관계가 있기때문에 되도록이면 자기 혼자서 폐쇄적으로 확인해야 한다고
생각되는데요....웹으로 보시면 쉽게 보고 편하게 볼 수 있겠지만 접근성에 대해선 열려있게 되는것이죠...
위험요소를 한가지라도 포함하고 있는 것이라면 최대한 자제하는 것이 좋을것같습니다..( 너무 폐쇄적인가요? 그래요..전 ㅂㅌ입니다 :) )
내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.
내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.
댓글 달기