CISO(최고정보보안책임자)들이 보안 문제의 주범으로 한결같이 지적하는 것은 바로 엉성하게 만들어진 소프트웨어다. 업계에서는 이미 다 알고 있는 사실이니 그리 놀랄 만한 것은 아니다.

개발자들은 보통 보안시스템 교육을 거의 받지 않는다. 설사 교육을 받았다 하더라도 소프트웨어 엔지니어들은 소프트웨어에 기능을 추가했다거나 개발 일정을 맞추는 경우에나 보상을 받을 뿐, 소프트웨어의 취약점을 제거했을 때는 아니다.

버
그 투성이의 코드가 작성되면 결국 소프트웨어가 개발된 후에 보안 전략을 다시 수립해야 하는 상황에 처하게 된다. 방화벽,
애플리케이션 게이트웨이, 패킷 필터링, 행동 차단(behavior blocking), 패칭 등 현재 우리가 사용하는 각종 보안
수단들은 소프트웨어 취약점, 개방형 인터페이스, 불안정한 기능 등에 맞서 소프트웨어를 보호하기 위한 조치들이다.

의료 행위와 비교한다면「병 자체가 아닌 증상을 치료하는 것(대증요법)」이라고나 할까.

사
후약방문식의 보안 처방은 비효율적일뿐만 아니라 비용도 많이 든다. 진정으로 자신의 가치 자산을 보호하고 싶다면 IT 관리자들이
해커들보다 한 템포 빠르게 대처할 수 있도록 소프트웨어 취약성 데이터베이스를 끊임없이 추적해야 한다.

소프트웨어
업체들이 발표하는 패치만 활용해도 모든 취약한 시스템에 대해 IT 보안 훈련과 응급처치를 할 수 있다. 이미 개발이 완료된
소프트웨어의 보안 취약점을 수정하는 것은 개발 과정에서 수정하는 것보다 100배나 더 많은 비용이 소요될 수도 있다.

하
지만 언제나 모자란 것보다는 넘치는 게 좋다. 소프트웨어 보안 문제가 이슈화되면서 이제는 학계와 정부에서도 관심을 기울이기
시작했다. 일례로 카네기 멜론 대학의 SEI(Software Engineering Institute)는 품질과 보안에 중점을
두는 소프트웨어 개발 프로세스 모델을 개발했다.

그리고 이 표준은 미국 국토안보부(Department of Homeland Security)의 BSI(Build Security-In) 계획에도 포함됐다.

출
발은 좋다. 하지만 매년 소프트웨어에 수십억 달러를 쏟아 붓고 있는 기업으로 눈을 돌려보자. 슬프지만 대부분의 기업들은
ISV(독립소프트웨어업체)들로부터 립서비스로만 보안 소프트웨어 개발을 제공받고 있을 뿐이다. 그렇다면 그 결과는? 불안정한
소프트웨어가 이미 상당수 설치돼 있거나 매일 추가되고 있다. 무언가 획기적인 조치가 필요한 시점이다.

	사후약방문식의 보안 처방은 비효율적일 뿐만 아니라 비용도 많이 든다.

흥미로운 사실은 대부분의 기업들이 보안 소프트웨어 개발에 대해 자유방임주의적 태도로 일관하는 데 비해 수많은 보안 문제를 유발하는 주범으로 종종 지목되는 MS는 철저한 보안 전략을 수립하고 있다는 점이다.

MS는 지난 2002년 빌 게이츠가 TC(Trustworthy Computing) 이메일 선언을 하기 오래 전부터 이미 소프트웨어 설계와 테스팅 프로세스에 보안 이슈를 포함시켜 왔다.

1998
년의「내부 보안 태스크포스」는 2000년 SWI(Secure Windows Initiative)로 발전했으며, 2004년「보안
푸시(security push)」를 거쳐 최종적으로 완전한 모습을 갖춘 SDL(Security Development
Lifecycle)로 탄생했다. SDL은 개발자 교육과 보안 응답 실행 처리로 시작되는 철저한 12단계 시리즈 보안 전략이다.

지난 2004년 MS 임원진의 지시로 시작된 이후 비즈니스 활동에 사용되고 있으며, 인터넷에 노출되거나 사적인 데이터를 포함하는 모든 MS의 소프트웨어는 SDL을 준수하도록 하고 있다.

그
러나 MS가 인정하듯 SDL은 무료가 아니다. 중요한 레거시 코드를 사용하는 기업의 경우, SDL로 인해 개발비와 프로젝트
비용이 15~20% 정도 상승할 수 있다. 하지만 MS는 SDL이 그 이상의 가치를 갖고 있다고 주장한다. SDL 프로세스를
거친 제품의 경우 취약점이 50% 정도 감소했으며, 지난 3년 동안 SQL 서버에서 단 한 번도 데이터베이스 취약점이 발견되지
않았다는 것이다.

그렇다면 빌 게이츠와 MS를 통해 기업들이 배울 수 있는 것은? MS의 SDL 성과는 보안
소프트웨어 개발이 얼마나 중요하며 또 효과적일 수 있는지를 잘 보여주는 사례다. MS가 SDL을 구현함으로써 상당한 비용을
절감한 것은 분명한 사실이다.

그러나 이보다 더 중요한 것은 MS가 고객들에게 보안 운영비용이 더 낮은 양질의 소프트웨어를 제공할 수 있게 됐다는 점이다.

다
른 기업들은 이를 모델로 삼아야 한다. 이제부터는 사내 개발자, ISV, 아웃소싱 업체들에 안전한 소프트웨어 개발을 요구해야
한다. 보안 소프트웨어 개발 프로세스의 전체 개요가 담긴 문서를 제공받고 ISV에는 보안 개발 프로세스 결과 보고서를 요구해야
한다.

즉 기업이 ISV들로부터 재무보고서처럼 소프트웨어 개발에 대해서도 투명성 있는 자료를 제출받아야 한다는 말이다.

자,
그러면 다음 단계는 무엇이 될 것인가? 보안 소프트웨어 개발이 오랜 시간을 거쳐 ISO 와 같은 국제 표준 기구를 통해 결실을
맺게 될 것이다. PCI(Payment Card Industry)는 오는 2007년 내에 PCI SSS(Security
Standard Specification) 2.0에서 이를 구현하기 위해 은행과 유통업체들을 준비시키고 있다.

앞을
내다볼 줄 아는 기업이라면 ISV들을 상대로 빠른 시일 내에 이러한 프로세스를 시작하라고 요구해야 한다. 2008년까지 보안
소프트웨어 개발 프로세스를 구현하지 않으면 사업상 문제가 생길 것이라며 정확한 데드라인을 제시하라. 너무 엄격한 것 아니냐는
불만이 나올 수도 있겠지만, 조금이라도 멀리 보는 기업이라면 지금 당장 이 작업을 시작해야 한다.

현재 보안 소프트웨어 개발에 대해 아무것도 하지 않고 있는 ISV들과 아웃소싱 업체들이 보안 문제에 눈을 뜰 때까지는 꽤 많은 시간이 걸릴 테니까 말이다. @

– Jon Oltsik ( CNET News.com )   2006/12/05

 1. ProFTPd 의 모든 설정은 이 파일에서 하게 됨.

 – proftpd.conf 설정예.

 –
proftpd.conf 파일의 전체적인 구성을 보면 모든 ftp 서비스에 대한 설정을 하는 Global 설정 부분이 있으며 그
다음에 anonymous 접근에 관한 설정이 있고 그 다음에 가상 ftp 호스트를 설정하는 부분이 있음. proftpd.conf
파일 설정시에 주의해야 할 것은 설정 지시자와 설정내용 사이에는 반드시 [TAB] 키로 띄워야 함.

 – ServerName 지시자
ServerName   “pchero21.com;s ftp service”
: ServerName 는 ftp 서버의 이름을 설정함. 대부분 ftp 사이트의 도메인명을 입력하거나 아니면 서비스명등을 입력하게 됨.

 – ServerType 지시자
ServerType   standalone
:
ServerType 설정에서는 ftp 서버데몬을 xinetd 모드로 할 것인가 아니면 standalone 모드로 운영을 할
것인가에 대한 설정을 하는 것임. 위의 설정을 standalone 모드로 운영할 경우의 설정이며 만약 xinetd 모드로 운영할
경우에는 다음과 같이 설정하면 됨.
ServerType   inetd

 – DefaultServer 지시자
DefaultServer   on
:
한대의 리눅스서버에서 여러 개의 ftp 서비스를 가상 ftp 서버로 설정하여 운용할 경우에 기본적으로 운용할 서버설정을 하는
것임. 하나의 proftpd 를 이용하여 여러 개의 가상 ftp 서버를 운용할 경우에 기본서버로 응답하게 하려면 on 을
설정하고 기본서버로 응답하지 않게 하려면 off 로 설정하면 됨.

 – DefaultRoot 지시자
DefaultRoot   ~ !wheel
: DefaultRoot 지시자는 ftp 사용자들이 자기의 홈디렉토리 상위로 이동하지 못하도록 설정하는 지시자임.
 
위의 설정은 wheel 그룹에 등록된 사용자들을 제외한 나머지 모든 사용자들에게 대한 자기자신의 홈디렉토리를 최상위 디렉토리로
인식하도록 함. 따라서 wheel 그룹에 등록된 사용자들을 제외한 나머지 모든 ftp 사용자들은 자기 자신의 홈디렉토리
상위디렉토리로 이동할 수 없음. 참고로 서버관리자는 대부분 wheel 그룹에 등록해서 사용함. 따라서 관리자에 속하는 사용자들을
wheel 그룹에 등록해 두고 이 설정을 사용한다면 관리자들은 제한없이 상위 디렉토리로 이동이 가능하면서 일반사용자들은 자기의
홈디렉토리를 벗어나지 못하므로 효율적인 설정이 됨.

 – Port 지시자
 Port   8021
:
ftp 서비스의 기본 사용포트를 지정한 것임. /etc/services 파일에 ftp 서비스의 포트설정이 되어 있어야만 정상적인
ftp 서비스가 가능함. 이 설정은 ftp 가 standalone 모드로 운영이 될 경우에만 유효한 것으로 만약 ftp 를
xinetd 환경에서 서비스를 한다면 /etc/xinetd.d/proftpd 파일에서 사용포트를 지정해 주면 됨.

 – Umask 지시자
 Umask   022   022
: Umask 설정은 ftp 로 접속한 사용자들이 파일 업로드시에 생성되는 파일퍼미션과 디렉토리퍼미션을 설정하는 것임.
 022 로 설정을 하였을 경우에는 업로드되는 파일의 퍼미션은 644 가 되며 생성되는 디렉토리의 퍼미션은 755 가 됨.
 002 로 설정을 하였을 경우에는 업로드되는 파일의 퍼미션은 664 가 되며 생성되는 디렉토리의 퍼미션은 775 가 됨.
 007 로 설정을 하였을 경우에는 업로드되는 파일의 퍼미션은 660 이 되며 생성되는 디렉토리의 퍼미션은 770 이 됨.
 070 으로 설정을 하였을 경우에는 업로드되는 파일의 퍼미션은 604 가 되며 생성되는 디렉토리의 퍼미션은 705 가 됨.
 Umask 의 설정을 파일과 디렉토리의 보안정책을 어떤식으로 가져갈 것인가에 따라서 달리 설정하면 됨.

 – MaxInstance 지시자
 MaxInstance   30
:
ftp 서비스 요청이 있을 경우에 ProFTPd 는 자식프로세스를 생성하여 개별 ftp 서비스 요구에 응답을 하게 됨. 이때
생성될 수 있는 ftp 자식프로세스의 최대수를 지정해 둔 것임. 즉, 동시에 서비스가능한 ftp접속수라고 이해 하면 됨. 또한
이 설정은 ProFTPd 서버 실행을 standalone 으로 했을 때에만 적용이 되는 것임. xinetd 로 서비스될 경우에는
적용되지 않음. 그리고 ftp 보안이라는 관점에서 이 설정이 갖는 중요한 의미는 DoS (Denal of Service)
공격방어를 어느정도 할 수 있다는 것임. DoS 공격은 수많은 서비스요구를 동시다발적으로 하여 ftp 서비스를 다운시키는
공격임. 여기서 설정된 기본 30개 이상의 ProFTPd 의 자식프로세스가 생성되지 않으므로 30개 넘게 요구가 있을 경우에는
DoS 공격이라고 판단하여 응답을 하지 않게 됨.

 – User, Group 지시자
 User   proftpd
 Group   nogroup
:
ProFTPd 의 실행시에 여기서 설정된 계정 (User) 과 그룹 (Group) 으로 실행이 됨. 어떤 이름으로 해도
상관없으나 반드시 실제 존재하는 계정으로 설정이 되어야 함. 즉 /etc/passwd 내에 존재하는 실제 계정 중 하나로 설정이
되어 있어야 한다는 것임. 다만 주의해야 할 것은 시스템에 특별한 권한이 있는 계정으로 설정을 해서는 안됨. 또한 앞서 소스를
컴파일하여 설치한 후에 proftpd 의 초기 실행시에 에러가 발생했던 것은 여기서 설정하는 Group 지시자 값이
nogroup으로 설정되어 있었기 때문임.

 – RootLogin 지시자
 RootLogin   off
:
이 설정은 시스템의 root 계정으로 ProFTPd 접속을 혀용할 것인가를 설정하는 것임. 위의 설정이 off 로 되어있는
것처럼 ProFTPd 의 초기 설정에는 root 계정으로 ftp 접속이 되지 않음. 만약 root 계정으로 ftp 접속을
허용하려면 on 으로 설정하면 됨. 하지만 서버 보안을 위해서 가능한 기본설정인 off 로 해두고 root 원격접속은 막아두는
것이 현명한 것임.

 – RateReadBPS 지시자, RateWriteBPS 지시자
: RateReadBPS
지시자는 파일을 서버에서 클라이언트로 다운로드할 때의 사용가능 대력포글 설정해 둔 것이며, RateWriteBPS 는 파일을
클라이언트에서 서버로 업로드 할 경우에 사용가능한 대역폭을 설정해 둔 것임. BPS 는 bit per second 의 약어로서
초당 전송가능한 bit 수를 의미함. 이 설정을 융통성있게 설정하면 ftp 를 효율적으로 운용할 수 있음. 즉 한명의 ftp
사용자가 모든 대역폭을 모두 차지하는 것을 방지할 수 있으며, 또한 ftp 서비스가 서버의 모든 네트웍 대역폭을 차지함으로
인하여 서버의 또 다른 서비스 (ex. www, email 등) 의 장애를 예방할 수 있음.

 – RateReadFreeBytes 지시자, RateWriteFreeBytes 지시자
: RateReadFreeBytes 지시자는 대역폭의 제한없이 download 를 허용할 bytes 수를 지정한다. RateWriteFreeBytes 지시자는 대역폭의 제한없이 upload 를 허용할 bytes 수를 지정한다.

 – DisplayLogin 지시자
 DisplayLogin   welcome.msg
: 이 설정은 ftp 접속시에 보여줄 메시지 파일을 설정한 것임. 위의 설정 예에 의하면 ftp 서버로 접속하였을 경우에 welcome.msg 라는 파일을 보여주게 된다는 것임.

 – DisplayFirstChdir 지시자
 DisplayFirstChdir   .message
:
앞서 설명한 DisplayLogin 이라는 지시자가 ftp 접속시에 보여주는 메시지내용을 설정한 것이라면 이
DisplayFirstChdir 은 ftp 접속 후에 특정 디렉토리로 이동하였을 경우에 그 디렉토리의 안내문을 보여주기 위한
설정파일임. 즉, ftp 접속후에 특정 디렉토리로 이동하게 되면 이동한 그 디렉토리내에 존재하는 .message 파일의 내용을
자동으로 보여주게 됨.

 – <Direcroty> ~ </Direcroty> 지시자
 <Direcroty /*>
    AllowOverwrite   on
 </Direcrtory>
:
이 디렉토리지시자는 개별디렉토리 이하에서의 설정을 할 수 있는 부분임. 이 설정은 주로 개별 사용자들의 ftp 디렉토리를 별도로
설정할 경우에 상둉하는 것임. 중요한 것은 이 설정에서 * 를 사용할 수 있다는 것이며, 또한 앞서 설정한 내용과 중복될
경우에는 여기서 설정한 개별 디렉토리내용이 지정한 디렉토리 내에서는 우선한다는 것임.

 – <Anonymous ~ftp> ~ </Anonymous> 지시자
: 이 설정은 anonymous ftp 에 대한 설정을 한 것임. Anonymous 접속시에 여기서 설정한 내용의 적용을 받는다는 의미가 됨.

 – <Limit> ~ </Limit> 지시자
: 이 설정이 위치하는 디렉토리내에서 사용할 수 있는 ftp 명령어들의 제약을 하기 위한 것임.

 – MaxLoginAttempts 지시자
: 동일한 클라이언트에서 ftp서버로 접속시도할 수 있는 최대허용횟수를 제한함.

 – RequireValidShell 지시자
:
이 지시자는 ftp 접속시에 쉘 (shell) 을 요구할 것인가 말것인가를 결정하는 지시자. 즉, 이 값이 on 으로 되어있다면
/etc/passwd 파일내에 설정된 각 사용자의 쉘종류가 유효한 쉘 사용자만 접속이 가능하게 됨. 반대로 이 값이 off 로
설정되어있다면 /etc/passwd 파일내에 설정된 각 사용자의 쉘종류가 유효하지 않은 쉘사용자라도 ftp 접속은 가능하게 됨.

 1. proftpd 의 xinetd 운영환경 설정하는 방법

 – proftpd 를 운용하는 방법에는 두가지 모드가 있음. Standalone 모드와 xinetd 운영모드가 그것임.

 –
Standalone 모드 : proftpd 를 운영하면 proftpd 서버데몬이 항상 메모리에 상주하게 됨. 그리고 ftp
클라이언트들의 응답요구를 직접 받아서 처리하게 되므로 당연히 xinetd 모드로 운영하는 것보다는 빠른 서비스를 제공할 수
있음. 하지만 메모리에 항상 proftpd 데몬이 상주 해야하기 때문에 ftp 서비스 요구가 없을 경우에는 시스템 자원낭비를 할
수가 있음.

 – xinetd 모드 : ftp 클라이언트들의 요구에 proftpd 서버데몬이 직접 응답을 하는 것이
아니라 xinetd 수퍼데몬이 먼저 응답을 하여 접속권한 체크등을 한 후에 허용될 경우에만 xinetd 데몬이 proftpd
서버데몬을 불러 클라이언트와 proftpd 를 연결하여 처리하도록 함. 즉, ftp 서비스의 모든 처리를 xinetd 데몬이
먼저 받아서 정당한 접속일 경우에만 proftpd 서버데몬과 연결을 시켜주는 방식이 됨. 이 경우 proftpd 서버데몬은
메모리에 항상 올라와 있는 것이 아니라 xinetd 의 요구에 의해 메모리로 불려와서 클라이언트의 응답에 대한 처리를 하게되고
응답이 끝났을 경우에는 proftpd 서버데몬은 종료되어 메모리에서 사라지게 됨. 따라서 ftp 서비스의 요구가 없을 경우에는
메모리에 proftpd 서버데몬은 메모리에 올라오지 않기 때문에 자원낭비를 하지않게 됨. 하지만 xinetd 를 거쳐서 서비스를
하기 때문에 즉각적인 응답을 할 수 없으며 당연히 standalone 모드 보다는 응답속도가 떨어지게 됨.

 –
ftp 서비스는 이 두가지 모드로 모두 운영이 가능함. Standalone 모드로 운영을 하려면
“/usr/local/proftpd/sbin/proftpd” 를 실행하여 proftpd 데몬을 띄워놓으면 됨. 하지만
xinetd 모드로 운영할 경우에는 다음과 같은 설정을 해 주어야 함.

 – /etc/xinet.d/ 디렉토리에 proftpd 라는 파일을 다음과 같이 생성해야 함.

 –
위의 항목에서 반드시 확인해야 할 것은 disable 항목과 server 항목임. 만약 ftp 서버로 ftp 접근이 안 될
경우에는 이 파일의 내용 중 “disable” 항목을 “yes” 에서 “no” 로 설정한 다음 xinetd 를 재시작 한 후에
ftp 를 접속을 한다. 그리고 server 항목에서 지정한 /usr/local/proftpd/sbin/in.proftpd 는
반드시 실제로 존재하는 파일명을 지정해야 함.

 – 그리고 /usr/local/proftpd/etc/proftpd.conf 파일을 열어서 ServerType 지시자의 설정값을 inetd 라고 지정해 주면 됨.
ServerType                        inetd

 – 위의 파일을 새로 생성하거나 기존에 있던 파일을 수정한 경우 xinetd 데몬을 재시작해 주어야 함.
 /etc/rc.d/init.d/xinetd restart