윈도우 서버에 nessus 를 설치했을 경우를 기준으로 설명합니다.

C:Program FilesTenableNessusconfnessusd.rules

nessusd.rules 파일을 열고 아래 룰을 추가하고 저장합니다.

reject 192.168.10.2:80    // 스캔 대상 서버의 IP 및 포트

reject 192.168.10.2:3306

저장되었으면 nessus를 재구동 합니다.

* 그래도 혹시 모르니 홈페이지 소스 및 DB는 백업해 두어야 합니다.

/proc 보안설정 script
> proc_security.sh 파일로 만들어 실행하면 하단 설정값이 적용됩니다.
 
 
----------------------------------------------------------------------------------------------------
 
#!/bin/sh
 
## TCP SYN_Flooding 공격을 차단하기 위해 설정하는 tcp-syncookies 값 ( 기본값 "0" ) ##
# sysctl -a | grep syncookies
# sysctl -w net.ipv4.tcp_syncookies=1
# echo "## TCP SYN_Flooding 공격을 차단하기 위해 설정하는 tcp-syncookies 값 ( 기본값 "0" ) ##
# echo "net.ipv4.tcp_syncookies = 1" >> /etc/sysctl.conf
 
## TCP SYN_Flooding 공격을 차단하기 위해 설정하는 syn_backlog 값 ( 기본값 "0" ) ##
# echo 1024 > /proc/sys/net/ipv4/tcp_max_syn_backlog
# echo "## TCP SYN_Flooding 공격을 차단하기 위해 설정하는 syn_backlog 값 ( 기본값 "0" ) ##" >> /etc/sysctl.conf
# echo "net.ipv4.tcp_max_syn_backlog = 1024" >> /etc/sysctl.conf
 
## 서버에서 IP포워딩 기능 ( 기본값 "0", 라우팅 기능이 필요시 "1" ) ##
# sysctl -a | grep ip_forward
# sysctl -w /proc/sys/net/ipv4/ip_forward=0
# echo "## 서버에서 IP포워딩 기능 ( 기본값 "0", 라우팅 기능이 필요시 "1" ) ##" >> /etc/sysctl.conf
# echo "net.ipv4.ip_forward = 0" >> /etc/sysctl.conf
 
## DoS공격 source로 사용차단(기본값 "0". IP스푸핑 방지하기) ##
# echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter
# echo "## DoS공격 source로 사용차단(기본값 "0". IP스푸핑 방지하기) ##" >> /etc/sysctl.conf
# echo "net.ipv4.conf.default.rp_filter = 1" >> /etc/sysctl.conf
 
## /proc 파티션 기본 퍼미션은 555 상태, 보안유지를 위하여 700 으로 변경 ##
## 단, Java 등과 같은 특별한 시스템이 이용될경우 본래 퍼미션 555 환경을 사용하여야 한다. ##
#chmod 700 /proc
 
echo "" >> /etc/sysctl.conf
echo "" >> /etc/sysctl.conf
echo "" >> /etc/sysctl.conf
 
## Smurf 공격방지를 위한 broadcast 패킷 방지하기 ( 기본값 "0" ) ##
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo "## Smurf 공격방지를 위한 broadcast 패킷 방지하기 ( 기본값 "0" ) ##" >> /etc/sysctl.conf
echo "net.ipv4.icmp_echo_ignore_broadcasts = 1" >> /etc/sysctl.conf
echo "" >> /etc/sysctl.conf
 
## TCP 세션 종료시간 조정 ( 기본값 "60" ) ##
echo 20 > /proc/sys/net/ipv4/tcp_fin_timeout
echo "## TCP 세션 종료시간 조정 ( 기본값 "60" ) ##" >> /etc/sysctl.conf
echo "net.ipv4.tcp_fin_timeout = 20" >> /etc/sysctl.conf
echo "" >> /etc/sysctl.conf
 
## Tcp keepalive time 설정 ( 기본값 "7200" ) ##
echo 1200 > /proc/sys/net/ipv4/tcp_keepalive_time
echo "## Tcp keepalive time 설정 ( 기본값 "7200" ) ##" >> /etc/sysctl.conf
echo "net.ipv4.tcp_keepalive_time = 1200" >> /etc/sysctl.conf
echo "" >> /etc/sysctl.conf
 
## SYN_Flooding 공격 막기 ( 기본값 "1024" 백로그 사이즈 변경 ) ##
echo 1024 > /proc/sys/net/ipv4/tcp_max_syn_backlog
echo "## SYN_Flooding 공격 막기 ( 기본값 "1024" 백로그 사이즈 변경 ) ##" >> /etc/sysctl.conf
echo "net.ipv4.tcp_max_syn_backlog = 1024" >> /etc/sysctl.conf
echo "" >> /etc/sysctl.conf
 
## ICMP redirect의 변조된 패킷 차단(accept 패킷 차단설정 기본값 "1") ##
echo 0 > /proc/sys/net/ipv4/conf/default/accept_redirects
echo "## ICMP redirect의 변조된 패킷 차단(accept 패킷 차단설정 기본값 "1") ##" >> /etc/sysctl.conf
echo "net.ipv4.conf.default.accept_redirects = 0" >> /etc/sysctl.conf
echo "" >> /etc/sysctl.conf
 
## ICMP redirect의 변조된 패킷 차단(send 패킷 차단설정 기본값 "1") ##
echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects
echo "## ICMP redirect의 변조된 패킷 차단(accept 패킷 차단설정 기본값 "1") ##" >> /etc/sysctl.conf
echo "net.ipv4.conf.default.send_redirects = 0" >> /etc/sysctl.conf
echo "" >> /etc/sysctl.conf
 
## 스푸핑 패킷에 대한 로그남기기 ( 기본값 "0" )##
echo 1 > /proc/sys/net/ipv4/conf/default/log_martians
echo "## 스푸핑 패킷에 대한 로그남기기 ( 기본값 "0" )##" >> /etc/sysctl.conf
echo "net.ipv4.conf.default.log_martians = 1" >> /etc/sysctl.conf
echo "" >> /etc/sysctl.conf
 
 
## Source Route 패킷 허용막기 ##
echo 0 > /proc/sys/net/ipv4/conf/default/accept_source_route
echo "## Source Route 패킷 허용막기 ##" >> /etc/sysctl.conf
echo "net.ipv4.conf.default.accept_source_route = 0" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.accept_source_route = 0" >> /etc/sysctl.conf
#echo "net.ipv4.conf.bond0.accept_source_route = 0" >> /etc/sysctl.conf
echo "net.ipv4.conf.eth0.accept_source_route = 0" >> /etc/sysctl.conf
#echo "net.ipv4.conf.eth1.accept_source_route = 0" >> /etc/sysctl.conf
#echo "net.ipv4.conf.eth2.accept_source_route = 0" >> /etc/sysctl.conf
#echo "net.ipv4.conf.eth3.accept_source_route = 0" >> /etc/sysctl.conf
echo "net.ipv4.conf.lo.accept_source_route = 0" >> /etc/sysctl.conf
echo "" >> /etc/sysctl.conf
echo "" >> /etc/sysctl.conf
 
## Source Route 패킷 허용막기 conf 전체 수정 ##
for ii in /proc/sys/net/ipv4/conf/*/accept_source_route; do
echo "0" > $ii
done;
 
sysctl -p
 
----------------------------------------------------------------------------------------------------

[작성] (주)스마일서브 | 백광수

TCP  SYN_Flooding 공격의 원인과 해결책 
   

                       오늘과 내일 넷센터 홍석범(antihong@tt.co.kr) 


최근 자신이 운영하는 서버에 특별히 부하가 걸리거나 이상이 있는 것도 아니고 
또 데몬도 정상적으로 떠 있는데, 정작 서비스가 작동하지 않는 경우가 종종 있다.
이러한 경우에는 해당 데몬을 완전히 멈추었다가 살리면 다시 작동하는데, 
잠시 후에 확인해 보면 똑같은 현상이 다시 나타나곤 한다.
혹시 프로그램을 잘못 설치했나 싶어 지우고 다시 설치해도 마찬가지이다. 

만약 최근 들어 이러한 경험이 있다면 이는 최근 유행하는 DoS(서비스 거부 공격)의 일종인 
TCP SYN Flooding 공격을 당했을 가능성이 크다.

SYN Flooding 공격의 개념이 소개된지는 꽤 되었지만 최근 들어 리눅스가 확산되고, 간단하게 실행할 수 있는 공격 소스가 광범위하게 배포되면서 이 공격이 자주 확인되고 있고, 이로 인해 그 피해가 급속히 확산되고 있다. 실제로 현재 가장 많이 사용되고 있는 배포판인  레드햇 6.X 계열에 이 공격을 실행하기만 하면 단 몇 초만에 서비스가 정지해 버리게 된다.

따라서 피해가 확산되고 있는 이 공격의 원리와 대처방법에 대해 알아보도록 하자.


  “TCP 의 약점을 이용한 공격원리”

SYN Flooding 공격은 TCP 의 취약점을 이용한 공격의 형태이므로 먼저 TCP 에 대해 
알아야 한다.   TCP 는 Transmition Control Protocol 의 약자로 UDP와는 달리 신뢰성 있는 연결을 담당한다.  따라서 서버와 클라이언트간에 본격적인 통신이 이루어지기 전에는 
다음 그림과 같이 소위 "3 Way handshaking" 이라는 정해진 규칙이 사전에 선행되어야 한다.









1단계.  A 클라이언트는 B 서버에 접속을 요청하는 SYN 패킷을 보낸다.
2단계.  B 서버는 요청을 받고 A 클라이언트에게 요청을 수락한다는  SYN 패킷과 
ACK 패킷을 발송한다. 
3단계.  A 클라이언트는 B 서버에게 ACK 를 보내고 이후로부터 연결이 이루어지고 
        본격적으로 데이터가 교환된다.

이것이 TCP 의 기본적인 Flow 이다.
그런데, 이 그림에서 악의적인 공격자가 1단계만 요청(SYN)하고 B서버로부터 응답을 받은 후(SYN+ACK) 3단계, 즉 클라이언트에게 ACK를 보내지 않는다면 어떻게 될까?
SYN+ACK 패킷을 받은 B 호스트는 A 로부터 응답이 올 것을 기대하고 반쯤 열린 
이 른바 “Half Open” 상태가 되어 대기 상태에 머무른 후 일정 시간(75초) 후에 다음 요청이 오지 않으면 해당 연결을 초기화 하게 되는데, 초기화하기 전까지 이 연결은 메모리 공간인 백로그큐(Backlog  Queue)에 계속 쌓이게 된다. 

그런데, 이 위조된 연결 시도를 초기화하기 전에 위조된 새로운 요구가 계속 들어오게 된다면 또한 위조된 새로운 요구가 연결을 초기화하는 속도보다 더 빨리 이루어진다면 어떻게  될까?  이러한 경우  SYN 패킷이 어느 정도 백로그큐에 저장이 되다 결국 꽉차게 되어 더 이상의 연결을 받아들일 수 없는 상태, 즉 서비스 거부 상태로 들어가게 되는 것이다.  이처럼 백로그큐가 가득 찼을 경우에 공격을 당한 해당 포트로만 접속이 이루어지지 않을 뿐 다른 포트에는 영향을 주지 않고, 또한 서버에 별다른 부하도 유발하지 않으므로 관리자가 잘 모르는 경우가 많다.  또한 다른 DoS 공격과는 달리 많은 트래픽을 유발하는 공격이 아니므로 쉽게 파악이 되지 않는 공격 형태이다.

그렇다면 이 공격을 당하고 있는지 여부는 어떻게 알 수 있을까?
시스템에 로긴후 "netstat" 이라는 명령으로 확인 가능하다.


“그럼, 어떻게 파악하는가?”


netstat 은 시스템의 각종 네트워크 정보를 알려주는 명령어로 네트워크 연결, 라우팅 현황, 인터페이스 통계등의 정보를 확인할 수 있게 해 준다.  여기서 잠깐 netstat 으로 나오는 연결 상태에 대해 알아보자.
netstat -na 로 확인해 보면 Local Address,  Foreign Address,  State 등의 정보가 출력되는데,
이 중 State 부분에 보이는 메시지를 주목하면 된다.

### 참고 : State 부분에 가능한 연결상태 ###################################
LISTEN   : 서버의 데몬이 떠서 접속 요청을 기다리는 상태
SYS-SENT : 로컬의 클라이언트 어플리케이션이 원격 호스트에 연결을 요청한 상태
SYN_RECEIVED : 서버가 원격 클라이언트로부터 접속 요구를 받아 클라이언트에게
    응답을 하였지만 아직 클라이언트에게 확인 메시지는 받지 않은 상태
ESTABLISHED : 3 Way-Handshaking 이 완료된 후 서로 연결된 상태
FIN-WAIT1 ,  CLOSE-WAIT , FIN-WAIT2 : 
서버에서 연결을 종료하기 위해 클라이언트에게 종결을 요청하고 
회신을 받아 종료하는 과정의 상태
CLOSING  : 흔하지 않지만 주로 확인 메시지가 전송도중 분실된 상태
TIME-WAIT : 연결은 종료되었지만 분실되었을지 모를 느린 세그먼트를 위해 
            당분간 소켓을 열어놓은 상태
CLOSED : 완전히 종료 
################################################################################

  
각각의 연결 상태는 통신 상황에 따라 매우 복잡하게 순간적으로 변화하는데, 
이 중 주로 주목하여야 할 상태는 SYN_RECEIVED 이다. 설명에 나온 대로 이 상태는 
클라이언트의 확인 메시지를 기다리는 상태이지만 특별히 전용 회선에 장애가 없는 한 이 과정은 순간적으로 일어나므로 실제 netstat 으로 확인되는 경우는 거의 없다.
따라서 netstat -na|grep SYN_RECV 로 확인해 보아 많은 메시지가 보인다면 
Syn Flooding 공격을 당하고 있는 것으로 판단하면 된다.


“실제 테스트 공격으로 직접 확인해 보자!!” 


실제 자신의 시스템이 얼마나 취약한지 자신의 시스템에 테스트해 보도록 하자.
노파심에 이야기하는 것이지만 이 공격은 반드시 자신의 시스템에서만 테스트 용도로 실행해 보기 바란다.  이 공격 소스는 인터넷상에서 쉽게 찾을 수 있다.
http://packetstorm.securify.com/ 나 http://rootshell.com/ 에 접속후 syn 으로 검색해 보면 많은 소스와 문서가 있는데, 이중 관련 파일을 다운로드받아 설치해 보면 된다.

소스에 따라 실행 방법이 다르지만  다운로드 받은 소스파일이 syn_floodinbg_dos.c 라면   gcc ?o syn_flooding_dos syn_flooding_dos.c 로 컴파일을 한다. 이후 
"./syn_flooding_dos 소IP 공격지IP 공격할하위포트번호 상위포트번호" 와 같이 실행하면 되는데,  필자는 ./syn_flodding_dos  0  localhost  80  80 과 같이 테스트해 보았다.

위 명령어의 의미는 공격지 주소를 랜덤하게 무작위 IP주소로 설정(0) 하여  localhost 서버의 80 번 포트에 Syn_Flooding 공격을 한다는 내용이다.

실제 본인이 테스트한 레드햇 6.2 서버에서는 공격후 2-3초만에 웹서비스가 중지되었다.
테스트 공격 후 telnet localhost 80 으로 접속해 보기 바란다.
분명히 httpd 데몬은 떠 있는데, 접속이 되지 않을 것이다.

아래는 공격을 당한 서버에서 netstat -na|grep SYN 으로 SYN 패킷을 잡은 부분이다.



분 명히 localhost 에서 공격을 했음에도 위 그림에서처럼 80번 포트로 SYN 패킷을 요청한 IP주소는 랜덤하게 보이고 있어 도무지 어떤 IP 에서 공격하고 있는 것인지 알 수 없다. 실제로 공격지 IP 를 확인해 보면 대부분이 현재 인터넷상에 연결되지 않은 존재하지 않는 위조된 IP들이다.

실제 공격 소스 코드중 소스 IP를 생성하는 부분을 보면 아래와 같이 0부터 255까지 
임의의 값을 뽑아 IP 주소로 설정하는 것을 확인할 수 있다.

                   {
                       a = getrandom(0, 255);
                       b = getrandom(0, 255);
                       c = getrandom(0, 255);
                       d = getrandom(0, 255);
                       sprintf(junk, "%i.%i.%i.%i", a, b, c, d);
                       me_fake = getaddr(junk);
                    }


SYN_Flooding 공격에 대한 대비 및 해결책 

그렇다면 이 공격에 대해 어떻게 대비하여야 할까?

1. 백로그 큐를 늘려준다. 

직관적으로 보았을 때 서비스 거부에 돌입하게 되는 것은 백로그큐(Backlog Queue)가 가득 
차 서 다른 접속 요구를 받아들이지 못하기 때문이므로 백로그 큐의 크기를 늘려주면 될 것이다. 실제로 리눅스를 포함해서 많은 운영체제들의 백로그큐값을 조사해 보면 이 값이 필요 이상으로 작게 설정되어 있어 적절히 늘려주는 것이 좋다.
현재 시스템에 설정된 백로그큐의 크기는 

[root@net /root]# sysctl -a|grep syn_backlog
net.ipv4.tcp_max_syn_backlog = 128 

또는 
[root@net /root]# cat /proc/sys/net/ipv4/tcp_max_syn_backlog
128 
로 확인가능하며  128kb 인 것을 확인할 수 있다.

일 반적으로 시스템의 RAM 이 128M 일 경우에는 128 을 설정하고 그 이상일 경우에는 1024 정도로 설정해 주는 것이 좋다. 이 때 주의할 점은 이 값을 무작정 크게 설정한다고 좋은 것은 아니며 1024 이상으로 설정할 경우는 /usr/src/linux/include/net/tcp.h 소스에서 TCP_SYNQ_SIZE 변수를 수정 후 커널을 재컴파일하여야 한다.  이 변수를 설정시 TCP_SYNQ_HSIZE에 16을 곱한 값이 tcp_max_syn_backlog 보다는 작거나 같아야 하는데,  그렇지 않을 경우에는 시스템에 문제가 발생할 수 있으니 1024 보다 높은 값으로 설정하지 말기 바란다.  그리고 이 값을 너무 크게 설정하였을 경우에는 경험적으로 아래 설명할 syncookies 기능이  잘 적용되지 않는 현상이 가끔 확인되었다.  
이와는 별개로 시스템의 부하가 많이 걸릴 경우에도 백로그큐를 늘려주면 일정 정도의 효과를 볼 수  있는 것으로 알려져 있다. 

백로그큐의 값을 설정하는 방법은 다음과 같다.

[root@net /root]# sysctl -w net.ipv4.tcp_max_syn_backlog=1024
또는 
[root@net /root]# echo 1024 > /proc/sys/net/ipv4/tcp_max_syn_backlog
로 해도 된다. 

그러나 이 방법은 임시적인 대책일 뿐, 지속적으로 많은 TCP SYN Flooding 공격을 당할 때는 결국 백로크큐가 가득 차게 되므로 근본적인 해결 방안은 아니다.

2.  syncookies 기능을 켠다.

Syncookies (“신쿠키” 라고 발음한다.) 는  "Three-way handshake" 진행 과정을 다소 변경하는 것으로  Alex Yuriev 와 Avi Freedman 에 의해 제안되었는데, TCP header 의 특정한 부분을 뽑아내어 암호화 알고리즘을 이용하는 방식으로 Three-way Handshake 가 성공적으로 이루어지지 않으면 더 이상 소스 경로를 거슬러 올라가지 않는다.  따라서 적절한 연결 요청에 대해서만 연결을 맺기 위해 리소스를 소비하게 되는 것이다. 

syncookies 기능은 TCP_Syn_Flooding 공격을 차단하기 위한 가장 확실한 방법으로 이 기능을 이용하려면 일단 커널 컴파일 옵션에서 CONFIG_SYN_COOKIES이 Y 로 선택되어 있어야 한다.

자신의 커널 옵션에 이 기능이 설정되어 있는지 확인하려면 
/usr/src/linux 디렉토리로 이동후 make menuconfig 후 
Networking options  ---> 
[*]   IP: TCP syncookie support (disabled per default)  
와 같이 확인하면 된다.

만약 설정이 되어 있지 않다면 선택 후 커널 컴파일을 다시 하여야 하지만 대부분 배포판은 기본적으로 이 옵션이 선택되어 있으므로 걱정할 필요는 없다.
그러나 위와 같이 커널 옵션에 설정되어 있다 하더라도 실제 syncookies 적용은 꺼져 있으므로 이 값을 다음과 같은 방법으로 활성화해야 한다.

[root@control src]# sysctl -a|grep syncookie
net.ipv4.tcp_syncookies = 0 

0 으로 설정되어 있으므로  현재 syncookies는 적용되지 않는다. 
따라서 아래와 같이 1을 설정하여 syncookies 기능을 활성화하도록 한다. 

[root@control src]# sysctl -w net.ipv4.tcp_syncookies=1

syncookies는 백로그큐가 가득 찼을 경우에도 정상적인 접속 요구를 계속 받아들일 수 있도록 해 주므로  SYN_Flooding 공격에 대비한 가장 효과적인 방법중 하나이다.
만약 공격을 당해 syncookies 가 작동할 때에는  /var/log/messages 파일에 아래와 같이 SynFlooding 공격이 진행중이라는 메시지가 출력된다.

Jun 11 18:54:08 net kernel: possible SYN flooding on port 80. Sending cookies.

SYN_Flooding 공격이 지속적으로 매우 심하게 진행중일 때에는 syncookies 기능이 작동한다 하더라도 네트워크가 다운되는 현상이 가끔 확인되었다. 따라서 syncookies 기능 외에 몇 가지 설정도 함께 적용하는 것이 시스템의 안정성을 위해 권장하는 방법이다. 아울러 네트워크가 다운되었을 경우에는 /etc/rc.d/init.d/network restart 로 network 를 재설정해 보거나 reboot 를 하여야 한다. 


3. 기타 시스템의 네트워크 설정을 최적화한다.

아래 설정은 비단 TCP Syn_Flooding 공격뿐만이 아니라 다른 여타 DoS 공격에도 효과적이으로 방어하므로 적절히 설정할 것을 권장한다.

sysctl -w net.ipv4.icmp_destunreach_rate=1
# 1/100초 동안 받아들일 수 있는 "dest unreach (type 3) icmp" 의 개수

sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1 
# Broadcast 로부터 오는 ping 을 차단함. (Smurf 공격을 차단함)

sysctl -w net.ipv4.icmp_echoreply_rate=1 
# 1/100초에 반응하는 ping 의 최대 숫자

sysctl -w net.ipv4.icmp_echo_ignore_all=1 
#모든 ping 을 차단함

sysctl -w net.ipv4.icmp_ignore_bogus_error_responses=1 
# IP 나 TCP 헤더가 깨진 bad icmp packet을 무시한다.

sysctl -w net.ipv4.icmp_paramprob_rate=1 
# 1/100 초에 받아들이는 param probe packets의 수

sysctl -w net.ipv4.icmp_timeexceed_rate=1 
# 1/100 초에 받아들이는 timeexceed 패킷의 수(traceroute 와 관련)

sysctl -w net.ipv4.igmp_max_memberships=1 
# 1/100 초에 받아들이는 igmp "memberships" 의 수 

sysctl -w net.ipv4.ip_always_defrag=0 
# 항상 패킷 조각 모음을 하지 않는다. 

sysctl -w net.ipv4.ip_default_ttl=64 
# 매우 복잡한 사이트에서는 이 값을 늘리는 것도 가능하지만 
# 64로 두는 것이 적당하며 더 늘렸을 경우에는 큰 문제가 발생할 수도 있다.

sysctl -w net.ipv4.ip_forward=0 
# 게이트웨이 서버가 아닌 이상 패킷을 포워딩 할 필요는 없다.

sysctl -w net.ipv4.ipfrag_time=15 
# fragmented packet이 메모리에 존재하는 시간을 15초로 설정한다.

sysctl -w net.ipv4.tcp_syn_retries=3  
# 일정한 시간과 IP 별로 보내고 받는 SYN 재시도 횟수를 3회로 제한한다.
# 이 옵션은 스푸핑된(위조된) 주소로 오는 SYN 연결의 양을 줄여준다. 
# 기본값은 5이며 255를 넘지 않아야 한다. 

sysctl -w net.ipv4.tcp_retries1=3 
# 무언가 문제가 있을 때 연결을 위해 재시도 할 횟수. 최소값과 기본값은 3이다.

sysctl -w net.ipv4.tcp_retries2=7 
# TCP 연결을 끊기 전에 재시도할 횟수.

sysctl -w net.ipv4.conf.eth0.rp_filter=2
sysctl -w net.ipv4.conf.lo.rp_filter=2
susctl -w net.ipv4.conf.default.rp_filter=2
sysctl -w net.ipv4.conf.all.rp_filter=2
# 이 설정은 자신의 네트워크가 스푸핑된 공격지의 소스로 쓰이는 것을 차단한다.
# 모든 인터페이스에서 들어오는 패킷에 대해 reply를 하여 들어오는 인터페이스로 나가지 
# 못하는 패킷을 거부한다.  

sysctl -w net.ipv4.conf.eth0.accept_redirects=0
sysctl -w net.ipv4.conf.lo.accept_redirects=0
sysctl -w net.ipv4.conf.default.accept_redirects=0
sysctl -w net.ipv4.conf.all.accept_redirects=0
#  icmp redirects 를 허용하지 않는다.
# 만약 ICMP Redirect 를 허용할 경우에는 공격자가 임의의 라우팅 테이블을 변경할 수
# 있게 되어 자신이 의도하지 않는 경로, 즉 공격자가 의도한 경로로 트래픽이 전달될 수 
# 있는 위험이 있다.

sysctl -w net.ipv4.conf.eth0.accept_source_route=0
sysctl -w net.ipv4.conf.lo.accept_source_route=0
sysctl -w net.ipv4.conf.default.accept_source_route=0
sysctl -w net.ipv4.conf.all.accept_source_route=0
# 스푸핑을 막기 위해 source route 패킷을 허용하지 않는다.
# 소스 라우팅을 허용할 경우 악의적인 공격자가 IP 소스 라우팅을 사용해서 목적지의 경로# 를 지정할 수도 있고, 원래 위치로 돌아오는 경로도 지정할 수 있다. 
# 이러한 소스 라우팅이 가능한 것을 이용해  공격자가 마치 신뢰받는 호스트나
# 클라이언트인것 처럼 위장할 수 있는 것이다.


sysctl -w net.ipv4.conf.eth0.bootp_relay=0
sysctl -w net.ipv4.conf.lo.bootp_relay=0
sysctl -w net.ipv4.conf.default.bootp_relay=0
sysctl -w net.ipv4.conf.all.bootp_relay=0
# bootp 패킷을 허용하지 않는다. 

sysctl -w net.ipv4.conf.eth0.log_martians=1
sysctl -w net.ipv4.conf.lo.log_martians=1
sysctl -w net.ipv4.conf.default.log_martians=1
sysctl -w net.ipv4.conf.all.log_martians=1
# 스푸핑된 패킷이나 소스라우팅,  Redirect 패킷에 대해 로그파일에 정보를 남긴다.

sysctl -w net.ipv4.conf.eth0.secure_redirects=0
sysctl -w net.ipv4.conf.lo.secure_redirects=0
sysctl -w net.ipv4.conf.default.secure_redirects=0
sysctl -w net.ipv4.conf.all.secure_redirects=0
# 게이트웨이로부터의 redirect 를 허용하지 않음으로써 스푸핑을 막기 위해 설정한다.

sysctl -w net.ipv4.conf.eth0.send_redirects=0
sysctl -w net.ipv4.conf.lo.send_redirects=0
sysctl -w net.ipv4.conf.default.send_redirects=0
sysctl -w net.ipv4.conf.all.send_redirects=0
# icmp redirects 를 보내지 않는다.

sysctl -w net.ipv4.conf.eth0.proxy_arp=0
sysctl -w net.ipv4.conf.lo.proxy_arp=0
sysctl -w net.ipv4.conf.default.proxy_arp=0
sysctl -w net.ipv4.conf.all.proxy_arp=0
# proxy arp 를 설정하지 않는다. 이 값이 1로 설정되었을 경우 proxy_arp 가 설정된 인터페
# 이스에 대해 arp 질의가 들어왔을 때 모든 인터페이스가 반응하게 된다.

sysctl -w net.ipv4.tcp_keepalive_time=30
# 이미 프로세스가 종료되어 불필요하게 남아 있는 연결을 끊는 시간을 줄이도록 한다.

sysctl -w net.ipv4.tcp_fin_timeout=30
# 연결을 종료시 소요되는 시간을 줄여준다. (기본 설정값 : 60)

sysctl -w net.ipv4.tcp_tw_buckets=720000 
# 동시에 유지 가능한 timewait 소켓의 수이다. 만약 지정된 숫자를 초과하였을 경우에는
# timewait 소켓이 없어지며 경고 메시지가 출력된다. 이 제한은 단순한 DoS 공격을 차단하
# 기 위해 존재하는데, 임의로 이 값을 줄여서는 안 되며 메모리가 충분하다면 적절하게 늘
# 려주는 것이 좋은데,  64M 마다 180000 으로 설정하면 된다. 따라서 256M 일 경우에는 
# 256/4=4 4*180000=720000 을 적용하면 된다. 

sysctl -w net.ipv4.tcp_keepalive_probes=2
sysctl -w net.ipv4.tcp_max_ka_probes=100
# 간단한 DoS 공격을 막아준다.

위의 모든 설정은 재부팅 후에 원래의 값으로 다시 초기화되므로  /etc/rc.d/rc.local 에 두어 부팅시마다 실행하도록 하여야 한다.  그리고 리눅스의 버전이 낮아 sysctl 명령어가 없는 경우에는 
echo 0 or 1 > /proc/sys/net/* 와 같이 직접 /proc 이하의 값을 직접 설정해 주어도 된다.
echo 명령어 역시 재부팅되면 초기화되므로 /etc/rc.d/rc.local 에 설정해 두어야 재부팅후에도 적용이 된다.  
아울러 레드햇 6.2 이상일 경우에는 /etc/sysctl.conf 파일에 net.ipv4.tcp_syncookies=1 와 같이 설정한 후 network 를 restart 하는 방법도 있다.
  

4. 그외 SYN_Flooding 에 대한 보충 설명 몇 가지 


(1)  위에서 설명한 방법 외에 추가적으로 설정할 만한 몇 가지 방법이 있다.
RFC 1918 에 의해 내부(Private) IP를 소스로 들어오는 트래픽을 차단한다.
127.0.0.0, 10.0.0.0, 172.16.0.0, 192.168.0.0 등은 Private IP 로서 내부의 가상 IP 를 사용할 때  쓰이는 주소이며 일반적으로 이러한 IP를 소스 주소로 라우팅이 될 수 없다. 
따라서 아래와 같이 비정상적인 IP 주소를 소스로 해서 들어오는 트래픽을 차단한다.

iptables -A INPUT -s 10.0.0./8 -j DROP
iptables -A INPUT -s 172.16.0.0/12 -j DROP
iptables -A INPUT -s 192.168.0.0/16 -j DROP 
# 사설 IP 를 차단한다.
# /8, /16 등은 CIDR 라 하며 /8 은 A Class, /16 은 B Class 를 뜻한다.

iptables -A INPUT -s 255.255.255.255/32 -j DROP
iptables -A INPUT -s 127.0.0.0/8 -j DROP
# 일반적으로 라우팅이 되지 않는 IP 대역을 차단한다.

iptables -A INPUT  -s 240.0.0.0/5 -j DROP
# IANA 에 예약된 주소를 차단한다.

iptables -A INPUT  -s 211.2.3.4 -j DROP
# 아울러 자기 자신의 IP 를 소스로 하는 패킷도 필터링한다.(211.2.3.4 대신 자신의 IP입력)
# 자신의 IP 를 소스로 해서 패킷이 들어올 수는 없다.

자신의 시스템이 Kernel 2.4 이전 버전의 경우에는 iptables 대신 ipchains 를 사용하므로 
ipchains -A input -s 10.0.0./8 -j DENY 와 같은 방법으로 사용하면 된다.
만 약 iptables 가 설치되어 있지 않으면 http://netfilter.kernelnotes.org/ 에 접속 후 최신 버전의 iptables.tar 를 다운로드 받아 압축해제 후 make; make install 로 설치하면 된다. 
현재 리눅스 시스템의 Kernel 버전은 uname ?r 을 입력하면 확인할 수 있다.
아울러 아래는 네트워크를 통해 라우팅 될 수 없는 IP 대역이므로  필터링 하여야 할 IP 이다.

0.0.0.0/8           - Historical Broadcast
10.0.0.0/8          - RFC 1918 에 의한 내부 네트워크 
127.0.0.0/8         - Loopback
169.254.0.0/16      - Link Local Networks
172.16.0.0/12       - RFC 1918 에 의한 내부 네트워크
192.0.2.0/24        - TEST-NET
192.168.0.0/16      - RFC 1918에 의한 내부 네트워크 
224.0.0.0/4         - Multicast D Class 
240.0.0.0/5         - 예약된 E Class 
248.0.0.0/5         - 미할당 
255.255.255.255/32  - 브로드캐스트 

(2) 임의의 IP 가 아닌 특정한 IP를 소스 주소로 계속적으로 SYN 공격이 이루어 질 경우에는 해당 IP 를 차단하는 것도 좋은 방법이다. 
만약 211.2.3.4 에서 지속적으로 공격이 들어올 때는 아래와 같이 차단할 수 있다.

iptables -A INPUT -s 211.2.3.4 -j DROP (Kernel 2.4.x 버전)
ipchains -A input  -s 211.2.3.4 -j DENY (Kernel 2.4 이전 버전)

또는 
route add -host 211.2.3.4 reject 로 한다.
만약 211.2.3.X 대역 전체를 차단하려면 211.2.3.0/24 와 같이 하면 된다.
(/24 는 C Class 를 뜻한다.)
그러나 위와 같이 route 보다는 iptables 나 ipchains 로 차단하는 것이 더 효과적이다.

만 약 임의의 IP로 공격지를 생성한다면 SYN_RECEIVED 로 보이는 IP 중에는 실제 네트워크에 연결되어 있는 IP 도 있을 것이고 그렇지 않은 IP 도 있을 것이다. 그러나 실제 공격을 당할 때 공격지 IP 를 검출해 보면 모두 ping 이 되지 않는 실제 네트워크에 연결되지 않은 IP 주소이다. 어째서 이런 현상이 일어날까? 이는 앞에서 설명한 TCP 의 3 Way-Handshake 원리를 잘 생각해보면 이해가 될 것이다.
즉, 무작위로 생성된 IP 를 소스로 한 SYN 패킷을 받은 서버는, 요청을 받은 모든 IP 로 SYN+ACK 패킷을 보낸다. 그런데, 정작 실제로 해당 IP 를 사용중인 호스트는 SYN 패킷을 보내지도 않았는데, 공격을 받은 서버로부터 영문도 모르는 SYN+ACK 를 받았으므로 이 패킷을 비정상적인 패킷으로 간주하고 해당 패킷을 리셋(RST)하여 초기화 시킨다. 
그리고 실제 존재하지 않는 IP 에 대해서 알아보자. 공격을 당한 서버가 해당 IP로부터  SYN 패킷을 받았다고 판단(실제로는 위조된 패킷이지만) 하여 SYN+ACK 패킷을 발송 후 ACK 패킷을 계속 기다리지만 해당 IP 는 인터넷에 연결되어 있지 않으므로 SYN+ACK 패킷을 받을 수도 없을 뿐더러 이에 대한 응답으로 ACK 패킷을 발송하지 않을 것임은 불을 보듯 뻔한 것이고, 결국 공격을 받는 서버는 존재하지도 않는 IP 로부터 ACK 패킷을 받을 것만을 기다리며 백로그큐는 가득 차게 되는 것이다.  이것이 백로그큐가 가득 차게 되는 이유이며 백로그큐를 가득 채우는 IP가  모두 실제로는 존재하지 않는 IP 들인 것이다. 따라서 공격자의 입장에서는 인터넷상에서 라우팅이 되지 않는 IP 를 소스 IP 로 하여 공격하는 것이 가장 효과적일 것이다. 즉 인터넷에 연결되어 있는 IP 를 소스 주소로 하여 SYN Flooding 공격하는 것은 의미가 없다. 


(3) 실제 공격지 IP를 추적하는 것은 거의 불가능하다.
대 부분의 DoS 공격이 그러하듯이 SYN_Flooding 공격도 소스IP를 속여서 들어오기 때문에 netstat 으로 보이는 IP를 실제 공격지 IP 라고 판단해서 해당 IP로 역공격을 해서는 안 된다.  공격을 당하는 리눅스 서버에서 공격지를 아는 방법은 없으며 상위 라우터와 해당 라우터가 연결되어 있는 ISP 업체와 긴밀하게 협조가 되었을 때라야  그나마 추척이 가능하다.
그 러나 사실상 협조가 이루어져도 추척하기란 매우 어려운데, 만약 라우팅 경로가 20개이상 되는 곳에서 공격한다면 20개 라우터를 관리하는 모든 관리자와 동시에 협조가 이루어져야하고 공격이 실제 이루어지고 있는 당시에  추척이 되어야 하므로 매우 어렵다고 할 수 있다.    결론적으로 공격지 IP 를 추척하는 것은 불가능하다고 할 수 있다. 
그리고, 참고적으로 시스템에서 위조된 패킷을 생성하는 것은 오직 root 만이 가능하므로 공격자는 공격지 시스템의 root 소유로 SYN Flooding 공격을 하는 것이라는 사실을 참고하기 바란다. 


(4) Virtul-Sever 커널 패치를 하는 방법도 있다.
이 커널 패치를 하였을 경우에는 몇 가지 DoS 공격을 차단할 수 있다. VirtualServer란 말 그대로 로드 밸랜싱등의 클러스터링 시스템을 구성할 때 필요한 커널 패치로서 패치를 한 후  sysctl -a|grep .vs. 로 확인해 보면 몇 가지 설정이 추가된 것을 확인할 수 있다. 
이 방법에 대한 보다 자세한 안내는 http://www.linuxvirtualserver.org/defense.html 를 참고하기  바란다. 

(5) 라우터나 방화벽에서 차단 가능하다.
라 우터등 네트워크 장비로 유명한 CISCO 에서는 TCP SYN_Flooding 공격을 차단하기 위해 TCP Intercept 라는 솔루션을 제안했다.  TCP Intercept 는 두 가지 방식으로 구현가능한데 , 첫번째 방식은 “인터셉트 모드” 라 하여 말 그대로 라우터로 들어오는 SYN 패킷 요청을 그대로 서버에 넘겨주지 않고 라우터에서 일단 가로채어(Intercept 하여) 서버를 대신하여 SYN 패킷을 요청한 클라이언트와 연결을 맺고, 연결이 정상적으로 이루어지면 이번에는 클라이언트를 대신하여 서버와 연결을 맺은 다음 두 연결을 투명하게 포워딩하여 연결시켜주는 방식이다.  따라서 존재하지 않는 IP 로부터 오는 SYN 요청은 서버에 도달하지 못하게 되는 것이다. 두번째 방식은 “와치(watch) 모드” 라 하여 “인터셉트 모드”와는 달리 라우터를 통과하는 SYN패킷을 그대로 통과시키고 일정 시간동안 연결이 이루어지지 않으면 라우터가 중간에서 SYN 패킷을 차단하는 방식이다.  몇몇 방화벽에서도 위의 두 가지 방식으로 SYN Flooding 을 차단하고 있다.   실제로 tcp intercept 를 설정하여 테스트 결과 서버 레벨에는 전혀 스푸핑된 SYN 패킷이 보내지지 않아 SYN_Flooding 공격을 차단하기 위한 가장 확실한 방법이기는 했지만 아쉽게도 라우터의 CPU, Memory 부하가 너무 높아지는 단점이 있었다. 이 설정에 대해 궁금하신 분은 http://www.cisco.com/ 접속후 "tcp intercept" 로 검색해 보기 바란다. 이 설정을 했을 경우에는 모든 패킷에 대해 인터셉트를 하므로 트래픽이 많을 경우에는 라우터가 다운되는 경우도 있으니 설정시 각별히 주의하기 바란다.


(6)  Windows NT/2000 계열에서는 Registry값을 수정함으로써 튜닝이 가능하다.
이 값에 대한 튜닝은 Microsoft 의 technical page 나 
http://packetstorm.securify.com/groups/rhino9/synflood.doc 를 다운로드 받아 참고하기 바란다.
AIX나 Solaris등 다른 UNIX 계열에 대한 튜닝은 
http://www.cymru.com/~robt/Docs/Articles/ip-stack-tuning.html 를 참고하기 바란다.


(7) CRON 을 이용해 SYN_Flooding 공격을 감지한다.
아 무리 튜닝을 잘 했다 하더라도 집중적으로 SYN Flooding 공격을 받을 때는 네트워크나 서비스 데몬이 이상 작동할  수도  있다. 그래서 이상 현상이 나타나기 전에 일정 시간마다 시스템에 로그인하여 netstat 으로  확인할 수 있겠지만 언제 공격이 들어올 줄 알고 지켜보고 있겠는가?    그래서 필자는 SYN Flooding 을 감지하기 위해 다음과 같이 간단한 스크립트를 짜서 공격이 확인되면 메일로 통보되도록 하여 사용중이다.

#!/usr/bin/perl

$TASK = `netstat -na|grep SYN_RECV`;
$HOSTNAME = `/bin/hostname`;
$TO_MAIL      = "antihong@tt.co.kr";       
$SUBJECT      = "$HOSTNAME SYN_FLOODING 공격 감지";
$MAIL_PROGRAM  = "/usr/sbin/sendmail";

if ($TASK){
  $TASK_ConFIRM = `netstat -na|grep SYN_RECV|wc -l`;

if($TASK_CONFIRM > 20){
`/etc/rc.d/init.d/httpd stop`;
`/etc/rc.d/init.d/httpd start`;
$HTTP_DonE ="httpd was Refreshed!! ";
}

open(MAIL, "|$MAIL_PROGRAM -t");
    print MAIL "To: $TO_MAIL ";
    print MAIL "Subject: $SUBJECT ";
    print MAIL "$HOSTNAME Server is Attacked by SYN_Flooding!!! ";
print MAIL "SYN_Flooding Process Number :$TASK_CONFIRM ";
    print MAIL "$HTTP_DONE ";
    print MAIL "$TASK ";
close(MAIL);
}


위 파일의 내용중 $TO_MAIL 은 공격 감지시 통보될 메일 주소이므로 자신의 e-mail 주소로 변경하고, 불완전한 SYN 패킷이 20개 이상일 경우 ($TASK_CONFIRM > 20)
`/etc/rc.d/init.d/httpd stop`; 과  `/etc/rc.d/init.d/httpd start`; 으로  웹데몬을 멈추었다가 시작하도록 설정하였는데, 이는 자신의 설정에 맞게 적절히 수정하도록 한다.
물론 SYN Flooding 공격이 특정 포트에 대해서만 가능한 것은 아니지만 거의 80번 포트에 대해 집중적으로 이루어지고 있으므로 웹데몬을 예로 설정한 것 뿐이다. 

위 파일의 내용을 /etc/cron.5min/ 이라는 디렉토리에 두고 실행할 수 있도록 700 으로 설정해 둔다. 그리고 /etc/crontab 파일을 열어 아래 내용을 추가하면 5분마다 SYN_Flooding 여부를 체크하여 공격이 확인시 지정된 메일 주소로 통보해 준다..

59/5 * * * * root run-parts /etc/cron.5min/

[출처] 그린IDC (http://www.greenidc.co.kr/gnuboard4/bbs/board.php?bo_table=linux&wr_id=38&page=0&page=0)

홈페이지가 뜨다 안뜨다 난리다.

cpu 점유율이 순간100%를 육박했다 떨어졌다 한다.

웹서버를 정지시켜보니 0%로 떨어진다.

재부팅해보니 안보이던 관리자에 RAS Server (Dial In) Interface 가 뜬다.

해킹이다.

VPN 서비스를 하지 않는 이상 대략 이런경우는 해킹을 당했을 경우 인거 같다.

재부팅보다 확인방법은

시작 -> 관리도구 -> 라우팅 및 원격 액세스 ->클릭

자기도 모르는 사용자들이 접속을 많이 해 있을수 있다.
우측 마우스 눌러보면 메뉴에서 모든작업 -> 중지 해주면 일단 접속은 차단된다.

그리고 사용자 관리에 아마 못보던 사용자들이 등록되어 있을텐데,

모두 삭제 처리 후 관리자 암호변경한다.

그리고 윈도우즈업데이트 후 재부팅하여 변경된 암호로 로그인해본다.

[출처] 허스키 | 허스키 (http://blog.naver.com/seenan/30075445138)

1.        소개

인터넷 주소 자원이 고갈됨으로 인해 이를 극복하는 수단으로 사설 IP 주소의 활용이 빈번하게 되었고, 이러한 컴퓨터들의 인터넷 연결을 지원하기 위해proxy 서비스가 활용되고 있습니다.

proxy 서버는 임의의 IP 주소를 갖는 컴퓨터에 대해 네트워크 연결을 중계해주는 "연결 대행" 서버입니다.

최근 들어 보안 설정이 잘못되어 누구나 접속이 가능한 proxy 서버들이 많이 발견되고 있습니다.

이번 시간은 proxy 서비스와 open proxy 서비스의 취약성 및 대응방안에 대해 알아보고자 합니다.

2.        Proxy 서비스

2.1      Proxy의 기능

①       Caching 기능

-         네트워크의 트래픽을 줄이고, 데이터 전송 시간을 향상시켜 줍니다.

-         일단 한번 접속이 이루어진 문서를 Proxy server의 Cache에 보관 해 놓은 다음 이 문서에 대한 요구가 있을 시 해당 Site까지 접근하지 않고Proxy Server가 Local Disk에서 원하는 문서를 보내주는 기능입니다.

②       Filtering 기능

-         네트워크 외부로부터 허가 받지 않은 접속을 제한합니다.

-         보안을 위해 네트워크를 외부와 차단 하고, proxy를 통해 서비스의 접속의 허가 및 거부 등의 기능을 수행합니다.

2.2      Proxy의 동작 방식

[그림 1] Proxy 서비스의 동작

-         Proxy server는 Web Server접속을 위한 Client의 요구를 받습니다. ①

-         우선 자신의 cache 영역에 해당 데이터가 존재하는지 살펴보고 ② 있으면 Client에게 데이터를 전송합니다. ③

-         자신의 cache 영역에 데이터가 없으면 Server에게 데이터를 요청해서 ④ 전송 받은 후에 자신의 cache 영역에 저장합니다. ⑤

-         Proxy 서버 내에 저장된 데이터는 시간과 용량, 그리고 사용 빈도에 따라 나중에 삭제되거나 유지됩니다.

3.        Open Proxy의 취약성

①       다양한 업체의 HTTP proxy 서비스들은 보안이 고려되지 않은 default 설정 상태로 운영되는 경우가 많습니다. (open proxy)

②       Open proxy를 이용하면 공격자들은 사용자가 누구든지, 목적지에 상관없이 HTTP CONNECT 방법으로 telnet, SMTP를 비롯하여 rlogin,rexec 등 다양한 서비스에 자신의 출처를 숨기고서 접속이 가능 합니다.

③       Open proxy를 이용하면 하나의 사용자가 여러 곳의 서버를 동시에 사용해서 네트워크 공격을 할 수 있으며 그 결과 스팸의 차단이나 해킹 방지 등은 매우 어렵습니다.

④       Open proxy를 이용하면 스팸 중계 서버(open SMTP relays)와는 달리 Received: 헤더를 임의로 조작할 수 있고, 그 결과 스팸 발송자의 신원 추적이 불가능합니다.

4.        Proxy를 이용한 공격기법

①       Proxy 서버를 이용한 접속

[그림 2] proxy 서버를 이용한 접속

-         [그림 #2]은 Attacker(1.1.1.1)가 proxy Server를 이용하여 피해자 시스템(3.3.3.3)에 접속합니다.

-         이때, 실제 피해자 시스템에서는 proxy 서버(2.2.2.2)에서 공격이 이루어진 것으로 나타나며, 실제 공격자를 추적할 수 없습니다.

②       Proxy 서버를 이용한 스팸메일 발송

[그림 3] Proxy 서버를 이용한 스팸메일 발송

-         [그림 #3]는 불법적으로 광고성 메일을 보내고자 하는 공격자가 proxy 서버를 이용하여 발송자 출처를 속여 다수의 사용자에게 발송하는 과정입니다.

-         메일이 발송된 주소를 추적하기 위해 수신된 메일의 헤더에서 Received 부분을 분석하게 되는데 proxy 서버를 이용하여 발송할 경우, 최초의 발송 주소가 proxy 서버 주소가 기록되어 추적할 수 없습니다.

5.        Proxy 서버 점검방법

-         갑자기 네트워크가 불안정하거나 속도가 많이 저하될 경우, proxy 서버의 공격 여부를 의심할 수 있습니다.

-         윈도우 시작 메뉴에서 [실행] 선택 -> “cmd” 입력 후 [확인] 선택 -> ‘터미널’이 나타나면 “netstat ?an”를 입력하여 세션 상태를 확인합니다.

-         만약 open proxy으로 악용이 되었다면, 평소와는 다르게 [그림 #4]과 같이 많은 세션이 있으며, 세션상태를 보면 발송 주소가 proxy 서버 주소로 기록되어 다수의 사용자에게 스팸 발송이 된 것을 확인할 수 있습니다.

-         [그림 #4]과 같이 발송 주소가 proxy 서버에서 다수의 목적지로의 접근 흔적이 있다면, open proxy악용되고 있음을 의심할 수 있습니다.

[그림 4] Proxy 서버가 스팸메일 발송에 사용되고 있는 화면

6.        대응방안

①       proxy 서버를 최신 버전으로 업그레이드

②       HTTP CONNECT 방법을 이용하여 임의의 TCP 포트로의 연결을 제어

③       Proxy 서비스들에 대한 접근은 신뢰된 네트워크에서만 가능하도록 제어

[그림 5] Proxy 서버에서 보안설정

[출처] http://support.oullim.co.kr/portal/Techletter/20080331/news4.htm

이번에는 웹쉘이 서버에 올라갔을 때의 탐지 및 대응 방법에 대해 알아 보려고 한다. 일단 웹쉘이 서버에 업로드 되면 그 서버는 해커의 수중에 들어 갔다고 보아야 한다. 이후 해커는 다양한 방법으로 서버의 정보를 취득하고 해킹툴을 이용해서 권한 상승을 노린다.

allow_url_fopen = On인 웹 페이지 취약점을 통해 다음과 같이 쉘권한을 얻을 수 있다. 

  
http://www.test.com/Test.php  ----------------->   http://hack.com/webshell.txt  

타킷서버의 Test.php에 취약점이 존재하는 경우 hack.com에 존재하는 webshell을 불러들여 쉘 권한을 획득 한 다음 내부 서버의 정보를 모으고 백도어를 설치하고 권한 상승을 노린다. 대표적으로 구 제로보드에서 많이 발생하고 있다.

웹쉘 실행 화면

이제부터 이러한 웹쉘에 대한 대응 방법에 대해 몇 가지 알아 보려고 한다.

우선 첫째로 당연한 것이겠지만 자신이 운영하고 있는 웹소스에서 보안 취약점을 제거해야 한다. 하지만 이것은 실제적으로 침해사고를 당하지 않는 한 탐지하기가 어려운 면이 있다. 특히 자신이 개발자가 아니고 단순히 운영만 하는 입장이라면 더욱 그렇다. 하지만 널리 알려진 웹 보안 취약점은 modsecurity 같은 무료 웹 방화벽으로 공격을 사전 차단 할 수 있을 뿐 아니라 차단 기능을 꺼 놓고 로그만 기록하게 해도 나중에 사고를 당했을시 로그 분석을 통해 원인을 찾는데 도움이 되므로 가능한 운영하는게 좋다. 공개 무료 웹방화벽 운영에 관한 자료는 정보보호진흥원에서 운영하는 다음 사이트에서 많은 도움을 받을 수 있다.

http://www.krcert.or.kr/firewall2/index.jsp

두번째는 필요없는 php 함수들은 사용 할 수 없게 하는 것도 하나의 방법이다. 설정은 php.ini에  다음과 같은 방법으로 할 수 있다.

대부분이 서버의 정보를 보여주는 설정들이다. 서비스에 별 필요 없는 기능들이고 서버에 어떠한 영향을 주는 함수들은 아니지만 해커에 의해 악용 될 수 있기 때문에 막아 놓은 것이 나을것이다.

disable_functions = php_uname, ini_set, getenv, get_user, phpversion, ini_get, ini_get_all, phpinfo, system, exec, passthru, escapeshellcmd, pcntl_exec, shell_exec

특히 주의할 점은 system, exec, passthru, escapeshellcmd, pcntl_exec, shell_exec 함수들은 서버상에서 운영체제 명령어를 실행 시키는 명령들이다. 일단 웹쉘이 업로드 되면 위의 함수들로 서버상에서 작업을 할 수 있으므로 막는게 좋으나 실제 운영되고 있는 홈페이지에서도 사용 할 수 있으므로 잘 알아 보고 필요한 함수는 빼고 설정 하는 것이 좋다.

세번째는 파일업로드 기능을 사용하지 않는다면 php.ini 에서 file_uploads 기능을 off 시키거나 파일 업로드를 한다면 업로드 디렉터리에.htaccess을 사용해 업로드 되는 디렉터리에서는 php를 아예 사용 할 수 없게 하는 것이다.

파일을 업로드 시키는 디렉터리에 다음과 같이 .htaccess 파일을 작성하자.

<FilesMatch ".(html|htm|php|pl|cgi|inc|lib)">

Order allow,deny

Deny from all

</FilesMatch>

해당 확장자로 끝나는 파일들은 접속이 금지된다.

이 방법은 해커가 웹쉘을 업로드 할 때도 사용 할 수 있다.

만약 php확장자를 가진 소스를 업로드 하지 못하게 했다면 해커는 다음과 같이 하여 확장자를 우회할 수 있다.

다음 내용을 가진 .htaccess파일을 업로드 시킨다.

AddType application/x-httpd-php  .txt

이후 txt 파일은 모두 php로 인식한다. 해커는 웹쉘의 확장자를 txt파일로 변경하여 서버에 올리면 된다. 마찬가지 방법으로 다음과 같은.htaccess 파일을 올려서 바이러스나 해킹툴을 설치하기도 한다.

ErrorDocument 403 http://www.hacktest.co.kr/hack.txt

ErrorDocument 404 http://www.hacktest.co.kr/hack.txt

이는 다음과 같은 명령어로 탐지가 가능하다.

find `locate .htaccess` -exec egrep -l -i ‘txt’ {} ; 2>/dev/null

find `locate .htaccess` -exec egrep -l ?I ‘http://’ {} ; 2>/dev/null

그 다음으로 할 일은 서버에 업로드 된 웹쉘을 제거하는 일이다. 한국 정보보호진흥원에서 개발한 웹 쉘 탐지 프로그램 Whistl을 이용하여 서버에 업로드 된 웹쉘을 제거 할 수 있다. 이 프로그램은 리눅스는 물론 윈도우에서도 동작하고 정확성도 높기 때문에 웹쉘 탐지 및 제거에 매우 추천 할 만한 프로그램이다.

프로그램은 다음 사이트의 공지사항에서 신청서를 작성한 후 신청하면 사용 할 수 있다.

http://www.krcert.or.kr/index.jsp

사용방법은 상당히 직관적이고 쉬운편이다. 보내온 프로그램의 압축을 풀면 프로그램과 함께 설명서에 사용법이 적혀져 있다. 다음과 같이 간단히 사용 할 수 있다.

./whistl_kernel_2.6 ?c

우선 자기 서버에 맞게 환경 설정을 해준다.

whistl Configuration

        [1] Checking Directory : /home/sungon

        [2] Inspection Center directory : /tmp

        [3] Extension of php     : inc,php,php3,php4,php5,ph

        [4] Extension of jsp     : jsp,js

        [s] save

        [q] quit

1번 메뉴를 누르고 검사할 디렉터리를 지정해 준다. /home 폴더 전체를 지정해 줄 수도 있다.

Choose Menu : 1

Checking Directory :/var/www/html

        [1] Checking Directory : /var/www/html

        [2] Inspection Center directory : /tmp

        [3] Extension of php     : inc,php,php3,php4,php5,ph

        [4] Extension of jsp     : jsp,js

        [s] save

        [q] quit

3번 메뉴을 누르고 검사할 파일의 확장자를 지정해 준다. txt확장자를 추가해 주었다.

Choose Menu : 3

Extension of php :inc,php,php3,php4,php5,ph,txt

        [1] Checking Directory : /var/www/html

        [2] Inspection Center directory : /tmp

        [3] Extension of php     : inc,php,php3,php4,php5,ph,txt

        [4] Extension of jsp     : jsp,js

        [s] save

        [q] quit

Choose Menu : s

        [1] Checking Directory : /var/www/html

        [2] Inspection Center directory : /tmp

        [3] Extension of php     : inc,php,php3,php4,php5,ph,txt

        [4] Extension of jsp     : jsp,js

        [s] save

        [q] quit

Choose Menu : q

다음과 같이 검사를 하면

./whistl_kernel_2.6

id : testid

pwd : password

Checking the configration

        [Config] Checking directory : /var/www/html

        [Config] Inspection Center directory : /tmp

Checking the update status

        [INFO] Pattern Update Finished

Checking /var/www/html directory

        [5 Found] /var/www/html/test2.php

        [18 Found] /var/www/html/test.txt

Check Result

        [INFO] 2 Files checked

        [INFO] 2 Suspected WebShell

        [INFO] Time cost : 00:00:10

        [INFO] Finish sending the checking result

웹쉘이 탐지되는 것을 알 수 있다. [5 Found] 나 [18 Found] 같은 숫자는 해당 파일에서 모두 5개의 웹쉘 패턴이 일치되었다는 것을 말한다. 5이상은 웹쉘이 거의 확실하지만 일치되는 패턴 숫자가 1이나 2이라면 정상적인 파일이 아닌지 확인해 봐야 한다. 경험상 1이나 2는 거의 정상적인 파일이고 패턴대응 숫자가 5이상이면 웹쉘이 확실하다고 보면 된다.

다만 아쉬운 점은 프로그램이 복수의 확장자를 지원하지 않는다는 사실이다. 아파치(apache)에서는 복수의 확장자를 지원하기 때문에webshell.php.test 같은 확장자를 가진 프로그램도 모두 php로 인식한다. 때문에 확장자를 약간만 변경하면 탐지프로그램을 우회할 수 있다.

이 부분은 추후에 개선이 되야 할 사항 같다.

리눅스를 사용하는 경우에는 디렉터리나 파일의 퍼미션에도 신경을 써야 한다. 777 퍼미션이나 파일이나 디렉터리에 apache나 nobody로 소유권을 설정하는 것은 가능한 피해야 한다.

업로드 디렉터리나 세션이 저장되는 디렉터리에는 어쩔 수 없이 707 퍼미션을 주어야 겠지만 그 외의 디렉터리에는 701 퍼미션을 주고 파일에는644 퍼미션을 준다. cgi같은 경우에는 755퍼미션을 주지 않으면 실행이 되지 않으므로 주의한다.

그외에도 /etc/cron.daily에 스크립트를 하나 만들어 다음과 같이 명령어에 제한을 걸어 슈퍼유저외에는 사용을 못하게 할 수도 있다.

#!/bin/sh

chmod 701 /

chmod 701 /home

cd /etc

chmod 600 fstab

chmod 600 hosts.*

chmod 600 modprobe.conf

chmod 600 sysctl.conf

chmod 600 redhat-release

cd /usr/bin

chmod 700 wget

chmod 700 lynx

chmod 700 curl

chmod 700 lwp-*

chmod GET

만약 사용되고 있는 서버가 여러 유저들이 모두 같이 사용하는 서버라서 명령어 제한이 자유롭지 못하다며 acl 기능을 사용해서 nobody권한의 유저만 제한을 걸 수 도 있다.

acl 기능은 다음과 같이 하면 사용 할 수 있다.

vi /etc/fstab

/dev/sda8               /                       ext3    defaults,acl        1 1

/dev/sda7               /usr                    ext3    defaults,acl        1 2

이렇게 acl을 옵션으로 붙여주고 다시 리마운트 한다.

mount -o remount /

mount -o remount /usr

다음과 같이 제한하고자 하는 명령어에 nobody유저만 접근이 안되게 한다.

setfacl -R -m u:nobody:- `which find`

setfacl -R -m u:nobody:- `which ls`

setfacl -R -m u:nobody:- `which chmod`

setfacl -R -m u:nobody:- `which echo`

setfacl -R -m u:nobody:- `which cat`

정책이 정확하게 적용이 되었는지 확인한다.

ls ?al `which find`

-rwxr-xr-x+ 1 root root 52460 Oct 20  2004 /usr/bin/find

끝에 +가 붙어 있으면 acl기능이 작동을 하는 것이다. acl기능을 제거 하려고 하면 다음과 같이 하면 된다.

setfacl -b /usr/bin/find

이상으로 웹 해킹 서버에 대한 간단한 분석 방법과 서버에서의 웹쉘에 대한 대처 방법에 대해 마치려고 한다. 웹서버 보안은 하나의 보안 어플리케이션으로 모든 것을 완벽하게 막을 수는 없다. 가능한 알고 있는 모든 방법을 다 적용하여서 조금씩 보안 허점을 줄여 나가는 수밖에 없다. 또한 리눅스 같은 경우 반드시 방화벽 정책을 수립하여 운영함으로써 해커가 서버를 악의적으로 운영하거나 외부로 공격을 하지 못하게 해야 한다. 이에 관해서는 차후에 다루어 보도록 하겠다.

[출처] 블루웹 | 시스템연구개발팀 양선곤 (http://blog.blueweb.co.kr)

가끔 접속 자 수도 많지도 않은데 로드가 높아서 서버 접속이 원활하지 못하다거나 나의 서버가 스팸서버로 지정 되어서 상대방에게 메일을 보냈는데도 차단되었다거나 혹은 idc 보안 관제 센터에서 당신네 서버가 외부로 ddos공격을 하고 있으니 빨리 조치를 취하지 않으면 네트워크를 차단시키겠다는 경고성 전화를 받았을 때 어떻게 조치를 취해야 하는지 막막할 경우가 있다.

이럴 경우 웹 해킹에 의해서 서버가 해커에 의해 조종되고 있지 않는지 살펴 볼 필요성이 있다. 이번에는 실제 사례를 가지고 웹 해킹 침해 사고 시 대처 방법을 소개해 보고자 한다.

 
해킹된 서버는 redhat9를 사용하고 있으며 커널 버전은 2.4.20-8이다. 웹서버는 apache + php + mysql 기반으로 돌아가고 있으며 앞으로 모든 설명을 여기에 맞추어서 진행 하려고 한다. (윈도우에 asp는 해당 사항이 아니다.) 

pstree

init-+-bdflush

     |-crond

     |-httpd-+-40*[httpd]

     |       `-2*[httpd---read.cgi]

     |-httpd---httpd

     |-httpd

     |-kapmd

     |-keventd

     |-khubd

     |-10*[kjournald]

     |-2*[klogd]

     |-kscand/DMA

     |-kscand/HighMem

     |-kscand/Normal

     |-ksoftirqd_CPU0

     |-kswapd

     |-kupdated

     |-mdrecoveryd

     |-6*[mingetty]

     |-named

     |-nohup---a---sshd---101*[sshd]

     |-perl

     |-rhnsd

     |-safe_mysqld---mysqld

     |-sshd---sshd---bash---pstree

     |-11*[sshd]

     |-syslogd

     |-vsftpd

     |-us1---us1

     |-us10---us11

     |-us12---us12

     |-us13---us13

     |-us14---us14

     |-us15---us15

     |-us16---us16

     |-us17---us17

     |-us18---us18

     |-us19---us19

     |-us2---us2

     |-us21---us21

     |-us22---us22

     `-xinetd

pstree명령어는 현재 돌아가고 있는 서버의 프로세스를 한눈에 파악할 수 있는 아주 중요한 명령어이다. 리눅스 사용자는 pstree명령어에 익숙해 져야 한다. 그냥 시간 날 때 마다 pstree치면서 나오는 결과를 눈에 익도록 하는 게 낫다.

위에 출력 결과를 한번 분석해 보도록 하자.

|-httpd-+-40*[httpd]

|       `-2*[httpd---read.cgi]

|-httpd---httpd

|-httpd

아파치 웹 서버가 돌아가면 위와 같은 프로세스가 보인다. 허나 진짜 웹 서버는 첫째 줄 뿐이다. 나머지는 두번째 줄과 세번째 줄은  웹 서버로 위조된 해킹 프로세스이다.

|-nohup---a---sshd---101*[sshd]

이 부분을 보자 외부로 ssh Login Brute force scan 공격을 하고 있다. 마찬가지로 us로 시작하는 프로세스도 모두 외부로 공격하는 해킹프로세스이다. 정상적인 서버에서는 절대 볼 수 없는 프로세스들이다. 이외에도 perl같은 프로세스도 비정상 프로세스이다.

현재 이 서버는 외부로 공격을 수행하는 해킹 프로세스들이 매우 많이 수행되고 있는 중이다.

포트 상태를 점검해서 좀더 자세한 상황을 살펴보자.

# netstat -nlp

Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address              Foreign Address   State                    PID/Program name  

tcp         0      0 0.0.0.0:3306                        0.0.0.0:*               LISTEN                655/                

tcp         0      0 0.0.0.0:80              0.0.0.0:*               LISTEN                26032/httpd        

tcp         0      0 0.0.0.0:2                             0.0.0.0:*               LISTEN                612/vsftpd         

tcp         0      0 192.168.10.1:53                    0.0.0.0:*               LISTEN                575/               

tcp         0      0 127.0.0.1:53                        0.0.0.0:*               LISTEN                575/               

tcp         0      0 0.0.0.0:22              0.0.0.0:*               LISTEN                588/sshd           

tcp         0      0 127.0.0.1:953                       0.0.0.0:*               LISTEN                575/               

udp        0      0 0.0.0.0:32768                       0.0.0.0:*                                          575/               

udp        0      0 0.0.0.0:37028                       0.0.0.0:*                           25089/sshd         

udp        0      0 0.0.0.0:37029                       0.0.0.0:*                           25479/httpd        

udp        0      0 192.168.10.1:53                    0.0.0.0:*                           575/               

udp        0      0 127.0.0.1:53                        0.0.0.0:*                           575/               

Active UNIX domain sockets (only servers)

Proto RefCnt Flags       Type       State         I-Node PID/Program name    Path

unix  2      [ ACC ]     STREAM     LISTENING     1318   655/                /var/lib/mysql/mysql.sock

정상적인 웹 서버는 다음과 같이 나타난다. 80포트가 열려져 있는 것을 알 수 있다. 26032는 실행되고 있는 아파치 프로세스의 pid이다.

tcp         0      0 0.0.0.0:80              0.0.0.0:*               LISTEN                26032/httpd

udp        0      0 0.0.0.0:37029                       0.0.0.0:*                           25479/httpd        

위의 프로세스를 보자. pid 25479인 이 프로세스는 아파치 웹서버 프로세스로 위장 되어 있지만 실질적으로는 37029번 포트로 서비스 되고 있는 hack 프로세스이다. 그리고 tcp가 아니 udp를 사용하고 있는 것도 눈에 띈다. sshd 프로세스도 마찬가지이다. 22번 포트를 LISTEN하고 있는pid 588 프로세스가 정상적인 sshd 프로세스이다. 25089프로세스는 sshd로 위장된 비 정상적인 프로세스이다.

3306포트와 53번 포트를 리슨하고 있는 것은 각각 mysqld와 named프로세스로 정상적인 프로세스들이다.

이제는 좀더 깊이 들어가서 이 프로세스들이 어디서 실행되고 있는지 한 번 살펴 보자.

lsof -p 25479

lsof 명령어는 파일과 프로세스의 입출력 상태를 나타내주는 명령어로 pstree와 netstat 다음으로 사용법을 잘 익혀둘 필요가 있는 매우 유용한 명령어이다. p옵션은 프로세스 id의 입출력 상태를 나타내주는 옵션으로 다음 부분을 살펴볼 필요가 있다.

COMMAND   PID   USER   FD   TYPE    DEVICE    SIZE      NODE NAME

httpd       25479      apache   cwd       DIR         0,8     280 321300582 /dev/shm/bq

httpd       25479      apache   txt          REG       0,8  612470 321300590 /dev/shm/bq/httpd

httpd       25479      apache   0u          IPv4        563618039 TCP 192.168.10.1:48562

->irc2.saunalahti.fi:ircd (ESTABLISHED)

httpd   25479 apache    5u   REG       3,7       0        55 /tmp/ZCUDUzGlho (deleted)

httpd   25479 apache    6u  IPv4 321303856               UDP *:37029

일단 이 위장 프로세스가 실행되고 있는 위치는  /dev/shm/bq/httpd라는 것을 알 수 있다.

192.168.10.1:48562->irc2.saunalahti.fi:ircd (ESTABLISHED)

이 부분을 주의 깊게 살펴 보자. 현재 해킹된 서버에서 irc2.saunalahti.fi 서버의 6667(ircd)포트로 접속 되어 있는 것을 알 수 있다. 즉 이 서버는 현재 좀비 컴퓨터화 되어 있다. 한마디로 말해서 해커가 원격에서 irc bot을 이용하여 이 서버를 자신이 원하는 데로 조종할 수 있다는 말이다. 이러한 좀비 컴퓨터를 대량으로 확보하면 해커는 보통 분산 서비스 거부 공격(DDOS ATTACK)을 하는데 이용하거나 돈을 받고 팔기도 한다. 특히IDC에 상주되어 있는 서버가 해커 손에 넘어가면 최대 100M급의 트래픽 공격을 할 수 있는 든든한 무기를 손에 넣게 된다.

USER부분을 살펴보자 apache라고 되어 있다. 현재 이 서버에서 실행되고 있는 웹서버의 권한이 apache로 웹해킹을 통해서 서버의 apache권한을 획득한 것을 볼 수 있다.

다음과 같은 명령으로 이서버의 전체적인 입출력 상태를 체크해 볼 수 있다.

lsof ?I ?n |grep apache

문제가 되는 apache권한만 살펴 보면 다음과 같은 입출력 상태가 2~300개씩 나타나고 있었다.

sshd    23901 apache    8u  IPv4 397205096       TCP 192.168.10.1:56970->217.18.114.168:ssh (ESTABLISHED)

외부에 ssh스캔 공격을 하고 있을 때의 대표적 증상이다. 만약 다량의 스팸 메일을 보낸다면 외부 ip의 25번포트(SMTP포트)로 수많은 연결이 보일 것이다. 이 외에도 ircd로의 접근도 포착 될 것이다.

lsof 명령어는 서버의 입출력 상태를 점검할 때 매우 유용한 명령어이니 잘 익혀두는 것이 좋다.

일단 hack process가 설치된 /dev 디렉터리를 좀더 자세히 점검해 보자.

find /dev ?type f

일단 정상적인 경우를 살펴보자

/dev/.udev.tdb

/dev/MAKEDEV

centos5같은 경우

/dev/.udev 디렉토리와 그 아래 디렉토리만 파일들만 있어야지 정상이다.

find 명령어로 살펴보니 아래와 같은 많은 수많은 hack tool들이 설치 되어 있는 것을 확인 할 수 있었다.

/dev/MAKEDEV

/dev/shm/stopex.pl

/dev/shm/bq/raw.session

/dev/shm/bq/Presedinte.seen

/dev/shm/bq/Silvic.seen

/dev/shm/bq/RamonaT.seen

/dev/shm/bq/httpd

…

/dev/shm/bq/3

/dev/shm/st/src/dcc.c

/dev/shm/st/src/parse.c

/dev/shm/st/src/main.c

/dev/shm/st/src/gencmd.c

/dev/shm/st/src/Makefile

웹쉘 권한을 얻었을 때 이와 같은 툴들이 설치되는 이유는 퍼미션 때문이다.

ll ?ld /dev/shm

drwxrwxrwt 2 root root 40 Nov  6 13:33 /dev/shm

/dev/shm, /var/tmp, /tmp 폴더등은 1777권한을 가지고 있기 때문에 웹쉘을 통해 권한을 얻었을 경우 쉽게 해킹툴들을 업로드 하고 이를 실행 시키는데 사용되는 디렉터리로 평소 주의를 기울여 관리해야 한다. 이외에도 디렉터리에 apache나 nobody유저에 쓰기 권한을 주거나 777같은 퍼미션을 주는 경우는 매우 잘못된 습관이라고 할 수 있다.

# cd /dev/shm/st

[root@canacom st]# ll

합계 836

-rwxr-xr-x    1 apache   apache       2156  7월 11  2005 Makefile

-rwxr-xr-x    1 apache   apache      20358  1월  2  2003 configure

…

-rwxr-xr-x    1 apache   apache     585643  1월  4  2007 sshd

-rwxr-xr-x    1 apache   apache      17495  1월  4  2007 stealth

보면 apache권한을 가지고 있는 것을 알 수 있다.

lsof 명령어로 보여주는 결과 값이 너무 길어서 의미가 있는 것 만 적었다. 다음 perl명령어는 원격에서 root로 쉘 권한을 가지고 직접 접속해서 명령을 내린 것으로 해커가 어떤 방법을 써서 아파치 권한에서 root로 권한이 상승 된 것을 확인 할 수 있다.

lsof -p 6411

COMMAND  PID USER   FD   TYPE    DEVICE     SIZE   NODE NAME

perl    6411 root  cwd    DIR       3,7     4096  87745 /tmp/.tmp

perl    6411 root  rtd    DIR      22,9     4096      2 /

perl    6411 root  txt    REG       3,5    12572  33642 /usr/bin/perl

perl    6411 root    0u   CHR     136,1               3 /dev/pts/1

perl    6411 root    1u   CHR     136,1               3 /dev/pts/1

perl    6411 root    2u   CHR     136,1               3 /dev/pts/1

perl    6411 root    3r   REG       3,7   116030  87748 /tmp/.tmp/bnc

perl    6411 root    4u  IPv4 398045837             TCP *:24338 (LISTEN)

perl    6411 root    5r   DIR       3,7     4096  43873 /tmp/.tmp/logs

perl    6411 root    6u  IPv4 398046908             TCP 192.168.10.1:24338->189.14.64.131:1327 (ESTABLISHED)

perl    6411 root    7u  IPv4 398046908             TCP 192.168.10.1:24338->189.14.64.131:1327 (ESTABLISHED)

perl    6411 root    8u  IPv4 398049150             TCP 192.168.10.1:35825->own.ipapo.org:ircd (ESTABLISHED)

다음 부분을 주목해서 보자.

perl    6411 root    0u   CHR     136,1               3 /dev/pts/1

원격 터미널을 통해서 슈퍼유저 권한으로 로그인한 것으로 추정된다. 이 상태에서 이미 최상위 권한을 탈취했으므로 이 시스템은 완전히 해커에게 장악 당했다고 볼 수 있다.

다음과 같은 명령으로 서버에서 실행되는 백 도어 프로세스에 관한 좀더 자세한 정보를 알 수 있다. 테크노트 게시판의 취약점을 이용해서 원격에서 쉘 명령어를 실행 시킨 것을 알 수 있다.

#ps -auxe --cols=3000

/usr/sbin/sshd shd _CMD=cd /dev/shm/n; nohup ./start 217 >>/dev/null & 2>&1;pwd SERVER_SIGNATURE=<ADDRESS>Apache/1.3.31 Server at test.co.kr

Port 80</ADDRESS>?

HTTP_USER_AGENT=Getter/0.1

SERVER_PORT=80

HTTP_HOST=www.test.co.kr

DOCUMENT_ROOT=/home/test/public_html SCRIPT_FILENAME=/home/test/public_html/technote/main.cgi REQUEST_URI=/technote/main.cgi?down_num=784879&board=any&command=down_load&filename=getfile.txt%3Bsh%20-c%20%22%24HTTP_CMD%22| SCRIPT_NAME=/technote/main.cgi

REMOTE_PORT=55507

PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin

HTTP_TE=deflate;q=0.3

PWD=/dev/shm/n

QUERY_STRING=down_num=784879&board=any&command=down_load&filename=getfile.txt%3Bsh%20-c%20%22%24HTTP_CMD%22|

SERVER_ADDR=192.168.10.1

GATEWAY_INTERFACE=CGI/1.1

SERVER_PROTOCOL=HTTP/1.0

REQUEST_METHOD=GET _=./sshd

테크노트 cgi 관한 원격 명령어 실행 취약점은 국정원에서 발표한 보안 취약점 8종의 한가지로 반드시 최신 버전의 테크노트로 업그레이드 하여야 한다.

또한 php를 사용할 경우는 반드시 php.ini 파일에

allow_url_fopen = Off

register_globals = Off

로 해놓는 것을 명심하자. 지금까지 경험한 바로 php경우 대부분 저 두 옵션으로 인하여 문제가 발생했다.

또한 php 개발자분들께 당부하고 싶은 것은 위의 두 옵션을 끄고 코딩을 해야 한다는 것이다. 그렇지 않을 경우 원한 던 그렇지 않던 잠재적인 보안 위협을 가진 소스를 만들어 내게 된다.

지금까지 웹 해킹 침해 사고를 당한 시스템을 간단하게 분석해 보았다. pstree, netstat, lsof, ps 명령어등은 리눅스에서 트러블슈팅을 하는데 정말 요긴하게 사용하는 명령어이므로 사용법을 자세하게 알아둘 필요가 있다. 일단 해커가 웹 쉘 권한을 얻으면 가능한 모든 디렉터리에 웹 쉘을 업로드 하여 하나의 침입경로가 막히면 다른 경로로 들어오기 때문에 대처하는데 어려움이 따른다.

그렇기 때문에 다시 한번 강조하지만 allow_url_fopen = Off, register_globals = Off 잊지 말도록 하자.

다음에는 웹 원격 취약점을 통해 해커가 서버에 침입했을 경우 서버에서의 대응 방법에 대해 알아 보도록 하겠다.

[출처] 블루웹 | 시스템연구개발팀 양선곤 (http://blog.blueweb.co.kr)

불법 접근(SSH 무작위 접속시도, 스패머 릴레이 시도) 자동 차단, 통보 스크립트  
" 아래의 메세지가 /var/log/message
check pass; user unknown
Aug  9 14:17:40 localhost sshd(pam_unix)[9144]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=

vi  sshsecurity.sh
======================================================================================

#!/bin/sh

IPTABLES="/sbin/iptables" # iptables 의 절대 경로
#IPTABLES="/usr/local/sbin/iptables" # iptables 의 절대 경로
NUMBER=20   ## 1일 Block 적용 대상에 포함될 최대 체크 횟수 (Default:하루에 10번 이상 체킹 되면 해당 IP 패킷은 모두 DROP)
ORDER=4     ## iptables 정책에 몇번째 라인에 DROP 라인을 삽입할것인가 (Default:4번째 라인에 삽입)

## 작업디렉토리 지정, 없을시 생성
if [ ! -d "/root/root_dir" ] ; then
                mkdir -p "/root/root_dir"
                chmod 700 "/root/root_dir"
fi
#########################################
##### 211.43.205.124를 자기 서버 아피를 적는다.    #
########################################
## 최초 실행시(/root/root_dir/iptables.deny 파일이 비존재시) 실행되는 부분

if [ ! -f /root/root_dir/iptables.deny ]; then
        cd /root/root_dir

        grep "illegal" /var/log/messages | egrep -v "211.43.205.124" | awk '{print $9 $13}' > temp
        sed -e "s/illegal//g" temp > iptables.deny.tmp

        grep "Invalid" /var/log/messages | egrep -v "211.43.205.124" | awk '{print $6 $10}' > temp
        sed -e "s/Invalid//g" temp >> iptables.deny.tmp

        grep "invalid" /var/log/messages | egrep -v "211.43.205.124" | awk '{print $9 $13}' > temp
        sed -e "s/invalid//g" temp >> iptables.deny.tmp

        grep "authentication failure" /var/log/messages | egrep -v "211.43.205.124" | awk '{print $9 $13}' | awk -F"host=" '{print $2}' > temp
        #빈줄 없앰
        sed -e "/^$/d" temp > temp.tmp
        mv temp.tmp temp
        sed -e "s/uid=0rhost=//g" temp >> iptables.deny.tmp

        grep "Relaying denied" /var/log/maillog | egrep -v "211.43.205.124" | awk '{print $9}' | awk -F"[" '{print $2}' | awk -F"]" '{print $1}' > temp
        #빈줄 없앰
        sed -e "/^$/d" temp > temp.tmp
        mv temp.tmp temp
        sed -e "s/^//g" temp >> iptables.deny.tmp

if [ -s /root/root_dir/iptables.deny.tmp ]; then
sort iptables.deny.tmp | uniq > iptables.deny.uniq
# 일정 횟수 이상만 차단
for block_ip in $(cat iptables.deny.uniq)
        do
                num=`grep "$block_ip" iptables.deny.tmp | wc -l`
                if [ $num -gt $NUMBER ]
                        then
                        echo $block_ip >> iptables.deny
                fi
done

if [ -s /root/root_dir/iptables.deny ]; then
        sort iptables.deny | uniq > iptables.deny.uniq
        mv iptables.deny.uniq iptables.deny
fi
        ## 포착된 IP 관리자 메일로 통보
        if [ -s /root/root_dir/iptables.deny ]; then
        mail -s "[IPTABLES]불법 접근 IP 발견!! 방화벽:ALL 포트 차단" root@localhost < iptables.deny
        fi
        
        ## 방화벽 정책에 DROP 정책 추가
        if [ -s /root/root_dir/iptables.deny ]; then
        for DENY_LIST in $(cat iptables.deny);
                do $IPTABLES -I INPUT $ORDER -s $DENY_LIST -j DROP;
        done;
        fi

        rm -f /root/root_dir/temp
        rm -f /root/root_dir/illegal
        rm -f /root/root_dir/invalid
        rm -f /root/root_dir/authentication
        rm -f /root/root_dir/smtp_block
        rm -f /root/root_dir/iptables.deny.tmp

fi
else

### 최초 실행이 아닐경우에 구동되는 부분(/root/root_dir/iptables.deny 파일이 존재하고 있을경우)
cd /root/root_dir

sort iptables.deny | uniq > iptables.deny.uniq
mv iptables.deny.uniq iptables.deny
#빈줄 없앰
sed -e "/^$/d" iptables.deny > iptables.deny.uniq
mv iptables.deny.uniq iptables.deny

grep "illegal" /var/log/messages | egrep -v "211.43.205.124" | awk '{print $9 $13}' > temp
sed -e "s/illegal//g" temp > iptables.deny.tmp

grep "Invalid" /var/log/messages | egrep -v "211.43.205.124" | awk '{print $6 $10}' > temp
sed -e "s/Invalid//g" temp >> iptables.deny.tmp

grep "invalid" /var/log/messages | egrep -v "211.43.205.124" | awk '{print $9 $13}' > temp
sed -e "s/invalid//g" temp >> iptables.deny.tmp

grep "authentication failure" /var/log/messages | egrep -v "211.43.205.124" | awk '{print $9 $13}' | awk -F"host=" '{print $2}' > temp
#빈줄 없앰
sed -e '/^$/d' temp > temp.tmp
mv temp.tmp temp
sed -e "s/uid=0rhost=//g" temp >> iptables.deny.tmp

grep "Relaying denied" /var/log/maillog | egrep -v "211.43.205.124" | awk '{print $9}' | awk -F"[" '{print $2}' | awk -F"]" '{print $1}' > temp
#빈줄 없앰
sed -e '/^$/d' temp > temp.tmp
mv temp.tmp temp
sed -e "s/^//g" temp >> iptables.deny.tmp

if [ -s /root/root_dir/iptables.deny.tmp ]; then
sort iptables.deny.tmp | uniq > iptables.deny.uniq
# 일정 횟수 이상만 차단
for block_ip in $(cat iptables.deny.uniq)
        do
                num=`grep "$block_ip" iptables.deny.tmp | wc -l`
                if [ $num -gt $NUMBER ]
                        then
                        echo $block_ip >> iptables.deny.tmp.tmp
                fi
done

if [ -s /root/root_dir/iptables.deny.tmp.tmp ]; then
sort iptables.deny.tmp.tmp | uniq >> iptables.deny.tmp.tmp.uniq
mv iptables.deny.tmp.tmp.uniq iptables.deny.tmp.tmp

diff iptables.deny.tmp.tmp iptables.deny | awk -F"< " '{print $2}' > deny.new
#빈줄 없앰
sed -e '/^$/d' deny.new > deny.new.tmp
mv deny.new.tmp deny.new

sort deny.new | uniq >> deny.new.tmp
mv deny.new.tmp deny.new
fi

## 포착된 IP 관리자 메일로 통보
if [ -s /root/root_dir/deny.new ]; then
        mail -s "[IPTABLES]불법 접근 IP 발견!! 방화벽:ALL 포트 차단" root@localhost < /root/root_dir/deny.new
fi

## 방화벽 정책에 DROP 정책 추가
if [ -s /root/root_dir/deny.new ]; then
for DENY_LIST in $(cat deny.new);
        do $IPTABLES -I INPUT $ORDER -s $DENY_LIST -j DROP;
done;
cat deny.new >> iptables.deny

fi

## 스크립트 실행 중 생성된 임시 파일들 삭제
rm -f /root/root_dir/temp
rm -f /root/root_dir/illegal
rm -f /root/root_dir/invalid
rm -f /root/root_dir/authentication
rm -f /root/root_dir/smtp_block
rm -f /root/root_dir/deny.new
rm -f /root/root_dir/iptables.deny.tmp
rm -f /root/root_dir/iptables.deny.tmp.tmp

sort iptables.deny | uniq > iptables.deny.uniq
mv iptables.deny.uniq iptables.deny
#빈줄 없앰
sed -e '/^$/d' iptables.deny > iptables.deny.uniq
mv iptables.deny.uniq iptables.deny

fi

fi

cd - > /dev/null 2>&1

======================================================================================

* 위의  스크립트를  임의의 파일명으로
 /etc/cron.1min/sshsecurity.sh  아래에 위치시키고,

 /etc/crontab 에 */1 * * * * root run-parts /etc/cron.1min

라인을 추가시키면 매, 1분마다 불법접근을 분석후 차단시킴.

* 하루에 10번(패스워드 입력 실패, 불법 릴레이 시도, 비존재 계정 접근 시도 등..)의 제한을 두었으므로, 로그파일(/var/log/messages)역시 하루에 한번 로테이션 되게 설정.

* 매일 리셋되어야 하므로,  /root/root_dir/iptables.deny 파일 내용을 하루에 한번 리셋(클리어) 해주어야 함
- 리셋 스크립트 내용을 아래의 디렉토리에 만들어주고 (/etc/cron.daily/reset_iptables_deny.sh)
======================================================================================
#!/bin/bash
cat /root/root_dir/iptables.deny >> /root/root_dir/iptables.deny_history
cat /dev/null > /root/root_dir/iptables.deny
uniq /root/root_dir/iptables.deny_history > /root/root_dir/iptables.deny_history.tmp
mv /root/root_dir/iptables.deny_history.tmp /root/root_dir/iptables.deny_history
/etc/rc.d/rc.firewall
======================================================================================

* 방화벽 구동시 차단된 아이피 자동 로딩 부분 추가 
 (/etc/rc.d/rc.firewall 파일 하단에 아래 스크립트 추가)함
======================================================================================
############# 불법 접근 시도 IP 차단 (해당 스크립트 구동시) #########################
if [ -s /root/root_dir/iptables.deny ]; then
for DENY_LIST in $(cat /root/root_dir/iptables.deny);
        do $IPTABLES -I INPUT 4 -s $DENY_LIST -j DROP;
#### 4 는 정책이 들어간 순서(몇번째 라인에 삽입할것인가 임)
done;
fi
======================================================================================

[root@sysdocu ~]# find ./ | egrep -i ".php|.htm|.html" | xargs grep -ri 'iframe src="http' | awk -F: '{print $1}' | xargs ls -l

위의 명령어를 사용하시면 됩니다.

고객님 다른 서버에서 사용하실 경우에 위의 명령이 되지 않는 경우가 있습니다.

커널의 차이때문인데, 이 경우 아래의 명령어로 확인이 가능합니다.

[root@sysdocu ~]find ./ | grep ".*/.*..*" | xargs grep -r "iframe src="./.*http"
또는

[root@sysdocu ~]find ./ -exec grep -l 'iframe' {} ;

f-prot 리눅스용 홈버젼을 다운받는다.

# cd /root

# wget http://files.f-prot.com/files/unix-trial/fp-Linux-x86_32-ws.tar.gz

# tar xvfz fp-Linux-i686-ws.tar.gz

# cd f-prot

# ./install-f-prot.pl

그냥 무조건 엔터 엔터 로 설치...

▶바이러스 스캔 방법

# fpscan -a

--------------------------------------------------------------
fpscan -a                    하드 전체 검사(스캔만)
fpscan -a --disinfect        하드 전체 검사(스캔만)+자동치료
fpscan /test                 /test 디렉토리만 검사
fpscan -b                    부팅섹터만 검사
fpscan / --exclude=*.doc     확장자 hwp인 파일만 제외하고 검사
fpscan / --exclude=/var/     / 밑에 var 폴더만 제외하고 검사
---------------------------------------------------------------

스캔화면

---------------------------------------------------------------------------------------------------------------

F-PROT Antivirus version 6.3.3.5015 (built: 2009-12-23T13-43-55)

FRISK Software International (C) Copyright 1989-2009
Engine version:   4.5.1.85
Arguments:        -a 
Virus signatures: 201011301301fba630179f01eccae250deb4f6029fd5
                  (/root/f-prot/antivir.def)

[Found possible security risk] <w32 eldorado="Eldorado" heuristic-210="Heuristic-210" damaged="damaged" not="not" disinfectable="disinfectable">        /util/ftp_data/security/blackenergy_11.9.2_ddos_tool.zip->Black Energy 1.9.2.exe->(embedded)->(YZPack)
[Contains infected objects]     /util/ftp_data/security/blackenergy_11.9.2_ddos_tool.zip      </w32>

Scanning: /

----------------------------------------------------------------------------------------------------------------

▶백신 자동 업데이트 방법

# crontab -e
---------------------------------------------------
30 * * * * root /root/f-prot/fpupdate > /dev/null
---------------------------------------------------

[출처] ::: 인생은 끝없는 삽질이다. ::: | 삽질맨 (http://blog.naver.com/nforce7050?Redirect=Log&logNo=140119066453)

/etc/sysctl.conf 파일에 아래내용 삽입

net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2

저장후 아래명령어로 적용합니다.

# sysctl -p