시스템이야기2014. 4. 9. 15:19

OpenSSL 1.0.1버전에 TLS heartbeat 취약점(일명 Heartbleed Bug라고 부름. CVE-2014-0160, openssl: information disclosure in handling of TLS heartbeat extension packets)이 있습니다. 

공격자가 https서버의 메모리 64KB 데이터를 볼 수 있습니다. 메모리에는 https서버와 유저간에 주고 받은 데이터들(ID/PW, ... 등의 정보)이 있는데, 공격자는 plain text형태로 볼 수 있습니다. 그리고,SSL 개인키를 얻을 수 있습니다. 반드시 업데이트하세요.


http://a4.aurynj.net/post/82075898166/heartbleed (Heartbleed 이슈에 관해 정리)

http://yisangwook.tumblr.com/post/82056087918/openssl-heartbeat-heartbleed (OpenSSL 취약점 발견. Heartbleed)

http://heartbleed.com/


1. 취약한 버전


OpenSSL 1.0.0과 0.9.8 버전은 취약하지 않으며,

1.0.1은 1.0.1f까지 취약합니다. 1.0.1g에서 패치되었구요.


http://www.openssl.org/news/secadv_20140407.txt



2. RHEL, CentOS


# yum update openssl*

... 생략 ...

=====================================================================

 Package              Arch      Version               Repository        Size

=====================================================================

Updating:

 openssl              x86_64    1.0.1e-16.el6_5.7     updates          1.5 M

 openssl-devel        x86_64    1.0.1e-16.el6_5.7     updates          1.2 M



3. FreeBSD


# freebsd-update fetch

# freebsd-update install

# ls -la /usr/lib*/libssl*

-r--r--r--  1 root  wheel  685846 Apr  9 12:28 /usr/lib/libssl.a

lrwxr-xr-x  1 root  wheel      11 Feb 25 09:24 /usr/lib/libssl.so -> libssl.so.7

-r--r--r--  1 root  wheel  430352 Apr  9 12:28 /usr/lib/libssl.so.7

-r--r--r--  1 root  wheel  713782 Apr  9 12:28 /usr/lib/libssl_p.a

-r--r--r--  1 root  wheel  470850 Apr  9 12:28 /usr/lib32/libssl.a

lrwxr-xr-x  1 root  wheel      11 Feb 25 09:26 /usr/lib32/libssl.so -> libssl.so.7

-r--r--r--  1 root  wheel  363552 Apr  9 12:28 /usr/lib32/libssl.so.7

-r--r--r--  1 root  wheel  480306 Apr  9 12:28 /usr/lib32/libssl_p.a


업데이트 후 openssl사용하는 데몬은 재실행해주세요.



Posted by 좋은진호
IT이야기2013. 9. 17. 13:07

'[국정원]내란음모로 인한 소환서 발부되었습니다 내용확인 rort.??/???'이라는 '스미싱 문자 기사'를 봤다.



apk파일을 받아보려고 'PC 브라우저'에서 접속해봤다. 그런데, '[olleh]스미싱 감염 예방 안내'라는 페이지( http://175.196.95.228/smishing.htm )로 바로 이동해버린다. KT가 스미싱 차단 서비스를 얼마전에 시작했는데, 이게 이통망만 적용한게 아니었다.


[olleh]스미싱 감염 예방 안내

1. 문자에 포함된 인터넷주소가 확실하지 않은 것이면 누르지 마십시오. 다양한 방법으로 유해어플이 설치되어 문자 수신이 안될 수 있습니다.

2. 올레마켓에서 알약(http://olleh.kr/alyac) 또는 올레스미싱차단 앱 등 백신을 다운받아 검사하시면 감염확인 및 치료를 할수 있습니다.

* 휴대폰을 최상의 상태로 유지하기 위하여는 하루에 한번 정도 전원을 껐다 켜 주세요.

다른망을 통해 PC에서 접속해봤는데, 악성 apk 배포 서버가 내려갔는지 접속은 안된다.


아무튼 안드로이드 사용자는 문자에 URL이 포함될 때 주의해야 한다.

1. 스마트폰에서 SMS문자의 URL을 누르지 않는다.
2. 실수로 URL을 눌렀을 때, 어플 설치하라는 메시지가 나오면 절대 설치하지 않는다.
3. URL을 '반드시' 확인해보고 싶다면(실제 지인이 보낸 문자일 가능성이 있을 때) 폰이 아닌 백신이 설치된 PC에서 크롬, 파폭 브라우저로 확인한다.

Posted by 좋은진호
시스템이야기2013. 5. 20. 18:56

로컬에서 root ID를 얻을 수 있는 커널 취약점이 발견되었다. 해당 커널 버전은 2.6.37~3.8.9 이다.
그러나 CentOS 6.x(또는 RHEL)의 커널 2.6.32버전은 2.6.27에서 백포팅된 것이 있는데 해당 취약점까지 백포팅된 것으로 알려졌다.



CentOS 6.x버전을 사용중이면 커널 업데이트(지난주에 커널패치가 나옴)를 반드시 해야한다.

* CentOS 6.x에서 취약점없는 버전 : 2.6.32-358.6.2.el6.x86_64 <-- 패치 번호 -358.6.2가 문제 없음.

* Linux PERF_EVENTS Local Root

http://packetstormsecurity.com/files/121616/semtex.c
http://downloads.securityfocus.com/vulnerabilities/exploits/59846.c

커널 취약점 테스트 결과다. gcc 컴파일할 때 반드시 -O2 optimize 옵션을 넣고 테스트해야 한다.

[ 커널 패치 전 ]

$ gcc semtex.c
$ ./a.out
2.6.37-3.x x86_64
sd _at_ fucksheep.org 2010
a.out: semtex.c:81: main: Assertion `p = memmem(code, 1024, &needle, 8 )' failed.
중지됨
$ gcc -O2 semtex.c  <-- -O2 옵션 넣고 컴파일
$ ./a.out
2.6.37-3.x x86_64
sd _at_ fucksheep.org 2010
-sh-4.1# id
uid=0(root) gid=0(root) groups=0(root),501(true)  <-- root권한 획득
-sh-4.1# exit
logout


[ 커널 패치 후 ( yum update kernel* 명령 후 ) ]

$ uname -r
2.6.32-358.6.2.el6.x86_64
$ ./a.out
a.out: a.c:51: sheep: Assertion `!close(fd)' failed.
중지됨
$

※ expolit 소스를 링크하고 싶지 않았다. 하지만 이미 공개가 많이 되었고, SE가 직접 취약성을 테스트하도록 링크를 걸었다.

Posted by 좋은진호
시스템이야기2012. 1. 11. 18:37
Hash table 충돌을 이용한 DoS 공격(일명 HashDoS)을 해결한 PHP 5.3.9버전이 나왔습니다.
  • php 5.3.8 포함하여 이전 버전 사용중 : 필히 업그레이드 할 것
  • php 5.3.9 RC 또는 5.4.0 RC4~RC5 사용중 : 임시 업그레이드하셨던 분은 필요하면 정식 버전을 적용해도 되겠네요.

php


참고로 php.ini의 max_input_vars default값은 1000입니다.

http://www.php.net/index.php#id2012-01-11-1

The PHP development team would like to announce the immediate availability of PHP 5.3.9. This release focuses on improving the stability of the PHP 5.3.x branch with over 90 bug fixes, some of which are security related.

Security Enhancements and Fixes in PHP 5.3.9:

* Added max_input_vars directive to prevent attacks based on hash collisions. (CVE-2011-4885)
* Fixed bug #60150 (Integer overflow during the parsing of invalid exif header). (CVE-2011-4566)


※ 2012.2.2에 php 5.3.10버전이 나왔습니다. HashDoS를 패치한 5.3.9버전에 원격에서 코드를 실행할 수 있는 취약점이 있습니다. 자세한 것은 'php 5.3.10으로 업그레이드하세요."를 읽어보세요.

* HashDoS 관련 글

- 2012/01/04 - [시스템이야기] - php에서 hash table DoS(HashDoS) 공격 방어
- 2012/01/02 - [시스템이야기] - 웹서버 hash table DoS(HashDoS) 공격 (중요. PHP, ASP 등 해당)


Posted by 좋은진호
시스템이야기2011. 8. 31. 17:15
지난주 '아파치 웹서버를 한방에 다운시키는 Range요청 취약점'이 발표되었다.

apache 웹서버


국내에서는 이 DoS 취약점에 대해 너무나 조용하지만, 한방에 서버를 다운시킬 수 있는 심각한 문제이다. 아파치 웹서버(Apache)에 정상적이지 않은 형태로 Range 헤더를 요청하면, 웹서버의 load는 단 몇초만에 급상승하여 서버는 응답을 처리할 수가 없다.

아파치 1.3, 2.0, 2.2버전대 모두 DoS 취약점이 존재한다. 오늘 DoS 취약점을 패치한 2.2.20 버전을 발표했다.

SECURITY: CVE-2011-3192 (cve.mitre.org) core: Fix handling of byte-range requests to use less memory, to avoid denial of service. If the sum of all ranges in a request is larger than the original file, ignore the ranges and send the complete file. PR 51714.

예전 1.3.x버전 운영중인 분들은 더 이상 지원하지 않는 버전대를 버리고 2.2.x대로 갈아타시기 권장한다. 2.0.x버전대는 조만간 발표될 것이다.
2.2.20 테스트 결과, 해당 취약점이 패치된 것을 확인했다.


Posted by 좋은진호
시스템이야기2011. 8. 30. 13:22


apache


jjun님이 글을 쓰셨으니 간단하게만 몇가지 언급하겠다.

'아파치 웹서버 무력화시킬 심각한 DoS 결함 발견' 기사에는 mod_deflate또는 mod_gzip 모듈과 관련이 있는 것으로 쓰여있지만, 이 모듈과는 무관하게 취약점이 존재한다. 해당 모듈을 주석처리해도 악의적인 Range 헤더 요청에 대해 똑같은 문제가 있으며, 아파치 메일링 리스트에서도 이 모듈을 언급한 것은 잘못된 판단이었다고 한다.

* Bug 51714 - Byte Range Filter might consume huge amounts of memory combined with compressed streams
As discussed on the Apache Dev Mailing list it looks like this issue has nothing to do with mod_deflate or mod_gzip, wrong assumption by me.

웹페이지 size에 따라서, Range 헤더의 문제가 발생할 수도 있고 없을 수도 없다.

1) mod_php5모듈이 없다면 웹페이지 size에 상관없이 문제가 있다.
2) mod_php5모듈과 함께 아파치를 동작중이라면 8000bytes 이하의 웹페이지를 요청할 때만 문제가 발생한다. mod_php5 모듈이 있더라도 php로 인식하지 않는 확장자(예를 들어 .css, js, .txt 등)는 사이즈에 상관없이 문제가 있다.

따라서 index페이지만 체크하고 '우리는 문제가 없네'라고 판단해서는 안된다. php로 된 index가 8000bytes를 넘는다면, 취약점이 없는 것으로 보일 수 있기 때문이다.

Request 헤더에 Range: bytes=0-,1-2,2-3,4-5 같은 형태로 요청했다고 가정하자.

0-은 해당 웹페이지의 시작부터 끝까지를, 1-2는 웹페이지의 2번째~3번째 문자(0부터 시작하니깐 1-2는 2~3번째)를, 나머지도 같은 의미이다. 일반적으로 콤마(,)로 구분해서 여러 필드를 요청하는 경우는 없다라고 생각하면 된다.

[ 아파치 설정에서 Range헤더에 콤마를 제한하는 예 ]
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range

따라서 위처럼 5개 필드 이상(콤마가 5개 이상)인 경우만 제한해도 좋고, 간단하게 콤마(,)가 포함된 경우를 차단해도 무방할 것으로 보인다.
곧 패치버전이 나올 것이다. 하지만 그 때까지는 L7장비 또는 웹서버에서 Range 헤더 조건 강화하는 방법으로 차단해야 할 것이다.


* 관련글 :
  - Mitigation of Apache Range Header DoS Attack
  - DoS with mod_deflate & range requests

* 내용 추가 (2011.8.31(수) 점심)

이 DoS 취약점을 패치한 2.2.20 버전이 발표되었다.

- Release 정보 : http://www.apache.org/dist/httpd/Announcement2.2.html
- 다운받기 : http://ftp.daum.net/apache/httpd/




Posted by 좋은진호
IT이야기2011. 1. 20. 22:48
DDoS공격은 꾸준했지만, 최근 12월과 1월에 DDoS 공격량이 증가하고, 공격도 심해졌다는 얘기를 한다.

최근 몇몇 업체가 DDos공격을 받았다. 이들 업체도 DDoS 공격 피해자인데, 고객들에게 그것도 못 막냐~라는 얘기를 듣게 되고, 고객에게 미안한 마음까지 생긴다. 하지만 이들 업체가 노력하지 않아서 못 막는게 아니다. 차단위한 인프라 구축에도 한계가 있다. 만약 50G, 아니 100G가 들어온다면 일반적인 국내 환경에서 이 트래픽을 감당할 인프라를 갖춘 곳이 얼마나 되겠는가.

1. 폭우가 쏟아져 상류댐에서 대량의 물을 방류하게 되면 하류에서는 대비를 하더라도 피해를 입을 수밖에 없다.

이런 경우 해결할 방법은 상류댐(IDC나 연동망 등)에서 물길을 막아주는 것 밖에 없다.(이를 IP null routing이라고 한다. 공격받는 IP로 들어오는 트래픽을 상단에서 버리는 것이다.) 그러나 이 댐은 특이해서 물을 한방울도 흘러보내지 않거나 대량의 물을 그대로 방류하거나 둘중 하나만 선택할 수 있다. 어쩔 수 없이 물을 한방울도 흘러보내지 않는 것을 선택하게 된다. 대량의 물은 막았지만 식수난을 겪게 된다. (IP null routing을 하게 되면 공격 트래픽은 막아지지만 해당 IP로는 서비스를 할 수 없다. 인프라는 보호했지만 서비스는 못하는 현실)

DDoS

[ 이미지 출처 : 구글 이미지 검색 -> make.to ]


※ DDoS공격 유형은 여러가지가 있는데, 위는 UDP유형으로 대역폭을 초과하는 공격을 예로 든 것이다.
※ DDoS공격은 유형에 따라 차단할 수 있다. 그리고, 인프라를 초과하더라도 상단과의 협조와 내부 DDos방어장비를 이용해 단계별 처리로 피해를 줄일 수 있다. 먼저 DDoS방어장비 구축과 인프라 개선은 해야하는 것은 당연하다.


2. 최근 공격량이 증가했다는 것은 좀비 PC가 늘었다는 이야기가 된다. '선' 좀비 PC 구축 -> '후' DDoS공격의 형태이기 때문이다.

'하우리의 맞춤전용백신 목록'에서도 Trojan/DDoSAgent 전용백신이 작년 11월부터 증가했다. 좀비 PC도 늘어 났다는 것이다.
인터넷침해대응센터(KRCERT)의 보안공지( http://www.krcert.or.kr/ )를 보면 12월말부터 국내 주요 오픈소스 게시판의 취약점이 줄줄이 발표되었다. (당시 대량의 서버에 설치된 제로보드를 자동 패치하느라 고생한 커피닉스 분이 생각난다. ^^) 이들 3개 게시판이면 국내 공개 게시판의 대부분을 커버한다고 보면 된다.
취약점을 이용해 악성코드만 심으면, 공장에서 찍어내듯 좀비 PC를 만들 수 있는 대량 양산 체제를 구축한 것이다. 밤낮이 필요없는 24시간 양산 체제. 게시판 사용하는 사이트는 널려있으니, 악의적인 사람 입장에서는 원감절감(노력절감) 체제. 우리 나라 좀비 PC들은 네트웍도 빵빵하고, 성능은 날아다닌다. 그만큼 막강한 공격력을 자랑(?)하게 된다.

[ 인터넷침해대응센터(KRCERT)의 보안공지 ]


* 국내 공개 웹 게시판(제로보드) 취약점 주의 (2010/12/21)

  o 국내 PHP 기반의 공개 웹 게시판 제로보드에서 XSS, CSRF 및 RFI 취약점이 발견됨[1, 2]
  o 해당 취약점을 이용한 홈페이지 변조 및 원격 실행 위협이 발생함에 따라, 취약한 버전 사용자의 주의 및 조속한 패치가 요구됨

* 국내 공개 웹 게시판(테크노트) 취약점 주의 (2011/01/06)

  o 국내 PHP기반의 공개 웹 게시판인 테크노트에서 SQL인젝션 취약점이 발견됨 [1]
  o 취약한 버전을 사용하고 있을 경우, 홈페이지 해킹에 의한 내부정보(개인정보 등)유출 등의 피해를 입을 수 있으므로 웹 관리자의 적극적인 조치 필요

* 국내 공개 웹 게시판(그누보드) 취약점 주의 (2011/01/07)

  o 국내 PHP기반의 공개 웹 게시판인 그누보드에서 XSS, CSRF 취약점이 발견됨[1]
  o 취약한 버전을 사용하고 있을 경우, 홈페이지 해킹에 의한 관리자 계정 탈취 및 악성코드 유포지로 악용되는 등의 피해를 입을 수 있으므로 웹 관리자의 적극적인 조치 필요

게시판 취약점 이용한 악성코드 심기, 유명사이트 해킹으로 악성코드 심기, 웹브라우저의 zeroday취약점 등으로 좀비 PC 양산체제 구축은 꾸준할 것이다. DDoS공격 증가와 좀비 PC 양산체제 여건 마련은 무관하지 않다.

PC점검 철저히 하시라. 그리고 IE에만 의존하지 말고, 파이어폭스나 크롬 등도 이용하시라.
내가 이용자이면서 그들에게 공격자일 수도 있다. 누구를 욕할 처지가 아닐 수 있다.
Posted by 좋은진호
IT이야기2010. 6. 16. 18:43
최근 월스트리트 저널(online.wsj.com)등을 포함한 MS IIS 서버와 ASP.net환경의 서버에 대량 SQL Injection(Mass SQL Injection) 공격이 이뤄지고 있으니 주의가 필요하다.

해킹된 사이트에는 _script src=http://ww.robint.us/u.js_ 스크립트가 삽입이 되었다. 그 이후에 2677.in/yahoo.js, 4589.in/yahoo.js 등의 도메인으로 스크립트를 삽입하고 있다. 최근 Adobe Flash 0-day 취약점(CVE-2010-1297)이 발생했다. 이 취약점을 패치하지 않은 유저가 해킹된 사이트를 방문하면 악성코드에 감염이 된다. Armorize Blog(상세한 분석 자료 있음)에 따르면 이 악성코드는 다음 3개 게임 사이트의 게임 계정을 가로채는 것으로 알려졌다.
 
aion.plaync.co.kr
aion.plaync.jp
df.nexon.com

구글에서 2677.in/yahoo.js 또는 4589.in/yahoo.js를 검색하면, 프레시안(현재는 정상 복구된 것으로 보임), 한국표준협회, 아산시 평생학습센터 등 다수의 국내 사이트들이 감염된 것을 확인할 수 있다.

[ 구글에서 '2677.in/yahoo.js' 검색 결과 ]


유저들은 KrCERT의 권고문을 살펴보고, 반드시 Adobe Flash Player(http://get.adobe.com/flashplayer/)를 업데이트해야 한다.

마지막으로 위 도메인의 등록정보를 살펴보자. 3개 모두 중국(CN)에서 등록을 했다. 등록일이 얼마되지 않았다. 스크립를 호스팅하기 위해 생성한 도메인이라는 것을 뜻한다. 그리고, 도메인이 차단될 경우에 유사 도메인으로 계속 등록을 시도할 가능성이 커보인다.

1. robint.us
   Domain Registration Date:                    Sun Mar 14 05:28:08 GMT 2010
   Domain Last Updated Date:                    Tue Jun 08 05:10:09 GMT 2010

2. 2677.in
   Created On:10-Jun-2010 10:33:51 UTC
   Last Updated On:12-Jun-2010 15:59:46 UTC

3. 4589.in
   Created On:13-Jun-2010 08:13:07 UTC
   Last Updated On:13-Jun-2010 08:13:08 UTC


* 관련 정보

  - Mass infection of IIS/ASP sites - robint.us
  - Mass infection of IIS/ASP sites - 2677.in/yahoo.js
  - 대량 SQL Injection 공격 주의 (2009.12월)
Posted by 좋은진호
시스템이야기2010. 5. 31. 19:14
MySQL의 SELECT LOAD_FILE() 함수, LOAD DATA는 서버내에 있는 파일을 읽어들이는 명령이다. MySQL 데몬이 파일을 읽을 권한이 있다면, 서버내의 경로와 상관없이 어떠한 파일이라도 읽을 수 있다. 만약 웹페이지가 SQL Injection 공격의 취약점이 있다고 할 때 다음과 같은 형식으로 쉽게 웹에서 서버 내의 파일을 확인할 수 있는 위험성이 존재한다.

select ...생략... from ...생략...  UNION SELECT LOAD_FILE("/etc/passwd");

이 함수가 편리성, 활용성 측면에서는 좋을 수 있지만, 보안에는 취약한 통로를 제공하는 셈이다.

2009월 말, 루마니아의 Unu 해커는 세계 주요 사이트와 국내 보안 업체 사이트를 SQL Injection공격으로 해킹을 했다. 그리고, MySQL의 load_file() 함수로 서버의 /etc/ 파일까지 캡쳐하여 블로그에 공개한 적이 있다.

mysql


MySQL 5.1.17부터는 LOAD_FILE() 함수, LOAD DATA, SELECT ... OUTFILE을 특정 디렉토리내의 파일만 허용하도록 설정할 수 있다. --secure-file-priv 옵션은 동적으로는 설정값을 변경할 수가 없다. my.conf 의 '[mysqld]' 섹션에 다음과 같은 설정을 한다. (경로는 운영 환경에 맞게 할 것)

[mysqld]

secure-file-priv=/var/tmp

위처럼 설정하고 MySQL 데몬을 실행하면 load_file()을 사용할 수 있는 경로가 /var/tmp으로 제한이 된다.

자세한 글은 커피닉스의 'MySQL에서 보안위해 load_file() 경로 제한하기' ( 2010.5 )를 읽어보기 바란다.


* 관련글

- 2009/11/30 - [IT이야기] - nProtect 웹사이트, SQL Injection공격 당해
- 2008/12/11 - [시스템이야기] - MySQL 인젝션 공격 방어하는 GreenSQL
- 12.22~23 커피닉스 이야기 (Intel사이트 SQL Injection등) (2009.12.24)
- 대량 SQL Injection 공격 주의 (2009.12.11)


Posted by 좋은진호
IT이야기2010. 4. 15. 01:32
최근 KISA의 '입찰공고' 중에 '2010년 웹사이트 개인정보 모니터링 사업자 선정' 제안요청서를 봤다. 개인정보 모니터링 시스템의 환경 정보가 있다.

- 10대 검색서버(OS : Redhat Ent5.0 이상)
-  3대 검증/제어/현황/확인 서버
-  1대 DB 서버 (DBMS 알티베이스)

검색서버, 즉 검색봇 용도로 10대가 마련되어 있다. 10대라면 떠오르는게 있다.

2009년 12월에 'KISA, 개인정보 노출 검사 위해 웹페이지 마구잡이로 긁어가'라는 제목으로 썼던 'KISA 개인정보 노출 대응시스템'이 있다. 그 때 검색봇인 pirs 봇의 IP가 210.97.192.140~149이거나 211.254.252.50~59등 IP개 10개다. 그리고, 당시 언론에서 '검증,확인,분석,대응'을 수행하는 시스템이라는 말을 썼는데, 제안요청서에 적혀있는 3대의 서버용도명과도 비슷하다. 이 제안서에 있는 시스템과 'KISA 개인정보 노출 대응시스템'은 같은 시스템일 것으로 추측해본다. 다른 시스템이라 하더라도, 모니터링 대상만 조금 다를 뿐 목적은 같을 것 같다.

작년말에는 대상이 6500여개 웹사이트였는데, 제안요청서에는 '약 45,000개 웹사이트 개인정보 모니터링'이라고 적혀있으니 그 대상이 확대된 모양이다.

  o 약 45,000개 웹사이트 개인정보 모니터링
   - 점검 대상 : 중앙부처, 지자체, 공사/공단, 대학교, 준용사업자, 교육기관 및 초중고 학교 웹사이트
     ※ 점검 대상은 '09년 점검대상과 KISA가 추가로 지정하는 웹사이트
   - 점검 주기 : 2주

2. 고려사항
  o 주요 준용사업자(병원,호텔,백화점 등) 및 초중고 학교로 노출점검 대상 확대
    - 약 22,000개 도메인 목록 수작업 확보 필요


다른 제안서도 봐보자.

  • 휴대전화 실시간 스팸차단리스트(M-RBL) 구축
스팸메일 차단할 때, RBL(Real-time Blackhole List)을 이용하는 경우가 많다.
제안요청서를 보니, 모바일도 스팸전화 차단을 위해 스팸메일과 비슷한 방법을 이용한다. KISA에 M-RBL 시스템(모바일 RBL시스템)을 구축해두고, 이통사에서는 rsync를 이용해서 주기적으로 M-RBL파일을 받아가는 형태이다.
  •  이해관계자별 IPv6 적용 안내서 제작 사업자 선정
2011년경 IPv4주소 할당 중지 예상에 따라 IPv6 인프라 준비를 위해서 안내서를 제작한다는 것이다.
IPv4 중지 예측에 대해서는 'IPv4, 2011년 9월 할당 중지 예측'를 읽어보길.


위 3개의 정보만으로도, KISA의 '입찰공고'를 자주 봐야할 이유가 생겼다.
1) '시스템 구성'정보를 얻을 수 있고,
2) 정책방향(그 정책이 좋은지, 나쁜지와는 상관없이)도 미리 알 수 있는 흥미로운 공간이다.


혹시 이글을 KISA등 IT 정책세우시는 분들이 한분이라도 읽을지도 모르니, 한가지 덧붙인다.

'IT이용도'에 따라 '한 사람'의 생활이 달라지지만,
'IT정책'은 '한 국가'의 IT생태계를 좌우한다는 것.

Posted by 좋은진호