보안 솔루션을 설치하는 것만큼 이를 운영하는 사람을 잘 훈련시키는 것도 중요하다.
샤대 중앙전산원은 보안 장비에 돈도 많이 쓰고 노력도 많이 하는 것 같은데, 도입해놓은 솔루션에 대해 썩 잘 알고 있다는 느낌이 안 든다.. UI가 쉽게 알아보기 어려운 문제가 있거나.. 교육이 잘 안 됐거나.. 둘 중 하나일텐데..
가령 스팸 차단 로그가 관제 화면에 막 올라온다고 해보자. 아래 사항들을 정확하게 알고 있지 않으면 서버가 뚫렸거나 릴레이를 허용하고 있다고 착각할 수 있다..
그리고 보안팀으로부터 억울하게 악의 근원(..)으로 몰리는 경우 일차적으로 설정을 확인하고, 이차적으로 패킷 덤프 등을 확인하면 되겠지만.. 역시 일반인들에게는 어려운 일이 되겠다..
참고로 가장 쉬운 스팸 판정 방식은 보내는 메일 주소의 도메인에서 사용하는 IP와 현재 접속한 메일 클라이언트의 IP가 일치하는지 확인하는 것으로, 패킷 덤프를 해보면 메일 서버에서 보내는 사람, 받는 사람을 전송받은 직후 DNS 쿼리가 나가는 것을 확인할 수 있다..
샤대 중앙전산원은 보안 장비에 돈도 많이 쓰고 노력도 많이 하는 것 같은데, 도입해놓은 솔루션에 대해 썩 잘 알고 있다는 느낌이 안 든다.. UI가 쉽게 알아보기 어려운 문제가 있거나.. 교육이 잘 안 됐거나.. 둘 중 하나일텐데..
가령 스팸 차단 로그가 관제 화면에 막 올라온다고 해보자. 아래 사항들을 정확하게 알고 있지 않으면 서버가 뚫렸거나 릴레이를 허용하고 있다고 착각할 수 있다..
- 차단 시점과 방식: SMTP 통신이 완전히 이루어진다고 하더라도 어차피 메일 서버가 릴레이를 차단하거나 스팸을 차단하도록 설정되어 있는 경우가 많다. 그런데 보안 장비는 스팸 메일 주소만 보고 TCP RST 패킷을 날려서 세션을 끊은 다음 로그를 발생시키게 되므로, 관제 화면을 보고 이를 단순히 받아들이면 원래 메일 릴레이를 차단하고 있는데도 서버가 릴레이를 허용하고 있다고 착각하게 될 수 있다. 허용하고 있는 것과 허용하고 있을 수 있다는 것은 다르기 때문에 잘 구분을 해야 된다.
- 차단 방향: 들어오는 스팸인지 나가는 스팸인지 알아야 서버가 실제로 취약한지 아닌지 명확하게 구분할 수 있다. 릴레이를 하고 있다면 분명히 해당 서버에서 다른 메일 서버로 접속해서 메일을 전송하게 될 것이다.
그리고 보안팀으로부터 억울하게 악의 근원(..)으로 몰리는 경우 일차적으로 설정을 확인하고, 이차적으로 패킷 덤프 등을 확인하면 되겠지만.. 역시 일반인들에게는 어려운 일이 되겠다..
참고로 가장 쉬운 스팸 판정 방식은 보내는 메일 주소의 도메인에서 사용하는 IP와 현재 접속한 메일 클라이언트의 IP가 일치하는지 확인하는 것으로, 패킷 덤프를 해보면 메일 서버에서 보내는 사람, 받는 사람을 전송받은 직후 DNS 쿼리가 나가는 것을 확인할 수 있다..




덧글