윈디하나의 누리사랑방. 이런 저런 얘기

글쓴시간
분류 기술,IT/서버
윈도 7의 wuauserv 서비스가 CPU를 100% 차지하는 현상

※ 어느날 갑자기 svchost.exe 라는 프로세스가 코어 1개를 100% 차지하면서 시스템 전체 CPU 사용량이 늘어나고 PC가 느려지는 현상이 발생했다. 그래서 살펴본 결과 wuauserv 서비스의 소행인걸 알아냈다.

※ wuauserv 는 "윈도 업데이트" 서비스다. 원래 가끔씩 CPU를 많이 차지하면서 뭔가가 실행되고 디스크를 많이 읽는 현상은 당연한거다. 하지만 필자의 경우는 수시간째 계속 그랬다.

사용자 삽입 이미지

작업관리자 상황. 오른쪽 아래의 "리소스 모니터"를 클릭해 리소스 모니터를 실행하자.



※ 당장 느려지는게 문제라면 해당 서비스를 정지시키면 된다. 리소스 모니터에서 wuauserv를 선택하고 오른쪽 버튼을 눌러 "서비스 중지"를 클릭하면 된다.

사용자 삽입 이미지

리소스 모니터에서 wuauserv 를 찾았다.



※ 근본적으로 해결하려면 패치를 하면 된다.

https://support.microsoft.com/en-us/kb/3172605 에서 "Windows6.1-KB3172605-x64.msu" 파일(윈도7 x64기준)을 다운받아 업데이트하면 된다.

※ 아예 윈도 10으로 업그레이드 해도 되지만 wuauserv 때문에 업그레이드가 많이 느릴 것이다. 업그레이드 전에 패치를 먼저 하자.
글쓴시간
분류 기술,IT/서버
업타임(Uptime)

별 생각없이 서버들어가서 uptime 이라는 명령을 쳐보았다.

두둥

사용자 삽입 이미지

2091 일이라니. 뭔가 잘못되었다. 아마 이 서버의 uptime 은 30일 조금 안될꺼다. 근데 이게 왜 바뀐건지는 잘 모르겠음. 버그인감.

참고로 uptime 이란건 어떤 장치의 운영 시간, 작동 시간을 말한다. 주로 컴퓨터의 이야기. 즉 "업타임이 2091일"이라는건 컴퓨터를 켜고 운영체제로 부팅 한 후, 5.7년동안 한번도 안 껐다는 의미다. Uptime 은 틱카운트를 세기 때문에 수정/조작 하는게 불가능한걸로 아는데, 내가 모르는 뭔가가 더 있는건감.

서버 관리 처음할떄에는 왠지 업타임에 신경썼었다. 가급적 안끄는게 좋은건 맞으니깐. 실제 서비스 중인 서버로 1800일은 넘겨봤다. 약 5년동안 한번도 안 껐다는 이야기. 엔터프라이즈급 솔라리스 서버였는데, 꺼야할 일이 없었다. 서버도 굉장히 안정적으로 돌아가고. 어쩔 수 없이 끈건 이중화되어있는 스토리지 컨트롤러중 한쪽 노드에 장애가 발생해 결국 하드웨어를 교체해야 했기 때문이다. PnP 지원되긴 했지만 만약을 위해 껐다 켰다.
글쓴시간
분류 기술,IT/서버
HTTP/2

사용자 삽입 이미지


- 2015.02.17에 HTTP/2 프로토콜이 승인되었습니다. RFC 등록이 남아있긴 하지만 이건 시간문제일 뿐이구요.

- HTTP란 웹의 근간을 이루는 프로토콜의 이름입니다. 웹 주소(예를 들어 http://windy.luru.net) 첫머리에 나오는 http 가 바로 그겁니다.

- 이번 HTTP/2 프로토콜은 현재 사용하고 있는 HTT/1.1 의 뒤를 잇는 프로토콜입니다. 1999년 발표된 프로토콜로 오래되긴 했지만 큰 문제 없이 쓰다가, 어느 시점부터 성능에 대한 불만이 생기기 시작합니다. 특히 https 가 대중화 되면서 더욱 가중되었죠. 뭔가를 바꾸면 훨씬 빨라질 수 있는데 그걸 표준 규격 지키느라고 못바꾸니까요.

- 답답해하던 구글은 결국 SPDY라는 프로토콜을 제안합니다. SPDY는 몇차례의 개정을 거치다가 SPDY 4.0 즉 HTTP/2 로 결실을 보게된겁니다.

- HTTP/2 의 핵심은 '다중화'입니다. '요청-응답-요청-응답'의 순서를 반드시 지켜야 할 필요 없게 된거죠. 이렇게 되면 서버에서 'I/O다중화'를 적극적으로 사용해 괄목할만한 성능 향상을 이뤄낼 수 있게 됩니다. 성능 향상정도는 특히 https 에서 두드러집니다.

- 현재 Chrome 40과 Firefox 36에서 HTTP/2를 지원하고 있습니다. 곧 나올 Windows 10의 IE11과 IIS에서도 지원됩니다. 문제는 오픈소스 웹 서버들인데 Nginx, Apache, lighttpd 가 지원을 못합니다. 특히 가장 널리 사용되는 서버인 아파치가 아직 지원을 못하기 때문에 범용적으로 사용하질 못하고 있습니다. 물론 이런 브라우저들도 지원계획은 있는데 아직 구현하지 못한것일 뿐 지원은 당연한 사항입니다. 어서빨리 지원되었으면 좋겠네요.

----

2015.10.13 업데이트

Apache 2.4.17 부터 mod_http2 를 통해서 http2 지원하네요. libnghttp2  를 사용하기 때문에 같이 설치해줘야 합니다.
글쓴시간
분류 기술,IT/서버
CVE-2015-0235 GHOST

※ GLIBC 에서 버그가 발견되어 긴급한 패치를 요한다고 하네요. Qualys라는 보안업체가 발견했습니다. 고스트버그라고 이름 붙였네요.

사용자 삽입 이미지

CVE-2015-0235 GHOST



※ glibc 는 GNU 의 C라이브러리입니다. C라이브러리는 여러가지가 있는데, 이중 FSF라는 단체에서 GNU이름으로 배포하는 C라이브러리라는 의미입니다. C라이브러리는 "여러 프로그램에서 공통적으로 사용하는 파일"로 보시면 됩니다.

※ C라이브러리는 C라는 언어로 만든 프로그램을 실행할 때 반드시 필요한데요, 유닉스/리눅스가 C로 만들어져 있기 때문에 유닉스/리눅스에서 실행되는 모든 프로그램은 C라이브러리를 필요로 합니다. 리눅스는 거의 대부분 glibc 기반이기 때문에 대부분의 리눅스가 영향 받게 됩니다.

※ glibc에 버그가 있다고 합니다. __nss_hostname_digits_dots()라는 내부 함수에 있다는데, 이 내부 함수는 gethostbyname(), gethostbyname2()에서 사용한다고 합니다. gethostbyname() 은 조금 과장해서 모든 통신 프로그램에서 사용하는 함수라 이 문제는 꽤 치명적인것 같네요. 2000년 하반기에 배포된 glibc 2.2 부터 문제가 있었다고 하고, 분석글에서는 메일을 사용한 예를 들어 이렇게 사용할 가능성에 대해 언급하고 있습니다. 제대로 안 읽어보긴 했습니다만, 임의의 코드를 실행할 수 있을 것으로 생각합니다.

※ MITRE에 CVE-2015-0235로 등록되어있으며, 패치는 바로 배포되었습니다. (GHOST 버그의 패치는 2013년에 glibc에 적용되어있었습니다만, 리눅스 배포판에는 glibc 의 최신버전을 사용하는 경우가 없죠. 2013년 적용 당시에도 이것이 보안 위협이 될 것으로 인지하지는 못했다고 합니다) 현재 작동하고 있는 거의 대부분의 리눅스가 영향 받을 것이고, 악의적인 해커는 이를 쉽게 응용할 수 있기 때문에 바로 패치가 필요해 보입니다.

※ 작년에 있었던 하트블리드와는 비교되지 않을 정도의 중대한 사건이 아닐까 하네요. 문제는 이미 지원이 종료된 리눅스를 사용하고 있는 서버는 어떻게 할지가 관건이네요. 운영체제 업그레이드만이 답이려나요.

----

MITRE CVE-2015-0235: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0235
레드햇 보안사이트 고스트: https://access.redhat.com/security/cve/CVE-2015-0235
고스트 버그 분석: https://www.qualys.com/research/security-advisories/GHOST-CVE-2015-0235.txt
하드블리드: http://windy.luru.net/1700
글쓴시간
분류 기술,IT/서버
하트블리드 버그(Heartbleed Bug)

사용자 삽입 이미지

하트블리드


최근에 공개된 OpenSSL의 보안 버그입니다. 2014.04.07에 패치되었습니다. 제 웹 서버는 별 생각없이 패치했습니다만, 이거 의외로 심각한거 같네요. 전 보안 위험은 낮게 봅니다만 OpenSSL이 안쓰이는 곳이 없을 정도로 대중화된 라이브러리라 아마 대부분의 기기가 영향 받을것으로 보입니다.

OpenSSL에서 TLS/DTLS 규격의 하나인 heartbeat 를 구현하는 코드에서, 메모리 관련 경계 검사 오류(경계 확인을 하지 않음)가 존재하고, 공격자는 이를 통해 서버 메모리상의 임의의 주소에 있는 데이터를 읽을 수 있다고 합니다. 임의의 주소에 민감한 정보가 남아있으면 위험하겠죠. 하지만 아직 스크립트 키드들을 위한 툴이 발견된건 아닌거 같습니다. '하트비트' 버그를 이용한거기 때문에 일종의 패러디로 '하트블리드'로 이름 붙였네요.

OpenSSL 1.0.1 ~ OpenSSL 1.0.1f 까지 영향 받습니다. OpenSSL 1.0.1g를 받아 설치하거나 업그레이드가 불가능한 경우 하트비트 기능을 끄고 설치하라네요.

이 버그에 대한 전용 홈페이지까지 나와있는 상태입니다. CVE-2014-0160으로 등록되어있습니다.

쉽게 말하면, 조만간 소프트웨어들 업데이트 있을테니 묻지 말고 패치하라는 겁니다. 특히 웹서비스 운영하시는 분들요. 시놀로지라는 NAS 업체도 자사의 DSM 솔루션을 이미 패치했네요.

----

2014.04.16 하트 블리드를 사용한 해킹 사례가 있네요. 하지 않으신 분들은 어서 패치해야 할듯 합니다.

http://www.zdnet.com/heartbleed-used-for-canada-revenue-agency-breach-7000028425/

----

2014.04.22 이 버그는 서버뿐만 아니라 클라이언트도 영향 받습니다. 공격자가 가짜 서버를 만들어 클라이언트의 메모리에 있는 데이터를 빼낼 수 있습니다. 영향받는 소프트웨어 중에 안드로이드 운영체제도 있네요.

----

하트블리드 버그: http://heartbleed.com/
소스 변경 내역: http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=96db9023b881d7cd9f379b0c154650d6c108e9a3
시놀로지 하트블리드 보안 패치: http://www.synology.com/ko-kr/support/security_hotfix_dsm_5_0_4458_update_2
글쓴시간
분류 기술,IT/서버
윈도 NT 버전

윈도NT 4.0      = 4.0
윈도2000        = 5.0
윈도XP          = 5.1
윈도XP x64      = 5.2 = 윈도 서버 2003
윈도Vista       = 6.0 = 윈도 서버 2008
윈도7           = 6.1 = 윈도 서버 2008 R2
윈도8           = 6.2 = 윈도 서버 2012
윈도8.1         = 6.3 = 윈도 서버 2012 R2


윈도XP, 윈도7이니 하는건 마케팅 용어고 내부적으로 커널 버전은 따로 매기고 있다. 커널 버전이 얼마나 바뀌었는지를 보면 어느정도의 수정이 가해졌는지 가늠해볼 수 있다.

윈도2000이 명작이었고, 개인적으로는 최고로 꼽는다. 이 이후 커널 변동사항은 미미한 편.
글쓴시간
분류 기술,IT/서버

구글, 암호화 체계 강화

※ 구글이 자사의 암호화 체계를 강화한다고 하네요. 몇달전 구글이 사용자의 이메일을 엿본다(?)고 말한 기사와 비교됩니다만, 저건 환영하는 일이긴 합니다. (엿본다는게 메일을 읽는다는게 아니라, 키워드를 추출해 광고에 활용한다는 이야기입니다. 이는 라이선스 어그리먼트에 나와 있습니다)

※ 예전에 스노든이란 사람이 폭로한게 있습니다. 정보기관에서, 인터넷으로 전달되는 정보를 엿본다는 것이죠. 현재 암호화 표준 방법으로 암호화된 정보는 쉽고 빠른 방법으로 풀 수 있는 방법은 없습니다. 수학적으로 증명된 내용이죠. 하지만 느린 방법으로 풀 방법은 있습니다. 슈퍼 컴퓨터를 사용하면 느린 속도가 커버되니 방법은 있는 셈입니다. 이런걸 정보기관이 한다는건 익히 알려져 있는 사실이긴 합니다. 게다가 추측이긴 합니다만 몇몇 사이트의 개인키를 정보기관에서 가지고 있다고도 알려져 있습니다. 해커에 의해 개인키가 유출되어도 소용없도록 만들기 위해 DHE나 ECDHE와 같은 키 교환 알고리즘도 나오구요.

※ 그런데 다른 방법이 있습니다. 암호화된 데이터는 사용자에게 보여줄 때 복호화하게 마련입니다. 이 복호화 한걸 가로채서 엿본다는 내용입니다. 암호 해독에 필요한 비용이 획기적으로 줄어드는 셈입니다.

※ 이게 문제가 되니까 구글도 이런 부분을 신경서서 암호화 체계를 강화하겠다는 겁니다. 정부기관에서 자신의 메일을 보고 있다는걸 알면 인터넷을 사용하려는 사람이 줄 가능성도 있으니까요. 구글로써는 반갑지만은 않은 일이겠죠.

※ 전 대부분의 정보를 자체적으로 운영하는 서버에 저장하고 있습니다. 딱히 공개 못할 정보가 있는건 아닙니다만, 그래도 위와 같은 기분 나쁜 문제를 겪고 싶지는 않네요.

----

윈도7, IE에서 ECDHE 알고리즘 사용하기: http://windy.luru.net/1620

글쓴시간
분류 기술,IT/서버

TLS 1.2

- TLS(Transport Layer Security)는 인터넷 프로토콜 암호화 규격이라고 이해하면 쉽다. 예전(2000년대 초)에는 SSL(Secure Sockets Layer)도 많이 사용되었지만 현재는 TLS를 권장하고 있다. SSL은 v3.0 까지 나와있지만, v3.0에서도 보안에 문제가 있기 때문에 SSL을 사용하는 것은 권장하지 않는다.

- 윈도 7의 익스플로러 9에서는 TLS 1.1, TLS 1.2가 비활성화 되어있다. 이 글을 쓰는 시점에서 TLS 1.2를 지원하는 브라우저가 별로 없는데, 윈도에서는 오페라와 사파리가 있다. 사파리의 경우 최근에서야 지원하기 시작했으며 크롬도 최근 업데이트부터 TLS 1.1을 지원한다. 파이어폭스는 아직 지원하지 않는다.

- 어쩄든 윈도 7의 익스플로러 9에서는 TLS를 활성화 할 수 있다. 아래와 같이 인터넷 옵션에서 바꿔주면 된다.

사용자 삽입 이미지

IE9의 TLS 1.1, TLS 1.2세팅 화면. 인터넷 옵션 화면에서 고급 탭에 있다.

- 예전엔 Apache-OpenSSL 조합의 웹 서버에서 TLS 1.2를 지원하지 못했는데, 2012년 초에 OpenSSL 1.0.1 이 나오면서 TLS 1.2를 지원하기 시작했다. 즉 2011년에는 브라우저에서 TLS 1.2를 지원해도 서버에서 지원하지 못하는 경우가 많았다는 의미다. 지금은 서버, 클라이언트 모두 지원할 수 있는 환경이 갖춰져 있으니 TLS 1.2를 활성화 해놓는게 좋을 것이다.

- TLS 1.1은 TLS 1.0에 비해 많은 것이 바뀌었다. 이 변경점은 CBC에서 예상되는 문제를 보완하기 위해 변경했기 때문에 반드시 TLS 1.0 대신 TLS 1.2을 사용해야 한다. (이를 이용한 TLS 1.0에 대한 취약점은 BEAST 패치를 통해 해결할 수 있다. TLS1.0 을 지원하는 대부분의 브라우저는 패치되어있을 것이다. 참고로 TLS 1.0과 SSL 3.0은 사실상 같은 프로토콜이다)  TLS 1.2는 SHA-1을 사용하던 해시 알고리즘을 SHA-256으로 변경하고, 다양한 알고리즘을 수용할 수 있도록 변경되었다.

----

2014.08.29 업데이트: 현재는 대부분의 브라우저에서 TLS 1.2를 지원하고 있다. ECDHE나 GCM 같은 알고리즘도 지원해준다. TLS 1.2 은 아직까지는 보안 결함이 없는 것으로 알려져 있다. 반대로, TLS 1.1도 지금 단계에서는 안심할 수 있는 단계가 아니다. 일부 취약점들이 보고되고 있다고 한다.

글쓴시간
분류 기술,IT/서버

ECC vs Non-ECC

DRAM 과같은 메모리는 우주선 또는 알파선(X선보다 강한 빛)에 의해 비트의 값이 변경된다. 특히 공정이 미세화될 수록 작은 에너지에도 비트의 값이 변경되는데, 미세 공정을 사용하고 집적도가 높아지면 이 빈도가 꽤 잦은 편이다.

통상 10~100 FIT/MB정도의 비율로 알려져 있다. (이 값은 지구 자기장, 고도, 서버가 놓인 곳의 차폐정도, 태양의 활동 등에 의해 변하며 인공적인 방사선, 예를 들면 원자력 발전소 옆이면 비율이 훨씬 더 높아진다) 1 FIT는 10억 시간동안 1개의 디바이스 실패를 나타낸다. 쉽게 말하면 100GB메모리를 가지고 있으면 100~1000시간이 지나면 1회 발생하는 비율이라는 의미다 - 생각보다 흔한 일이다.

변경되는 현상중 90%는 1비트만 변하고, 나머지는 2비트 이상 변한다. 메모리의 ECC는 1비트가 변했을 때, 이를 감지해내고 고칠 수 있는 데이터를 제공한다. 2비트 이상 변했다면 감지는 해내지만 고쳐주지는 못한다. ECC가 없다면 이런 형태의 오류에 대해 감지할 수도, 수정할 수도 없다. 따라서 중요한 데이터를 다루는 PC라면 ECC가 반드시 필요하다.

메모리 모듈은 64비트로 작동한다. ECC메모리 모듈은 여기에 8비트 ECC가 붙어, 72비트가 된다. 또한 ECC메모리와 Non-ECC 메모리는 물리적으로는 호환된다. 따라서 메모리 컨트롤러에서 ECC를 지원해준다면, 메모리 소켓 변경이 필요 없기 때문에 데스크탑 마더보드에서도 ECC메모리를 사용할 수 있다.

사용자 삽입 이미지

삼성 DDR4 REG ECC 메모리. 메모리 칩이 7개로 하나는 ECC를 위해 붙어있다. 가운데 붙어있는 작은 칩은 REG구현을 위해 붙어있는 버퍼용 칩이다.


대부분의 엔터프라이즈급 운영체제는 비트 오류를 감지해 자동으로 복구해주는 메커니즘을 가지고 있다. 윈도도 가지고 있는걸로 알고 있는지 아직 문서를 확인해본건 아니다.