매일매일 중국에게 해킹 시도 당하는 블로그
route로 공격시도를 하는 ip를 임시 차단을 하여도 시간이 지나서 다시 공격을 시도하는 경우가 꽤 자주 있다.
이러한 상황에는 iptables를 이용하여 차단하면 직접 해제하기 전까지 영구적으로 차단 할 수 있다.
# iptables -L // 차단 리스트 출력
# iptables -A INPUT -s xxx.xxx.xxx.xxx -j DROP // ip 차단하기
# iptables -A INPUT -s xxx.xxx.xxx.xxx -j ACCEPT // ip 차단 해제
# iptables -F // 전체 차단 해제
iptables는 route 명령어와는 다르게 즉시 적용이 되지 않고 서비스를 재시작 하여만 차단이 적용됨으로 차단 후 서비스를 반드시 재시작 해야한다.
# services iptables restart그 다음에 iptables -l 를 치면 제대로 적용이 된 것을 확인할 수 있다.
기계번역된 문제내용을 정리하자면 문제파일(사진)안에 인코딩 된 메시지가 있고 찾는 힌트는 2개의 NULL 바이트라고한다.
winhex를 실행시키고 ctrl + alt + x로 Hex 검색창을 띄운 후 NULL값 (00 00)을 검색 후 f3로 넘기면서 값을 살펴보던 중 00 00 으로 둘러 쌓인 문자열을 발견 하였다.
2진수이거나 모스부호 일 것 같은 느낌이 들었다. 하지만 모스부호라면 중간중간에 구별이 가능하게 띄어쓰기가 있어나 표시가 되어있는데 그런 흔적들이 없어서 아닌 것 같았다.
16을 0 17을 1로 치환해서 2진수로 변환 하였다
변환된 값을 2진 변환기에 넣으면 쉽게 flag가 나올 줄 알았는데 에러가 발생하였다.
문자열이 잘못 되었나 8자리씩 끊어서 보니 어디서 하나가 부족한 상태였다…
| 00111000 01100110 01101110 11010000 11000010 11100110 0110110 |
각 줄 앞에 0과 1을 하나씩 넣어보면서 때려 맞추기를 하고 있었는데 2번째 줄에 0을 추가하고 줄을 다시 정리하니 정상적으로 변환이 되는 것을 확인하였다.
플래그 값을 넣으면 클리어와 동시에 아래와 같이 다음 문제를 풀 수 있는 버튼이 만들어진다!
문제 내용을 요약하자면 피자를 제조하는 것이 중범죄인 어떤한 주에서 피자를 제조한 혐의로 체포된 용의자가 가진 USB를 회수하였고 해당 USB안에서 피자를 만들었다는 증거가 있는지 찾아내는 문제인 것 같다.
문제파일을 받고 압축을 풀면 8개의 파일을 확인 할 수 있다.
8개의 파일들의 용량을 각각 확인해보니 shh.jpg 파일이 약 10MB로 해상도에 비해 비정상적으로 커서 수상해 보였다.
shh.jpg 파일을 winhex 열어서 있을거 같은 파일 형식을 선택 후에 카빙을 진행하였다.
카빙 한 파일들의 용량 총합이 36.6KB으로 제대로 카빙이 되지 않은 것으로 추정된다. 직접 수동으로 파일을 찾아보기로 하였다.
우선 카빙된 000001.jpg 파일의 영역을 잘라내려고 하니 jpg파일의 푸터 뒤에 rar 압축파일의 시그니처와 비슷해 보이는 문자열을 발견하게 되었다.
000001.jpg 의 영역을 지운 후 5A 를 52로 수정한 후 7zip으로 압축 풀기를 시도 하였다.
암호를 입력하라는 창이 뜨는데 앞에서 카빙할때 나온 000002.jpg 파일에 적혀있는 GL0zMe를 입력하니 암호가 정상적으로 해제되었다.
압축 해제된 파일들을 보니 수많은 피자 사진들 중에서 한개의 txt파일 보이는데 이 파일을 열면 이번 문제의 flag가 적혀있다.
문제 내용을 정리하자면 어떤 의뢰인이 다른 사람과 바람을 피운 혐의로 기소가 되었다고 한다.
다른 여성과 같이 찍은 사진이 증거로 제출되었는데 의뢰인은 해당사진은 셀카였으며 해당 사진이 합성되었다고 주장하는 중이다.
해당사진이 합성사진인 것을 증명하면 되는 문제로 추정된다.
문제에는 저렇게 쓰여 있어도 스테가노그래피일 가능성이 있어서 우선 스테가노그래피인지 확인해보았다.
gimp를 이용하여 색상 레벨도 바꿔보고 채도도 바꾸어 봤는데 플래그는 보이지 않았다.
푸터 뒤에 문자로 존재하는 경우도 종종 있기에 winhex로 바이너리 값을 보기로 하였다.
숨겨진 메시지는 발견하지 못하였으나 해당 사진이 어도비 포토샵을 사용한 흔적은 발견 할 수 있었다.
하지만 저 문자열만으로는 해당 사진이 포토샵으로 단순 보정을 했는지, 합성을 했는지 할 수는 없다.
어떻게 하면 합성 사진으로 증명 할 수 있을지 구글링을 하던 중 jpg와 같은 손실 압축 사진 파일들은 ELA(Error Level Analysis) 분석을 통하여 사진의 합성 유무를 확인 할 수 있다는 것을 알게 되었다.
ELA(Error Level Analysis) 분석으로 압축수준이 다른 정도를 확인 할 수 있는데 압축수준이 특정 한곳만 지나치게 다른 경우에는 합성 사진일 가능성이 높다.
ELA 분석을 해주는 소프트웨어도 있고 웹사이트도 있는데 필자는 https://29a.ch/photo-forensics/#error-level-analysis 에서 진행하였다.
ELA 분석을 한 결과 여성쪽만 균일하지 않게 노이즈가 발생하는 것을 확인 할 수 있다.
이것으로 해당 사진이 합성 사진임을 증명 할 수 있게 되었고 좌상단에 flag로 추정되는 문자열도 얻을 수 있다.
플래그 값이 ELA4LIFE!! 인지 ELAALIFE!! 인지 해상도가 낮아 구별이 안되는 작은 이슈가 있는데, 그냥 둘다 제출해보니 ELA4LIFE!!가 플래그였다.
기계번역 된 문장들을 정리해보자면 최근에 전 직원과 마찰이 있었는데 그가 USB에 있는 파일을 날려버렸고 파일 복구를 하기 위해 USB 이미징을 진행한듯 하다.
이미징 파일을 받아서 USB안에 있는 암호파일을 구하면 되는 문제인 것으로 추정된다.
첨부파일을 받고 본격적으로 문제를 풀기전에 이미지 파일이 제대로 받아졌는지 무결성 검사를 진행한다.
해쉬값이 문제에 적힌 값과 같아서 바로 문제 풀이에 들어갔다.
압축을 풀면 image.dd 파일이 나오는데 해당 파일을 ftk imager로 불러와준다.
.Trash-1000 폴더(휴지통 폴더) 안으로 들어간 후 expunged 폴더로 들어가면 삭제된 파일 리스트들이 나온다.
파일을 둘러보면 고양이 사진, 산맥 사진 등등 평범한 사진들이 대부분인데 딱 한폴더가 수상하게 선정성(?)이 높은 사진 한장과 압축파일 들어 있다.
해당 폴더에 있는 압축파일을 풀면 flag가 나올 것 같았으나… 압축파일이 암호로 잠겨있다…
어디에 암호가 숨겨져 있는지 폴더를 이리저리 뒤져가며 확인하던 중 음성 파일과 pdf문서, docx 문서들을 발견했다.
voicemail 1.wav 파일을 실행시켜서 소리를 들어보면 8초 정도의 짧은 대화가 나온다.
대화 내용을 해석하자면 핸드폰 번호로 어떤 파일의 암호를 해제 할 수 있는다는 내용 같았다.
여러 문서들을 살펴보던 중 Termination – Allen Smith.docx 해당 파일에서 핸드폰 번호를 찾을 수 있었다.
핸드폰 번호를 압축파일에 넣었는데 압축이 안풀렸다…. 혹시나 싶어서 -를 빼고 다시 해보니 압축이 풀렸다!
압축을 풀면 flag값이 적힌 docx파일을 확인 할 수 있다! 플래그를 제출하면 끝!
XRDP를 이용하여 GUI 환경을 원격으로 사용 할 수 있다. 그러나 윈도우즈와는 다르게 재접속시 작업 중이던 환경은 모두 날라가고 새로운 세션으로 연결 되는 치명적인 단점이 있다.
세션이 증발하는 현상을 막기 위해 1주일간 구글링과 온갖 삽질을 해본 결과 gnome 데스크톱 환경의 버그인 것으로 결론 내렸다. 16.04 LTS 버전부터 해결 되지 않고 지금까지 해당 버그가 있는 것으로 판단 된다.
이러한 문제를 근본적으로 해결하는 방법은 아직 없는 것 같으며 gnome 환경을 xfce4로 변경하여 임시 해결책이 있다는 것을 알게 되었다.
이번 글에서는 xfce4 설치 및 xrdp 재설정을 할 것이다.
명령어 1줄로 간단하게 설치 가능하다. (설치 오류시 apt-get update 후 재시도 할 것!)
$ sudo apt-get install xfce4x11 환경이 제대로 실행 될 수 있도록 홈 디렉토리에 .xession 파일을 만들어 준다
$ echo xfce4-session > ~/.xsession다음으로는 xrdp에서 기존의 그놈 환경과 새로설치한 xfce4가 충돌이 일어나지 않도록 startwm.sh 파일을 수정 해준다.
$ sudo nano /etc/xrdp/startwm.sh13번째 줄과 14번째 줄을 주석처리한다
test -x /etc/X11/Xsession && exec /etc/X11/Xsession
exec /bin/sh /etc/X11/Xsession위 2줄을 주석 처리하면 된다.
그리고 맨 마지막 줄에 아래의 코드를 추가한다.
test -x /usr/bin/startxfce4 && exec /usr/bin/startxfce4
exec /bin/sh /usr/bin/startxfce4재부팅을 하고 이후부터는 세션 유지가 가능하다 (로그아웃시 다음 로그인에 대비하여 세션 저장 체크를 반드시 해야한다!!!)
++ 내용 추가)
xfce4 환경도 gnome 환경과 마찬가지로 비정상적으로 접속이 종료 된 경우에는 똑같이 세션이 증발한다…. 수시로 저장 및 백업은 필수 인 것 같다!
사람이 많은 장소에 있거나 음영지역에 있는 경우 등등 자동으로 매칭된 LTE 주파수 상태가 좋지 않아 인터넷과 전화가 불가능한 상황이 종종 발생한다.
이런 상황에서 원할하게 통신을 하기 위해서는 수동으로 주파수를 지정해줘야 원할하게 통신이 가능하다
삼성 기본 전화앱을 켜고 319712358을 입력하면 아래와 같은 화면이 뜬다.
위 창에서 OK를 누르고 본인 통신사에 맞는 코드를 입력한다
SKT : 996412 LG : 0821 KT: 774632
코드를 입력하면 아래와 같은 히든메뉴에 진입 할 수 있다. 4번째에 있는 Network Setting를 터치한다.
맨 위에 있는 Network mode를 터치하면 LTE밴드를 선택 할 수 있는 메뉴가 나오게 된다
좌측 상단에 있는 三을 터치 한다음 Band Selection 메뉴로 진입 한다
본인이 원하는 주파수를 선택 후 우측 상단의 selection을 누르면 적용된다
여기서 여러개의 주파수를 지정하고자 할때에는 Preferred가 적힌 항목들로 선택해야한다 Preferred가 없는 항목으로 구성할 경우 한 주파수만 고정되어 더 나은 주파수가 있어도 자동으로 변경이 되지 않기 때문이다.
https로 웹 서버를 운영을 하면 몇 개월 마다 인증서를 갱신해야 한다.
유효기간이 지나도록 인증서를 갱신하지 않으면 보안에도 좋지 않을 분더러 구글 등 검색 사이트에 본인의 사이트가 노출이 되지 않기 때문에 만료되기 전에 인증서를 갱신하는 것이 좋다
인증서를 갱신하기 위해서는 인증서가 설치된 위치로 이동해야 한다.
Let’s Encrypt 무료 인증서로 https를 구축한 경우는 대부분이 /etc/letsencrypt에 인증서가 존재한다.
해당 위치에서 아래 명령어를 실행한다.
$ sudo certbot renew # 인증서가 만료 되었을때
$ sudo certbot certonly --force-renew -d [기존 인증서 도메인] # 인증서가 만료되기 전 갱신할 때
명령어를 입력하면 번호를 입력하라는 창이 뜬다.
필자는 아파치 서버를 운영 중이여서 1번을 입력하였다. 각자 서버에 맞는 번호를 입력하면 된다.
명령어 실행이 끝났으면 웹 서비스를 재시작 한다.
$sudo service apache2 restart재시작 후 웹에 접속해보면 인증서가 갱신 된 것을 확인 할 수 있다.
서버를 옮기거나, 새롭게 워드프레스 사이트를 제작한 후 워드프레스가 업데이트 되지 않는 상황이 가끔 발생한다.
“일부 파일이 복사가 안돼 업데이트가 설치되지 않았습니다”로 업데이트 되지 않는 상황은 서버 업데이트를 진행하는데 시스템(apache2, www-date) 계정이 권한이 없어서 발생하는 문제이다.
웹 호스팅을 사용하는 경우에는 서버 운영사에 문의를 하면 해결 할 수 있지만 집에서 직접 서버를 돌리는 경우에는 파일 권한을 수정 해줘야 한다.
$ cd /var/www/html 간혹 웹 폴더가 /home/유저명/html 로 되어있는 경우도 있므로 이동이 안 될 경우에는 먼저 본인 서버의 웹 폴더를 확인 한다.
$ sudo chown www-date:www-date -R /*
$ sudo chmod +755 /*간혹 웹 서비스 계정이 www-date가 아닌 apache2 등으로 되어있는 경우도 있으므로 먼저 확인 후에 변경 하도록 하자
위 과정을 거친 후 업데이트를 시도하면 제대로 되는 것을 확인 할 수 있다.
원래 SSH 기본 포트는 22번 포트다.
22번 포트를 사용하여도 상관 없지만, 간혹 중국이나 러시아에서 무차별 대입 공격을 시도하는 경가 있어 이를 대비하고자 포트를 변경하고자 한다.
중국발 무차별 대입 공격은 며칠 간 지켜본 결과 22번 포트에 ssh 서비스가 운영 중일 경우 무차별 대입을 시도하게 스크립트가 짜여져 있는 것 같았다.
포트를 변경하면 무차별 대입 공격을 피할 수 있을 것 같아 SSH 포트를 변경하게 되었다.
$ sudo nano /etc/ssh/sshd_config
#Port 22에서 #을 지워 주석을 해제한 뒤 자신이 원하는 포트로 변경 후 저장한다.
포트를 열기 않고 그냥 서비스를 재시작하면 영영 ssh에 접속을 못하는 불상사가 발생 할 수 있다. 반드시 포트를 연 후 재시작 하도록 하자! 제발!
눈물을 머금고 서버를 밀어야 할 수도 있다….(경험담)
$ sudo iptables -I INPUT -p tcp --dport 1122 -j ACCEPT
$ sudo iptables -I OUTPUT -p tcp --dport 1122 -j ACCEPTINPUT, OUTPUT 모두 열어야 한다.
$ sudo service sshd restart서비스를 재시작 한 이후부터 변경된 포트로 접속이 가능하다.
$ ssh user@domain.com -p1122 # 파란색 숫자 부분에 변경한 ssh 포트 입력