Huzylog

apache 가 원인미상의 오류로 재시작되는 현상이 있어 원인을 찾아 보았다.

먼저 apache error log에 coredump 가 생성되었으니 확인해보라는 부분이 있었고,

coredump 가 생성된 위치를 알려준다. 해당 위치로 이동해보자.

cat 또는 vi 를 사용해 coredump 파일을 열어보았는데, 텍스트 파일이 아니었다.

그래서 여는 방법을 찾아보았더니, gdb 를 사용해야 했다.

하지만 단순히 gdb 로 연다고 해서 열리는게 아니라, 이걸 생성한 데몬을 기준으로 열어주어야 한다.

gdb /app/apache/bin/httpd /app/log/coredump/core.httpd.xxxx.2.xxxxx

이런식으로 coredump 파일을 열어주면 오류 내용이 출력되고, 어느 부분을 실행하다 오류가 발생했는지는 backtrace를 입력해주면 된다.

(gdb) backtrace
#0  0x00007f6765dc772a in __strchr_sse2 () from /lib64/libc.so.6
#1  0x00007f6765d7cfd6 in putenv () from /lib64/libc.so.6
#2  0x00007f6763ea7292 in php_putenv_destructor (pe=0x7f6727891b40)
    at /app/src/php-5.3.29/ext/standard/basic_functions.c:3435
#3  0x00007f6763f8585b in zend_hash_destroy (ht=0x7f66d423bd48) at /app/src/php-5.3.29/Zend/zend_hash.c:529
#4  0x00007f6763ea78a5 in zm_deactivate_basic (type=1, module_number=26, tsrm_ls=0x7f66d412c8f0)
    at /app/src/php-5.3.29/ext/standard/basic_functions.c:3768
#5  0x00007f6763f7a0af in module_registry_cleanup (module=<value optimized out>, tsrm_ls=<value optimized out>)
    at /app/src/php-5.3.29/Zend/zend_API.c:2173
#6  0x00007f6763f855b8 in zend_hash_reverse_apply (ht=0x7f676479e4a0,
    apply_func=0x7f6763f7a090 <module_registry_cleanup>, tsrm_ls=0x7f66d412c8f0)
    at /app/src/php-5.3.29/Zend/zend_hash.c:757
#7  0x00007f6763f78120 in zend_deactivate_modules (tsrm_ls=0x7f66d412c8f0)
    at /app/src/php-5.3.29/Zend/zend.c:867
#8  0x00007f6763f18509 in php_request_shutdown (dummy=<value optimized out>)
    at /app/src/php-5.3.29/main/main.c:1643
#9  0x00007f6764010257 in php_apache_request_dtor (r=0x7f670413c6c0)
    at /app/src/php-5.3.29/sapi/apache2handler/sapi_apache2.c:509
#10 php_handler (r=0x7f670413c6c0) at /app/src/php-5.3.29/sapi/apache2handler/sapi_apache2.c:681
#11 0x0000000000443450 in ap_run_handler (r=0x7f670413c6c0) at config.c:158
#12 0x0000000000446a7e in ap_invoke_handler (r=0x7f670413c6c0) at config.c:376
#13 0x0000000000492940 in ap_process_request (r=0x7f670413c6c0) at http_request.c:282
#14 0x000000000048f8c0 in ap_process_http_connection (c=0x7f672000d198) at http_core.c:190
#15 0x000000000044a9e0 in ap_run_process_connection (c=0x7f672000d198) at connection.c:43
#16 0x00000000004b03df in process_socket (thd=0x27f74a8, dummy=<value optimized out>) at worker.c:545
#17 worker_thread (thd=0x27f74a8, dummy=<value optimized out>) at worker.c:895
#18 0x00007f67660e3aa1 in start_thread () from /lib64/libpthread.so.0
#19 0x00007f6765e30c4d in clone () from /lib64/libc.so.6
(gdb)

해당 문제가 발생한 서버는 php5.3.29 라는 오래된 버전을 사용하고 있는 중인데,.. 

putenv() 를 실행할때 메모리 오류가 발생하였다. 그래서 해당 건을 $_SERVER 와 $_ENV를 활용한 코드로 대체하여 수정하였다.

끗.

오늘 오전 4시경부터 메일로 cron 작업이 실패했음을 알리는 알람 메일이 계속해서 수신되었다.

아침에 일어나서 이걸 확인하고 우선은 메일서버를 내린뒤 원인을 파악해보았다.

1. crontab 에 내가 등록하지 않은 watchdog 작업이 추가됨

2. 예전에 제거했던걸로 알고 있었던 사용자가 아직 살아있음

3. 그 제거했던 사용자로 crontab이 생성되어 계속 실행됨

#1. userdel 시도

- 해당 사용자가 프로세스에서 사용중이라며 제거가 되지 않았음

#2. pkill ID

해당 사용자가 사용하는 프로세스 강제종료. 그리고 userdel 을 실행하니 제거 되었음

#3. crontab 제거

/var/spool/cron/crontab 에 들어가 root 에서 설정한 작업 외의 cron 을 모두 점검하고 의심되는 cron 스케쥴은 모두 제거하였음.

#4. 실패한 crontab 작업만 메일 전송

MAILTO="" 을 선언해두기도 했지만, 기존 cron 작업 들의 뒤에 아래 부분을 붙여 실패한 경우에만 메일이 오도록 처리 추가.

 > /dev/null 2>&1

nginx 에서 proxy_pass 를 선언하였을때, api 서버에서 bridge 역할을 하는 서버의 IP를 client ip 로 인식하는 문제가 생겼다.

backend에서 client  ip 를 필요로 하는 상황이라, nginx conf 를 아래와 같이 변경해주었다.

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend_server;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

하지만 이렇게 설정 하였을때에도 클라이언트에서 IP변조가 일어날 수 있는 가능성이 있다는건 인지해야한다.

메일로 notification 알람이 너무 많이와서, 그냥 netdata 를 제거하기로 했다.

그런데, apt-get remove netdata 가 먹히질 않았다. 

그래서 제거하는 방법을 찾아보았다.

#sudo systemctl stop netdata

#sudo systemctl disable netdata

#find / -name netdata-uninstaller.sh

#경로를 찾아보니 /usr/libexec/netdata/ 에 있었다.

# cd /usr/libexec/netdata

# ./netdata-uninstaller.sh --yes

오래된 사이트를 호스팅 하는 서버들은 항상 보안에 취약하고, 공격을 당하게 되어있다.

그렇게 공격을 당하면 서버에 해킹 스크립트, 홈페이지 등이 심어져 리소스를 갈취당하게 되는데

현재까지 몇년간 서버를 운영하며 당한 공격

1. 좀비서버화 및 DDOS 

스크립트가 심어져 내 서버로 공격을 해서 IDC상황실에서 리포트가 왔다.

서버 송신이 차단되고 포맷을 할수밖에 없었다.

2. 메일서버 relay 

내 메일서버를 통해 다량의 스팸메일을 뿌려댄다. 

덕분에 내 서버에서 postfix 를 지울수밖에 없었다.

3. /var/www/html 에 살림을 차린다.

모든 리눅스 서버의 웹서버는 보통 /var/www/html 을 기본으로 호스팅하는데, 그 경로에다가 php파일과 zip, tar.gz, sh 등 잡다한 파일들을 잔-뜩 올려놓는다.. 웹서버를 깔면 무조건 임의의 경로로 바꿔놓기를 추천.

4. crontab 으로 백도어를 구성한다.

이런 파일들을 찾아 제거해도 crontab 으로 스크립트를 실행해 다시 침투한다.

오늘은 별도 백업서버를 구성 하였을 때, 운영 서버로부터 원격 백업을 구성하는 방법을 포스팅해보려 합니다.

백업에 있어서는 정말 많은 다양한 방법들이 있겠지만, 저는 운영서버에서 crontab 스케쥴링을 통해 먼저 백업을 수행하도록 하고,

백업서버에서는 백업(압축)된 파일을 다운로드 받아가는 방식을 사용하였습니다.

이번 포스팅에서는 운영 서버에서 압축된 파일이 backup-xxx-YYYYMMDD.tar 로 있음을 가정하였습니다.

wget --user={FTP_USER} --password={FTP_PASSWORD} ftp://{HOST}/backup/home/home-$(date '+%Y%m%d').tar
mv home-$(date '+%Y%m%d').tar /home3/backup/home/home.tar

wget 으로 ftp 프로토콜에 user,password option을 주어 접속하는 방식을 사용하였습니다.

먼저 이렇게 시도하였더니 FTP 권한 없음 오류가 발생하였습니다. 그래서 아래와 같이 2가지 권한을 추가해주었습니다.

만약 백업 디렉토리의 소유가 ftp 계정에 있다면 굳이 안그래도 됩니다.

1. 상위 권한의 그룹으로 이동 vi /etc/sudoers

2. vsftpd.chroot_list 에 접속할 계정 추가

리눅스도 강제 재부팅 등을 수행하게 될 경우, 작업하고 있던 부분이 유실되어 파일시스템 손상이 될 수 있습니다. 그리고 부팅을 하게되면 다음과 같은 화면을 마주할수 있는데 이럴 때에는 다음과 같이 수행하면 됩니다.

해당 스크린샷을 보면, "/dev/sda2" 가 손상된 파일시스템이 있는 마운트 위치임을 알 수 있는데요.

간단히 아래와 같이 수행하면 정상 부팅이 됩니다. fsck 명령어를 실행하면, 복구할건지 y 를 입력하게 하는데요. 

a 를 입력하면 모든 복구 질의에 y 가 자동 입력됩니다.

# fsck /dev/sda2

.....

# reboot

var/log 에 용량이 많아 확인해보니 journal log 가 4G 넘게 쌓여있는걸 보고, 

stackoverflow 를 참고해 해결했다.

The self maintenance method is to vacuum the logs by size or time.

Retain only the past two days:

journalctl --vacuum-time=2d

Retain only the past 500 MB:

journalctl --vacuum-size=500M

man journalctl for more information.

출처:

https://unix.stackexchange.com/questions/139513/how-to-clear-journalctl