CentOS6 php-4.3.11 with apache 2.4

먼저 아파치 2.4 및 DB는 사전에 서버 구축이 되어 있다는 가정하에 출발한다 ‘ㅅ’a
php 4.3 혹은 4.4.의 경우 배포툴을 까봤을때 apache 1.x 혹은 apache 2.0.x 와 호환되도록 되어 있다.

 

일반적인 웹서비스를 구성할수 있는 extension 을 포함한 설치 방법이다.

문제점은 아래와 같다. –

CentOS6에 포함된 openssl-1.0.1e , curl 버전 충돌 이난다. 그리고 apache MPM 정상인식 불가에 따른 configure 수정이 필요하다.
shutdown-patch 는 snmp 공격에 의해 error_log 가 난잡해지는것을 방지하는 패치이다

위 패치파일을 받아 패치를 한뒤에 컴파일을 진행한다.

–with-ldap 과 –with-imap 은 포함시 해결이 되지 않아 제거 하였다 ‘ㅅ’a
그다음 아파치 구동을 한다 ‘ㅅ’a

20160615_PicPick_164916

그렇다.. 이 테스트의 목적은 PHP-4.x 기반의 HTTP/2 구현이 주목적…
부가적으로 각종 웹, OS 취약점 등등이 패치된 구형 php가 구동 가능한 서버를 구축할 수 있다.

 

크롬에서의 HTTP/2 사용확인은  아래의 주소를 별도의 탭에 띄워두고 사이트 접속을 하면 현재 유지되는 커넥션의 정보를 확인할 수 있다.
chrome://net-internals/#http2
20160722_PicPick_140008

 

 

CVE-2016-2107 -취약점 Padding oracle , CVE-2016-2108 취약점 – Memory corruption ASN.1 encoder

아직 한국어 기사 혹은 취약점 공문 이런게 안떳지만..
https://www.openssl.org/news/vulnerabilities.html#y2016
openssl – Severity: High 즉 심각한 보안 취약점이 두개나 공개 되었다. ‘ㅅ’a

https://www.openssl.org/news/secadv/20160503.txt

이 공격에 대비하여 openssl 을 각각 1.0.1t 혹은 1.0.2h 로 업그레이드를 권고 하고 있다.

 

openssl 컴파일 설치 방법은 아래의 게시물 하단을 참조

CVE-2016-0800 취약점 – DROWN, CVE-2016-0702 취약점 – CacheBleed

 

Centos 5/6/7 버전에서 yum 을 이용한 openssl 을 설치 및 운용중인 경우 아래와 같이 yum으로 업데이트 하면 된다.

yum을 이용한 업데이트 이후에는 아래와 같은 명령어로 보안 취약점이 패치 되었는지 확인할 수 있다.

openssl 업데이트 후에는 아파치 재시작을 해야 적용되니 참고 ‘ㅅ’a
memory corruption 은 레드햇에서 찾아서 적용이 공식 사이트보다 하루 빨랐나보다 ‘ㅅ’a

 

PS. openssl 0.9.8 버전의 경우 AES – CBC cipher 가 없기 때문에 CVE-2016-2107 취약점은 패치가 없다.

php 에서 dbcon 작성 할때 localhost가 안먹을때.

서버에 APM 이 정상 설치가 되어 있으나

php 로 dbcon 을 할때 127.0.0.1은 먹고 localhost 로는 접속이 불가능할때가 있다.

 

먼저 mysql로 로그인을 하여 소켓 위치를 파악하자.

 

php.ini 파일에서 mysql.default_socket 을 일치시켜준다.

 

그다음 아파치나 php-fpm을 재시작 ‘ㅅ’a

php 5.6이상 fsockopen 문제

php 5.6 이상 버전에서 인증서를 확인하는 옵션인 verify_peer 의 값이 flase => true로 변경이 되었다.
때문에 이와 관련하여 (대부분 PG연동) php 5.6 버전과 php 7.0 버전은 PG결재 진행이 안될 수 있다.
http://php.net/manual/kr/migration56.openssl.php

  • 서버의 php 버전이 5.6 이상이고 외부로 HTTPS 통신을 할때 발생한다.

에러메세지는 대략 다음과 같다.
Warning: fsockopen(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed in

 

일반적으로 신뢰할수 있는 CA 값을 서버에 /etc/pki/tls/cert.pem 에 저장하고 있다.(아래 명령어로 확인)

단지 특정 외부에서 사용하는 인증서의 ROOT CA 가 서버내 ca-certificates  파일내에 없는것이다 ‘ㅅ’a

해결을 위해서는 서버에 ca-certificates 을 업데이트 하면 되겠다.

해결이 안된다면 아래와 같이 인증서 확인을 끄는 방법으로 php 소스코드를 수정해야 한다.

 

원본: 작동불가 코드

위와 같은 fsockopen 을 아래와 같이 stream_socket_client 으로 대체 하면서
verify_peer 와 verify_host 를 false 로 옵션을 변경하는것으로 해결이 가능하다.

수정본: 작동가능 코드

php 소수 수정을 이용한 해결 방법은 아래 글을 참조하였습니다 🙂
https://blog.e2info.co.jp/2015/12/29/php5-6でカード決済できない

memcache 설치 및 session.cache 운용

memcached 는 서버의 메모리를 할당해서 사용할수 있는 데몬의 일종이다.

파일캐시, 쿼리캐시, 세션캐시 등을 할 수 있으나 파일 캐시, 쿼리캐시는 최근에 사용되는 자체 데몬의 캐시가 오히려 더 효율적이기 때문에 사용치 않는다.

때문에 여기서는 세션캐시 부분만을 설명할 예정이다.

1. 설치

pecl, phpize, php-config 경로는 자신의 php 경로에 맞게 수정되어야 한다 ‘ㅅ’a

 

2. 실행 및 데몬 자동 실행 등록

 

3. php.ini 설정 ( session 은 기존 설정값 변경 / 다른 부분은 추가. ) ( php 7.0 – memecahe을 포함 한다 )

 

설정 후 아파치를 재시작 하거나 php-fpm 일경우 php 을 재시작 하면 적용이 된다.
용량이나 포트등은 /etc/sysconfig/memcached 에서 설정할 수 있다.
기본 설정인 32M 의 경우 약 25000개의 세션을 버티는거 같다 = =a

 

4. 주의 사항.
일반적으로 문제가 생기지는 않으나 그누보드4 & 5 의 경우에 문제가 발생한다.
common.php 파일부분에 수정을 가해야만 정상동작 할 수 있다.

그누보드5

그누보드4

물론 위에서 설명한 php.ini 설정을 하지 못했다면 더 어려워지겠다 =3=a

 

일반적인 /tmp 를 사용하거나 그누보드처럼 자체 폴더에 세션을 생성 하는 방법은 그 폴더에 32000여개의 파일이상이 생성이 될경우 사이트 속도가 매우 느려질 수 있다. ( 10초이상 걸릴 수도 있다. )
즉 사이트가 대형화가 된 경우의 속도 저하를 방지 한다.

그누보드의 경우 각 접속 뿐만 아니라 각 게시물의 xx번 읽음 체크를 위해 세션을 이용하기도 하기 때문에 이 느려지는시점은 본인 생각보다 빨리 올 수 있다.

 

운영중인 memcached 의 자원 관리를 위해 memcache.php 를 운용해서 확인할 수 있다.
https://github.com/lagged/memcache.php