보안업무를 담당하거나 서버를 운영하다 보면 취약점을 패치해야 될 경우가 빈번히 발생된다.
보안취약점에 패치, 성능 상향에 대한 패치, 암호 알고리즘 지원 중단 , OS지원 종료 등 여러가지 상황에 대해서 OS 및 어플리케이션을 새로운걸 사용하던지 패치를 하던지 해당 문제에 대한 결과를 내야 된다.
1] 보안 취약점 패치
보안 취약점은 바로 조치 해야 되는 긴급과 몰아서 한꺼번에 하는 정기 점검때 가능한 비긴급으로 나눌수 있다. 긴급은 Apache Struts2, glibc 취약점이나 NTP, Heart bleed등 remote exploit에 해당 된다. 비긴급은 local exploit예는 shell shock같은 취약점이나 커널, 어플리케이션 관련 취약점에 해당 된다.
shell shock도 CGI환경에서는 remote 명령이 실행이 가능하지만 우리나라 환경에서는 거의 사용되지 않는다.
보안담당자가 긴급, 비긴급을 나누는 기준은 정보를 빨리 습득해서 실력이 되면 직접 POC를 해보는게 가장 좋다. 그게 현실적으로 힘드니 페이스북에서 좋아요나 공유수가 많은 게시물 이나 보안 관련 언론에 기사화 되어서 등장하는 취약점 또는
상급기관에서 공문을 보내어 패치를 하고, 그 결과를 다시 보내 달라는 경우에 대해서는 긴급일 확률이 높다.
하지만 실제로 보안취약점 패치를 하는게 쉽지 않다.
최근에 다시 알려진 glibc같은것도 bind DNS서비스라면 DNS잠시 내려놓고, 패치를 진행 해야 된다.
glibc는 CVE코드만 보면 알듯이 작년에 나온건데 그 심각성에 대해서는 최근에 구글팀에서 POC를 공개하면서 다시 한번 이슈가 된 버그다.
그렇게 되면 해당 도메인 계정을 사용하는 모든 서비스가 죽는다.
그래서 낮에 하기도 꺼럼직 하다. 하지만 낮에 못하게 되면 밤 동안 어느정도 대책을 마련 해야 된다. 주로 sk인포섹나 Krcert에서 해당 공격에 대한 시그니처를 snort룰로 제공 한다.
긴급이 힘든 경우는 해당 시그니처를 IPS나 웹방화벽에 등록을 먼저 해야 된다.
실제로 저 glibc를 작년에 패치하다가 linux 서버 몇몇에서 다른 어플리케이션 호환성으로 인해 롤백 시킨적도 있다.
그 만큼 취약점 패치는 호락 호락 한 작업이 아니다.
2] 성능 향상에 대한 패치
주로 리눅스 커널 컴파일을 이야기 하는거 같다. os protection이나 여러가지 성능이 굉장히 기하 급수적으로 빨리 발전 중이다. FreeBSD에 비해서도 리눅스가 월등히 앞서는 성능을 가진 OS가 되었다.
하지만 오픈소스 특성상 라이브러리간의 구버전과 신버전 간의 호환성, 이식성은 거의 최악이다. 그래서 커널 컴파일을 웬만하면 하지 말라고 하고, 구지 새로운 커널을 쓰고 싶으면 OS를 신규버전으로 재설치를 하는걸 권장 한다.
상용 was의 경우는 설치 전 필요한 라이브러리에 대한 버전을 체크하는것도 이런 이유 때문이다.
3] 암호 알고리즘 지원 중단
주로 Hash 함수가 collision이 발생된 경우다. auth를 위해 hash를 싼다면 해당 알고리즘 과감히 버려야 된다. md4, md5, sha1등이 최근이고 그 이전에 여러가지 구시대의 유물의 알고리즘이 많았을 것이다.
이것도 참 크리티컬 한것이 장비를 사용중인데 유지보수를 못받는 경우가 있다. 외산을 도입하였는데 벤더사나 서비스사가 망한 경우도 있고, 해당 장비 업체가 영세하여 개발을 해놓고 팔았는데 개발자가 계속 퇴사하여서 더 이상 신규 리뉴얼이 불가능한 경우도 있다.
대체 장비를 구매하여 쓰던지, 안쓰던지, 위험성을 가지고 사용할지는 판단을 잘 해야 된다.
4] OS 지원 종료
XP지원 종료, Windows 2003서버 지원 종료 OS는 구버전을 쓰면 안좋다. OS 보호모드도 빈약하다. aslr같은 경우도 비스타에 적용된것과 7에 적용된것이 좀 급이 다르다. 레드헷9.0 적용된것과 요즘 최신 버전에 적용된 것도 다르다. 하지만 너무 계속 신규 OS를 쓰는것도 조금 위험하다. 서버를 운영하는 입장에서는 OS가 출시되고 2년 정도 지난 시점에 어느정도 버그가 잡힌 후 사용하는것이 가장 안전한거 같다.
cuckoo_1.2.tar.gz