Bind 취약점이 발견 되었다.

해당 취약점은 Bind 구현상 결함으로 인해 Bind DNS에 대한 DoS 공격이 가능해지는

취약점으로 개발자 ISC에 발표 되었다.

Bind 9.1.0 이후의 모든 버전의 Bind 9이 대상입니다.

CVE-2015-5477 가 할당 되었습니다.

 

취약점 및 패치 여부 확인방법

 

취약한 경우

# rpm -q -changelog bind | grep CVE-2015-5477

#

 

패치된 경우

# rpm -q -changelog bind | grep CVE-2015-5477
- Fix CVE-2015-5477

 

 

해결책

Bind 버전의 패치 또는 해당 패킷의 차단

패킷 차단시 RPM Changelog 확인 불가능

 

CentOS 5 버전 YUM 패치 제공

# yum update bind

 

CentOS 6 버전 YUM 패치 제공 안됨 2015/08/04

아래 URL 에서 맞는 버전의 RPM을 다운 로드 한 후 패치를 진행한다.

http://lists.centos.org/pipermail/centos-announce/2015-July/thread.html

 

설치된 패키지 확인 법

# rpm -qa | grep bind
bind-9.8.2-0.23.rc1.el6_5.1.x86_64
bind-utils-9.8.2-0.23.rc1.el6_5.1.x86_64
bind-libs-9.8.2-0.23.rc1.el6_5.1.x86_64

동일 이름의 파일을 다운로드 한 후 패치를 진행한다.

# wget http://ftp.jaist.ac.jp/pub/Linux/CentOS/6.6/cr/x86_64/Packages/bind-9.8.2-0.37.rc1.el6_7.2.x86_64.rpm
# wget http://ftp.jaist.ac.jp/pub/Linux/CentOS/6.6/cr/x86_64/Packages/bind-libs-9.8.2-0.37.rc1.el6_7.2.x86_64.rpm

# wget http://ftp.jaist.ac.jp/pub/Linux/CentOS/6.6/cr/x86_64/Packages/bind-utils-9.8.2-0.37.rc1.el6_7.2.x86_64.rpm

# rpm -Uvh bind*

 

 

Iptables를 이용한 차단 법

# iptables -A INPUT -p udp --dport 53 -m string --algo bm --hex-string '|00F900FF|' -j LOG
# iptables -A INPUT -p udp --dport 53 -m string --algo bm --hex-string '|00F900FF|' -j DROP

 

 

 

 

 

 

 

Posted by 24X365

댓글을 달아 주세요

Iptables는 리눅스 네트워크 룰을 추가 및 삭제하는 명령이다.

 

룰 추가시 사용 명령 옵션

# iptables -I

# iptables -A

 

옵션이 두개인 이유는 룰을 적용받는 순서가 위에서부터 아래로 흐르는 방식이라서

허용 차단 순으로 사용을 해야 하기 때문이다.

만약 차단 허용 순으로 룰이 만들어진다면 허용 룰은 차단 룰셋에서 버려지므로 적용받지 못하게 된다.

 

I 옵션은  룰의 처음부터 추가 하는 옵션

A 옵션은 룰의 마지막에 추가 하는 옵션

 

룰 삭제시 사용 명령 옵션

# iptables -D

 

보기)

# iptables -A INPUT -p tcp --dport 22 -j DROP

# iptables -I INPUT -p tcp -s 1.1.1.1--dport 22 -j ACCEPT

# iptables -L --line-number
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination        
1    ACCEPT     tcp  --  1.1.1.1               anywhere            tcp dpt:ssh 
2    DROP       tcp  --  anywhere             anywhere            tcp dpt:ssh

 

# iptables -D INPUT -p tcp --dport 22 -j DROP

# iptables -L --line-number
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination        
1    ACCEPT     tcp  --  1.1.1.1               anywhere            tcp dpt:ssh 


 

'Linux > Linux - Iptables' 카테고리의 다른 글

[Linux] Iptables 룰 입력, 삭제, 확인  (0) 2015.04.30
Posted by 24X365

댓글을 달아 주세요

리눅스 서버의 NIC 카드의 Promiscuous 모드 설정 방법은 다음과 같다.

 

# ifconfig eth0 promisc

 

설정 후 확인 방법은

 

# ifconfig | grep "PROMISC"

 

 

설정 원복 방법

 

# ifconfig eth0 -promisc

 

 

Posted by 24X365

댓글을 달아 주세요

특정 서버들의 CPU 사용율이 및 로드 에버리지가 높아 확인하여보니 Kipmi 이녀석이 100%를 사용하고 있다.

뭐하는 애인지 찾아보았다.


ipmi를 operation 하는 동안 ipmi 드라이버를 폴링을 하는 녀석이다.

만약 시스템의 ipmi operations 수가 많아지게 되면  kipmi는 CPU를 점유하게 될 수 있다.


해당 점유율에 대해 처리하는 방법은 다음과 같다.


방법 1.

원인이 되는 ipmi 를 정지시킨다

service ipmi stop



방법 2.

kipmid 자체를 disable 시킨다.

해당 방법은 ipmi  operations 속도의 저하를 일으킬수 있다.


/etc/modprobe.conf 파일일을 수정

options ipmi_si force_kipmid=0

OS 버전에 따라서는 위치가 틀리다

/etc/modprobe.d/ipmi.conf


service ipmi restart





방법 3.

kipmi의 자원 점유 MAX 값을 설정한다.


echo 100 > /sys/module/ipmi_si/parameters/kipmid_max_busy_us


부팅시 적용을 위하여 rc.local 에 등록을 같이 하여 준다




Posted by 24X365

댓글을 달아 주세요

 

crontab을 사용하여 mysqldump 백업 스크립트를 사용중에 다음과 같은 문제가 발생하였다.

crontab을 이용하여 백업을 하면 정상백업 용량이 안나오며 쉘 상에서 스크립트를 구동시켜

배업을 실행시 정상 적으로 백업이 완료 된다.

 

해당 서버는 컴파일 설치로 Mysql 설치를 하였던 서버이다.

환경변수는 Mysql 관련하여 root의 변수 설정 파일에만 설정이 되어 있었다.

 

크론탭에 등록 내용

00 4 * * * /root/script/backup.sh &

 

스크립트의 구문 내용

mysqldump -uroot -pongsi --all-databases > $dir"/"$time"-mysqldump.sql"

 

동일한 서부가 두대여서 두 가지로 테스트를 해보기로 하였다.

 

1. 한대의 서버는 크론탭을 다음과 같이 변경

00 4 * * * su - root -c /root/script/backup.sh &

 

2.다른 한대의 서버는 스크립트 내용을 절대경로 값으로 변경

/usr/local/mysql/bin/mysqldump -uroot -pongsi --all-databases > $dir"/"$time"-mysqldump.sql"

 

수정 후 두가지 방법 모두다 정상적으로 Mysqldump 를 통한 백업이 정상적으로 되는걸 확인 할수 있다.

 

 

 

 

 

Posted by 24X365

댓글을 달아 주세요

아래 방법은 RPM을 사용하는 Linux 서버 기준입니다.



취약한 경우

[root]# rpm -q --changelog openssl | grep CVE-2015-0204
아무런 내용이 없다면 패치 필요


패치방법

[root]# yum update -y openssl


패치 후 확인
[root]# rpm -q --changelog openssl | grep CVE-2015-0204
- fix CVE-2015-0204 - remove support for RSA ephemeral keys for non-export

패치 적용 후 SSL 취약점인 관계로 웹 서비스의 재기동이 필요합니다.



Posted by 24X365

댓글을 달아 주세요

아래 방법은 CentOS 6.5 기준입니다.

 

 

취약한 경우

[root]# rpm -q --changelog glibc | grep CVE-2015-0235

아무런 내용이 나오지 않음

 

패치방법

[root]# yum update -y glibc

패치후 리부팅 필수!!!

 

취약점 패치후 확인

[root]# rpm -q --changelog glibc | grep CVE-2015-0235

- Fix parsing of numeric hosts in gethostbyname_r (CVE-2015-0235, #1183533).

 

 

참고링크

https://documentation.cpanel.net/display/CKB/CVE-2015-0235+GHOST

Posted by 24X365

댓글을 달아 주세요

[Linux] Mail Queue 비우기

Linux 2015. 1. 12. 10:23

 

리눅스 서버에서 사용하는 mail 명령어로 인해 큐가 가득 차게 되는 경우가 있다.

이럴때 확인 및 해결 방법은 다음과 같다.

 

Queue  확인 방법

[root@Backup-DNS ~]# mailq -v

......

Mail queue is empty

 

Mail Queue  삭제 방법

 

[root@Backup-DNS ~]# postsuper -d ALL

 

 

 

Posted by 24X365

댓글을 달아 주세요

/var/log/messages 내용

Nov 12 14:24:40 localhost kernel: TCP: time wait bucket table overflow

상기 내용의 로그가 보인다면 다음 부분을 확인 하면 된다.

cat /proc/sys/net/ipv4/tcp_max_tw_buckets


웹서버의 경우 다음 명령을 통해 추가로 Time Wait 값을 확인한다.

# netstat -an | grep 80| awk '{print $6}' | sort | uniq -c | sort -rn
   3343 TIME_WAIT
     24 ESTABLISHED
     12 SYN_RECV
      5 FIN_WAIT2
      4 FIN_WAIT1
      2 CLOSING
      1 LISTEN
      1 LAST_ACK
      1 CONNECTED

두개의 값을 확인 한 후


설정을 수정한다.

/etc/sysctl.conf

net.ipv4.tcp_max_tw_buckets = 10000


수정 후 적용을 위해

sysctl -p

'Linux > Linux - Log' 카테고리의 다른 글

[Linux] /var/log/message - time wait bucket table overflow  (0) 2014.11.12
Posted by 24X365

댓글을 달아 주세요

Apache 웹서버 멀티 프로세스 방식을 확인 하는 명령어

멀티 프로세스 방식은 Worker, Prefork 방식 두개로 구분된다.


# httpd -l
Compiled in modules:
  core.c
  prefork.c
  http_core.c
  mod_so.c


YUM을 통한 RPM 설치는 Prefork 방식으로 설치 된다.

Posted by 24X365

댓글을 달아 주세요