Security Note

SMTPS(Simple Mail Transfer Protocol Secure)는 전자메일을 보내고 받을 때 사용되는 프로토콜인 SMTP의 보안 버전이다. HTTPS와 마찬가지로 송수신되는 데이터를 암호화하여 전자메일 통신의 보안을 강화할 수 있다.

SMTPS도 HTTPS와 같이 TLS 암호화를 사용하기 때문에 SMTPS 서버 구축 시 SSL 인증서 발급을 필요로 한다. SSL 인증서 발급에 대해서는 ‘서비스식별: HTTPS (443)’를 참고하여 진행할 수 있다.

SMTPS 서버 구축을 위해서는 기본적인 메일 서버를 구축해야 한다. 이를 위해 ‘Ubuntu 20.04’ 운영체제를 사용하였으며 서비스는 ‘Postfix’를 사용했다. 부가적으로 ‘Dovecot, MySQL’ 서비스도 함께 사용하였다. 구축 과정이 상당히 길기 때문에 이에 대해 적는 대신 아래 링크를 참고하면 된다.

메일 서버 구축이 끝나면 mxtoolbox.com/SuperTool.aspx 라는 링크에서 구축한 메일서버에 대한 테스트를 간단히 진행할 수 있다.

이렇게 서버 구축을 하고 나면 기본적인 SMTP 메일 서버로의 기능을 사용할 수 있다. 그러나 이 상태에서 서버의 네트워크 연결 상태를 확인하면 465번 포트는 활성화되어 있지 않을 것이다. Postfix에서는 465번 포트를 활성화시키기 위해 별도로 설정 파일을 수정해야 한다. 이에 대한 과정도 참고할 수 있도록 링크를 남겨둔다. 이 과정까지 마치면 비로소 465번 포트를 이용하여 SMTPS 통신을 수행할 수 있게 된다.

통신 테스트를 위해 python의 ‘smtplib’ 라이브러리를 사용하여 간단한 테스트 코드를 작성하였다. 이 코드는 SSL을 사용하여 SMTP 연결을 시도한다. 연결 시도 시 SSL 프로토콜을 필요로 하기 때문에 SMTP 서버이더라도 SMTPS 통신을 사용하지 않을 경우 SMTPS 서비스로 판단하지 않는다.

import smtplib

def test_SMTPS(mail_server):
	result = ''
    try:
    	smtp = smtplib.SMTP_SSL(mail_server, 465)
        smtp.quit()
    except:
    	result = 'no service'
    else:
    	result = 'on service'

if __name__ == "__main__":
	mail_server = '<mail server domain or IP address>'
    print(test_SMTPS(mail_server))

이러한 과정을 네트워크 패킷 레벨에서 확인한 결과는 다음과 같다. 

연결 성공 시 TCP 3-way handshake에 성공하며 그 이후 암호화 통신을 사용하여 데이터를 교환한다. [그림 1] 그러나 연결에 실패할 경우 서버로부터 TCP RST 패킷을 반환 받는다. [그림 2]

HTTPS(Hypertext Transfer Protocol Secure)는 HTTP의 보안 버전으로, SSL/TLS 프로토콜을 사용하여 데이터를 암호화 후 전송하는 방식을 사용한다. 이를 통해 제3자가 패킷을 감청하더라도 데이터를 확인하기 어렵게 하여 안전한 통신 채널을 설정할 수 있다.

HTTPS의 테스트를 위해서는 SSL 인증서를 발급받아야 한다. 인증서를 발급받기 위해서는 사전에 도메인 발급이 필요하며 발급된 도메인이 있을 경우 곧바로 SSL 인증서 발급 절차를 거치면 된다. 테스트를 위해 사용하는 임시 인증서 발급을 목적으로 하기 때문에 무료로 인증서 발급이 가능한 ‘Let’s Encrypt(LE)’라는 인증기관의 인증서를 사용하였다.

다음은 인증서 발급에 사용된 command line 명령어이다. 이 과정에서 추가로 ‘openssl’과 ‘certbot’ 라이브러리가 사용되었다. 서버 구성 시 사용한 운영체제는 ‘Ubuntu 20.04’ 버전이다.

$ openssl genrsa -des3 -out server.key 2048
$ openssl rsa -in server.key -out server.key.insecure
$ openssl rsq -new -key server.key -out server.csr
$ mv server.key server.key.secure
$ mv server.key.insecure server.key

$ sudo git clone https://github.com/certbot/certbot /opt/cerbot && cd /opt/cerbot
$ sudo snap install certbot --classic
$ sudo certbot certonly -d <domain>

인증서 발급 후 이를 테스트하고자 하는 웹서버에 적용하면 된다. 여기서는 ‘Apache’ 웹서버를 사용하였으며 Apache 웹서버에 SSL 인증서를 등록하는 과정은 [참고 문헌 1]을 참고하여 진행할 수 있다.

테스트 시 클라이언트 프로그램으로는 ‘curl’ 명령어를 사용하였다. 이 때 -k 옵션을 사용할 경우 https 프로토콜을 이용하여 연결을 맺을 수 있다.

$ curl -k https://yutaa.kr

서버에 https가 서비스되고 있을 경우 응답 값으로는 해당 url에서 서비스되고 있는 웹페이지를 받을 수 있다. [그림 1] 그러나 만약 서비스되고 있지 않을 경우에는 [그림 2]와 같은 응답을 확인할 수 있다.

이러한 과정을 네트워크 패킷 레벨에서 확인하면 다음과 같다.

서버에서 https가 서비스되고 있을 때에는 TCP 3-way handshake 후 암호화된 패킷 형태로 데이터를 교환하는 것을 확인할 수 있다. [그림 3] 그러나 https가 서비스되고 있지 않을 때에는 TCP SYN 패킷이 전송된 이후 TCP RST 응답이 오는 것을 확인할 수 있다. [그림 4]

LDAP(Lightweight Directory Access Protocol)은 네트워크 상에서 directory 서비스 내 데이터에 접근하고 관리할 수 있도록 하기 위한 프로토콜이다. 클라이언트와 서버 구조로 통신하며, 이를 테스트하기 위해 간단한 ldap 서버를 구축하였다.

서버는 MacOS 환경에서 OpenLDAP을 사용하여 구축하였다. 구축 과정은 아래 링크를 참고하여 진행할 수 있다.

서버 구축 후에는 아래 명령어를 이용하여 ldap 서비스를 구동할 수 있다.

$ sudo /usr/libexec/slapd -h ldap://localhost -d 50

테스트를 위한 클라이언트 프로그램으로는 ‘ldapsearch’를 이용하였으며, 이 때 사용한 명령어는 다음과 같다.

$ ldapsearch -x -D "uid=user1,ou=group-01,dc=test,dc=com" -H ldap://localhost -b "ou=group-01,dc=test,dc=com" -w asdf

명령어 구성 시 실제 접속에 필요한 도메인 정보 등은 무시한 채 임의의 데이터를 사용했다. 이는 현재 진행하는 작업이 서비스 접속 성공이 아닌 서비스 식별이기 때문에 이 부분에 초점을 맞추기 위함이다. 따라서 인증 실패 응답이 올 경우에도 해당 포트에서 서비스가 제공되고 있는 것으로 판단하였다. 실제로 포트가 열려있으며, 해당 포트에서 ldap 서비스가 제공 중일 경우 아래와 같이 인증 실패 응답을 확인할 수 있다.

ldap_bind: Invalid credentials (49)

만약 해당 포트에서 ldap이 서비스되고 있지 않을 경우에는 아래와 같은 응답을 확인할 수 있다.

ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

이러한 과정을 네트워크 패킷 레벨에서 확인하면 다음과 같다.

서버에서 ldap이 서비스되고 있을 때에는 TCP 3-way handshake 후 LDAP 형태로 메시지를 교환한다. 그러나 ldap이 서비스되고 있지 않을 때에는 ldapsearch의 TCP SYN 패킷 이후 ICMP 형태로 Destination unreachable 응답이 오는 것을 확인할 수 있다.

패커에 대해 공부하는 과정에서 정리한 자료입니다.

자료에는 아래 내용이 기록되어 있습니다.

• 데이터 압축
  • 압축 기법의 유형
  • 패커의 유형

• UPX packer 실습
  • Packing
  • Unpacking
    • OEP vs. EP
    • 일반적인 실행 압축 해제 매커니즘
    • Tracing
    • UPX 패커의 특징

리버싱을 공부하는 과정에서 개념 정리하고, 실습한 내용 공유합니다.

아래 내용이 기록되어 있습니다.

• PE File format
• RVA to RAW
• IAT, EAT

정보 보안 분야를 공부하고 있는 학생으로서 뉴스나 공격 동향 등을 꾸준하게 보는 것은 정말 중요한 것 같다.

그렇기 때문에 이러한 생각을 실행에 옮기고자 오픈채팅방도 들어가고 Feedly와 같은 서비스도 활용해보고 하였다. 그러나 이러한 방법들은 모두 처음에만 잠깐 확인하고 이후에는 알림만 쌓여가게 되었다..

이러한 상황임에도 어떻게든 꾸준하게 확인하고자 직접 구독할 자료를 선택하여 이를 한 곳에 수집할 수 있는 시스템을 구축해 보았다.

시스템 구축에는 Slack이라는 메신저 서비스를 사용하였다. Slack은 직장인이라면 대부분 사용해본 적이 있는 메신저일 것이다. 이 서비스는 워크스페이스 내에 RSS 피드 설정이 가능하여 쉽게 원하는 서비스를 구독할 수 있다. 또한 트위터 연동 시 사용하고자 하는 IFTTT에서도  Output channel로 Slack을 지원하여 더욱 쉽게 연동할 수 있다.

RSS 구독 등록

기본적으로 슬랙에 RSS 주소를 이용하여 피드 구독하는 방법은 다음과 같다.

구독 글을 수집할 채널에 접속 후 입력란에 다음과 같은 형식으로 feed 명령어를 입력한다.

/feed <RSS link>

이렇게 하면 이후부터 업로드되는 피드들이 자동으로 슬랙의 해당 채널에도 게시된다.

Github branch commit 구독 등록

이번엔 구독하고자 하는 github repository가 있을 때 특정 브랜치를 등록하는 방법이다.

RSS 등록할 때와 마찬가지로 feed 명령어를 사용한다. 이중 RSS link 위치에 다음과 같은 형태로 url을 작성하여 입력하면 된다.

/feed https://github.com/{username}/{repository}/commits/{branch name}.atom

나 경우 다음과 같이 github repository의 master branch commit 업데이트 이력을 구독해두었다.

Twitter 구독 등록

Twitter의 트윗 내역을 정기적으로 받아보려면 별도의 플랫폼을 사용해야 한다. Twitter에는 직접적으로 제공해주는 RSS url이 없기 때문이다. 이를 위해 여기서는 IFTTT를 사용하였다.

IFTTT는 다양한 앱 서비스들을 자동화하여 사용할 수 있게 해주는 서비스이다.

회원 가입 후 우측 상단의 Create를 누르면 다음과 같은 페이지를 볼 수 있다.

여기서 보이는 것처럼 기본적으로 이 서비스의 동작은,
=> 특정 애플리케이션이 특정 조건을 만족할 경우, 어떤 애플리케이션의 이러한 동작을 수행시키겠다.
로 이루어진다.

이를 우리가 해야할 일에 대입하면,
=> "Twitter"에 "새 트윗이 생길" 경우, "Slack"에 "이 트윗의 내용과 링크를 게시"해줘
가 된다.

이를 위해 먼저 If This를 누른다.

많은 애플리케이션 중 Twitter를 선택한다.

그럼 이 Twitter가 어떤 조건을 만족할 경우에 대한 이벤트 설정을 할 것인지 고를 수 있는 메뉴를 선택한다. 원하는 조건에 따라 선택하면 되겠지만, 여기서 나는 특정 인물의 트윗을 구독하고자 하는 것이기 때문에 이 중 "New tweet by a specific user"를 선택한다. twitter의 경우 최근 트위터 정책이 변경됨에 따라 이를 스크랩하는 것이 유료버전으로 바뀐 것 같다. 물론 나는 이를 위해 프로 구독을 했다..ㅠ

New tweet by a specific user를 선택하게 되면 자신의 트위터 계정 입력 후 스크랩 하고자 하는 사용자의 username을 입력하도록 한다. 

이렇게 조건 설정을 한 후 조건 충족 시 수행할 행동을 정하기 위해 Then That을 누른다. 

Slack을 선택하고,

채널에 게시(Post to channel)를 선택한다.

그 후 아래와 같은 화면을 볼 수 있는데, 여기서 Slack 계정을 선택하고, 게시하고자 하는 채널을 선택하면 된다. 일반적인 슬랙 채널에 자동 게시를 원하면 Public Channels를 선택한 후 게시할 채널을 선택한다. 선택하였으면 이후는 게시되길 원하는 형식에 따라 알아서 수정 후 생성까지 마치면 된다.

여기까지 한 후 Finish를 하면 자동화를 마친 것이다. 곧 소식이 있을 때 알아서 Slack에 게시가 될 것이다.

다만 IFTTT Pro 버전은 자동화 파이프를 20개까지만 만들 수 있어서, 이 제한을 풀려면 Pro+를 구독해야하는데 연 8만원 가량 되길래 아직은 Pro로 버티는 중이다ㅋㅋ.. 나중에 더 필요하게 되면 업그레이드 하던지 하려고 한다.

이러한 방법을 사용하여 카테고리별로 소식과 자료들을 수집하고 확인하는 중이다. 확실히 slack은 알림이 매번 와서 잊지 않고 확인하게 만드는게 좋은 것 같다. 수집한 데이터를 계속 보관하고 싶다면 slack도 유료버전으로 업그레이드 해야 한다. 그러나 나는 만들다 보니 함께 공부하는 동아리 친구들과 공유하고 싶다는 생각이 들어 워크 스페이스에 친구들을 초대하였고, 그러고 나니 워크 스페이스를 사용하는 사람수가 많아졌다ㅋㅋㅋ 이렇게 되면 사람수에 비례하여 월정액이 커지기 때문에 이를 감당할 자신이 없어 현재까지는 90일 제한으로 사용하고 있다. 그렇기에 일단 플랜 업그레이드 하는 것은 추후에 논의해봐야할 것 같고, 당분간은 뉴스 챙기는 것에 의의를 두고자 한다!