승하연서빠의 작업 메모

$ tar cvf - * | ssh root@[Target IPAddress] tar xf - -C [Target Directory]

# vsftpd 주요 서비스

# vsftpd 관련 파일

# 계정별 vsftpd 접속제한 파일

# /etc/vsftpd/vsftpd.conf 설정옵션

출처 : http://oracle.tistory.com/129 (안나푸르나)

SFTP는 기본적으로 로그를 남지 않습니다, 때문에 파일의 변경/삭제가 어떻게 된 것인 찾기가 곤란할 수 있습니다.

이번에 소개해 드릴 openssh 및 syslog의 간단한 설정으로 SFTP 작업 로그 남기는 방법에 대해 소개 드립니다.

1. /etc/ssh/sshd_config 의 편집

아래의 라인을 수정이나 추가해 줍니다.
보통 ‘Subsystem’이 주석 처리되어 있을 것이니 주석을 해제하고 아래와 같이 수정/추가해 주시면 됩니다.

추가할 내용 : Subsystem       sftp    /usr/libexec/openssh/sftp-server -f local2 -l INFO

명령: # echo “Subsystem       sftp    /usr/libexec/openssh/sftp-server -f local2 -l INFO” >> /etc/ssh/sshd_config
          # tail /etc/ssh/sshd_config

sftp-server에 대한 자세한 설정 사항은 “man sftp-server” 로 옵션 사항을 참고하세요.

2. syslog.conf 나 rsyslog.con 파일 수정

저는 경우 rsyslog를 사용하여 /etc/rsyslog.conf 에 내용을 추가 했습니다.

추가 내용  : local2.*                                        /var/log/sftp.log

명령: # echo “local2.*                                        /var/log/sftp.log” >> /etc/rsyslog.conf
         # tail /etc/rsyslog.conf

3. 로그 파일 생성 : sftp.log

sftp.log 파일은 syslog나 rsyslog 서비스를 재시작 해주면 자동으로 생성이 된다, 만약 생성이 되지 않았을 경우 다음 명령으로 생성해 줍니다.

명령:  # touch /var/log/sftp.log

4. rsyslog, sshd,서비스 재시작

명령 : # /etc/init.d/rsyslog restart 또는 /etc/init.d/syslog restart
          # /etc/init.d/sshd restart

5. 로그 남김 확인
sftp 테스트 접속 후 로그를 보자

명령 : # tail -f /var/log/sftp.log

6. 로그로테이트 추가
로그가 기록되는 것이 확인되었다면, 마지막으로 로그로테이트에 sftp.log를 추가하여, 일정 용량 이상일 경우 로그를 백업하도록 하자.
/etc/logrotate.d/syslog 에 “/var/log/sftp.log” 를 추가하자.

sftp 로그를 남겨보자.

sftp 로그는 남지 않습니다. 그 방식이 inet 방식이 되었든 standalone가 되었든 안남습니다.
왜 남지 않을까요?
생각해보았지만, ftp로그에도 별도로 남지는 않더라구요.

ftp 로그는 저는 xferlog로 남기지만, 암튼 남지 않는건 확실합니다. 

vi /etc/ssh/sshd_config 
루트로 로그인 하여 다음의 설정 상황을 살펴봅시다.
119 # override default of no subsystems
120 Subsystem       sftp    /usr/libexec/openssh/sftp-server -f local2 -l INFO

편의상 set nu로 줄표시를 하였습니다. 

이것과 상관이 있지는 않습니다. 

일단 멘페이지에서 관련된 메뉴얼을 확인해보았습니다. 
번역을 할까 말까 했는데, 우리가 관심있게 봐야 할 것은 로그레벨 설정하는 것과 로그 패실리티 설정하는 것 두개만 존재한다고 보면
될것 같습니다. 

man sftp-server
SFTP-SERVER(8)            BSD System Manager’s Manual           SFTP-SERVER(8)

NAME
     sftp-server - SFTP server subsystem

SYNOPSIS
     sftp-server [-f log_facility] [-l log_level]

DESCRIPTION
     sftp-server is a program that speaks the server side of SFTP protocol to stdout and expects client requests from
     stdin.  sftp-server is not intended to be called directly, but from sshd(8) using the Subsystem option.

     Command-line flags to sftp-server should be specified in the Subsystem declaration.  See sshd_config(5) for more
     information.

     Valid options are:

     -f log_facility
             Specifies the facility code that is used when logging messages from sftp-server.  The possible values
             are: DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7.  The default is
             AUTH.

     -l log_level
             Specifies which messages will be logged by sftp-server.  The possible values are: QUIET, FATAL, ERROR,
             INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3.  INFO and VERBOSE log transactions that sftp-server
             performs on behalf of the client.  DEBUG and DEBUG1 are equivalent.  DEBUG2 and DEBUG3 each specify
             higher levels of debugging output.  The default is ERROR.

     For logging to work, sftp-server must be able to access /dev/log.  Use of sftp-server in a chroot configuation
     therefore requires that syslogd(8) establish a logging socket inside the chroot directory.

SEE ALSO
     sftp(1), ssh(1), sshd_config(5), sshd(8)

     T. Ylonen and S. Lehtinen, SSH File Transfer Protocol, draft-ietf-secsh-filexfer-00.txt, January 2001, work in
     progress material.

AUTHORS
     Markus Friedl 〈markus@openbsd.org〉

HISTORY
     sftp-server first appeared in OpenBSD 2.8 .

BSD                             August 30, 2000                            BSD
(END) 

그 다음은 로그를 관리해야 할 부분을 세팅해야 합니다. 

vi /etc/syslog.conf 
35 local2.*                                        /var/log/sftp.log
가장 바닥에 셋팅하면 됩니다.

여기가 좀 중요한것 같은데,
syslog 재시작 해주고, sshd 재시작해주면 됩니다. 
순서가 중요하다고 이런 저런 사이트에서 보면 있네요.

되는지 안되는지 확인해보면 됩니다. 

tail -f /var/log/sftp.log 
Apr 16 17:59:02 www sftp-server[2985]: debug1: request 291: sent names count 1
Apr 16 17:59:02 www sftp-server[2985]: debug1: read eof
Apr 16 17:59:02 www sftp-server[2985]: session closed for local user 

되는 것을 확인합니다.

1. 먼저 /etc/inetd.conf 파일에서 FTP부분을 수정한다.

출처: http://egloos.zum.com/donquite/v/8860506

서버 구축시에 iptables를 꺼두고 차후에 관련 사항등을 업데이트 하거나 잊고 사는 분들이 많을꺼라 본다. 처음에 iptables를 접하면 방화벽 규칙 작성하는게 여간 복잡해 보이는 것이 아니기 때문이다. 홈서버의 경우 대부분 공유기를 사용할텐데, 이를 믿고 등한시하기도 할테다. 행여나 iptables가 궁금해졌다면 잘 찾아왔다.

iptalbes란?

iptables란 넷필터 프로젝트에서 개발했으며 광범위한 프로토콜 상태 추적, 패킷 애플리케이션 계층검사, 속도 제한, 필터링 정책을 명시하기 위한 강력한 매커니즘을 제공한다.

서비스 등록과 시작

CentOS 6.4 Minimal에는 iptables가 설치되어 있다. ip6tables도 함께 설치되어 있는데 이는 IPv6 체계에서 사용한다.

rpm -qa | grep iptables

  iptables-1.4.7-9.el6.x86_64
  iptables-ipv6-1.4.7-9.el6.x86_64

설치되어 있지 않다면 설치

yum -y install iptables 

상태 확인

chkconfig --list

  ip6tables 0:해제  1:해제  2:해제  3:해제  4:해제  5:해제  6:해제
  iptables 0:해제  1:해제  2:해제  3:해제  4:해제  5:해제  6:해제

서비스를 시작프로그램에 등록한다.

chkconfig iptables on

서비스를 시작한다.

service iptables start

iptables의 파일위치는 /etc/sysconfig/iptables 이다.

iptables 용어

어려운 용어들은 제껴두고 간략히 사용할 부분에 대해서 설명한다.

1) 테이블(tables)

우선 iptables에는 테이블이라는 광범위한 범주가 있는데, 이 테이블은 filter, nat, mangle, raw 같은 4개의 테이블로 구성되며, 이중에서 우리에게 필요한 것은 필터링 규칙을 세우는 filter 테이블이다.

2) 체인(chain)

iptables에는 filter 테이블에 미리 정의된 세가지의 체인이 존재하는데 이는 INPUT, OUTPUT, FORWARD 이다. 이 체인들은 어떠한 네트워크 트래픽(IP 패킷)에 대하여 정해진 규칙들을 수행한다.

가령 들어오는 패킷(INPUT)에 대하여 허용(ACCEPT)할 것인지, 거부(REJECT)할 것인지, 버릴(DROP)것인지를 결정한다.

• INPUT : 호스트 컴퓨터를 향한 모든 패킷
• OUTPUT : 호스트 컴퓨터에서 발생하는 모든 패킷
• FORWARD : 호스트 컴퓨터가 목적지가 아닌 모든 패킷, 즉 라우터로 사용되는 호스트 컴퓨터를 통과하는 패킷

3) 매치(match)

iptables에서 패킷을 처리할때 만족해야 하는 조건을 가리킨다. 즉, 이 조건을 만족시키는 패킷들만 규칙을 적용한다.

• --source (-s) : 출발지 IP주소나 네트워크와의 매칭
• --destination (-d) : 목적지 ip주소나 네트워크와의 매칭
• --protocol (-p) : 특정 프로토콜과의 매칭
• --in-interface (i) : 입력 인테페이스
• --out-interface (-o) : 출력 인터페이스
• --state : 연결 상태와의 매칭
• --string : 애플리케이션 계층 데이터 바이트 순서와의 매칭
• --comment : 커널 메모리 내의 규칙과 연계되는 최대 256바이트 주석
• --syn (-y) : SYN 패킷을 허용하지 않는다.
• --fragment (-f) : 두 번째 이후의 조각에 대해서 규칙을 명시한다.
• --table (-t) : 처리될 테이블
• --jump (-j) : 규칙에 맞는 패킷을 어떻게 처리할 것인가를 명시한다.
• --match (-m) : 특정 모듈과의 매치

4) 타겟(target)

iptables는 패킷이 규칙과 일치할 때 동작을 취하는 타겟을 지원한다.

• ACCEPT : 패킷을 받아들인다.
• DROP : 패킷을 버린다(패킷이 전송된 적이 없던 것처럼).
• REJECT : 패킷을 버리고 이와 동시에 적절한 응답 패킷을 전송한다.
• LOG : 패킷을 syslog에 기록한다.
• RETURN : 호출 체인 내에서 패킷 처리를 계속한다.

REJECT는 서비스에 접속하려는 사용자의 액세스를 거부하고 connection refused라는 오류 메시지를 보여주는 반면 DROP은 말 그대로 telnet 사용자에게 어떠한 경고 메시지도 보여주지 않은 채 패킷을 드롭한다. 관리자의 재량껏 이러한 규칙을 사용할 수 있지만 사용자가 혼란스러워하며 계속해서 접속을 시도하는 것을 방지하려면 REJECT를 사용하는 것이 좋다.

5) 연결 추적(Connection Tracking)

iptables는 연결 추적(connection tracking)이라는 방법을 사용하여 내부 네트워크 상 서비스 연결 상태에 따라서 그 연결을 감시하고 제한할 수 있게 해준다. 연결 추적 방식은 연결 상태를 표에 저장하기 때문에, 다음과 같은 연결 상태에 따라서 시스템 관리자가 연결을 허용하거나 거부할 수 있다.

• NEW : 새로운 연결을 요청하는 패킷, 예, HTTP 요청
• ESTABLISHED : 기존 연결의 일부인 패킷
• RELATED : 기존 연결에 속하지만 새로운 연결을 요청하는 패킷, 예를 들면 접속 포트가 20인 수동 FTP의 경우 전송 포트는 사용되지 않은 1024 이상의 어느 포트라도 사용 가능하다.
• INVALID : 연결 추적표에서 어디 연결에도 속하지 않은 패킷

상태에 기반(stateful)한 iptables 연결 추적 기능은 어느 네트워크 프로토콜에서나 사용 가능하다. UDP와 같이 상태를 저장하지 않는 (stateless) 프로토콜에서도 사용할 수 있다.

6) 명령어(commond)

• -A (--append) : 새로운 규칙을 추가한다.
• -D (--delete) : 규칙을 삭제한다.
• -C (--check) : 패킷을 테스트한다.
• -R (--replace) : 새로운 규칙으로 교체한다.
• -I (--insert) : 새로운 규칙을 삽입한다.
• -L (--list) : 규칙을 출력한다.
• -F (--flush) : chain으로부터 규칙을 모두 삭제한다.

• -Z (--zero) : 모든 chain의 패킷과 바이트 카운터 값을 0으로 만든다.
• -N (--new) : 새로운 chain을 만든다.
• -X (--delete-chain) : chain을 삭제한다.
• -P (--policy) : 기본정책을 변경한다.

7) 기본 동작

1. 패킷에 대한 동작은 위에서 부터 차례로 각 규칙에 대해 검사하고, 그 규칙과 일치하는 패킷에 대하여 타겟에 지정한 ACCEPT, DROP등을 수행한다.
2. 규칙이 일치하고 작업이 수행되면, 그 패킷은 해당 규칙의 결과에 따리 처리하고 체인에서 추가 규칙을 무시한다.
3. 패킷이 체인의 모든 규칙과 매치하지 않아 규칙의 바닥에 도달하면 정해진 기본정책(policy)이 수행된다.
4. 기본 정책은 policy ACCEPT , policy DROP 으로 설정할 수 있다.

일반적으로 기본정책은 모든 패킷에 대해 DROP을 설정하고 특별히 지정된 포트와 IP주소등에 대해 ACCEPT를 수행하게 만든다.

8) iptables 출력

Iptables의 룰셋을 확인할때 아래와 같이 하면 보기 더 편리하다.

iptables -nL

  Chain INPUT (policy DROP)
  target     prot opt source               destination
  ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
  ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
  ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22
  ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:53
  ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:53
  ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80
  ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:443
  ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:3306

  Chain FORWARD (policy DROP)
  target     prot opt source               destination

  Chain OUTPUT (policy ACCEPT)
  target     prot opt source               destination

아래와 같이 각 룰셋의 적용순서까지 확인 가능한 방법도 있다.

iptables -nL --line-numbers

  Chain INPUT (policy DROP)
  num  target     prot opt source               destination
  1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
  2    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
  3    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22
  4    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:53
  5    ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:53
  6    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80
  7    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:443
  8    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:3306

  Chain FORWARD (policy DROP)
  num  target     prot opt source               destination

  Chain OUTPUT (policy ACCEPT)
  num  target     prot opt source               destination

iptables -L -v

  Chain INPUT (policy DROP 1626 packets, 214K bytes)
   pkts bytes target     prot opt in     out     source               destination
      0     0 ACCEPT     all  --  lo     any     anywhere             anywhere
    944  194K ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED
      0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            tcp dpt:ssh
      0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            tcp dpt:domain
      4   245 ACCEPT     udp  --  any    any     anywhere             anywhere            udp dpt:domain
      6   304 ACCEPT     tcp  --  any    any     anywhere             anywhere            tcp dpt:http
      0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            tcp dpt:https
      2    88 ACCEPT     tcp  --  any    any     anywhere             anywhere            tcp dpt:mysql

  Chain FORWARD (policy DROP 0 packets, 0 bytes)
   pkts bytes target     prot opt in     out     source               destination

  Chain OUTPUT (policy ACCEPT 179 packets, 22190 bytes)
   pkts bytes target     prot opt in     out     source               destination

iptables 설정

아래는 CentOS 6.4 Minimal의 기본적인 iptables의 설정내용이다.

iptables -L

  Chain INPUT (policy ACCEPT)
  target     prot opt source               destination
  ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
  ACCEPT     icmp --  anywhere             anywhere
  ACCEPT     all  --  anywhere             anywhere
  ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh
  REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited

  Chain FORWARD (policy ACCEPT)
  target     prot opt source               destination
  REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited

  Chain OUTPUT (policy ACCEPT)
  target     prot opt source               destination

기본 정책이 모든 패킷에 대해 ACCEPT이며, SSH 서비스가 기본적으로 허용되어 있다. 이것을 과감히 날리고! 새로운 정책의 규칙을 작성할 것이다.

기본 정책 수립에 있어 DROP으로 설정할 경우 원격에서 SSH를 접속해 사용중이라면 그 순간 서버에 접속할 수 없게 된다. 그러므로 일단 기본 정책을 ACCEPT로 설정해서 SSH 설정을 마친후 다시 기본 정책을 DROP으로 변경하도록 하자. 현재 iptables 작업을 콘솔(서버컴퓨터로)상으로 작업하고 있다면 문제 될것이 없다.

기본설정

1. 기본 정책을 ACCEPT 로 변경

   BASH

   iptables -P INPUT ACCEPT
   

2. 체인에 정의된 모든 규칙을 삭제

   BASH

   iptables -F
   

3. 확인해보면 규칙이 모두 제거되어 있다.

   BASH

   iptables -L
   
     Chain INPUT (policy ACCEPT)
     target     prot opt source               destination
   
     Chain FORWARD (policy ACCEPT)
     target     prot opt source               destination
   
     Chain OUTPUT (policy ACCEPT)
     target     prot opt source               destination
   

4. INPUT 체인에 로컬호스트 인터페이스에 들어오는 모든 패킷을 허용 추가

   BASH

   iptables -A INPUT -i lo -j ACCEPT
   

   일반적으로 많은 소프트웨어들이 localhost 어댑터와 통신이 되어야 하기에 필요하다.

5. INPUT 체인에 state 모듈과 매치되는 연결상태가 ESTABLISHED, RELATED인 패킷에 대해 허용 추가

   BASH

   iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
   

   INPUT 체인에 접속에 속하는 패킷(응답 패킷을 가진것)과 기존의 접속 부분은 아니지만 연관성을 가진 패킷 (ICMP 에러나 ftp데이터 접속을 형성하는 패킷)을 허용하는 규칙이다.

6. INPUT 체인에 프로톨콜이 tcp이며 목적지포트가 22번인 패킷에 대해 허용 추가

   BASH

   iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
   

   이로써 SSH 접속이 허용된다. telnet의 경우는 목적지 포트가 23번

7. 이제 INPUT 체인에 대한 기본 정책을 버림(DROP)으로 변경

   BASH

   iptables -P INPUT DROP
   

8. FORWARD 체인에 대한 기본정책을 버림으로 변경

   BASH

   iptables -P FORWARD DROP
   

   서버를 라우팅기기로 사용하지 않기에 모든 포워드에 대한 패킷을 DROP

9. OUTPUT 체인에 대한 기본정책을 허용으로 변경

   BASH

   iptables -P OUTPUT ACCEPT
   

10. 설정한 것들에 대한 확인

    BASH

    iptables -L -v
    
      Chain INPUT (policy DROP 108 packets, 12199 bytes)
       pkts bytes target     prot opt in     out     source               destination
          0     0 ACCEPT     all  --  lo     any     anywhere             anywhere
        273 25012 ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED
          0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            tcp dpt:ssh
    
      Chain FORWARD (policy DROP 0 packets, 0 bytes)
       pkts bytes target     prot opt in     out     source               destination
    
      Chain OUTPUT (policy ACCEPT 9 packets, 1612 bytes)
       pkts bytes target     prot opt in     out     source               destination
    

11. 설정한 것들 저장

    BASH

    service iptables save
    
    iptables: 방화벽 규칙을 /etc/sysconfig/iptables에 저장 중: [  OK  ]
    

iptables 규칙을 만들 때는 순서가 매우 중요하다. 예를 들어 만일 chain에서 로컬 192.168.100.0/24 서브넷에서 들어오는 모든 패킷을 drop하도록 지정한 후 (drop 하도록 지정된 서브넷에 포함되는) 192.168.100.13에서 들어오는 패킷을 모드 허용하는 chain (-A)을 그 후에 추가하면 뒤에 추가된 추가 규칙이 무시된다. 먼저 192.168.100.13를 허용하는 규칙을 설정한 후 서브넷을 drop하는 규칙을 설정해야한다.

그 밖의 서비스 허용

아래의 설정은 기본 정책을 OUTPUT 체인을 DROP (iptables -P OUTPUT DROP)으로 설정했을 경우를 대비해 OUTPUT도 함께 기술하였다.

네임서버

DNS -- TCP 53 / UDP 53

iptables -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j ACCEPT

웹서버

HTTP -- TCP 80

iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

HTTPS -- TCP 443

iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp -m multiport --dports 80,443 -j ACCEPT

MySQL -- TCP 3306

iptables -A INPUT -p tcp --dport 3306 -j ACCEPT 

FTP(passive mode)

iptables -A INPUT -p tcp --dport 21 -j ACCEPT
iptables -A OUTPUT -p tcp –-sport 21 -j ACCEPT

iptables -A INPUT -p tcp --dport 1024:65535 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 1024:65535 -j ACCEPT

메일서버

SMTP -- TCP 25

iptables -A INPUT -p tcp -m tcp --dport 25 -j ACCEPT

Secure SMTP -- TCP 465

iptables -A INPUT -p tcp -m tcp --dport 465 -j ACCEPT

POP3 -- TCP 110

iptables -A INPUT -p tcp -m tcp --dport 110 -j ACCEPT

Secure POP3 -- TCP 995

iptables -A INPUT -p tcp -m tcp --dport 995 -j ACCEPT

IMAP -- TCP 143

iptables -A INPUT -p tcp -m tcp --dport 143 -j ACCEPT

Secure IMAP -- 993

iptables -A INPUT -p tcp -m tcp --dport 993 -j ACCEPT

ICMP 허용 (ping)

iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type echo-reply -j ACCEPT

NTP 시간동기화

iptables -A INPUT -p udp --dport 123 -j ACCEPT 

서버 취약점 보안

NULL 패킷 차단

NULL 패킷은 정찰 패킷으로 서버설정의 약한 곳을 찾기위한 방법으로 사용된다.

iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP

syn-flood attack 차단

syn-flood attack은 공격자가 새로운 연결을 만들고 빠지고를 반복해 리소스의 소모를 시키는 것

iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

Anti synflood with iptables

Edit /etc/sysctl.conf to defend against certain types of attacks and append / update as follows:

net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.netfilter.ip_conntrack_max = 1048576

XMAS 패킷 차단

XMAS 또한 정찰 패킷이다.

iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP

기타 사용법

iptables 수정법

등록된 iptables를 수정하는 방법은 /etc/sysconfig/iptables 에서 직접 vi로 수정하거나 iptables 명령어를 사용한다.

실행 순번을 확인하기

iptables -nL --line-number

아래의 예는 순번 3의 행을 아래와 같이 R(replace) - 수정하게 된다.

iptables -R INPUT 3 -p tcp --dport 2222 -j ACCEPT

인터페이스 지정

루프백 인터페이스에 대해 모든 패킷을 허용

iptables -A INPUT -i lo -j ACCEPT

랜카드 지정에 대해 모든 패킷을 허용

iptables -A INPUT -i eth0 -j ACCEPT

IP 주소 지정

신뢰할 만한 ip에 대해 모든 패킷을 허용

iptables -A INPUT -s 192.168.0.3 -j ACCEPT

신뢰할 만한 ip 대역에 대해 모든 패킷을 허용

iptables -A INPUT -s 192.168.0.0/24 -j ACCEPT

신뢰할 만한 ip 대역에 대해 모든 패킷을 허용

iptables -A INPUT -s 192.168.0.0/255.255.255.0 -j ACCEPT

신뢰할 만한 ip와 MAC주소에 대해 모든 패킷을 허용

iptables -A INPUT -s 192.168.0.3 -m mac --mac-source 00:50:80:FD:E6:32 -j ACCEPT

포트 범위지정

iptables -A INPUT -p tcp --dport 6881:6890 -j ACCEPT

자동화 스크립트

자주 방화벽 설정을 초기화하고 재설정해야 한다면 자동화 스크립트를 짜놓는게 좋다. 아래는 그에 대한 예이다.

#!/bin/bash
# iptables 설정 자동화 스크립트
# 입맛에 따라 수정해서 사용합시다.
iptables -F

# TCP 포트 22번을 SSH 접속을 위해 허용
# 원격 접속을 위해 먼저 설정합니다
iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

# 기본 정책을 설정합니다
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# localhost 접속 허용
iptables -A INPUT -i lo -j ACCEPT

# established and related 접속을 허용
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Apache 포트 80 허용
iptables -A INPUT -p tcp --dport 80 -j ACCEPT

# 설정을 저장
/sbin/service iptables save

# 설정한 내용을 출력
iptables -L -v

1. 위 내용을 입맛에 맞게 수정한 후에 저장(myfirewall)

2. 권한부여

   BASH

   chmod +x myfirewall
   

3. 실행

   BASH

   ./myfirewall
   

   


WEB 서비스를 운영하다 보면 HTTPS SSL 보안 프로토콜을 이용한 서비스를 제공하기 위해 SSL 인증서를 WEB 서버에 설치하여 운용하게 된다.

때문에 다수의 WEB 서버 SSL 인증서를 운용, 관리하다보면, 인증서 인증 만료 일자의 관리를 필요로 하게 된다.

이때 아래와 같이 Linux OS 이하에 설치된 openssl client와 Shell Script를 통해 다수의 인증서의 만료일자 효율적으로 조회 및 확인이 가능하다.

1. 조회할 Domain 및 서비스 Port를 기재한 List 파일 작성

2. Shell Script 의 실행 예시

3. Shell Script Code

출처 : 불량펭귄 - http://blog.helperchoi.com

일반적으로 Web 서비스를 구성할때는 Load balancing 역활을 수행하는 L4 Switch 이하로 n대의 WEB 서버를 구성하여 부하분산과 이중화를 통해 서비스 가용성을 높인다.

만약 다량의 Web Server Node를 동시에 점검해야할 사항이 발생한다면, Client Hosts 파일에 서비스 도메인에 대하여 IP를 수동 정의하여 웹브라우저를 통해 Server Node별 체크를 수행하거나 각 웹서버별 Access 로그나 Error 로그를 기준으로 체크하게 된다.

만약 이런 일련의 과정이 여의치 못하거나 간단히 각 Web Server Node들의 상태체크만을 원한다면 아래와 같이 Shell Script를 통해 간단히 점검이 가능하다.

이하 Shell Script는 curl 명령을 통해 Web Server에서 응답된 상태 Code를 기준으로 상태를 판별하며, HTTP 응답코드는 아래와 같이 분류된다.

발췌 - 위키백과사전 HTTP 상태코드 (http://ko.wikipedia.org/wiki/HTTP_%EC%83%81%ED%83%9C_%EC%BD%94%EB%93%9C)

1. Check 대상 Web Server Node의 IP 또는 Domain을 기준으로 리스트 파일 작성

2. Shell Script 의 실행 예시

3. Shell Script Code

출처 : 불량펭귄 - http://blog.helperchoi.com

iptables은 강력한 패킷필터링 툴입니다.
기존의 iptables에 관한 자세한 문서들이 많이 나와있지만
이 문서는 리눅스 환경을 전제로 하며 iptables의 초심자들을 위해 설명을 하고자 합니다.
오타나 틀린 내용이 있으면 홈페이지에 관련부분을 기제해주기바랍니다.

작성일 2002.10.13

작성자 : 김창현 [CTCquatre] http://www.eyetolife.com

[ 패킷필터링 지식 ]

패킷필터링이란?

패킷필터링은 지나가는 패킷의 해더를 보고 그 전체 패킷의 운명을 결정하는 것을 말한다.
(iptables의 경우 많은 개발중인 기능에서 헤더에 그치지 않고 data의 내용을 검토하기도 한다. 가장 대표적인것이 string match기능이다.)

*:(일반적으로 패킷은 헤더와 데이타를 가진다. 헤더에 필터링할 정보인 출발지IP:PORT,도착지 IP:PORT, checksum,프로토콜 옵셋등을 가지며 데이터는 각각의 전송데이터가 들어간다.)

리눅스 박스의 패킷필터링의 역사

리눅스는 커널 1.1버젼 부터 패킷필터링을 포함하기 시작했다.
제 1세대는 BSD의 ipfw을 기본으로 하였고 
2.0버젼에서 ipfwadm이 사용되었으며
1998년에 2.2기반 패킷필터링툴인 ipchains를 내놓았다. 
그리고 이글에서 논의하고자 하는 제 4세대 필터링툴인 iptables이 2.4커널을 위해
만들어졌다.

netfilter?

일반 iptables사용자들이 가장간과하기 쉬운부분중 한 부분이다.
iptables이 패킷을 필터링 하는것이 아니다.
패킷필터링은 커널에 탑제된 netfilter기능으로 하며
iptables은 단지 netfilter의 룰을 세워줄 뿐이다.
즉 다시 말하자면 iptables은 룰셋구축 툴이라는 말이다.

[ 패킷필터링 ]

iptables에 대해

iptable에 기본 Chain은 아래와 같다.

INPUT chain
FORWARD chain
OUTPUT chain

위의 3가지가 기본 체인이다. 체인들의 모식도는 아래와 같다.

——>INPUT——> Linux Box ——>OUTPUT———>
———↕—————————-↕
———└——— FORWARD ———-┘

여러분의 Linux box를 도착지로 삼는 모든패킷은 INPUT Chain을 통과하게 되며 
여러분의 Linux box에서 생성되 외부로 보내지는 모든패킷은 OUTPUT Chain을 
통과하게 된다.

Forward chain은 *엄밀히 말하자면 도착지가 여러분의 Linux box가 아닌 패킷이 통과하게 되는 체인이다.

*:(다음문서에 다루게 될 Masqurading시에 패킷의 destnationIP정보는 여러분의 Linux box이지만 패킷의 최종도착지는 내부네트워크의 어떠한 컴퓨터일것이다)

지금 커맨드라인에 아래와 같이 쳐보기 바란다.

# iptables -A INPUT -j DROP

엔터키를 누르는 즉시 여러분의 Linux box로 오는 패킷은 모두 거부당할것이다. 즉 모든 통신이 끊어진다.

위의 룰을 굳이 말로 옮기자면

-A:룰을 추가한다 
INPUT: 패킷이 들어오는 체인에 
-j:패킷의 운명을 결정한다. 
DROP: 패킷을 버려라.

즉, INPUT체인으로 들어오는 패킷을 모두 버리는 룰을 추가하는 명령이다.

적용시킨 룰을 보고 싶다면 

# iptables -L 

이라는 명령을 치면된다.

-A와 같은 위치에 있는 옵션은 아래와 같다.

체인에 새로운 규칙을 추가하기 (-A) 
체인의 어떤 지점에 규칙을 삽입하기 (-I) 
체인의 어떤 지점의 규칙을 교환하기 (-R) 
체인의 어떤 지점의 규칙을 제거하기 (-D) 
체인에서 일치하는 첫번째 규칙을 제거하기 (-D) 

이제 위에서 내린 룰을 지워 통신이 되게 하자.
아래와 같이 명령을 내리면 된다.
# iptables -D INPUT 1
또는
# iptables -D INPUT -j DROP 하면 될것이다.

첫번째 방법은 index(룰의 순서)를 지정해서 지우는 방법이고, 두번째는 룰의 내용으로 지우는것이다.

-I,-R은 첫번째 방법과 유사하게 쓸수있다.

룰을 다시 세우고 목록을 보자.

# iptables -A INPUT -j DROP
# iptables -L

살펴보면 

Chanin INPUT (policy ACCEPT)

위와 같은 줄을 볼수있을것이다.
저 줄 밑에는 여러분들이 세운 룰의 정보를 볼수있을것이다.

(policy ACCEPT)를 설명하자면 여러분들이 세운룰에 해당되지 않을때
마지막으로 기본정책을 따라 패킷의 운명을 결정하게 된다. 여기서는 ACCEPT이므로
패킷은 받아드려질것이다. 아지만 이것을 DROP으로하면 패킷은 버려질것이다.

그리고 패킷필터링을 알아가면서 여러룰들을 세울것이다.
기본적으로 룰은 세워진 순서대로 패킷을 검사한다.

이제 기본정책을 바꾸어 보자.

# iptables -P INPUT DROP

위의 명령을 내리고 다시 iptables -L을 하면

Chanin INPUT (policy DROP)으로 된걸 볼수있다.

-P와 동등 위치의 옵션은 아래와 같다.

새로운 체인 만들기 (-N). 
비어있는 체인을 제거하기 (-X).
※ 이 두옵션은 직접체인을 만들었을경우와 제어할경우에 해당된다. 기본체인(INPUT,OUTPUT,FORWARD) 에는 해당되지 않는다.

미리 만들어진 체인의 정책을 바꾸기 (-P) 
어떤 체인의 규칙들을 나열하기 (-L) 
체인으로부터 규칙들을 지우기 (-F) 
체인내의 모든 규칙들의 패킷과 바이트의 카운드를 0 으로 만들기 (-Z) 

[ 패킷의 목적지또는 출처 제어 ] 

패킷출처 제어옵션 -s

# iptables -A INPUT -s 192.168.10.10 -j DROP 

위에 같은 명령을 내렸다면 192.168.10.10으로 부터 온 패킷은 모두 버려지게 된다.

-s(–source,–src와 같은 옵션이다.) : 패킷의 출처 IP 지정

목적지 제어옵션 -d

# iptables -A INPUt -d 192.168.10.12 -j DROP

위와 같은 명령을 내렸다면 192.168.10.12의 IP를 도착지로 가지고있는 패킷은 모두 버려지게된다.

-d(–destination,–dst와 같은 옵션이다.): 패킷의 도착지 IP지정

※ IP지정 이외에 몇 가지 방법이 더 존재한다.
-s www.xxxx.com : 도메인으로 제어
-s 192.168.10.0/24 : 네트워크 또는 집단으로 제어
-s 192.168.10.0/255.255.255.0 :위와 동일

※ 보통 프로그래밍 약속기호처럼 !는 역(‘not’)이라는 것을 표시한다.
ex) -s ! 192.168.10.10 이라고 하면 “출발지가 192.168.10.10이 아닌” 이라는 뜻이된다.

[ 프로토콜 제어 ]

프로토콜제어 옵션은 -p이다

-p옵션의 인자는 TCP,UDP,ICMP가 될수있다.

# iptables -A INPUT -p TCP -j ACCEPT 

라는 명령을 내렸다면 tcp프로토콜을 쓰는 모든 패킷은 ACCEPT에 의해 허락될것이다.

※ -p의 인자로 TCP,UDP,ICMP의 프로토콜번호를 알고있다면 번호를 써도 상관없다.

포트 제어

포트제어 옵션은 –sport와 –dport이다

–sport는 패킷의 출발지 포트이다.( –source-port와 같은 옵션이다.)

–dport는 패킷의 도착지 포트이다.( –destination-port와 같은 옵션이다.)

# iptables -A INPUT -p tcp –dport 80 -j DROP

위와 같은 명령은 tcp프로토콜의 80(www:웹서버포트)번 포트를 목적지로 하는 패킷을
버리는 것이다.

※ –dport나 –sport의 인자로 서비스이름을 적어도 된다.
ex) –dport www

※ 여러 포트를 지정해야 된다면 –dport 1024:65535 와 같이 지정할수있다. 
뜻은 1024 부터 65535번까지라는 뜻이다.

[ 인터페이스 지정 ]

인터페이스는 -i (input interface), -o (output interface)로 지정할수있다.

# iptables -A INPUT -i eth0 -p tcp –dport 80 -j DROP

위의 명령은 -i eth0옵션을 빼고는 port지정 예와 같다.

-i eth0는 eth0로 들오는 모든 패킷을 뜻한다.

보통 리눅스 박스처럼 인터넷과 연결된 디바이스가 1개라면 필요없는 옵션이 되겠지만
만약 eth0, eth1등 2개이상의 인터페이스가 인터넷과 연결되어있다면 위의 옵션은 유용하게 쓰일것이다.

※ INPUT 체인은 -i 옵션만 쓸수 있고, OUTPUT 체인에는 -o옵션만 쓸쑤있다.
반면에 FORWARD 체인은 -i,-o 옵션 두가지 다 쓸쑤있다. 이유는 다음문서에서 다루겠다.

총괄적인 예:

# iptables -A INPUT -i eth0 -d 192.168.10.10 -p tcp –dport 80 -j DROP

해설: INPUT 체인에 – 입력인터페이스가 eth0이고 도착지가 192.168.10.10이고
프로토콜은 tcp이며 도착 포트는 80(www)인 패킷은 DROP시켜라.

이제까지는 별 다른 지식이 없이도 이해할수있는 부분이었다.
하지만 지금부터 나오게될 내용은 tcp/ip의 기반적인 지식을 가지고있어야
이해하기 쉬울것이다.
tcp/ip지식이 필요한 옵션에 대해서는 그에따른 자세한 설명을 하겠지만
이해가 되지 않는 부분은 다른 문서나 책을 찾아보길 바란다.

[ 패킷의 행동 유형에 따른 필터링(–tcp-flags,m state –state) ]

! 주의 : 밑에 나오는 모든옵션은 TCP프로토콜옵션(-p TCP)가 먼저 
선행되어 있어야 적용되는 옵션이다.

1)
–tcp-flags 옵션은 상태에 따라 유용하게 설정할수있다.
이 옵션을 설정하는 가장 큰 예는 한방향으로만 통신이 되게끔설정하기 위해
많이 사용한다. 
tcp/ip는 3핸드쉐이크의 접속방식이다.
즉. 접속요청패킷,접속허가 패킷,확인패킷

접속 단계를 좀더 자세하게 보면

C: Client S:Server

1) C ——— syn ——-▷ S
2) C ◁——- syn ack —– S
3) C ——— ack ——-▷ S

이런식으로 접속절차가 이루어진다.

syn패킷은 접속요청 플래그(syn)가 설정된 패킷이므로 syn패킷만 막으면 상대편에서 접속을 할수 없다는 것이다.

※ Dos공격의 일종인 Syn Flooding이 서버에 위에서 말한 syn형패킷을 무수히 많이
보내는 것이다.

이제 본격적으로 –tcp-flags옵션으로 syn 접속형 패킷을 막는것을 하겠다.

# iptables -A INPUT -p TCP –tcp-flags SYN,RST,ACK SYN -j DROP

–tcp-flags에 첫번째 인자는 검사할 리스트 마스크이다. 
두번째 인자는 설정되어있어야할 플래그다.
즉 syn,rst,ack플래그중 syn이 set이 1로 되어있으면 위의 –tcp-flags설정에
해당이 되므로 패킷은 DROP된다.

위의 옵션과 같은 뜻을 가진것이 있는데 그것은 –syn이다.
–syn은 ‘–tcp-flags SYN,RST,ACK SYN’의 뜻을 가지고 있다.

2)
–tcp-flags보다 더 간단하게 설정하는 방법이 있다.
바로 tcp의 상태천이 다이아그램을 축소시켜 놓은듯한 느낌을 받는 상태에 따른 패킷분류를 iptables은 지원한다.

이것은 확장기능이므로 -m 플래그로 설정은 한다.

사용옵선은 -m state –state 이다.

인자값으로 들어가야할 상태에따른 리스트는 아래와 같다.

NEW : 새로운 접속을 만드는 패킷 

ESTABLISHED :존재하는 접속에 속하는 패킷 (즉, 응답 패킷을 가졌던 것) 
즉 접속이 허가되고 통신하면서 발생되는 패킷이다. 

RELATED :기존의 접속의 부분은 아니지만 연관성을 가진 패킷으로 . 
ICMP 에러 나 (FTP 모듈이 삽입 되어있으면) ftp 데이터 
접속을 형성하는 패킷. 

INVALID :어떤 이유로 확인할 수 없는 패킷. 알려진 접속과 부합하지 않는 ICMP 에러와 
‘out of memory’ 등을 포함한다. 보통 이런 패킷은 DROP 된다. 

이제 이 state 옵션을 사용해보자

위의 –tcp-flags옵션에서 예제와 같은 작용을 하는 룰을 만들어보겠다.

# iptables -A INPUT -p TCP -m state –state NEW -j DROP

왜 룰이 이렇게 되는지 차근차근 읽어보았다면 쉽게 이해가 될것이다.

일반적으로 서버는

# iptables -A INPUT -p TCP –dport 특정포트 -m state –state NEW,ESTABLISHED -j ACCEPT

이렇게 룰을 많이 세운다.
뜻은 tcp 특정 포트에 new:접속패킷과,established:통신패킷(정확히 쉽게 설명할 
단어가 생각나지 않아 부적절하지만 통신패킷이라 부른다)을 허용하라.

그리고 클라이언트 측에서는 위의 state상태에서 NEW를 빼고 사용한다.

# iptables -A INPUT -p TCP –sport 특정포트 -m state –state ESTABLISHED -j ACCEPT

왜 NEW를 뺄까? 그 이유는 
그 이유는 클라이언트입장에서 보면 접속을 허가해달라는 패킷이 필요없다는것이다.
더 쉽게 말하자면 클라이언트는 접속허가를 요청하는 위치이지 요청받는 
위치가 아니라는 말이다.
그러므로 ESTABLISHED만 있으면 일반적으로 통신하는데 아무런 문제가 없다

그리고 주의깊게 본 사람이라면 위에 –sport가 쓰여진것을 볼수있을것이다.

왜 서버에서는 –dport로 제어를 하면서 클라이언트는 –sport로 제어를 할까?

지금 리눅스 박스라면 wget을 쓰던지 x-windows에서 브라우져를 쓰던지 아무런 웹사이트에 접속을 하고 바로 콘솔에서 ‘netstat -nat’라는 명령을 내려보자.

무슨말인지 알겠는가?

서비스를 한번이라도 해본적있는 사람이면 알겠지만 서버는 특정PORT를 열어놓고 접속을 기다린다.
클라이언트는 특정 서버에 접속을 하기 위해 별도로 포트를 생성하고 접속을 시도한다.
이때 클라이언트가 생성하는 포트번호는 1024이후의 랜덤값이다. 이런이유로 클라이언트입장에서는
–dport로 제어를 하지않는게 보통이다. 제어를 하더라도 상관없다. 하지만 그것은
상당한 비효율적인 룰이 될것이다.

[ftp를 위한 상태천이를 이용해 룰 설정]

ftp는 참 유별난 프로토콜이다. 특히 마스커레이드때 쓰이는 nat과 잘 맞지도 않을뿐더러.
ftp서버에서 passive모드로 운영을 할시 iptables로 제어하고 싶다면 따로 모듈이 필요하다.

passive로 1025:65535까지 임이의 데이타 전송포트를 쓸때 
상태천이로 제어를 하자면,보안상 NEW를 사용하지 않는다.
즉,새로운 접속을 허가하지 않고
RELATED로 기존접속에 관련된것만 접속을 허용한다.

즉 실제 룰을 보면 아래와 같다

# iptables -A INPUT -p tcp –dport 1024:65535 
-m state –state ESTABLISHED,RELATED -j ACCEPT

※ 만약 NEW를 사용한다면 방화벽 구실을 못할것이다.
왜그런지는 직접 생각해보라 위에서 이미 충분히 설명하였다.

ftp에서 위처럼 RELATED로 방화벽룰을 설정했다면 
ip_conntrack_ftp라는 모듈없이 연결이 제대로 되지 않을것이다.

ip_conntrack_ftp는 ftp서버의 ftp접속 추적 모듈이다.

[ 조각(Fragments) 처리하기 ]

때때로 하나의 패킷이 한 번에 한 회선을 통과하기에는 너무 큰 경우가 발생한다.
이 때는 패킷이 `조각’으로 나뉘어 여러 개의 패킷으로 전송된다.
받는 쪽에서는 이 조각을 모아 하나의 패킷으로 재구성한다.

패킷 필터링 HOWTO에서는 nat이나 접속추적을 할때에는 분절패킷이 하나의 패킷으로

재구성되어 필터링되기때문에 해당되지 않는다고 명시되어 있다.

하지만 위와 같은 상황이 아니라면 조각을 처리해야하나 안전성을 이유로 처리하지
않는 것을 권장하고 있다. 그 이유는 아래에 설명할것이다.

일반적으로 패킷이 분절(토막)될때 필터링을 할 정보인 특히 발신지 포트,
목적지 포트, ICMP 유형, ICMP 코드 또는 TCP SYN 플래그등은 첫번쩨 패킷의
헤더에 밖에 포함되지 않는다. 즉 두번째 분절패킷부터는 그 정보가 없다는 말이다.
이를 위해서 우리는 분절된 패킷을 처리하기 위해 -f 옵션을 사용한다.

하지만 -f옵션을 권장하지 않는다. 왜냐하면 첫번째 필터링정보가 담긴 헤더를 보고
필터링을 할때 그 패킷이 거부하는 룰에 적용되어 거부되면 분절된 패킷이 거부되지
않고 오더라도 그것은 하나의 패킷으로 재구성 되지 않고 버려지기 때문이다.

사용법은

# iptables -A OUTPUT -f -d 192.168.1.1 -j DROP

처럼 사용한다.
위의 뜻은 192.168.1.1을 항해 나가는 분절된 패킷은 모두 버린다 이다.

다시 한번 말하지만 꼭 필요한경우를 제외하고 이 옵션은 권정하지 않는다.

이정도로 iptables의 기본 사용법에 대해 마치고자 한다.
이문서에서는 방화벽설정에서 자주 사용하게 되는 옵션에 대해서만 언급했다.
아니 이정도 옵션들이면 어느정도 방화벽은 구성할수 있을것이다.
나머지 옵션들은 man패이지나 패킷필터링 HOWTO에서 찾아보기 바란다

JVM 구조

IBM JVM를 구성하는, 각각의 Component structure는 아래와 같이 나뉜다.

각 영역의 주요 기능은 아래와 같이 요약된다.

[표 1] IBM JVM 구성 요소 설명

여기서 우리는 ‘Memory management’ 를 중점적으로 다뤄본다.

JIT 컴파일러

흔히, IBM JVM을 JIT계열의 JVM이라고 표현한다.

JIT는 흔히 Just-In-Time의 약자로 알려져 있으며, 이는 JVM의 한 part라기 보다는, SDK의 기본 구성요소로 생각하는 것이 맞다.

Java가 Interpreter 언어이고, 이는 소스가 bytecode로 컴파일 되고, 실행되기 위해서는 다시금 system code로 해석되어 수행되어야 하는, performance적인 저하요소를 극복하기 위해 자주 수행되는 Java method를 대상으로 미리 system code로해석해서, Method가 call되면 컴파일 과정 없이 바로 서비스를 하는 방식으로 작동한다.

 이런 JIT 컴파일러가 때때로 Runtime시 문제점이 발생하는 경우는, 아래의 방법으로 JIT 옵션을 꺼둘 수도 있다.

[표 2] JIT 컴파일러 비활성화

또, 아래와 같이 JIT 옵션을 켤 수도 있다.

[표 3] JIT 컴파일러 활성화

Garbage Collector

Sun의 HotSpot 계열의 JVM은 ‘New/Old/Permanent’등의 ‘세대(Generation)’로 불리는 영역으로 분리된 Heap구조를 가진다.

이에 반해, IBM JVM은 영역이 따로 분리되지 않은 하나의 ‘Single Space’로 Heap이 구성되어 있다.

참고로, IBM JDK 1.5부터는 아래와 같이 ‘세대(Generation)’기반의 Heap 구조를 지원한다.

(GC 알고리즘이 Concurrent Generational Collector 인 경우의 Heap 구조임)

각 영역이 어떤 식으로 Garbage Collector에 의해 사용되는지 설명하기 위해서,

‘Generational Concurrent Garbage Collection’의 알고리즘에 대해 잠깐 언급하도록 한다.

JVM이 Logic을 처리하는 동안, 새로운 Object들은 당연히 ‘Nursery’영역에 생기게 된다. 만일, 새로운 Object가 할당되는데 필요한 ‘연속된 메모리 영역’이 부족하게 되면, 객체는 ‘Tenured’영역으로 옮겨지게 된다. 또한, Garbage collection 발생시 옮겨지기도 한다.

Nursery 영역은 ‘Allocate Space’와 ‘Survivor Space’로 나뉘게 된다.

Object는 최초 Allocate Space에 생기게 된다. 만일, Space가 부족하게 되는 경우,

Allocation Failure가 발생되면 Garbage Collector가 작동되고, Scavenge가 시작된다.

Scavenge가 진행되는 동안, reference가 살아있는 Object들은 ‘Survivor Space’로 이동되고, 이때 reference가 없는Object들은 건들지 않는다.

Reference가 살아있는 Object들의 이동작업이 다 끝나게 되면, ‘Allocate Space’와 ‘Survivor Space’는 그 역할을 순간적을 바꾸게 된다.

이때, 기존의 reference가 없는 Object들은 순간적으로 비워지게 된다. 그리고, 다음 Scavenge가 발생할 때 까지는‘Survivor Space’가 Object를 위한 Allocate 공간 업무를 수행하게 된다.

GC command-line options

-verbose:gc

garbage collection 의 정보를 standard out 으로 출력한다.

-Xverbosegclog:<file, X, Y>

garbage collection 의 정보를 파일로 출력한다. 만약 integer X와 Y의 값을 명시하면 output이 Y GC Cycle의 output을 포함하는 X 파일로 재지정된다.

-Xgcpolicy: <optthruput | optavgpause | gencon | subpool>

이 option은 garbage collector 행동을 제어한다.

-. optthruput

concurrent mark를 비활성화 한다. 만약 application response time에 문제가 없다면 이 option을 사용하여 최적의throughput을 낼 수 있다. Optthruput은 default 값이다.

-. optavgpause

concurrent mark를 활성화 한다. 만약 일반적인 garbage collections 에 의해 application response time에 문제가 있다면이 option을 사용함으로 문제를 줄일 수 있다.

-. gencon

Concurrent와 generational GC를 겸용하여 사용함으로 garbage collection 지체 시간을 최소화 할 수 있다.

-. subpool

concurrent mark를 비활성화 한다. 이것은 heap에 객체들을 배치할 때 더 나은 성능을 내기 위해 향상된 object allocation알고리즘을 사용한다. 이 option은 16 이상의 processor의 SMP system에서 실행되며, subpool option은 AIX, Linux PPC 와 zSeries, z/OS, i5/OS 에서 가능하다.

-Xmx<value>

최대 heap size를 지정한다. (Xmx >= Xms)

-Xms<value>

최소 heap size를 지정한다.  Xmo 또한 사용할 수 있다. 최소 size는 8KB이다.

scavenger 가 활성화 되어 있을 경우, -Xms >= -Xmn + -Xmo

scavenger 가 비활성화 되어 있을 경우, -Xms >= -Xmo

-Xcompactgc

모든 garbage collections(system 또는 global) 에 대하여 압축을 가능하게 한다.

-Xnocompactexplicitgc

System.gc() 호출에 의한 압축을 불가능하게 한다. 압축은 만약 –Xcompactgc 명시하거나 또는 compaction triggers를 만나면 global garbage collections 에서 발생한다.

-Xcompactexplicitgc          

System.gc()가 호출 될 때마다 모든 GC 시스템에서 압축을 사용 가능하게 한다.

-Xnocompactgc

모든 garbage collections(system 또는 global) 에 대하여 압축을 사용 불가능하게 한다.

-Xnoclassgc

Class garbage collection 을 비활성화 한다. JVM에 의해서 더 이상 사용되지 않는 Java class 들과 연관된 storage의garbage collection을 끈다. 즉 dynamic 클래스 로드 해제를 사용 불가능하게 한다.

-Xclassgc

dynamic 클래스 로드 해제를 사용 가능하게 한다.

-Xalwaysclassgc

global collection 동안 항상 dynamic class load 해제를 수행한다. Default 는 -Xclassgc 에 의해 정의된다.

-Xmaxf<percentage>

garbage collection 후 free 되어야 하는 heap의 최대 percentage를 지정한다. 만약 free 영역이 이 값을 초과하면 JVM은heap을 줄이기 위해 시도한다. Default는 0.6(60%) 이다.

-Xminf<percentage>

garbage collection이후 free되어야 하는 heap의 최소 percentage를 지정한다. 만약 free영역 이 값에 못 미치는 경우 JVM은 heap을 확장하기 위해 시도한다. Default는 30%이다.

-Xgcthreads<number>

Garbage Collector 의 thread 수를 지정한다. Default는 물리적인 CPU의 수로 지정된다. 다른 수로 지정하기 위해 (예를 들어 4)  -Xgcthreads4 로 표기한다.

Nonstandard command-line options

-Xss<size>

모든 Java thread의 최대 stack size를 지정한다. Default는 32bit JVM에서 256KB, 64bit JVM에서 512KB 이다.

-Xmso<size>

OS thread의 stack size를 지정한다.  

JIT command-line options

-Xint

JVM을 JIT로 사용불가하고, Interpreter 로만 사용한다.

-Xquickstart

최적화를 지연하여 시작 시간을 향상시킨다. 

GC 알고리즘의 이해

IBM JDK에서는 아래와 같이 주요 4가지 Garbage Collection 옵션을 제공한다.

이들은 아래와 같은 방법으로 설정이 가능하다.

여기에 설정할 수 있는 옵션은 다음과 같다.

optthruput GC 알고리즘 설명

optavgpause GC 알고리즘 설명

gencon GC 알고리즘 설명

subpool GC 알고리즘 설명

GC Dump의 이해

앞에서, GC 알고리즘에 대해 개략적으로 살펴보았다.

여기서는, 로그가 실제 어떤 식으로 생성되는지 간략한 예를 살펴보도록 한다.

아래는, 실제로 JEUS에 각각의 GC 알고리즘을 적용시켜 생성한 Dump이다.

–Xgcpolicy:optthruput GC dump

로그 패턴을 보면, Allocation Failure가 발생하였고, GC를 거쳐 Tenured영역의 Free Space가 57%로 증가했음을 알 수있다. 

–Xgcpolicy:optavgpause GC dump

 
–Xgcpolicy:gencon GC dump

–Xgcpolicy:subpool GC dump

Subpool은 CPU가 16장 이상인 환경에서 최적화 되어있다고 앞서 말했다.

종종 System Capacity가 부족한 환경에서는 아래와 같은 로그가 목격되기도 한다.

위의 로그와 비슷하게, System.gc()가 명시적으로 호출된 경우는 아래와 같은 GC Dump가 발생한다.

Java Thread Dump 분석

Java Thread Dump란, 특정 Java Process에 대한 청사진이라 해석될 수 있다.

IBM 플랫폼에서 Java Thread Dump는 text형태로 생성된다.

이를, 직접 열어서 내용을 Trace하는 것도 가능하지만, 여기서는 Visual Tool을 이용한 분석법을 소개한다.

JCA를 이용한 Java Thread Dump 분석

1. 다운로드 : http://www.alphaworks.ibm.com/tech/jca (파일명:jca*.zip)

2. 실행화면

 3. 설명

실제 javacore덤프를 분석한 화면이다.

덤프 생성 당시, 가용한 메모리가 없었다는 경고와 함께, Worker Thread들 중 하나가

Running 상태였다는 정보를 쉽게 알 수 있다.

이와 같이, Worker Thread의 상태정보 및 Heap Memory Usage정보, Thread Monitor 상태정보(dead lock)등의 정보에쉽게 접근이 가능하다.

Java Heap Dump 분석

Java Heap Dump란, 특정 Java Process에 allocation 되었던 Heap Memory에 대한 청사진이라 할 수 있다.

IBM 플랫폼에서는 text형태, 혹은 phd(Portable Heap Dump)포맷으로 생성된다.

Heap Dump 분석에는 주로 아래와 같은 방법이 사용된다.

여기서는 GUI기반의 HeapAnalyzer를 소개한다.

HeapAnalyzer를 이용한 Java Heap Dump 분석

1. 실행화면 

2. 설명

실제 Heap Dump를 분석한 화면이다.

Heap Dump 생성 당시의 Memory allocation에 대한 Stack정보를 계층구조로 보여주고 있어서, Memory 누수 라던지OOM(Out Of Memory)상황이 발생하였을 경우, 그 원인파악에 매우 도움이 되는 화면을 제공한다.

(*주의: Heap Dump Size가 매우 큰 경우는, 서버의 X-Window환경에서 작업하도록 한다. 통상적인 Heap Dump 분석에는 많은 Memory가 필요하기 때문이다.)

GC Dump 분석

GC Dump 분석이란, -verbose:gc –Xverbosegelog:logname.log 의 결과로 생성된 GC log파일을 분석하는 것을 말한다.

이 역시, script를 이용하는 방법과 command-line을 이용한 명령어 사용방법 등이 있는데, 여기서는 역시 GUI 기반의 툴인‘GCCollector’를 이용하는 방법을 소개한다.

GCCollector를 이용한 GC Dump 분석

1. 다운로드: GCCollector를 실행하기 위해서는 JFreeChart 도 다운받아야 한다.           

2. GCCollector 실행파일에 오류가 발생할 경우 아래와 같이 작성한다.

javaw -Xmx300m –classpath lib/GCCollector.jar;lib/jfreechart-1.0.0-rc1.jar;lib/jcommon-1.0.0-rc1.jar it.imperato.jvmperf.GCCollector

3. 실행화면

4. 설명

실제 GC Dump를 분석한 화면이다. (-Xgcpolicy:optthruput or –Xgcpolicy:optavgpause)

GCCollector를 통해 판단할 수 있는 항목은 아래와 같다.

표준 설정 옵션

전체적인 GC Time이 너무 길고, Response Time이 너무 나오지 않습니다.

상황

GC 수행시간 그래프를 보면, 수행시간이 오래 걸리는 GC들의 peak가 자주 목격됩니다.

Response Time 역시 너무 안 나옵니다.

조치

대부분, GC에 있어서 Full heap collection 혹은 compaction에 소요되는 시간이 너무 긴 경우 발생할 수 있습니다.

이 경우, -Xgcpolicy:optavgpause 옵션을 적용하면, concurrent 하게 heap collection이 발생하게 되고, GC에 따른 pause시간이 감소하여, 전체적인 Response Time 향상을 기대할 수 있습니다.

Throughput이 너무 적게 나옵니다.

상황

CPU 및 Memory등의 capacity가 좋은 장비임에도 불구하고, WAS 서비스의 전체적인

Throughput이 너무 나오지 않습니다.

조치

이 경우, -Xgcpolicy:optthruput 옵션을 적용하면, concurrent 한 mark&sweep 작업을 막음으로써, 대부분의 Thread가Business Service를 수행하는데 사용되도록 유도하여 전체적인 Throughput을 향상시키는데 도움이 될 수 있습니다.

만일, CPU가 16장 이상인 고 사양 환경의 경우 –Xgcpolicy:subpool 옵션이 좀더 효과적인 성능을 발휘 할 수 있습니다.

Garbage Collection이 너무 자주 발생합니다.

상황

GC Interval이 매우 좁게 나타나며, GC count가 너무 높게 나옵니다.

조치

Application 특성에 비해 Heap Size가 너무 작게 설정되어 있을 수 있습니다.

또한, 이 경우 –Xgcpolicy:optthruput 옵션이 도움이 될 수 있습니다.

설정된 Heap Size와 실제 사용량의 차이가 너무 심하게 납니다.

상황

실제 WAS JVM에 할당한 Heap Size와 사용되는 Heap Size의 등락폭이 너무 심하게 자주 바뀝니다.

조치

Heap Size가 너무 크게 설정되어 있을 수 있습니다.

Heap Size를 줄이고, Generation Heap Space가 설정된 경우 ‘Nursery’영역의 Size를 좀더

할당해 주는 것도 도움이 될 수 있습니다.

CPU 16장 이상의 환경에서 WAS를 운영하는 경우, 권장 GC 정책은 무엇인가요?

상황

CPU 16장 이상의 AIX장비의 IBM JDK 1.5 이상 환경에서 WAS를 운영하고자 합니다.

권장 GC 정책은 무엇 인가요.

조치

이 경우 -Xgcpolicy:subpool 옵션을 권장합니다.

하지만 Business Application의 성격에 따라 다른 결과가 나올 수 있음으로, 다른 GC 정책과의 비교 Test가 필요합니다.