kkkaa

오늘 퇴근시간이 다 되어서 갑자기 앞에 아이디만 변경해서 수십통의 메일이 수신된다는 문의를 받았다

평소처럼 스팸메일 솔루션에 해당 도메인을 예외처리 하려고 하던 중  발신인을 보니 모두 IP 예외처리가 되있는게 아닌가?

오잉??? 하고 보니 사내 IP를 가진 Sendmail 서버가 발송한 메일이었다.......

분명히 내용은 사내 메일내용이 아니고 발신자도 아니었다. 

원인은?????

우선

메일서버에서 내부로 들어오는 메일에 대해서 내 도메인이 아닌 메일이 들어왔을 때 메일서버는 두가지 방식을 취한다.

1. 그냥 씹는다.

2. 그 잘못 들어온 메일의 도메인 주인에게 넘겨준다 ( Relay 한다라고 한다. )

결국 원인은 

Sendmail 서버로 무작위 하게 누군가가 스팸성 메일을 보냈는데 이 중 하나 걸린게 우리 내부 도메인인 것이었다.

( 보안상 메일 서버에는 보통 릴레이 설정을 해두지 않는다. 다만, 사내 도메인만 Relay 설정을 해둔다. ) 

결국은 운좋게 보낸 메일 중 모두가 씹히?고, 내부 도메인 하나가 걸려서 사내 도메인이네 하고 Relay 설정되있어서 그렇게 

내부 Exchange 서버로 전달을 한것이었다.

정상 경로

외부 -> Exchange -> SpamMail Server ( 스팸?? - 불통!! / 정상? - 통! ) -> 사내 메일 직원 에게로

비정상 경로

외부 -> SendMail Server -> Exchange -> SpamMail Server ( 응? 사내 IP? - 내부 IP 잖아 그냥 예외~~ 즉시 통! ) -> 사내 메일 내부 직원 에게로

MX레코드란? ( Mail Exchange record )

특정 도메인에 대한 메일을 수신하는 메일 서버를 지정하는 레코드

#! : 명령의 시작을 알림

/bin/bash : bash 스크립트의 시작.

ping -c 1 아이피 : 핑을 한번만 테스트 / ping -c 1 -w 1 아이피 : 핑테스트 응답시간 줄이기.

주의!  if [ "$?" == "0" ]; then " ' [ ' 와 ' " '  등... 각 문자 사이의 띄어쓰기 주의. 띄어쓰기 안되있을 경우 에러. 

 -> 바로 전 명령어의 리턴값을 받아오는 변수 "$?", 결과가 0 일 경우 ok / 결과가 1 일 경우 not ok 를 출력.

 -> 명령의 결과 출력은 /test/pingresult 로 볼 수 있다.  미리 touch pingresult 로 파일을 만들어 놔야 한다.

참고 블로그 : http://hyunmini.tistory.com/28

개요

• 통신 구간 암호화를 위해 많이 사용하는 OpenSSL 라이브러리에서 서버에 저장된 중요 메모리 데이터가 노출되는 HeartBleed라고 명명된 심각한 버그가 발견되어 시스템 및 소프트웨어에 대한 신속한 취약점 조치를 권고

취약점 정보

• 시스템 메모리 정보 노출 취약점
• CVE-2014-0160 (2014.04.07.)
• 영향 받는 버전
• OpenSSL 1.0.1 ~ OpenSSL 1.0.1f
• OpenSSL 1.0.2-beta, OpenSSL 1.0.2-beta1
• 영향 받는 시스템 및 소프트웨어
• 취약한 OpenSSL 버전이 탑재된 시스템
• 서버(웹서버, VPN 서버 등), 네트워크 장비, 모바일 단말 등 다양한 시스템이 해당될 수 있음
• 취약한 OpenSSL 라이브러리가 내장된 소프트웨어 제품
• 영향 받지 않는 소프트웨어
• OpenSSL 0.9.x 대 버전
• OpenSSL 1.0.0 대 버전
• OpenSSL 1.0.1g

취약점 내용

• OpenSSL 암호화 라이브러리의 하트비트(Heartbeat)라는 확장 모듈에서 클라이언트 요청 메시지를 처리할 때 데이터 길이 검증을 수행하지 않아 시스템 메모리에 저장된 64KB 크기의 데이터를 외부에서 아무런 제한 없이 탈취할 수 있는 취약점
• 하트비트 : 클라이언트와 서버 간의 연결 상태 체크를 위한 OpenSSL 확장 모듈

공격 형태

• 본 취약점은 원격에서 발생 가능한 취약점으로, 공격자는 메시지 길이 정보가 변조된 HeartBeat Request 패킷을 취약한 OpenSSL 버전을  사용하는 서버에 전송할 경우, 정해진 버퍼 밖의 데이터를 공격자에게 전송하게 되어 시스템 메모리에 저장된 개인정보 및 인증 정보 등을 탈취할 수 있음

   

  

                         ※ 노출 가능한 정보: SSL 서버 비밀키, 세션키, 쿠키  및 개인정보(ID/PW, 이메일주소 등) 등
                         ※ 노출되는 정보는 서비스 환경에 따라 다를 수 있음

•  

   

•  

  

  • OpenSSL 하트비트(HeartBeat) 활성화 여부 확인
  • 취약한 버전의 OpenSSL을 사용하는 시스템 중 HeartBeat 기능 사용 여부 확인 방법 (단, 패치된 최신 버전(1.0.1g)은 활성화 여부를 확인할 필요 없음)
  • 취약한 버전이 HeartBeat를 사용하지 않은 경우 취약점에 영향 받지 않음   

  

                         ※ 명령어 실행 방법 :　domain.com에 점검 대상 URL 정보로 수정

                         ※ HeartBeat 기능이 활성화되어 있는 경우 heartbeat 문자열이 검색됨

   

•  

  

                         ※ HeartBeat 기능이 활성화되지 않은 경우 heartbeat 문자열이 검색되지 않음

  

  • OpenSSL에서 사용하는 소스코드 확인
  • OpenSSL 취약점이 발생된 소스코드를 열람하여 아래와 같이 보안 패치 코드가 추가되었는지 확인을 통해 취약 여부 판별
  • 패치된 버전에서는 아래와 같이 사용자 요청 메시지에 대한 길이를 검사하도록 코드가 추가됨

  

                          ※ 참고 사이트 : http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db902

  • KISA(한국인터넷진흥원)를 통한 취약점 여부 확인
  • 자체적인 확인이 어려울 경우 KISA 전문가로부터 점검을 요청

   

•  

   

•  

   

•  

  출처 :  http://m.krcert.or.kr/file/view.jsp?type=1&btno=20884

DLP 보안을 위한 Snort Rule 설정 

Snort Install

 초기 방화벽 개념

• 패킷필터링 방화벽
• 애플리케이션 게이트웨이 방화벽

이 방식은 방화벽 기능을 수행하지 못하거나 속도저하 문제의 단점을 지니고 있다.

이 단점을 극복하고자 장점만 가지고 구현한 새로운 개념이 바로 Stateful Inpection 방식

이스라엘의 방화벽 업체 '체크포인트'사가 최초로 사용한 용어로,

네트워크 계층(3계층)에서 패킷을 처리하면서 프로토콜의 상태정보 테이블을 유지하여

프로토콜 특성에 따른 변화를 동적으로 대응해 주는 기능으로 최근 방화벽 시스템에서 채용되어 사용되고 있다.

이 기술의 장점은 하나의 서비스에 대한 접근규칙(Access Rule)을 생성할 때 마다

되돌아가는 flow에 대한 또 다른 규칙을 생성할 필요가 없다는 것이다.

패킷 필터링 방식의 방화벽의 경우

내부 서버에 대한 허용을 위해 인바운드 규칙을 설정하였다면 나가는 아웃바운드 규칙도 설정해주어야 한다.

하지만

이 기능이 채용된 방화벽에서는 관리자가 인바운드 규칙을 생성하였다면 동적으로 아웃바운그 규칙을 자동생성한다.

단점으로는 데이터 내부에 악의적인 정보를 포함할 수 있는 프로토콜에 대한 대응은 어렵다는 것이다.

Packet filtering 방화벽은 Stateful Inspection 방화벽에 비해 다음과 같은 단점이 존재한다.

첫째, 하나의 서비스를 허용하기 위해서는 패킷이 들어오는 방향과 나가는 방향에 대한 접근규칙을 정의해야 하므로 두 개 이상의 Rule 설정이 필요하다. 이는 단순히 한두 번의 일을 더하게 되므로 귀찮은 일일 뿐만 아니라 여러 개 규칙을 관리하면서 발생할 수 있는 관리자의 실수 등으로 인해 보안상의허점이 나타날 수도 있다.

둘째, 가변적인 통신포트(Dynamic Port)를 사용하는 서비스나 FTP처럼 다중 포트를 사용하는 서비스를 처리하기가 매우 어렵습니다. 때문에 Packet Filtering 방화벽을 사용하게 되면, 명시적으로 차단하는 서비스에 대해서만 차단하고 나머지 서비스를 모두 허용하는 정책을 적용할 수 밖에 없다.

이에 비하여 Statful Inspection 방화벽에서는 클라이언트의 요청 정보를 내부에 저장하고 있다가 되돌아가는 통신에 대하여 그 유효성을 검증한 후 필요하다면 스스로 임시적인 정책을 순간적으로 만들어 서버로부터 클라이언트로의 통신을 허용해 준다. 따라서 가변 포트를 사용하는 서비스나 다중 포트를 사용하는 서비스에 효과적으로 대응할 수 있다.