레이블이 보안인 게시물을 표시합니다. 모든 게시물 표시
레이블이 보안인 게시물을 표시합니다. 모든 게시물 표시

2012-09-16

DBMS/MSSQL]SQL Server 2005의 최신보안 기능을 이용한 해커 저지하기

해커 주의

SQL Server 2005의 최신보안 기능을 이용한 해커 저지하기


이 기사는 SQL Server 2005의 프리릴리즈 버전에 근거합니다. 여기에 실린 모든 정보는 변경될 수 있습니다.

This article discusses:
  • 세밀한 사용 권한과 최소 권한 원칙
  • 메타데이터 가시성 제어
  • 사용자와 스키마 분리
  • 데이터베이스 실행 컨텍스트와 암호화
This article uses the following technologies:
SQL Server 2005, 보안


Code download available at:
SQLServerSecurity.exe (115KB)

지금은 여러분의 데이터베이스와 클라이언트 응용프로그램에 대해 더욱 더 적대적인 세상입니다. 공격자들은 매일 여러분의 귀중한 데이터를 손상시키기 위해 새롭고 영리한 공격을 개발합니다. 다행스럽게 SQL Server 2005은 철저한 방어와 최소 권한 같은 원칙을 전적으로 다루는 강력한 새로운 보안 기능들을 제공합니다. SQL Server 온라인 설명서에서 설명된 것처럼 Microsoft는 변화하는 보안 상황에 높을 보안을 유지하는 것에 관한 보다 나은 보안 도구와 문서를 제공하면서, 공격 표면적을 줄이고 SQL Server와 데이터베이스를 안전하게 배포하는 것을 쉽게 하는 많은 보안 전략을 구현했습니다.
이 문서에서는 개발자 관점에서 SQL Server2005내에서 가장 흥미로운 보안 기능 향상에 대해서 알아볼 것입니다. 저자는 TechNet Magazine (영문)의 2005년 봄호에서 관리자 보안 기능들에 대해서 다루었습니다. 그러나 종단점 인증과 서버에서 실행하는 관리 코드의 보안 컨텍스트에 대한 지원 같은 수많은 개발자 기능 향상이 있습니다. 저자는 핵심 관계형 데이터베이스 엔진에만 집중할 것입니다. Reporting Service나 Analysis Service 같은 지원 시스템은 전체기사를 할애할만한 가치가 있는 자체 보안 기반구조를 가지고 있습니다.

사용 권한
SQL Server 2000과 그 이전 버전은 사용자, 로그인 및 다른 대리 사용자(principal) 에게 권한을 할당하는 합리적인 스키마를 가지고 있습니다. 그러나 이런 버전의 SQL Server에 대한 락 다운(lock down)을 시도할 때 여러분은 강력한 보안을 구현하기 위해 날카로운 해부용 메스라기 보다는 상당히 뭉툭한 도구를 가지고 작업을 하고 있습니다. 여러분은 종종 사용자에게 사용자가 필요로 하는 권한 뿐만 아니라 사용자가 필요로 하지 않은 다른 많은 권한을 가지는 고정 역할을 사용자에게 할당해야만 합니다. 이것은 개개의 사용자나 다른 대리 사용자가 더도 말고 덜도 말고 딱 필요한 권한만 가진다는 최소 권한 원칙의 심각한 위반입니다.
SQL Server 2005에서는 부여할 수 있는 권한이 이전 버전보다 훨씬 한정되었습니다. 사실상 어떤 개체든 실질적인 대리 사용자에 수여할 수 있는 다양한 권한을 가지고 있습니다. SQL Server는 여전히 서버와 데이터베이스 수준에서 역할을 많이 사용합니다만 사용자 요구가 특정한 자원에 대한 제한된 액세스일 때 더 이상 사용자를 역할에 추가할 필요가 없습니다.
SQL Server 2005의 보안 용어에서, 대리 사용자(principal)는 보호되는 자원에 액세스하는 요청을 할 수 있고 이것에 액세스 하기 위해서 권한이 부여 되는 어떤 개인, 그룹(역할), 또는 프로세스입니다. 이전 버전의 SQL Server에서처럼 대리 사용자는 Windows내에 정의 할 수 있고 하거나 일치하는 Windows 대리 사용자 없이도 SQL Server 로그인을 기반으로 할 수 있습니다. 그림 1 에서는 고정 서버 역할과 고정 데이터베이스 역할을 제외한 SQL Server 2005 대리 사용자 계층구조를 보여주며 어떻게 로그인과 데이터베이스 사용자 보안 개체에 매핑될 수 있는지를 보여줍니다. 이전 버전에서처럼 SQL Server 2005에서 대리 사용자의 영향이 미치는 범위는 이것의 정의 범위 에 달려 있습니다. 따라서 Windows 수준 대리 사용자는 SQL 서버 수준 대리 사용자를 포함하고 SQL 서버 수준 대리 사용자는 데이터베이스 수준 대리 사용자를 포함합니다. 모든 데이터베이스 사용자는 자동적으로 고정 공용(Public) 역할에 속합니다.
또한 주목할만한 것은 개체는 사용 권한을 부여하고 거부함으로서 보호될 수 있다는 것입니다. 그림 2은 SQL Server 2005의 보호할 수 있는 개체 목록입니다. 서버 수준에서 서버로부터 와 서버로의 통신 채널을 제어하기 위한 네트워크 종단점뿐만 아니라 데이터베이스, 바인딩, 역할, 및 로그인을 보호할 수 있습니다. 데이터베이스와 스키마수준에서는 생성할 수 있는 모든 개체는, 특히 데이터베이스 개체들을 포함하기 위해 사용되는 스키마 개체, 사실상 보호할 수 있습니다.
그림 2 SQL Server 2005에 보호할 수 있는 개체들 -1){ thisSrc = this.src; ns = thisSrc.lastIndexOf('='); ne = thisSrc.length; orgImg = thisSrc.substr(ns + 1, ne); this.src = './dnImage/' + orgImg;}" src="http://tfile.nate.com/download.asp?FileID=4886328" localfile="yes" height="196" width="300">
그림 2 SQL Server 2005에 보호할 수 있는 개체들
고정 서버 역할들과 고정 데이터베이스 역할들은 SQL Server 2000와 비교해서 변경되지 않았습니다. 그래서 사용자나 응용프로그램이 전부 또는 대부분의 정의된 사용 권한을 요구할 때 이런 미리 정의된 사용 권한 묶음을 여전히 이용할 수 있습니다. 그러나 최소 권한 원칙하에서는 여러분은 대리 사용자에게 초과 권한을 부여하는 역할을 사용하기를 원하지 않을 것입니다. 비록 대리 사용자에 필요한 권한을 알아내고 사용 권한을 할당하는 것은 약간의 일을 더하게 되지만 이것은 좀 더 안전한 데이터베이스 환경일 수 있습니다.
SQL Server에서 사용 가능한 사용 권한의 숫자에 대해 알기 위해서, builtin_permissions 카타로그 뷰를 볼 수 있습니다:
          SELECT * FROM sys.fn_builtin_permissions(default)
          
4월의 CTP에서는 모든 사용 권한을 나타내는 180행 이상의 행을 반환합니다; 여기서는 좀 더 중요한 몇 가지에 대해서 설명할 것입니다.
CONTROL사용 권한은 권한을 허가 받든 사용자(grantee)에게, 보호할 수 있는 개체에 사용 권한을 수여하는 능력을 포함하여, 소유권을 수여합니다. 계층구조내의 한 레벨에 있는 보호할 수 있는 개체가 CONTROL 권한을 가지고 있다는 것은 포함된 모든 개체에 같은 권한이 있다는 것을 뜻합니다.
ALTER ANY 엔터티 사용 권한은 엔터티 형태의 어떤 개체에 생성(create), 대체(alter), 및 삭제(drop)하는 권한을 수여합니다. 예를 들어 서버 수준의 ALTER ANY DATABASE 사용권한은 권한을 허가 받은 사용자가 어떤 데이터베이스든 대체할 수 있게 합니다. 특정한 데이터베이스 범위내의 ALTER ANY ASSEMBLY 사용 권한은 권한을 허가 받은 사용자가 어떤 어셈블리든 변경할 수 있도록 합니다.
IMPERSONATE ON 로그인 또는 IMPERSONATE ON 사용자는 권한을 허가 받은 사용자에게 특정한 로그인이나 데이터베이스 사용자를 가장할 수 있게 해서 가장된 보안 자격 증명을 사용하여 어떤 연산이든 수행됩니다. 이 사용 권한은 EXECUTE AS 기능(이 기사의 뒤에서 설명하는)에서는 중요합니다.
SQL Server 2005는 보호할만한 개체에 권한을 할당하고 거부하기 위해서 잘 알려진 GRANT, DENY,및 REVOKE 스키마를 여전히 사용합니다. GRANT 구문은 권한 부여 영역과 대리 사용자가 다른 대리 사용자에게 권한를 부여할 수 있는지 와 같은 새로운 권한 옵션을 포함하도록 확장되었습니다. 데이터베이스 간의 사용자 권한은 허용되지 않습니다. 데이터베이스 간의 사용자 권한 부여를 위해서, 각각의 데이터베이스에 복제 사용자를 만들고 각각의 데이터베이스 사용자에게 권한을 할당해야 합니다. 이전 버전의 SQL Server와 같이 응용프로그램 역할 활성화는 역할이 활성화되는 기간동안 다른 권한을 보류됩니다.
특정한 권한 부여는 함축을 통해서 다른 사용 권한을 옮길 수 있습니다. SQL Server 온라인 설명서에는 sys.fn_builtin_permissions 카테고리 뷰로부터 계층구조 목록을 모으고 각각 사용 권한의 깊이를 식별하는 ImplyingPermissions 사용자 정의 함수를 위한 T-SQL이 있습니다. 개체와 사용 권한 형태를 전달해서 사용 권한의 계층 구조 목록을 생성하기 위해 아래 구문을 실행 합니다:
          SELECT * FROM master.dbo.ImplyingPermissions('schema', 'alter')
          
SQL Server 2005내에서 단지 얼마나 세밀한 사용 권한이 가능한지를 평가하는 것은 처음에는 어려울 것입니다. 서버와 대표적인 데이터베이스내의 사용 가능한 대리 사용자의 숫자와 형태 그리고 보호할 수 있는 개체의 숫자를 고려하십시오(검토하십시오). 또한 사용 가능한 사용 권한과 포함되고 내포한 사용 권한의 숫자를 고려하십시오. 응용프로그램 생성은 좀더 자세한 분석 보안 요구사항에 대한 상세한 분석과 모든 개체의 사용권한을 주의 깊은 제어를 필요로 합니다. 그럼에도 불구하고 여전히 부여할 수 있는 권한을 가지지 않는 동작들이 있습니다. 예를 들면 TRUNCATE TABLE은 테이블에 단지 테이블의 행을 삭제하는 것 이상의 능력을 수여하는 ALTER 사용 권한을 필요로 한다.

카탈로그 뷰와 메타데이터 가시성
SQL Server 2005의 고도로 세밀한 권한 스키마의 장점은 현대 데이터베이스 엔진이 필요로 하는 메타데이터에 대한 보다 나은 보호를 할 수 있다는 것입니다. SQL Server는 SQL-92 명세에 정의 되어 있는 INFORMATION_SCHEMA 뷰, 서버와 데이터베이스 수준의 시스템 테이블, 그리고 시스템에 내장된 막대한 숫자의 저장 프로시저를 통해서 강력히 지원되는 리치(rich) 메타데이터를 가지고 있습니다. 시스템 안정성에 커다란 위험이 있지만 시스템 테이블을 수정해서 서버와 서버의 데이터베이스의 내재하는 상태 조차도 변경할 수 있습니다. Microsoft는 언제든지 내재하는 시스템 테이블을 변경할 수 있어서 이것을 사용한 것은 본인의 책임임을 끊임없이 상기시킵니다.
SQL Server 2005에서 Microsoft는 시스템 전체의 모든 메타데이터를 표시하는 새로운 카탈로그 뷰 집합을 만들었습니다. 새로운 sys 스키마는 메타데이터 뷰를 캡슐화 합니다. 카타로그 뷰들은 읽기 전용이며 이것은 이전 버전의 SQL Server에서 가능했던 해킹을 제거합니다. 많은 뷰들이 원하는 정보를 쉽게 찾기 위해서 예전 시스템 테이블의 이름과 같은 이름을 사용합니다. 예를 들어 sysobjects 메타데이터 sys.objects 뷰를 통해서 표시됩니다. 뷰 정의는 물리적으로 이 정의에 직접적으로 액세스하는 방법이 없는 알려지지 않은 (undocumented) 위치에 숨겨져 있습니다. (서버에 해킹을 해서 이것을 찾지 않으면) 그럼에도 불구하고 메시지는 명백합니다: 서버와 데이터베이스의 모든 데이터를 얻기 위해 카타로그 뷰를 이용하십시오. 그리고 이전 해킹에 대해서는 잊어버리십시오. 저장 프로시저, T-SQL, 및 그 밖의 SQL Server를 구성하고 조정(tweaking)하는 공식적인 방법을 준수하십시오. 이것은 모두 보안과 안정성을 위해서 입니다.
보안 관점에서 메타데이터를 표시하기 위해서 뷰를 사용하는 것의 장점은 카탈로그 뷰로부터 반환되는 데이터가 데이터를 요청하는 사용자 컨텍스트의 보안에 따라 필터된다는 것입니다. 예를 들어, 과거에는 데이터베이스내의 sysobject 테이블에 액세스하는 권한을 가지고 있는 사용자(대부분의 사용자는 많은 응용프로그램 내에서 합니다.)가 테이블에 대한 쿼리를 실행할 수 있고 데이터베이스에 있는 모든 사용가능한 개체를, 이 사용자가 각각의 개체에 대한 액세스가 있던 없던 상관없이, 볼 수 있었습니다. SQL Server 2005에서는 테이블을 보기 위해서는 테이블에 대한 SELECT 권한 같은 최소한의 액세스를 가지고 있어만 합니다. 만약 사용자가 데이터베이스에 대한 액세스를 가지고 있지만 이 데이터베이스 개체에 대해서는 액세스 없으면, sys.objects에 대한 쿼리는 아무런 결과 행을 반환하지 않습니다.
이것이 어떤 식으로 동작하는지 보기 위해서 다음의 코드를 관리자로 실행하십시오:
          USE master

          CREATE LOGIN User1 WITH password = 'myPassword'

          

          

          -- 여러분이 선택한 데이터베이스를 사용하십시오

          

          USE AdventureWorks

          CREATE USER User1

          

          EXECUTE AS LOGIN = 'User1'

          SELECT * FROM sys.objects

          

          -- 사용자 db내에 사용권한이 없기 때문에 아무런 행이 반환되지 안습니다.

          

          REVERT
          
코드는 서버에 대한 User1 로그인을 생성하는 것으로 시작해서 로그인한 사용자와 매핑 되는 사용자를 예제 AdventureWorks 데이터베이스에 추가합니다. 그리고는 실행 컨텍스트를 User1으로 바꾸고 sys.objects로부터 데이터를 검색합니다. User1은 데이터베이스에 대한 액세스는 가지고 있지만 어떤 개체에 대한 권한도 없기 때문에 카타로그 뷰로부터 아무것도 반환되지 않습니다. REVERT 구문은 관리자로 실행 컨텍스트를 복귀시킵니다.
데이터가 반환되기 위해서는 두개의 권한을 사용자에게 부여해야만 합니다. 다음 코드는 Contact 테이블에 대한 SELECT 권한과 dbo.uspGetBillOfMaterials 저장 프로시저에 대한 EXECUTE 권한을 부여합니다.
          -- 테이블과 저장 프로시저에 대한 권한을 부여 하십시오 

          

          GRANT SELECT ON Person.Contact TO User1

          GRANT EXECUTE ON dbo.uspGetBillOfMaterials TO User1

          

          -- User1으로 다시 실행하십시오

          

          EXECUTE AS LOGIN = 'User1'

          SELECT * FROM sys.objects

          REVERT
          
User1으로 카타로그 뷰를 실행했을 때, sys.objects 카타로그 뷰로부터 Contact 테이블와 uspGetBillOfMaterials 저장 프로시저의 메타데이터뿐만 아니라 테이블 제약 조건과 트리거 같은 연관된 개체를 포함하는 아홉개의 행을 얻게 됩니다. 이것은 개체 계층구조의 한 수준에 권한을 부여하면 연관된 권한이 자식 개체에 부여되는 방법을 보여줍니다.
예상한 것처럼, sysadmins와 sa는 시스템 카타로그 뷰에서 서버에 있는 모든 것을 볼 수 있으며 데이터베이스 소유자는 데이터베이스의 모든 것을 볼 수 있습니다. 사용 권한 기반 필터링은 sp_help와 sp_helpdb 같은 별개의 개체에 대한 정보를 보여주는 시스템 저장 프로시저에도 적용합니다. 이런 시스템 저장 프로시저는 시스템 카타로그 뷰를 읽기 때문에, 프로시저를 실행하는 대리 사용자의 권한에 따라 필터링됩니다. 그렇지만 메타데이터 가시성의 한계가 아직까지는 모든 메타데이터 함수에 적용되지 않았기 때문에(OBJECTPROPERTY같은) 주의해야만 합니다.
대부분의 예전 시스템 테이블, 저장 프로시저, 및 뷰들은(모두 읽기 전용 뷰로 표시되는 것을 제외하고) 여전히 사용하는 가능합니다. 이것들은 이전 버전 호환을 위한 것이며 어떤 SQL Server 2005의 새로운 기능도 나타내지 않습니다.

사용자/스키마 분리
ANSI SQL-99 명세는 데이터베이스 스키마를 개체의 단일 네임스페이스로 구성하는 단일 대리 사용자가 소유한 데이터베이스 개체의 집합으로 정의 합니다. 스키마는 테이블, 뷰, 저장 프로시저, 함수, 타입, 트리거 같은 데이터베이스 개체를 포함하며 이것은 개체를 그룹화하는 간편한 방법이며 그래서 데이터베이스가 서로 다른 소유자 밑에서 개체 이름과 그룹 개체를 재사용할 수 있습니다.
SQL Server 2000에서는 그림 3의 제일 윗 부분에서 보는 것 같이 소요자와 스키마를 구별할 수 없었습니다. 만약 관리자가 데이터베이스 내에 Fred라는 이름의 사용자를 생성하면 Fred라는 이름의 스키마를 자동으로 생성하고 Fred 사용자 밑에 숨깁니다. Fred 사용자가 SQL Server에 로그인하고 Table1 테이블을 생성하면 테이블 이름은 Fred.Table1이 됩니다. Fred가 만드는 Fred.StoredProcedure와 Fred.View1같은 다른 개체에 대해서도 마찬가지 입니다. Fred가 데이터베이스의 소유자이면 Fred1 개체가 대신 생성되고 dbo 스키마의 일부가 됩니다.
그림 3 SQL Server내의 사용자와 스키마 -1){ thisSrc = this.src; ns = thisSrc.lastIndexOf('='); ne = thisSrc.length; orgImg = thisSrc.substr(ns + 1, ne); this.src = './dnImage/' + orgImg;}" src="http://tfile.nate.com/download.asp?FileID=4886329" localfile="yes" height="215" width="300">
그림 3 SQL Server내의 사용자와 스키마
Fred가 퇴사하고 George가 Fred의 일을 맡은 때 같은 개체의 소유권 변경이 필요할 때 문제가 발생합니다. 시스템 관리자는 Fred가 가지고 있는 모든 개체의 소유권을 변경해야만 합니다. Fred.Table1를 참조하는 T-SQL이나 클라이언트 응용프로그램 코드는 George가 테이블의 소유권을 획득한 후에 George.Table1로 변경되어야 합니다. Fred가 소유하고 있는 개체의 수와 얼마나 많은 응용프로그램이 내부에 이 이름을 포함하고 있는가에 따라서 이것은 복잡해질 수 있습니다.
SQL Server 2005는 이 문제를 해결하며 그림 3의 아래 부분에서 보는 것과 같이 사용자와 스키마를 분리함으로써 SQL-99스키마를 좀 더 엄격하게 구현합니다. 새로운 DDL 구문을 이용해서 Fred라는 이름의 사용자를 만들 때 SQL Server는 더 이상 자동으로 같은 이름의 스키마를 생성하지 않습니다. 대신에 명시적으로 스키마를 생성하고 소유권을 할당해야만 합니다. 모든 데이터베이스 개체가 MySchema 스키마 (처음에 Fred가 소유하는)에 포함되어 있기 때문에 스키마의 소유권을 George로 바꿈으로써 스키마의 모든 개체의 소유권을 바꾸는 것은 간단해 집니다. 각각의 사용자는 이 사용자에 할당되는 기본 스키마를 가지고 있어서 스키마 참조 없이 이름으로 참조되는 어떤 개체든 기본 스키마 내에 있다고 여겨집니다. 그래서 그림 3의 아래 부분에서 사용자 Fred가 기본 스키마로 MySchema를 가지고 있으면 테이블을 MySchema.Table1나 또는 간단히 Table1로 참조할 수 있습니다. George는 아마도 이름에 연관된 기본 스키마가 없어서 테이블을 참조 할 때 MySchema.Table1로 참조해야만 할 겁니다. 지정된 기본 스키마가 없는 사용자는 기본적으로 dbo를 갖습니다.
그림 4 는 이것이 어떻게 작동하는지를 보여줍니다. 코드는 Carol이라는 이름의 로그인을 만드는 것으로 시작하고 CREATE TABLE 권한을 가지는 Pub 데이터베이스의 Carol이라는 이름의 사용자를 생성합니다. 코드를 실행하는 보안 컨텍스트는 Carol로 바꿔고 Carol 테이블 생성을 시도 합니다. 이 시도는 “지정된 스키마 이름 ’dbo’가 존재하지 않거나 이것을 이용할 권한이 없습니다.”라는 에러와 함께 실패합니다. 이 경우의 문제점은 Carol이 dbo 스키마에 개체를 생성할 권한이 없다는 것입니다. 기본 스키마 지정이 되지 않았기 때문에 CREATE TABLE 구문은 dbo.table1생성을 시도합니다.
이 코드는 이 코드를 실행하고 CarolSchema을 생성하고 Carol에게 스키마의 소유권을 수여한 signed in 한 admin 사용자로 복귀합니다. 그리고 Carol의 보안 컨텍스트 내에서 다시 실행되고 다시 테이블 생성을 시도합니다. 이 시도는 같은 에러 메시지를 가지고 실패합니다. Carol이 그녀의 재량권에 스키마를 가지고 있기 때문인데 이것은 SQL Server가 기본적으로 이것을 사용할 것이라는 것을 의미하지 않습니다. 결과적으로 이용할 사용 권한을 가지고 있는 개체 이름과 스키마를 명시적으로 사용할 때 CarolSchema.table1을 성공적으로 생성할 수 있습니다. 두 번째 테이블 생성 시도의 실패는 CarolSchema 이 존재한 이후에, 아래 보는 바와 같이 사용자 Carol를 생성할 때나 사용자에 기본 설정을 추가함으로, Carol 기본 스키마를 설정해서 성공할 수 있습니다.
          CREATE USER Carol FOR LOGIN Carol WITH DEFAULT_SCHEMA = CarolSchema

          -- or

          ALTER USER Carol WITH DEFAULT_SCHEMA = CarolSchema
          

실행 컨텍스트
SQL Server는 데이터에 접근하는 코드를 실행하는 사용자가 적절한 권한을 가지고 있다는 것을 보증하는 강력히 지원되는 소유권 연결(chaining)을 가지고 있습니다. 코드를 호출하는 사용자가 실행 권한을 가지고 있고 그리고, 예를 들어, 코드의 소유자가 액세스한 두 개의 테이블과 뷰의 소유자이기만 하면, 더 이상의 권한이 검사되지 않고 호출자는 요청된 데이터를 받습니다. 만약 소유권 체인이 손상(예를 들면 코드의 소유자가 참조되는 뷰를 소유하고 있지 않은경우)되면 호출자의 보안 컨텍스트를 검사합니다.
만약 호출자가 뷰에 액세스하는 권한이 있다면, 데이터는 반환됩니다. 만약 호출자가 뷰에 액세스 하는 권한을 가지고 있지 않다면, 데이터는 반환되지 않을 것입니다. 이것이 SQL Server 200와 이전 버전이 작동하는 방법이었습니다. 데이터에 대한 액세스를 프로시저나 함수를 통해서 사용자에게 수여할 때 이런 방법은 좋습니다. 소유권 연결은 약간의 제한이 있습니다. 한가지는 데이터 조작 작업에만 적용되고 동적 SQL에는 아닙니다.
그러나 호출자의 권한을 데이터 액세스의 유효성 검사에 사용하는 것을 원하지는 않을 것입니다. 데이터를 보호하기 위해 주의 깊게 디자인된 프레임워크의 일부분으로써, 권한을 검사하기 위해서 다른 사용자의 보안 컨텍스트를 사용하는 저장 프로시저를 생성하고 싶다면 어떻게 할 것인가? 실행 컨텍스트의 개념을 소개하는 SQL Server 2005이전에는 어떤 쉬운 선택 사항들이 없었습니다. 이제 저장 프로서저, 데이터 조작 트리거, 및 사용자 정의 함수(인라인 테이블 값을 제외하고)를 정의 할 때, EXECUTE AS 절을 이용하여 SQL Server가 개체와 프로시저에 의해 참조되는 개체와 데이터에 대한 액세스의 유효성 검사를 위해 어떤 사용자의 권한을 사용할 것인가를 지정할 수 있습니다. 예를 들어 코드 생성자와 관련된 권한을 데이터에 액세스하는데 항상 사용하도록 지정할 수 있습니다. 다음은 지정된 사용자 권한을 가지고 코드를 실행하는 예제입니다. 이 경우에 실행 컨텍스트가 ec의 컨텍스트이기 때문에 사용자 ec는 반듯이 titles 테이블에 대한 SELECT 권한을 가지고 있어야 합니다:
          USE pubs

          

          CREATE LOGIN ec WITH PASSWORD = 'ecpassword'

          CREATE USER ec FOR LOGIN ec

          

          CREATE PROCEDURE GetTitlesEC(@Table varchar(40))

          WITH EXECUTE AS 'ec'

          AS

              EXECUTE('SELECT * FROM ' + quotename(@Table))

          GO
          
SQL Server 2005는 네 가지의 실행 컨텍스트 옵션을 제공합니다. EXECUTE AS CALLER는 코드 모듈의 호출자 컨텍스트내에서 실행되도록 지정합니다. 따라서 호출자는 모듈의 실행 권한뿐만 아니라 모든 내제하는 개체의 액세스 권한을 가지고 있어야 합니다. SQL Server는 끊어진 소유권 체인에 대해서만 권한을 검사합니다. 그래서 만약 코드의 소유자가 내제하는 개체도 소유하면, 모듈의 실행 권한만 검사됩니다. 이것은 이전 버전 호환성을 보장하기 위한 기본 실행 컨텍스트입니다.
EXECUTE AS 'user_name'는 지정된 사용자의 보안 컨텍스트내에서 코드가 실행되는 것을 지정합니다. 이것은 소유권 체인화에 의지하고 싶지 않고 대신에 코드를 실행할 필요한 권한을 가진 사용자를 생성하기를 원한다면 주목할 만한 옵션입니다.
EXECUTE AS SELF는 모듈이 모듈을 생성하고 대체하는 사용자의 보안 컨텍스트 아래 실행되는 것을 지정하기 위한 간단한 표기법입니다. SQL Server는 SELF가 아니라 모듈과 연관된 실제 사용자 이름을 저장합니다.
EXECUTE AS OWNER는 보안 컨텍스트가 모듈의 현재 소유자의 컨텍스트라는 것을 지정합니다. 만약 소유자가 지정되지 않으면 포함하는 스키마의 소유자의 컨텍스트가 사용됩니다. 소유자는 지정된 사용자(역할이 아닌)의 싱글턴(singleton) 계정이어야 합니다. 모듈 자제를 변경하지 않고 모듈의 소유자를 변경할 수 있기를 원할 때 주목할 만한 옵션입니다.
코드의 실행 컨텍스트를 변경하는 데는 약간의 제한이 있습니다. 모듈의 생성자는 반드시 특정한 사용자를 위한 IMPERSONATE 권한이 있어야 합니다. 여러분 자신을 가장하기 위해 이 권한을 가질 필요는 없습니다. 또한 특정 사용자를 더 이상 사용하지 않기 위해서 모든 모듈의 실행 컨텍스트를 변경하기 전까지 데이터베이스에서 이 사용자를 삭제할 수 없습니다. 소유권 연결은 모듈 내에서 동적 SQL 실행에는 적용하지 않습니다. SQL Server 2000고 마찬가지로 실행 컨텍스트는 동적 SQL에 의해 액세스된 내제하는 개체의 권한을 가지고 있어야 합니다.

암호화
귀중한 자원에 대한 최선의 보호는 보안을 겹겹이 하는 것 입니다 ? 철저한 방어로 알려진 원칙. 공격자는 상품에 도달하기 전에 계층을 연달아 통과해야 합니다. 해커는 빈번하게 네트워크 보안을 손상시켜왔고 그 다음엔 컴퓨터 보안을 그 다음엔 데이터베이스를 손상시켜서 귀중한 데이터에 자유로운 액세스를 획득해 왔습니다.
SQL Server에 암호화된 데이터는 방어의 마지막 선입니다. 비록 공격자가 데이터베이스 액세스를 성공적으로 획득했다 하더라고 데이터를 해독 해야만 합니다. 요즘의 강력한 암호화 알고리즘이라면 해독 키 없이는 공격자는 거의 넘을 수 없는 도전에 직면하게 됩니다. 물론 암호화는 결코 공짜가 아닙니다. 여러분은 아마도 상품 카탈로그 같은 공개적으로 접근가능한 데이터를 포함해서 SQL Server내에 저장되어 있는 모든 데이터를 암호화 하고 싶은 유혹에 빠져들 수도 있을 겁니다. 그러나 암호화는 프로세서 집중적이기 때문 성능상의 막대한 타격을 초래할 수 있습니다. 암호화나 해독에 요구되는 처리 주기 테이블의 하나의 짧은 문자열을 1000만행으로 증대시켜서 쉽게 서버를 굴복시킬 수 있습니다. 보호가 필요한 수준을 고려해서 필드를 보호하는 것이 비용을 지출을 초래할 만한 가치가 있는 때만 암호화를 사용하십시오.
SQL Server 2005는 다양한 키 형태과 암호화 알고리즘을 제공합니다. 대층 키에는 RC4, RC2, DES군, 그리고 AES군 알고리즘를 사용할 수 있습니다. 비대층 키로 RSA를 제공하고 증명서로는 인터넷 엔지니어링 테스크 포스팀의 X.509 V1 표준을 사용합니다.
암호화의 가장 어려운 부분은 키 관리(기밀사항을 비밀에 붙이는것)입니다. 만약 공격자가 데이터를 암호화하는데 사용한 대칭키를 획득하면 데이터에 액세스 할수 있고 거리낌없이 데이터를 변경할 수 있습니다. SQL Server 2005는 서버내의 별개의 범위에 다양한 형태의 키를 보호하기 위해 암호화 개체의 계층구조를 사용해서(그림 5에 서 보듯이) 여러분이 직접 키를 관리하거나 SQL Server가 여러분의 위해 키를 관리하도록 할 수 있습니다.
그림 5 SQL Server 2005의 암호화 계층구조 -1){ thisSrc = this.src; ns = thisSrc.lastIndexOf('='); ne = thisSrc.length; orgImg = thisSrc.substr(ns + 1, ne); this.src = './dnImage/' + orgImg;}" src="http://tfile.nate.com/download.asp?FileID=4886330" localfile="yes" height="212" width="300">
그림 5 SQL Server 2005의 암호화 계층구조
그림 5 의 제일 위는 SQL Server의 모든 키와 인증서의 부모인 서비스 마스터 키입니다. 서비스 마스터 키(서버의 모든 키를 직간접적으로 암호화 하는 대칭키)는 SQL Server를 설치할 때 자동으로 생성됩니다. 만약 이것이 손상되면, 공격자는 결과적으로 모든 데이터베이스내의 모든 키를 해독(crack)해 낼 수 있습니다. 이런 이유 때문에 이것은 윈도우 내의 Data Protection API(DPAPI)에 의해 보호됩니다. SQL Server가 운영중인 서비스 계정 이름을 이용해서 이것이 액세스할 수 있습니다.
비록 그림 6 에서 보이는 T-SQL문을 이용하여 키를 파일에 덤프하고, 키를 재생성, 파일에서 키를 복원하는 다소간의 관리 작업을 수행 할 수는 있지만 SQL Server가 여러분을 위해 서비스 마스터 키 관리를 책임집니다.
대부분의 경우 키에 어떤 변화도 원하지 않거나 필요하지 않지만, ALTER SERVICE MASTER KEY구문은 복구 옵션과 DPAI에서 키를 암호화하는데 사용하 서비스 계정을 변경하는 옵션을 가지고 있고 있습니다.
데이터베이스의 범위 내에서 데이터베이스 마스터 키는 모든 키와 인증서와 데이터베이스 데이터의 루트 암호화 개체입니다. 각각의 데이터베이스는 단일 마스터 키를 가질 수 있습니다: 만약 보조 키를 만들려고 시도한다면 에러가 발생할 것 입니다.
사용자가 제공하는 패스워드를 가지고 CREATE MASTER KEY T-SQL 사용하기 전에 CREATE MASTER KEY T-SQL를 통해 데이터베이스 마스터 키를 생성해야만 합니다:
          CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'WeZ#6hv*XHq#akAEaqcr7%CUP3aQ'
          
결과적으로 생성되는 키는 triple DES로 암호화되고 두 번 저장됩니다. 첫 번째로 저장되는 장소는 sys.symmetric_keys 데이터베이스 테이블에 저장되며 제공되는 패스워드에 의해 암호화되고, 두 번째로는 master 데이터베이스의 sys.databases 테이블에 저장되며 서비스 마스터 키를 이용하여 암호화됩니다. 이 복제 저장소는 마스터 키가 자동으로 열릴 수 있게합니다.
데이터베이스에서 현재의 마스터 키를 분리해 내서 다른 서버로 이동하는 것는 문제를 발생시킵니다. 왜냐하면 새로운 서버의 서비스 마스터 키가 서로 다르기 때문입니다. ALTER MASTER KEY는 이전 서버의 서비스 마스터 키에 의한 암호화를 해제하는 옵션을 가지고 있으며 이렇게 한 뒤에 새로운 서버에 추가합니다. 이렇게 하지 않으면 마스터 키를 사용하기 전에 항상 명시적으로 열어야만 합니다.
데이터베이스 마스터 키가 존재하면 필요한 암호화에 따라 세가지 형태의 키를 만드는데 사용할 수 있습니다.
  • 비대칭 키는 공개키 공개키와 개인키의 쌍을 가지는 공개키 암호화에 사용됩니다.
  • 대칭 키는 데이터를 암호화하고 해독할 때 같은 키를 사용하는 공유되는 비밀에 사용됩니다.
  • 인증서는 기본적으로 공개키에 대한 래퍼입니다.
그림 5는 이 키들과 인증서 다른 키나 데이터를 암호화 하는데 사용되는 방법을 보여줍니다. 비대칭 키는 대칭 키와 데이터를 암호화 할 수 있으며, 대칭 키는 다른 대칭 키와 데이터를 암호화 할 수 있으며, 인증서는 대칭 키와 데이터를 암호호 할 수 있습니다. 만약 여러분이 직접 키 관리를 다루고 싶다면 대칭 키는 사용자 지정 패스워드를 이용해서 생성될 수 있습니다. 물론 결국에는 이 모든 키는 데이터베이스 마스터 키를 이용해서 암호화 됩니다.
인증서는 문서, 이메일, 파일 서명에 관해 얘기할 때 전자 서명의 컨텍스트에서 사용되는 같은 종류의 개체입니다. 인증서 개체는 비대칭 암호화에 사용되는 공개키를 이것이 생성하는 방법에 대한 풍부한 옵션을 가지고 감쌉니다. 그러나 SQL Server모든 자세한 사항을 책임지기 때문에 다른 환경에서 인증서를 생성하기 위해 요구되는 단계를 숨깁니다.
SQL Server가 자체적인 사용을 위해서 인증서를 만들게 할 수 있으며 Microsoft 인증 서버나 VeriSign과 같은 다른 신뢰된 인증 기관이 발행한 인증서를 가져올게 할 수 있습니다. 옵션은 개인 키를 암호화하는데 사용하기 위한 패스워드 설정이나 SQL Server 데이터베이스 마스터 키를 사용하도록 하는 설정뿐만 아니라 생성일과 만료일을 설정을 포함합니다. 인증서를 파일부터 가져오거나 서명된 실행 파일이나 탑재된 .NET 어셈블리로부터 인증서를 읽을 수 있습니다. 다음의 코드는 두개의 인증서를 만드는데 User1과 연관된 만료되지 는 하나와 User2을 위한 2005년에 만료되는 다른 하나입니다:
          -- User1과 관련된 데이터베이스 마스터 키로 암호화된 인증서를 생성하십오  

          

          -- database master key. 데이터베이스 마스터 키는 이미 존재해야 합니다. 

          

          

          CREATE CERTIFICATE User1Certificate

              AUTHORIZATION User1 WITH subject = 'Certificate For User1'

          GO

          -- 제한된 User2를 위한 인증서를 생성하십시오 

          

          CREATE CERTIFICATE User2Certificate

              AUTHORIZATION User2 WITH subject = 'Certificate For User2',

              EXPIRY_DATE = '12/31/2005',

              ENCRYPTION_PASSWORD = 'q%dsabciJ&#QZk#wM5G!WB36z5m7'
          
인증서가 존재하면 암호화를 지원하는 새로운 T-SQL 함수 EncryptByCert를 이용하여 데이터를 암호화할 수 있습니다. 다음과 같은 Customer라는 이름의 테이블이 있다고 생각해 봅시다
          CREATE TABLE Customer (

              CustId int, 

              name nvarchar(30), 

              City varchar(20), 

              CreditCardType varbinary(300),

              CreditCardNumber varbinary(300), 

              Notes varbinary(4000))

          GO
          
암호화된 데이터는 바이너리라서 테이블은 이것을 담기 위해 varbinary 필드를 사용합니다. 암호화된 데이터는 디지털 인증을 포함하기 때문에 필드 길이는 간단한 문자열 “Visa”와 크레디트 카드 번호를 담지만 다소간 커야 합니다. 여기서는 이 테이블에 데이터 행을 삽입하는 방법을 보여줍니다.
          INSERT INTO Customer VALUES (1, 'Don Kiely', 'Fairbanks',

              EncryptByCert(Cert_ID('User1Certificate'), 'Visa'),

              EncryptByCert(Cert_ID('User1Certificate'), '1234-5678-8765-4321'),

              EncryptByCert(Cert_ID('User1Certificate'), 

                  'This customer is a real flake. Don''t trust him!'))
          
EncryptByCert는 Cert_ID 함수(여러분이 인증서에 명명함 이름을 이용하는)를 가지고 얻을 수 있는 인증서 ID와 암호화되는 데이터의 두개의 인수를 가집니다.
테이블에서 데이터를 select할 때 암호화한 데이터의 장점을 볼 수 있습니다. SQL Server Management Studio 에서 SELECT * FROM Customer를 실행하면 그림 7에 보이는 결과를 반환합니다. INSERT문은 Encrypt함수에 대해 다중 호출를 사용하기 때문에 각각의 필드가 다른 메소드를 이용하여 암호화될 수 있습니다. SELECT 문의 일부분으로 데이터를 해도하기 위해서는 아래에 보이는 DecryptByCert를 이용하십시오:
To decrypt the data as part of a SELECT statement, use DecryptByCert as shown here:
          SELECT CustID, Name, City,

              CONVERT(VARCHAR, 

                  DecryptByCert(Cert_ID('User1Certificate'),

                      CreditCardType)) AS CardType,

              CONVERT(VARCHAR, 

                  DecryptByCert(Cert_ID('User1Certificate'),

                      CreditCardNumber)) AS CardNumber,

              CONVERT(VARCHAR, 

                  DecryptByCert(Cert_ID('User1Certificate'),Notes)) AS Notes

          FROM Customer
          
DecryptByCert는 varbinary 데이터를 반환하기 때문에 일반적으로 다른 데이터 타입(여기서는 varchar)으로 변화해야 합니다. 이것은 그림 8에서 보는 바와 같이 일반 텍스트로 반환합니다.
그림 8 DecryptByCert을 이용한 SELECT -1){ thisSrc = this.src; ns = thisSrc.lastIndexOf('='); ne = thisSrc.length; orgImg = thisSrc.substr(ns + 1, ne); this.src = './dnImage/' + orgImg;}" src="http://tfile.nate.com/download.asp?FileID=4886331" localfile="yes" height="35" width="430">
그림 8 DecryptByCert을 이용한 SELECT
비대칭 키를 가지고 수행하는 암호화의 매우 일반적인 형식은 공개 키 암호화라 불립니다. SQL Server 2005내의 비대칭 키는 512, 1,024,또는 2,048 bit 크기의 키를 가지는 RSA 알고리즘을 사용합니다. 지정된 패스워드나 데이터베이스 마스터 키를 가지고 생성된 개인 키를 암호화할 수 있습니다. 또한 디스크 파일, 실행 파일, 메모리에 로드된 .NET 어셈블리에서 키를 가져올 수 있습니다. 다음 코드는 키를 생성하는 서로 다른 두 가지 방법을 보여줍니다. 첫 번째는 사용자에 의해 관리되는 시크릿(secret)를 이용하고 두 번째는 SQL Server에 의해 관리되는 데이터베이스 마스터 키를 이용합니다:
          -- 사용자 제공 패스워드에 의해 보호되는  

          

          -- 개인 키를 가지고 비대칭 키를 만드십시오.

          

          CREATE ASYMMETRIC KEY User1AsymmetricKey

              AUTHORIZATION User1

              WITH ALGORITHM = RSA_2048

              ENCRYPTION BY PASSWORD = 'AVeryVerySecretPassword'

          

          -- 데이터베이스 마스터키에 의해서 보호되는 다른 하나를 만드십시오 

          

          CREATE ASYMMETRIC KEY User2AsymmetricKey

              AUTHORIZATION User1

              WITH ALGORITHM = RSA_2048
          
데이터베이스에서 키가 사용하는 하면 데이터를 암호화 하기 위해서 EncryptByAsymKey 함수를 사용할 수 있습니다. EncryptByCert 함수와 비슷하게 첫 번째 인수는 AsymKey_ID 함수를 사용해서 얻을 수 있는 여러분이 사용하고자 하는 키의 ID입니다. 비록 그림 9 에서는 이런 접근 방법이 사용하지만 레코드의 모든 암호화되는 필드에 같은 키를 사용할 필요는 없습니다.
각각의 열의 데이터를 해독하기 위해서 데이터 암호화에 사용된 비대칭 키의 이름을 가지고 AsymKey_ID 함수를 한번 더 이용하여 DecryptByAsymKey 함수를 사용하십시오. 그림 10 에서는 User1AsymmetricKey가 패스워드를 가지고 생성됩니다. 따라서 DecryptByAsymKey 함수 호출의 세 번째 필드에 패스워드를 전달해야 합니다. varbinary 데이터를 사람이 읽을 수 있는 형태로 변환하기 위해서 CONVERT함수를 사용해야 합니다.( 그림 10참조)
데이터베이스 마스터 키를 가지고 생성되는 User2AsymmetricKey(그림 11참고)를 가지고 데이터를 암호화 하기 위해서는, SQL Server가 키를 관리하기 때문에 어떤 자격 증명도 전달할 필요가 없습니다. 바라건대 SQL Server가 여러분을 위해 키를 관리하도록 하는 것이 매운 쉽다는 것을 보기 바랍니다.
만약 SQL Server이 비대칭 키 쌍을 생성하면 다른 사람에게 전송하기 위한 공개키를 sys.asymmetric_keys 카타로그 뷰의 public_key 필드에서 구할 수 있습니다. 다음 코드는 생성하는 각각의 비대칭 키 쌍과 연관된 공개 키를 반환합니다:
          SELECT Name, Public_Key FROM sys.asymmetric_keys
          
인증서와 비대칭 키는 SQL Server데이터를 위한 고성능의 암호화를 제공합니다. 특히 데이터베이스 외부로 데이터를 옮기고 그 도중에 데이터를 보호해야 할 때 고성능의 암호화를 제공합니다. 그러나 서버에 있는 데이터를 보호해야하고 다른 위치에서도 걱정 없으려면 대칭 키는 좋은 선택입니다. 데이터는 안전하게 저장되어 있고 서버에서 해독되고, 클라이언트에 보내고 인증된 사용자에게 보여지는 것은 상당히 일반적인 데이터베이스 시나리오입니다. 대칭 키는 다른 형태의 암호화보다 프로세싱 싸이클이 덜 필요합니다. 이것은 데이터베이스 응용프로그램에 아주 적절하기 때문에 SQL Server내의 대층키 암호화는 아주 유연합니다.
대칭 키 생성은 인증서와 비대칭 키를 생성하는 것과 유사합니다. CREATE SYMMETRIC KEY 구문은 여러 옵션을 가지고 있습니다. 한 옵션은 데이터베이스에 저장될 때 키 자체가 암호화되는 방법입니다. 그 림 5을 참조하여 인증서, 비대칭 키, 사용자 지정 패스워드, 또는 다른 대칭 키를 사용하는 대칭 키를 보호할 수 있습니다. 그 외의 옵션은 사용된 압축 알고리즘, 키를 생성하기 위해 사용자가 제공한 패스워드를 이용할 것인가, 및 선택적인 ID 문구 을 포함한다. 이 구문은 암호화된 데이터에 임시 키를 태그(tag)로 다는데 사용되는 GUID를 생성합니다. SQL Server는 DES, triple DES, 및 AES을 비롯해서 가장 널리 사용되는 대부분의 대칭 키 알고리즘을 지원합니다.
대칭 키를 생성하고 이 키를 직접 관리할 것인지SQL Server가 관리할 것인가를 고려할 때 선택적인 패스워드를 어떻게 보호할 것인가에 대한 고려가 중요합니다. 키를 암호화 하기 위해 패스워드를 지정하면, 생성된 대칭 키를 가지고 데이트를 암호화하는데 사용하려고 선택한 알고리즘이 뭐던지 상관없이, triple DES가 패스워드로부터 키를 이끌어 내는데 사용됩니다. 키를 보호하는 패스워드를 보호하는데 사용된 것보다 더 강력한 암호화를 데이터를 위해 사용하는 것은 가능합니다.
그림 12 은 대칭 키를 생성하는 많은 옵션중 몇 가지를 보여 줍니다. 첫 번째 예제는 현재 있는 인증서에 의해 triple DES를 가지고 암호화한 키를 생성하고 User1 소유권을 결과 키에 부여합니다. 대칭 키와 다르게 인증서를 사용하기 위해서는 명시적으로 인증서를 열지 않아도 된다는 것에 주의하십시오. 두 번째 예제는 비슷한 대칭 키를 만듭니다. 그러나 인증서 대신, 사용자는 제공되는 패스워드를 사용하여 키를 관리하도록 선택했습니다. 세 번째 예제에서는 AUTHORIZATION 절을 생략해서 dbo가 키를 소유하고 RC4 알고리즘을 사용합니다. 이 예제는 새로운 대칭 키를 보호하기 위해서 현재 있는 비대칭 키를 사용합니다. 마지막 예제는 dbo가 키를 소유하는 또 다른 대칭 키를 생성합니다. 그러나 이것 자체는 다른 대칭 키에 의해서 보호됩니다. 새로운 키를 암호화 하기 위해서 현재 있는 대칭 키를 이용하기 전에 현재 있는 키를 명시적으로 열어야 합니다.
대칭 키를 가지고 암호화된 데이터를 삽입하고 select하는 것은 인증서와 비대칭 키를 이용하는 것과 이용하는 메소드와 비슷합니다만 예제 코드 다운로드(MSDN Magazine 웹 싸이트에서 다운 가능)좀더 복잡합니다. 코드는 특정한 키를 검색하기 위한 Key_GUID 함수와 함께 데이터를 전환하기 위해서 EncryptByKey 와 DecryptByKey 함수를 이용합니다. 데이터베이스 마스터 키에 의해 암호화된 키 같은 키를 생성할 수 없기 때문에 대칭 키를 사용하기 전에 반드시 명시적으로 이 대칭 키를 열어야 합니다. 예제에서는 GenericSymmetricKeySym 키를 생성하고 사용합니다. 이 키는 대칭 키User1SymmetricKeyCert에 의해 보호되기 때문에 사용하고자 하는 키를 보호하는 대칭 키를 먼저 열어야 합니다. 이것은 어느 때든지 데이터베이스에서 대칭 키를 다중으로 열 수 있다는 것을 설명합니다. SQL Server는 어떤 키가 데이터를 암호화하는데 사용되었는지를 알고 있습니다: DecryptByKey 함수 내에서 키를 지정하지 않아도 됩니다.
SQL Server 2005 암호화 구현의 흥미 있는 장점 한가지는 사용자가 그들의 데이터만 보도록 하는 방법을 제공한다는 것입니다. 이 기사의 여러 예제에서 보인 것처럼 AUTHORIZATION 절을 사용해서 키나 인증서의 소유권을 다른 사용자에게 데이터를 보기 위해서 권한을 수여할 수 있는 사용자에게 줄 수 있습니다.

결론
SQL Server 2005는 데이터베이스 엔진내의 보안을 위한 전례가 없는 수준의 지원을 했습니다. 이것은 안전한 서버에 있는 데이터를 액세스 할 수 있는 안전한 응용프로그램을 만드는데 사용할 풍부한 기능 집합을 개발자에게 제공합니다. 높은 입자성 권한은 최소 권한의 보안 원칙을 실천하도록 하고 사용자에게 일을 수행하는데 필요한 권한만을 부여 하고 자만하는 권한의 이점을 이용하는 공격을 막습니다. SQL Server 2005의 이런 보안 기능 향상은 여러분의 데이터에 대한 오늘날의 세련된 공격을 극복해 내는데 필요한 모든 도구를 제공합니다.

Don Kiely, MVP, MCSD, 는 책임 기술 컨설턴트이며 보안, 특히 분산 Windows Forms과 ASP.NET 응용프로그램의 개발 내에서의 보안에, 에 중점을 두고 있는 개발자입니다. 그는 또한 기술에 관한 저술, 컨퍼런스 발표, 강연을 합니다. Don에게 연락하려면 donkiely@computer.org.

2012-09-14

Linux] iptables 사용법 - 출처 http://www.gentoo.or.kr/wiki/moin.cgi/iptables

목차
  1. 응용프로그램이름
    1. 소개
    2. 관련 홈페이지
  2. 설치
    1. Emerge
    2. USE 플래그
  3. 사용법/팁
  4. 설정
    1. 부팅할 때 자동으로 시작되도록 하기
    2. 설정한 내용 저장하기
    3. 저장한 내용 불러오기
    4. 설정한 내용 다음 부팅할 때도 적용되도록 하기
  5. 설정예제
  6. 동작 확인
  7. 질문과 답변
  8. 잡담

1 응용프로그램이름

1.1 소개

2.4 커널부터 포함된 방화벽 설정 유틸리티

1.2 관련 홈페이지

2 설치

2.1 Emerge

          # emerge net-firewall/iptables 
          
커널을 컴파일할 때 iptable 관련 기능을 설정해야 합니다.
Device Driver --> Networking Support --> Networking Support --> Networking Options --> Network packet filtering

2.2 USE 플래그

  • ipv6 : ipv6 를 지원

3 사용법/팁

기본적인 사용법은 아래 내용을 참고하세요.

4 설정

4.1 부팅할 때 자동으로 시작되도록 하기

rc-update add iptables default

4.2 설정한 내용 저장하기

iptables-save 명령을 사용하면 현재 설정된 내용을 표준출력으로 내보냅니다. 이걸 파일에 리다이렉트하면 저장할 수 있습니다.

4.3 저장한 내용 불러오기

iptables-save 로 저장한 파일로 iptables-restore 명령을 실행하면 저장했던 내용이 적용됩니다.

4.4 설정한 내용 다음 부팅할 때도 적용되도록 하기

자신에게 맞게 설정한 다음 /etc/init.d/iptables save 를 실행하면 됩니다.

5 설정예제

이건 위 링크에 있는 내용을 참고로 해서 제가 대충 만들어 본 것입니다.
             iptables -N block 

             iptables -A INPUT -j block 

             iptables -A FORWARD -j block 

             iptables -A block -m state --state RELATED,ESTABLISHED -j ACCEPT 

             iptables -A block -s localhost -d localhost -j ACCEPT 

             iptables -A block -j DROP 

             
          
iptables -A block -m state --state NEW -i ! ppp0 -j ACCEPT
저는 ppp를 쓰지 않으므로 제외하였습니다.
iptables -A block -s localhost -d localhost -j ACCEPT
내부적으로 오가는 패킷은 accept 합니다. 이걸 해주지 않으면 mplayer에서 동영상 재생이 안되더군요.
참고로 저는 p2p 나 메신저 등은 쓰지 않고 웹서핑만 합니다. 일단 현재로서는 아무문제가 없네요.

6 동작 확인

자신의 컴퓨터에 열린 포트를 검사해볼 수 있는 곳입니다. http://scan.sygate.com/ "block"이라고 나오는 것이 좋습니다.

7 질문과 답변

  • 질문과 답을 여기서하고 정리된 문답은 사용법/팁 등 관련된 항목으로 옮겨준다.

8 잡담

사실 저도 초보입니다. 제가 잘 모르는 부분도 있고 틀린 부분도 있을 수 있습니다. 잘아시는 분 계시면 계속 내용추가해 주세요.

Linux] 방화벽 설정 관련 내용...

http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-sg-ko-4/ch-fw.html

2012-09-12

FreeBSD]보안확인및 대처방법



퍼온글입니다.
  Posted: 2002-03-24 00:25



시스템을 관리하다 보면 많은 위험으로부터 공격을 받습니다.
이중에서 제일 관리자를 기분 나쁘게 하는 것이 바로 크래킹이죠.
지금 부터 서버에 백도어를 숨겨놓았나 확인하는 방법과 보안에 결함이 있나 확인하는 방법을 설명하겠습니다.

글은 모두 확인을해야 함으로 일정한 순서없이 진행하겠습니다.
물론 프비도 같은 방법으로 체크를합니다.


1. # grep -v "^#" /etc/inetd.conf --> 레드햇 7.1이전 버젼이 대부분이다.
하여 필요없는 서비스를 #로 주석처리하고 # killall -HUP inetd하여 데몬을 다시 실행한다.



2. #chattr +i /etc/inetd.conf

이것은 super-user만이 이 파일에대해 접근할 수 있도록 inetd.conf파일을 셋팅하는 것입니다. 셋팅이되면 수정,삭제 또는 리네임을 할 수 없습니다. 셋팅은 오직 super-suer만이 가능합니다.

이것을 풀기위하여는 -i 옵션을 주면 원상태로 됩니다.



3. 얼마나 많은 서비스들이 실행되는지 확인합니다.

#ps aux | wc -l

이것으로 서비스들을 확인하여 기록합니다.
이것을 다음에 예전 기록과 비교하여 이상한 서비스를 검출하기 위함입니다.



4. 스크립트 변경 후 확인

#netstat -na --ip



5. TCP Wrapper 사용

이것은 암호화는 지원하지 않지만 로그와 서버로의 접근을 제한 합니다.
이것은 telnet 또는 ftp와 같은 inetd서비스를 둘러싸는 실행화일입니다.

시스템 이름이나 도메인 이름을 사용하지말고 IP주소를 사용합니다.

/etc/hosts.deny 을 deny ALL로 설정한 후 접속을 허용할 주소만 /etc/hosts.allow파일에 기록합니다.

우선 순위는 allow가 먼저 입니다.


다음은 사용 예입니다.

  /etc/hosts.allow
    in.ftpd:192.168.0.1:ALLOW -->192.168.0.1으로 부터의 FTP만 허용
  /etc/hosts.deny
    ALL:ALL DENY -->모든 접근 불허


구성 후 #tcpdchk를 실행합니다.



6. 관리자의 history를 없앤다.
.bash_history에서  HISTFILESIZE=0으로한다.
그래도 HISTSIZE환경변수에 저장이됨으로 확인이 가능하다.



7. /etc/lilo.conf파일에 password=123 와 같이 암호부분을 넣어준다.
설정을한다음에 lilo -v한다.
그럼 재시동시 lilo에서 암호를 물어본다.



8. ipchains 나 iptables를 사용한다.
이것을 설정은 맨페이지나 관련 홈피를 참조하라..



9. /var/log및의 파일을 점검한다.

  acct 또는 pacct --> 사용자별로 실행되는 모든 명령어를 기록
  actlog --> 다이얼 -아웃 모뎀 관련 기록(자동 호출 장치)
  lastlog --> 각 사용자의 가장 최근 로그인 시간을 기록
  loginlog --> 실패한 로그인 시도를 기록
  messages --> 부트 메세지 등 시스템의 콘솔에서 출력된 결과를 기록하고
  syslog에 의하여 생성된 메시지도 기록
  sulog --> su 명령 사용 내역 기록
  utmp --> 현재 로그인한 각 사용자 기록
  utmpx --> utmp 기능을 확장, 원격 호스트 관련 정보 등 자료구조 확장
  wtmp --> 사용자의 로그인, 로그아웃 시간과 시스템의 종료 시간, 시스템 시작 시간 등을 기록
  wtmpx --> wtmp기능 확장
  vold.log --> 플로피 디스크나 cd - drom과 같은 외부 매체의 사용에서 발생하는 에러를 기록
  xferlog --> ftp 접근을 기록
  secure -->보안에 관련된 로그


위의 파일들을 확인하여 이상한 접근이나 사용자가 있는가를 점검한다.
이것은 시스템에 문제가 있을적에 제일 먼저 확인을 해야하는 로그들이다.



10. # w 명령으로 현재 로그인한 사용자를 확인한다.
이상한 유저가 로그인시 접속을 끊거나 활동상황을 감시한다.



11. # last 명령으로 기존 로그인한 사용자를 확인한다.
수상한 사용자가 있음 의심을 하자


특정한 ip를 제외하고 검색을 할려면
# last | grep -v 192.168.0.1 | grep -v www.linuxfreebsd.com

이것은 내부 ip가 192.168.0.1 이고 도메인이 www.linuxfreebsd.com  이란 말이다.
이런식으로 검출을 하면 많은부분을 쉽게 찾을수 있다.



12. secure를 확인하여 사용자 인증 관련 로그등을 확인한다.



13. access_log, error_log
파일에도 어느 사이트에서 어느 파일에 접근을 했는지를 확인한다.



14. 가장 상위 / 디렉토리에 .profile .history 파일들이 있나 확인을한다.
이런것들이 있으면 침입을 당한것이다.

# ls -al 으로 확인한다.



15. crontab -l 로 cron에 관리자가 이외의 사용자가 설정한 파일이있나 확인한다.



16. # find / -ctime -ndays -ls 로 ndays 이전 시점부터 현재까지 ctime 이 변경된

모든 파일을 찾아준다. 하지만 이는 파일의 접근시간(atime)을 변경시킨다.

따라서 침입자가 어떠한 파일에 접근했는지 알고 싶은 경우에는 사용하지 말자.



17.
nmap -sT -p 1-65535 www.linuxfreebsd.com
nmap -sU -p 1-65535 www.linuxfreebsd.com

이것으로 어떤 포트가 열려있는지를 확인한다.
nmap프로그램은 www.nmap.org에서 다운받아 설치한다.



18.
# find / -type -f -perm -04000 -ls --> SUID 파일을 찾기
# find / -type -f -perm -02000 -ls --> SGID 파일을 찾기



19.
# rpm -V -a --> 모든 설치된 패키지의 변화에 대하여 검사
# rpm -V 패키지 이름 --> 특정 패키지에 대해서만 변화여부 검사
# rpm -V fileutils --> 트로이잔 ls 프로그램을 확인한다.

예) S.5....T /bin/ls

S - 프로그램의 사이즈가 변경
5 - md5 cheksum 값이 변경
T - 파일의 mtime 값이 변경



20.
ps - sniffer 또는 취약점 스캔 프로그램등 공격 프로그램이 실행되고 있는지 살펴본다.
주로 평소에 보지 못했던 프로세스를 확인한다.
lsof - 시스템상의 모든 프로세스가 이용하는 열려진 파일 정보를 보여준다. 이는 ps 명령을 이용한 정보를 대체할 수 있다.
netstat - 서비스하지 않는 포트가 열려 있는지 또는 이상한 사이트에서 접속이 있는지 확인한다.
who - 누가 접속해 있는지 확인한다.



21.
/etc/passwd 파일에서 이상한 사용자를 검사한다.



22.
# find / -name "..*" -print 또는
# find / -name ".*" -print

이것으로 숨겨진 디렉토리를 찾아낸다.

# find /dev -type f -print

이것을 이용하여 /dev및에의 루트킷, 백도어 설정 파일을 찾아낸다.



23.
사용자 홈디렉토리의 ".rhosts", ".forward" 파일 내용을 점검한다.





무엇보다 중요한것은 초기 O/S인스톨이 끝난다음에나 설정이 완료된시점에서 모든 디렉토리를 백업하는것이다.
그래서 침입이 확인되었을적에 기존 파일을 지우고 백업파일을 올리는것이다.



이상으로 보안확인 및 대처 방법을 끝낸다.
리눅스 뿐만 아니라 프비도 위와 거의 같은 체크를한다.
그럼 본인의 시스템을 한번 확인해보자.

FreeBSD ]보안- A basic guide to securing FreeBSD 4.x-STABLE



장창균 님께서 남기신 글 (2002-03-12 02:31:11, Hit : 2377)

[번역] A basic guide to securing FreeBSD 4.x-STABLE


+===================================================================+
+           A basic guide to securing FreeBSD 4.x-STABLE            +
+-------------------------------------------------------------------+
+                                                                   +
+              Written by Marc Silver            +
+                   http://draenor.org/securebsd/                    +
+                                                                   +
+                                                                   +
+===================================================================+


Marc Silver <marcs@draenor.org> 저.

http://draenor.org/securebsd

2002년 02월 04일


장창균<ckchang@seoul.com> 역.

2002년 03월 12일


주의 : 저자와의 약속으로 인해 본 문서의 수정을 허용하지 않습니다.

$Id: secure,v 1.10 2002/02/04 11:30:01 marcs Exp $;

Table of Contents:

  ==> Overview
  ==> The Foundation for a secure system
      -> File System Layout

  ==> Post Installation
      -> System Secure Levels
      -> Removal of the toor user
      -> Shut down services that you dont need/want
         -> syslogd
         -> portmap
         -> telnetd
         -> sshd
         -> inetd
         -> ftpd
      -> Log in vain
      -> Blackhole
      -> Crontabs
      -> Secure the console
      -> Process accounting
      -> ipfw
      -> Mail aliases

  ==> Kernel changes
      -> Disable bpf if you dont need it
      -> Disable Ctrl-Alt-Del
      -> Quota Support
      -> ipfw/ipf support

  ==> Managing user accounts
      -> User quotas
      -> Home directory permissions
      -> Hiding processes
      -> Disabling procfs
      -> login.conf(5)

  ==> Stay up to date
      -> Keep your packages current
      -> Keep your OS current

  ==> Be Vigilant

  ==> Topics of Interest
      -> Jail

  ==> Other documents about FreeBSD Security

  ==> Thanks

Overview
========


보안이란 단어는 사람마다 다르게 받아들인다. 이 문서는 여러가지 상황을 설명하며 기본으로 설치된 FreeBSD의 보안을 강화할 수 있는 것들을 제안하지만, FreeBSD 보안을 강화하는 공식적인 가이드는 아니다. 단지 내 자신의 시스템에서 사용되고 대단히 성공적으로 수행되었던 모델에 관해서만 논의하는 것이다. 또한 내가 보안 ‘전문가’라고 말하는 것이 아님을 밝히고 싶다. 나는 단지 지나치게 조심스럽고 서버의 보안에 굉장한 자부심을 갖는 시스템 어드민일 뿐이다.

FreeBSD의 보안을 더 넓게 전망하기 위함과 아울러, 본론으로 들어가기 전에 FreeBSD 시스템에서 security(7)의 man page를 모든 이들이 읽어 볼것을 제안한다.  

본 문서 작업은 아직 진행중이다. 그러기 때문에 이 문서는 수정되고 증본되며 발전될 것이다. 더 추가 또는 수정할 사항이 있거나, 주석을 필요한 부분이나 문제가 되는 사항이 있다면, 메일을 보내주기 바란다
(marcs@draenor.org). 이 문서의 공식 홈페이지는 http://draenor.org/securebsd 이다.

또한 이 문서를 통해서 원격이나 로컬 DoS 공격을 막을 수 있음을 뜻하는 것은 아니다. 단지 기본으로 기본으로 설치된 FreeBSD 보안을 강화하는 데 도움을 주고자할 뿐이다. FreeBSD 보안에 관한 고급수준의 문서 또한 아니다. 단순히 자신의 머신을 안전하게 지키는데 사용할 수 있는 기본적인 아이디어를 설명한다.

이점을 인지하고 시작하기로 하자.

보안 시스템에 관한 기초
The Foundation for a secure system
==================================

시스템은 아주 초기부터 안전하게 설정되어야 한다. FreeBSD를 설치하는 동안 설치 이후의 골칫거리에서 피할 수 있도록 수행할 여러가지 것들이 있다. 내 생각으로는, 공격자가 시스템에 로컬 로그인을 이미 가지고 있다고 생각되는 곳에서는 파일 시스템 설정이 크게 다를 수 있다.

o  파일 시스템 레이아웃
o  File System Layout

아래의 파일 시스템 레이아웃은 어느 시스템에서든 가이드 라인으로 사용될 수 있다. 명백한 것은 디스크 레이아웃은 머신의 기능에 따라 달라질 수 있지만 이는 기본 가이드로 도움이 된다.

자신의 필요에 따라 적합하게 적용할 수 있다.

   Filesystem  1K-blocks     Used    Avail Capacity  Mounted on
   /dev/ad0s1a    128990    31390    87282    26%    /
   /dev/ad0s1f     49583    27879    17738    61%    /tmp
   /dev/ad0s1d  12348393  2563101  8797421    23%    /usr
   /dev/ad0s1h   4065262    97983  3642059     3%    /home
   /dev/ad0s1g   2032623     6026  1863988     0%    /var
   procfs              4        4        0   100%    /proc



이제, mount(8) 명령의 출력을 보자:


   /dev/ad0s1a on / (ufs, local)
   /dev/ad0s1f on /tmp (ufs, local, nodev, nosuid, soft-updates)
   /dev/ad0s1d on /usr (ufs, local, soft-updates)
   /dev/ad0s1h on /home (ufs, local, nosuid, with quotas, soft-updates)
   /dev/ad0s1g on /var (ufs, local, soft-updates)
   procfs on /proc (procfs, local)


이제, 왜 이렇게 설정했는지를 논의해보자.

루트 파티션은 128MB로 적합하다(tuning(7) man page에서 추천한 대로이다) 그리고 KLD 그리고 상당히 중요한 여러 디렉터리뿐 아니라 커널이 저장되어 있는 곳이다. (/sbin이 유일하게 머리에 떠오르는 것이다). 이를 염두에 두고, 나중에 fstab(5) 파일을 수정하여 루트 파티션을 읽기전용으로 마운트가 가능하다.

임시 파일들은 /tmp에 저장된다. 그리고 이 디렉토리는 일반적으로 누구나가 기록할 수 있기때문에, 이 디렉토리에서 특정 파일이 사용되지 않도록하는 것이 중요하다. Fstab(5) 파일을 사용하여 (또한 mount(8)을 참고하라) /tmp에 NOSUID와 NODEV 플래그를 추가해주어 suid 프로그램을 사용할 수 없도록하고 캐릭터나 블록 특수 장치를 이 파일 시스템에서 정지하도록 해야한다. /tmp에 NOEXEC 플래그를 추가하기를 원할지도 모르지만 이는 여러가지로 제한적이며 일반 사용자에게 어려움을 가져다 줄지 모른다. NOEXEC는 ‘make install world’의 작업을 할 때 문제를 발생할 수 있다. NOEXEC는 또한 침입자를 찾아내는 기량을 제한할 수 있다. /usr/tmp와 /var/tmp를 /tmp 파티션에 심볼릭 링크를 걸어두어야 함을 인지하는 것이 중요하다. 그렇지 않으면 사용자에게 tmp 디렉토리를 아무런 제약없이 제공해야 한다.

사용자 디렉토리는 /home에 위치하며 이 파티션에 NOSUID 플래그를 추가하는 것은 좋은 아이디어 있다.

또한 QUOTA를 추가하여 사용자가 사용할 디스크 공간을 제한하라. /usr와 /var 모두 soft-updates를 사용할 수 있는 표준 파티션이다.

또한 procfs를 사용하지 않도록 선택할 수 있다. 자세한 사항은 ‘Disabling procfs.’
이 모델은 본인의 필요에 맞게 변경할 수 있다.

설치후 작업
Post Installation
=================

일단 FreeBSD 시스템을 설치한 후에 머신을 안정화하는데 도움이 될 여러가지가 있다.

시스템 보안 레벨
o  System Secure Levels

보안 레벨은 FreeBSD 보안의 핵심이다. FreeBSD 보안에서 매우 강력하고 기본적인 것이다.

대부분의 머신에서, X-Window를 실행하려하지 않는다면 보안 레벨 -1로 운영할 이유가 없다. X-Window를 실행하지 않는다면, sysctl(8) 변수 kern.securelevel을 수정하여 보안 레벨을 1로 변경할 것을 추천한다.

보안 레벨 1로 변경하되면 싱글 유저 모드가 아니고는 커널을 변경할 수 없고 KLD도 load/unload될 수 없으며 /dev/mem과 /dev/kmem은 쓰기모드로 오픈될 수 없다. 시스템을 재부팅하지 않기 위해서는 다음과 같이 명령을 실행한다.  

   sysctl kern.securelevel=1

이 변경을 지속하고자 한다면 다음을 /etc/rc.conf에 추가하라.

   kern_securelevel_enable="YES"
   kern_securelevel="1"

보다 중요한 머신에서는 보안 레벨을 2나 3로 올리고자할 것이다. 이 문서에서는 이들 상위 보안 레벨을 논의하지 않을 것이다. 여러 보안 레벨에 관한 자세한 정보와 작업사항은 init(8)의 man page 를 읽기 바란다.


Toor 유저의 삭제

o  Removal of the toor user

기본적으로, FreeBSD는 UID가 0인 부수적인 사용자계정이 함께 존재한다. 이 계정은 toor(root의 반대방향)이며, 백업 유저의 용도라서, 루트의 셀이 동작하지 않으면 이 유저로 로그인하여 문제를 해결할 수 있다. 이 계정은 기본으로 사용불가로 되어 있기때문에 패스워드를 변경하지 않는다면 사용할 수 없다.

이 계정에 패스워드를 설정하거나 삭제할 수 있다. 필자는 삭제하는 것을 선호하지만 선택은 전적으로 자신에게 달려있다.

Rmuser(8) 명령은 UID가 0인 계정의 삭제를 허용하지 않으니 주의하며, 이 계정을 삭제하기 위해 vipw(8)을 사용해야 할 것이다.

필요치 않거나 원치 않은 서비스들을 종료하라.

머신에서 필수적이지 않거나 모르는 서비스들은 실행하지 않도록 한다. 이를 수행하는 가장 좋은 방법은 머신에서 실행되는 모든 서비스들을 종료한 후에, 실행하고자 하는 것들만 사용하도록 한다. 이 방법으로 자신의 머신에서 실행되는 서비스들을 확실히 알 수 있다. Netstat(1) 명령으로 자신의 머신에서 오픈되어 있는 TCP 포트들을 알 수 있다. 즉:

   secure-me (1) :  netstat -na | grep LIST
   tcp4       0      0  *.80                   *.* LISTEN
   tcp4       0      0  *.25                   *.* LISTEN
   tcp4       0      0  *.22                   *.* LISTEN


위의 예는 TCP 포트 22(ssh), 25(smtp), 80(http)가 머신에서 대기상태이며 모든 IP에 반응할 것임을 나타낸다. 대기상태의 프로세스가 있으며 어떤 프로세스가 포트를 오픈하고 있는지 불확실하다면 sockstat(1)를 사용하여 오픈되어 있는 소켓를 나열하고 관련된 정보를 제공할 것이다.

Rc.conf(5)를 사용하여 기본적으로 사용할 서비스를 쉽게 설정할 수 있을뿐 아니라, /usr/local/etc/rc.d 디렉토리에서 볼 수 있는 로컬 패키지 init 스크립트도 마찬가지다.

비슷하게 UDP를 통해 대기상태에 있는 것들에 관해서도 볼 수 있다. Netstat(1)를 통해 이들 정보를 얻을 수 있다.


   secure-me (2) :  netstat -na | grep -i udp
   udp4       0      0  *.514                  *.*



위에서 syslogd가 514(UDP) 포트에서 대기상태에 있음을 알 수 있다.

이제 몇개의 공통적인 서비스들과 이들 서비스를 보다 안전하게 할 수 있는 것들에 관해 논의해보겠다.

   - syslogd ::

     syslogd는 UDP 514를 사용하지만, syslogd을 명령행으로 시동시킬 때 ‘-s’플래그를 사용하여 사용하지 않을 수 있다. 이는 네트워크 소켓을 사용하지 않게하며 간단히 /etc/rc.conf에 다음을 추가하면된다.

     syslogd_flags="-ss"
 

syslogd(8)를 참고하라.

     See the syslogd(8) man page for more information.

   - portmap ::

portmap은 원격 프로시져 호출에 사용되며 FreeBSD에서의 대부분의 일반 프로그램은 NFS와 함께 사용한다.

Portmap을 disable상태로 만들기 위해서는 /etc/rc.conf에 다음을 추가한다.



     portmap_enable="NO"

   - telnetd ::

이 서비스는 어떻게 해서든 사용을 피하라. telnet이 유용하기는 하지만, 더이상 사용할 이유가 없다.

telnet 세션을 통해 전송되는 모든 데이타는 일반 텍스트이다. (사용자명, 비밀번호도 포함한다)

inetd(8)을 완전히 종료하거나 /etc/inetd.conf에서 telnetd행을 제거하여 이 서비스를 제거할 수 있다.

본 서비스를 실행해야만 한다면 login.access(5)나 ipfw(8) 등의 사용법을 주지하여 접속을 제한할 수 있다.

FreeBSD는 sshd(8)를 포함한다. 이 대몬은 더 강력한 보안성을 갖는 telnetd의 대안이다.


   - sshd ::

FreeBSD 4.1.1부터 OpenSSH를 기본 시스템으로 포함하며 sshd(8)는 이제 telnetd의 확실한 대안이다.

하지만 암호화를 사용하므로서 접속 세션을 보호하여 더 안전하게 할 수 있다. RSA/DSA 키를 사용하여 더 견고한 암호화가 가능한 프로토콜이다.

대부분의 OpenSSH의 현재 버전들은 SSH 프로토콜 버전 2를 사용하지만 좀 오래된 버전을 사용하는 시스템에서는 버전 2만을 허용하도록 권한다. 이를 위해, /etc/ssh/sshd_config에 다음 문자열이 있는지 확인한다.



     Protocol 2



이는 sshd가 서버로의 SSH2 접속만을 허용한다는 것을 알려준다. 변경사항을 적용하기 위해 sshd를 재시작해야한다.

비슷하게, 서버로부터의 모든 SSH 접속을 기본으로 SSH2를 사용하도록 설정할 수 있다. 이는 /etc/ssh/ssh_config를 수정하여 할 수 있다.

보안을 더 향상시킬 수 있는 곳에서 DSA 키의 사용은 바람직하다. 이 문서는 DSA 키의 사용에 관해 설명하지 않을 것이다. 관련 정보는 http://www.openssh.com/에서 볼 수 있다.

OpenSSH, RSA/DSA 키와 이들 사용법에 관한 자세한 사항은 http://www.openssh.com/을 방문해보라.



   - inetd ::

inetd는 임의의 수개의 소켓에서 접속을 대기하도록 설계되었다. Telnetd(8), qpopper그리고 ftpd(8)와 같은 대중적인 응용프로그램들이 사용한다. 최소한, 필요하지 않거나 실행하려하지 않는 서비스들은 주석처리해야 한다(원치않는 행 앞에 #을 추가하여). Inetd 가 실행하는 대몬이 더이상 필요치 않다면, /etc/rc.conf에 다음을 추가하여 완전히 사용정지할 수 있다.



     inetd_enable="NO"



inetd를 사용한다면, 인바운딩 접속을 제한하기 위해 /etc/hosts.allow 파일을 살펴보라.



     ftpd ::

FreeBSD는 기본적으로 ftpd를 포함한다. FTP는 사용자 이름과 패스워드가 일반 텍스트로 전송되기 때문에 안전하지 않은 프로토콜이다. FTP의 대안으로 sftp(1)가 있으며 이 대몬은 모든 FTP의 이점과 함께 SSH의 암호화 기능도 제공한다. 또는 scp(1)를 사용할 수 있다.

그러나, ftpd를 서비스하기로 결정했다면 서버를 견고히 할 수 있는 몇가지 것들이 있다. 기본적으로 ftpd는 “-l”플래그와 같이 실행하며 이는 서버에 사용자가 실행하는 명령에 관한 더 많은 정보를 제공한다. “-r”플래그를 추가하여, ftpd를 읽기전용 모드로 설정할 수 있으며 이는 파일시스템을 변경하는 모든 명령들을 사용할 수 없게 할것이다. 또한 나는 익명 로그인만 허용하기 위해 “-A”플래그를 추가한다.

Ftpd 행은 /etc/inetd.conf에서 다음과 같이 보일것이다.


     ftp  stream  tcp  nowait  root  /usr/libexec/ftpd   ftpd -l -l -r -A

LOG_FTP 메시지는 기본적으로 syslogd(8)이 기록하지 않으며 enable해야함을 주의하라. 더 자세한 사항은 ftpd(8) man page를 참조하라. 명백한 이유때문에 사용자 로그인을 허용하도록 추전하지 않는다. 사용자 로그인을 필요하다면 ncftpd의 사용을 추천한다. 이 프로그램으로 별도의 사용자/패스워드 데이타베이스를 사용할 수 있으며 시스템의 사용자명과 독립적이며 다른 패스워드를 가질 수 있다.


o  Log in vain

많은 서비스들을 사용하지 않게 되었을 지라도 listeners/daemons이 없는 포트로의 접속시도를 기록해야 한다. 이를 위해 간단히 /etc/rc.conf에 다음을 추가한다.



   log_in_vain="YES"



서버를 재부팅하지 않고 변경하기 위해서는 아래와 같이 명령을 실행한다.



   sysctl net.inet.tcp.log_in_vain=1
   sysctl net.inet.udp.log_in_vain=1



listeners가 없는 포트로의 접속 시도 실패는 /var/log/messages에 기록될 것이다.
:

블랙홀



FreeBSD에는 대몬이나 listeners에 묶이지 않은 포트로의 모든 TCP/UDP 정보를 그러 모으는 옵션이 있다.

‘log in vain’과 같이 접속을 기록하는 대신, 블랙홀을 생성하여 패킷들이 블랙홀을 통해 묵살된다. 이 기능과 관련된 man page 또한 시스템을 목표로 한 DoS 공격을 지연시킬 수 있다고 서술한다. 블랙홀 MIB는 다음 명령으로 쉽게 enable할 수 있다.


   sysctl net.inet.tcp.blackhole=1
   sysctl net.inet.udp.blackhole=1

 

한가지 주의할 점은 UDP에서 블랙홀을 사용하게 되면 타 시스템에서 블랙홀이 enable된 시스템으로 traceroute(8)를 사용할 수 없게된다. TCP 값 역시 2로 증가된다. 자세한 정보는 blackhole(4) man page를 참고하라.

재부팅 후에도 계속 설정을 유지하기 위해서는 아래 설정을 /etc/sysctl.conf에 추가하라.


   net.inet.tcp.blackhole=1
   net.inet.udp.blackhole=1


이것은 ipfw/ipf의 대안이 아님을 주의하라.

주의 : James Lawrence에 따르면, 이것은 Konqueror에 문제가 있을 수 있다.


o  Crontabs

먼저, 일반적으로 사용자가 열람하지 않으면 하는 파일들이 있다. Root의 crontab이 바로 그러하다.

/etc/crontab을 0640으로 파일 모드를 안전하게 변경할 수 있으며 root와 wheel 그룹의 사용자만이 열람할 수 있다. 사용자가 어떤 작업이 cron으로 동작되는지 알 필요는 없다.

동시에, crontab(1)을 사용자가 사용하지 않기를 원할 수 있다. 간단히 /var/cron/deny 파일을 생성하고 파일에 사용자 리스트를 추가하여 원하는 것을 얻을 수 있다. 리스트에 오른 사용자들은 아래와 같은 메시지를 볼 것이다.

   crontab: you (marcs) are not allowed to use this program


비슷하게, /var/cron/allow를 생성하여 crontab을 사용할 수 있는 사용자를 추가할 수 있다. 자세한 사항은 crontab(1) man page를 참고하라.


콘솔 보안


많은 사람들이 물리적 접근이 가능한 악의적인 사용자가 싱글 유저 모드로 재부팅하여 루트 패스워드를 변경하는 것을 걱정한다. 하지만 침입자가 서버로 물리적 접근이 가능하다면 할 수 있는 일은 없다.

단순히 싱글 유저 모드로 부팅하여 root 패스워드를 변경하는 것을 막을 수 있을 뿐이다. /etc/ttys를 수정하여 ‘console’행의 ‘secure’단어를 ‘insecure’로 변경한다. 이렇게 되면 싱글 유저 모드로 들어갈때 root 패스워드를 입력해야 한다. 해당 라인은 다음과 갈다.


   console none                            unknown off insecure


또한 콘솔 보안을 설정하고 root 패스워드를 잊는다면, 패스워드를 초기화하기 위해 fixit 플로피를 사용해야 한다. 이는 싱글 유저 모드로 접속하게 되면 패스워드를 변경할 수 없기 때문이다.  


프로세스 어카운팅

머신에서 무슨일이 일어나는지 정확히 아는 것은 지극히 좋은 일이며 머신에서 프로세스 어카운팅을 enable하도록 권장한다. 이 기능을 사용하여 사용자가 실행한 명령을 살펴볼 수 있으며, 또한 어떤 문제들을 디버깅할 때 꽤 유용하기도 하다. 약간의 부하가 걸리지만 일반적으로 저하된 성능을 알아차릴 수 있는 정도는 아니다. Enable하기 위해서 단순히 다음의 명령을 실행한다.


   secure-me (1) :  touch /var/account/acct
   secure-me (2) :  accton /var/account/acct



재부팅 후에도 계속 설정을 유지하기 위해서는 아래 설정을 /etc/rc.conf에 추가하라.


   accounting_enable="YES"


어카운팅이 enable되면 lastcomm(1)과 sa(8)를 사용하여 프로세스 어카운팅 데이타베이스에서 유용한 통계자료를 얻을 수 있다.


o  ipfw

ipfw는 이 문서의 범위를 벗어나기는 하지만 머신을 안전하게 지키고자 할 것이며 ipfw를 사용하여 공격 패턴에 관한 정보를 얻고자 할 것이다. 때때로 당신의 머신에 관심을 갖는 누군가가 관심 이상의 의도를 갖는지를 알려줄 수도 있다. Ipfw(8) man page를 참고하라.


메일 얼라이어스

자신의 시스템에서 일어나는 일들을 감시하라. FreeBSD는 일/주/달 단위로 동작하는 많은 스크립트를 가지며(periodic(8)의 man page와 /etc/periodic 파일을 살펴보라) 이 스크립트들이 추출하는 정보들은 SUID 프로그램이나 커널 메시지 그리고 다른 유용한 정보와 같은 시스템에 관한 것들이다. 이 때문에 이러한 정보들을 메일로 받아보는 것이며 스크립트들의 출력이 root 계정으로 발송되지만 여러개의 이메일 주소로 발송할 수도 있다. /etc/mail/aliases를 수정하여 아래와 같은 행을 추가한다.


   root:   localuser, remoteuser@yourdomain.com


로컬 관리자뿐 아니라 별도의 메일 서버에 위치하는 곳에서도 결과물을 받아 볼 수 있다.



커널 변경
==============

필요치 않다면 bpf를 disable 상태로 하라.

FreeBSD을 설치한 후 가장 먼저 할 것 중 하나는 커널 컴파일이다. 공격자가 네트워크 카드를 정상적인 요청에 응답할 수 없는 상태로 만들 수 있기 때문에 커널에서 disable 상태로 설정하는 것중 하나가 bpf 장치이다. 서버 자체가 위험에 놓여 있기 때문에 유용하다. 간단히 커널 파일에서 다음 행을 주석처리하면 된다.


   #pseudo-device   bpf             #Berkeley packet filter


DHCP를 사용하는 사용자는 bpf를 diable하면 안된다. BPF를 diable상태로 설정하면 snort와 같은 프로그램에 영향을 줄 것이다.

또한 이 옵션에  ipfw, ipfilter를 추가할 수 있으며 동시에 쿼터설정을 지원할 수 있다.


Ctrl-Alt-Del 사용금지

물리적 접근이 가능한 사용자가 Ctrl-Alt-Del 키를 사용하여 시스템을 재부팅하지 못하게 할 수 있다.

다음을 커널 파일에 추가하기만 하라.


   options         SC_DISABLE_REBOOT       # disable reboot key sequence



이 설정은 모든 사용자가 시스템을 재부팅하는 것을 방지한다는 것을 명심하라. 또한 콘솔을 insecure로 설정했다면 재부팅하여 root 패스워드를 변경하지 못하게 한다. 즉, 물리적으로 접근할 수 있는 누군가가 악의적인 일을 하고자 한다면 당신은 상당한 곤란에 처하게 된다.


o  Quota Support

파일 시스템이 쿼터를 지원하기 위해서는 커널에 옵션을 enable해야 한다. 아래의 옵션으로 이를 설정할 수 있다.


   options         QUOTA                   #enable disk quotas


o  ipfw/ipf support

방화벽 지원 또한 커널에 추가할 수 있다. 무엇을 추가할 지는 자신에게 달려 있다. FreeBSD는 기본 시스템에 ipfw와 ipf가 포함된다. 자세한 사항은 LINT를 참고하라.


사용자 계정 관리
======================

사용자 쿼터

임의의 파일시스템에서 사용자 쿼터를 설정함으로써 한 사용자가 디스크 공간을 소모해버리는 위험을 덜 수 있다. 사용자가 모든 디스크 공간을 잡아먹을 가능성이 있는 곳에 설정하라. 또한 디스크 사용을 효육적으로 관리할 수 있는 장점이 있다.

쿼터는 커널에서 지원하도록 컴파일한 경우에 사용할 수 있다. 쿼터를 지원하도록 컴파일한 경우에는 다음을 /etc/rc.conf에 추가해야 할 것이다.


   enable_quotas="YES"
   check_quotas="YES"


edquota(8), qoutacheck(8), qoutanon(8), qoutaoff(8), repqouta(8)를 사용하여 쿼터 파일시스템을 관리할 수 있다.


홈 디렉토리 권한

사용자가 무엇을 열람할 수 있는지 알고 있어야 한다. 사용자가 Root의 crontab을 열람하기를 원치않는 것과 마찬가지로 root 디렉토리의 내용을 열람할 수 있는 걸 원치않을 것이다. ‘chmod 0750 /root’명령은 wheel 그룹의 사용자가 아니라면 디렉토리의 내용을 볼 수 없을 것이다.

또한 파일 권한을 0700으로 설정하여 사용자 홈 디렉토리들을 제한할 수 있다. 이렇게 되면 사용자들은 자신의 홈 디렉토리를 다른 사용자가 열람할 수 있도록 직접 변경해 주어야 한다.


프로세스 숨기기

ps(1) 명령을 사용하여 사용자가 볼 수 있는 프로세스를 제한할 수 있다. 기본적으로 FreeBSD 는 자기가 소유하지 않는 프로세스를 포함하여 시스템의 모든 프로세스를 볼 수 있다. 자기 소유의 프로레스만을 열람할 수 있도록 하고자한다면 kern.ps_showallprocs sysctl 변수를 변경하라. 시스템이 실행중인 상태에서 아래의 명령으로 변경할 수 있다.


   sysctl kern.ps_showallprocs=0


재부팅 후에도 변경사항을 유지하고자 한다면 /etc/sysctl.conf에 아래와 같이 추가한다.


   kern.ps_showallprocs=0

root는 kern.ps_showallprocs 변수에 영향을 받지 않고 모든 프로세스를 볼 수 있다.



이 방법은 ps(1)의 출력을 제한하는 반면 공격자가 어떤 프로세스가 실행되고 있는지 알아내기 위해 /proc를 접근을 막을 수는 없다. 이에 관한 정보는 ‘Disabling procfs’를 살펴보라.


o  Disabling procfs

procfs를 사용하여 실행되고 있는 프로세스에 관한 정보를 얻을수 있다. 이것은 또한 ps(1), w(1), truss(1)와 같은 프로그램이 완전히 동작하기 위해 필요하다. Procfs가 포함하고 있는 많은 정보들로 인해 많은 관리자들이 이 파일시스템을 disable로 설정하는 데 유익하다고 생각하고 있다.

이 설정은 본인에 달려있다. 원치 않으면 disable 상태로 설정할 필요는 없다.

Procfs를 disable상태로 설정하기 위해서는 /etc/fstab에서 procfs 파일시스템에 NOAUTO 옵션을 추가하라.
필요하다면 수동으로 마운트할 수도 있다.


o  login.conf(5)

‘login classes’에 사용자를 추가하여 사용자가 사용할 수 있는 CPU/memory 등을 제 한할 수 있다. 이 기능은 로컬 DoS 공격자를 제한하는 데 매우 효과적이다. 더 자세한 사항은 login.conf(5) man page를 참고하라.



최신 상태로 유지하라.
===============

패키지를 최신으로 유지하라.

외부에서 노출되어 있고 접근가능한 대몬들을 실행할 때는 자신의 패키지가 항항 최신 상태로 유지하는 것은 중요하다. 설치되 패키지의 새 버전이 나오면 포트 트리를 이용하여 항상 최신 버전을 유지하라.

대부분의 경우 몇분도 걸리지 않지만 골치거리로부터 해방되기 위한 최소한의 노력이다. 보안 권고에 관해서는 bugtraq과 같은 리스트를 살펴보는 것도 도움이 될 것이다.

패키지를 항상 최신 상태로 유지하기위해서 FreeBSD  핸드북을 참고하기 바란다.


   http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/


운영체제를 최신 상태로 유지하라.

비슷하기, FreeBSD 자체를 최신 상태로 유지하는 것 또한 중요하다. 소스 트리를 최신 상태로 유지하고 새 보안 패치가 나오면 ‘make world’를 수행하라. 보안 권고에 관해서는 bugtraq과 같은 리스트를 살펴보는 것도 도움이 될 것이다.

운영체제를 항상 최신 상태로 유지하기위해서 FreeBSD  핸드북을 참고하기 바란다.


   http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/


또한 FreeBSD 보안 권고 메일리스트에 가입하도록 하라.


   http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources.html


조심성을 갖는다.

===========


이상 징후를 발견했을 때 시스템에서 낯선 점들을 탐색해야 한다. 특히 다음과 같을 때 주의한다.

최근 재부팅된 시스템

시스템이 재부팅되었다면 심각한 무언가가 변경되었는지를 체크하라. 특히 시스템 보안레벨에 주의를 기울여라. 이는 공격자가 커널이나 KLM등과 같은 것을 수정하기 위해 변경할 것이며, 변경 불가 시스템이나 추가 전용 플래그 시스템을 통과할 수 있는 기회를 갖게 되기 때문이다.


SUID 파일들의 변경

일단위 레포트는 SUID 파일에서 변화에 관한 정보를 담고 있다. 이 레포트에 상당한 관심을 기울여라.

중요한 시스템 파일에서의 변경

커널과 같은 중요한 시스템 파일들의 변경을 항상 주지하라. FreeBSD를 설치할 때, 이들 파일의 MD5 값을 구한후 안전한 곳에 저장하라. 그리고 수시로 이 값을 비교하라. 알수 없는 이유로 일치하지 않는다면 조사하라. 이를 위해 /usr/ports/security/tripwire를 사용할 수 있다. 물론 다른 툴을 사용할 수 있다.



Topics of Interest
==================

당신이 중요하게 생각하는 다른 토픽들이 있지만 그것들은 이 문서의 범위를 벗어 난다.


o  Jail

jail 환견은 chroot(8)와 비슷하지만 더 많이 향상되는 것을 경험할 수 있다. Jail이 무엇이며 어떻게 사용하는 지에 대한 설명은 jail(8) man page에서 찾을 수 있으며 아래 링크에서도 볼 수 있다.


   http://docs.freebsd.org/44doc/papers/jail/jail.html


FreeBSD 보안에 관한 다른 문서들
======================================

다음 사이트들은 FreeBSD 보안에 관한 정보를 가지고 있다.

   - http://www.freebsd.org/security/
   - http://www.freebsd.org/~jbk/howto.html
   - http://www.subterrain.net/presentations


FreeBSD 보안에 도움이 되는 툴들

   - http://www.openssh.com/ - 현재 FreeBSD 기본 배포에 포함되어 있다..


다른 유용한 프로그램들

-        http://www.ncftpd.com/ - 안전한 FTP 대몬


감사의 말
======

이 문서를 개선할 수 있는 제안을 하고 문제점을 지적해준 다음의 사람들에게 감사하고 싶다.



   Hiten Pandya  (who is converting this document to DocBook for addition as an article on the FreeBSD website)
   Gary W. Swearingen
   Tom Rhodes
   Nick Cleaton
   Sean Lewis
   Jean-Michel Amblat
   Dominic Marks
   Seth
   Chris Phillips
   Sebastian Benner
   Trevor Johnson
   James Lawrence

FreeBSD]ssh howto(리눅스에도 적용)


SSH Howto
임은재
         eunjea@kldp.org
이 문서는 ssh 서버, 클라이언트의 설정, 사용법에 관한 문서이다.

차례
1. SSH 가 무엇이며, 어디서 구할수 있나?
왜 SSH를 사용해야만 할까?
어디서 구하나?
2. 클라이언트 사용법
기본적인 사용 방법
인증키 사용하기
ssh를 이용한 파일 복사
ssh 터널링
설정 파일
3. 서버 운영
설치
서버 설정
4. 저작권, 관련/참고 문서
저작권
관련/참고 문서
장 1. SSH가 무엇이며, 어디서 구할수 있나?
SSH (Secure SHell)은 말 그대로 보안 로그인 쉘이다.
전통적인 ftp, pop, telnet 같은 서비스들은 잘 알려진 대로 매우 보안에 취약하다. 이런 암호화 되지 않은 인증 방법은 당신의 암호가 그대로 노출될수도 있다.
ssh를 통한 모든 데이타는 암호화되며, 트래픽은 압축되어 더 빠른 전송 효율을 얻을수 있다. 또한 기존의 ftp,pop 같은 안전하지 못한 서비스들을 위한 "터널"까지 지원한다.
sshd 서버를 운영하지 않는 서버 관리자는 보안에 전혀 관심이 없는 사람이다.
왜 SSH를 사용해야만 할까?
다음글은 http://www.openssh.com/의 OpenSSH FAQ중에서 인용하였다.
강력한 보안
프라이버시 보호. 모든 통신은 자동으로 그리고 투명하게 암호화된다.
안전한 X11 세션. 원격 서버에 DISPLAY 변수를 자동으로 설정하고 모든 X11 연결을 보안채널을 통해서 포워딩한다.
TCP/IP 포트를 양 방향에서 다른 포트로 자유롭게 포워딩할수 있다.
rlogin, rsh, rcp등을 완전히 대체한다.
선택적으로 데이터를 압축하여 느린 네트워크 상에서의 속도 향상
서버는 자신의 RSA 키를 가지며 일정 시간마다 자동으로 재 생성한다.
어디서 구하나?
리눅스에서 사용할수 있는 ssh 는 두가지가 존재한다. ssh의 원 제작처인 http://www.ssh.com/ (핀란드 회사) 와 BSD licence(사실 100% BSD licence는 아니다.)의 http://www.openssh.com/가 그것이다.
나는 openSSH를 사용하며 이 문서도 openSSH를 기준으로 설명할 것이다. openSSH는 하나의 클라이언트/서버에서 ssh1,ssh2 프로토콜을 모두 지원한다.
ssh는 이미 당신의 배포본에 이미 포함되어 있을지도 모른다. 직접 컴파일 하여 사용하고 싶다면 http://www.openssh.com/portable.html에 서 소스를 받아 설치한다.
그외 ssh를 사용하기 위해 꼭 필요한 openssl 라이브러리는 www.openssl.org에서 구할수 있다.
ftp://ftp.koru.org/pub/rpm 에는 필자가 최신 버젼의 openSSH 와 openssl을 rpm 빌드해놓은 것과 소스 rpm을 찾을수 있다.
openssh는 OpenBSD, NetBSD, FreeBSD, AIX, HP-UX, IRIX, Linux, NeXT, SCO, SNI/Reliant Unix, Solaris, Digital Unix/Tru64/OSF, MacOS X 등의 다양한 OS를 지원한다.
장 2. 클라이언트 사용법
이 장에서는 ssh 서버에 접속하는 ssh 클라이언트의 사용방법에 대해 알아본다.
기본적인 사용 방법
openSSH 클라이언트는 ssh1,ssh2 프로토콜을 모두 지원하므로, 서버가 지원하는 ssh 프로토콜에 상관없이 접속할수 있다. 예를 들어, 접속할 ssh서버가 gate.eunjea.org 이고 계정명이 silver 라면
          [foo@home silver]$ ssh -l silver gate.eunjea.org
       
또는
          [foo@home silver]$ ssh silver@gate.eunjea.org
       
이제 다음과 같은 메세지와 함께 접속이 진행될 것이다.
          The authenticity of host 'gate.eunjea.org (192.168.1.1)' can't be established.

          RSA1 key fingerprint is e3:56:xx:b4:19:7e:xx:b1:7e:cd:xx:fe:5e:5b:17:66.

          Are you sure you want to continue connecting (yes/no)?
       
위 메세지는 ssh로 해당 서버에 처음 접속할때만 나오는 메세지이며, 접속할 서버의 호스트 키가 ~/.ssh/known_hosts (ssh2의 경우 known_hosts2) 파일에 저장된다. yes로 대답해주면, 다음과 같이 계정 암호를 물어오고, 이제 텔넷과 동일한 작업을 할수 있다.
          Warning: Permanently added 'gate.eunjea.org,192.168.1.1' (RSA1) to the list of known hosts.

          silver@gate.eunjea.org's password:
       
인증키 사용하기
인증키를 사용하는 것은 로그인 할때마다 암호를 직접 입력하는 것보다 더욱 안전하며, 하나의 암호로 여러 ssh서버에 접속할수 있는등의 장점을 가진다.
인증키 만들기
인증키는 ssh-keygen로 만든다. 키를 만들때는 사용할 키의 형태를 지정해 주어야 하는데 원격 서버가 ssh 프로토콜 버전 2를 지원한다면 ``rsa'' 또는 ``dsa'', 프로토콜 1만을 지원한다면 ``rsa1''을 사용한다.
예를 들어 원격 서버가 ssh2를 지원하고, ``rsa'' 키를 만들고자 한다면,
          [ home@foo ]$ ssh-keygen -t rsa

          Generating public/private rsa key pair.

          Enter file in which to save the key (/home/foo/.ssh/id_rsa):
       
키가 저장될 곳과 이름을 물어 오는데 디폴트로 그냥 엔터를 치고 넘어가면, 다음과 같이 인증키 암호를 물어온다. 원하는 암호를 두번 반복해서 입력해주면 키가 생성된다.
          Enter passphrase (empty for no passphrase):

          Enter same passphrase again:

          Your identification has been saved in /home/foo/.ssh/id_rsa.

          Your public key has been saved in /home/foo/.ssh/id_rsa.pub.

          The key fingerprint is:

          64:09:73:19:9e:ac:a0:f7:aa:c3:08:f9:0e:5a:fe:61 foo@home.eunjea.org
       
인증키 생성시 인증키 암호를 공백으로 (passphrase 를 물어올때 그냥 엔터를 치면 된다) 만들수도 있는데, 이것은 ssh 접속시 암호를 입력하지 않아도 그냥 접속이 되므로 편리할수는 있으나, 만약 당신의 인증키가 어떠한 경로로든 유출되었을 경우를 생각 해보면 피해야 할 것이다. 그리고 ssh-add와 ssh-agent를 사용하여 접속시마다 인증키 암호를 입력하지 않는 방법이 있다.
공개 키 사용하기
이제 ~/.ssh/ 안에 한쌍의 키(id_rsa 와 id_rsa.pub)가 생성되어 있을것이다. .pub 확장자가 붙은 것은 공개키로 이 파일을 접속할 리모트 서버들의 ~/.ssh/ 에 authorized_keys 라는 이름으로 복사해준다.
          [foo@home silver]$ scp ~/.ssh/id_rsa.pub silver@gate.eunjea.org:.ssh/authorized_keys
       
이제 ssh 접속을 진행 해보면 계정암호가 아닌 인증키 암호를 물어볼 것이다. 만약 계정 암호를 물어본다면 원격 서버상의 ~/.ssh 디렉토리나 공개키 권한의 문제이므로, 일단 접속후 chmod 755 ~/.ssh 그리고 chmod 644 .ssh/authorized_keys 해준다.
rsa1 방식의 ssh1 프로토콜의 사용할 것이라면 ssh-keygen -t rsa1 으로 키를 만들고, 공개키 (identity.pub)를 같은 방법으로 원격 서버의 ~/.ssh/authorized_keys 에 추가해 주면 된다.
키 파일을 다른 이름으로 저장했거나 서버마다 다른 키를 사용하려면 ssh에 -i 옵션을 사용해 키 파일을 직접 지정해 주면 된다.
인증키를 메모리에 상주 시키기
다음 방법으로 인증키를 메모리에 기억시켜 두면 처음 한번만 인증키 암호를 입력하면 다음부터는 암호를 입력하지 않아도 같은 인증키를 사용하는 모든 서버들에 접속할수 있다.
          [foo@home silver]$ eval $(ssh-agent) [Enter]

          다음과 같은 메세지를 보여줄 것이다.

          Agent pid 31234

          이제 ssh-add 를 입력하면

          Identity added: /home/silver/.ssh/identity (silver@home.eunjea.org)
       
이제 인증키를 복사해둔 ssh서버에 접속하면 이 세션에서는 더 이상 암호를 묻지 않을 것이다.
서버가 지원한다면 되도록 SSH2 프로토콜을 사용하도록 한다. SSH2는 SSH1과는 전혀 다른 프로토콜이며 더욱 안전하고, 성능이 좋다.
ssh를 이용한 파일 복사
scp
위에서 인증키를 리모트 서버에 복사할때 사용한 scp에 대해서 알아보자
예를 들어, 복사하려는 파일명이 'dumb' 라고 하고 접속하려는 원격 서버의 주소는 www.foobar.com, 당신의 쉘 계정은 babo 라고 한다면
dumb 파일을 www.foobar.com 의 babo 계정 홈 디렉토리에 복사하기
          [foo@home silver]$ scp dumb babo@www.foobar.com:.
       
www.foobar.com 의 babo 계정 홈 디렉토리에 있는 dumb 파일을 로컬로 복사하기
          [foo@home silver]$ scp babo@www.foobar.com:dumb .
       
만약 ~/.ssh/config 파일에 다음과 같이 www.foobar.com 의 계정을 설정해 놓았다면,
          Host *fbc

          HostName www.foobar.com

          User babo

          ForwardAgent yes
       
다음과 같이 더 간단하게 할수 있다.
          [foo@home silver]$ scp dumb fbc:.
       
또한 scp 는 -r 옵션도 가지고 있는데 이것은 디렉토리를 통채로 복사 할때 사용한다. 예를 들어 test/ 디렉토리안의 모든 파일과 하위 디렉토리를 서버 계정의 www 디렉토리 안에 복사 하려면 다음과 같이 한다.
          [foo@home silver]$ scp -r test/ babo@www.foobar.com::www/
       
sftp
sftp는 ssh하에서 전통적인 ftp 환경을 제공하며, 리모트상의 프로그램을 실행시킬수도 있다.
openSSH 클라이언트 패키지에는 sftp가 포함되어 있다.
ssh 터널링
ssh 터널링이란 ssh 접속을 다른 프로그램이 사용할수 있도록 port forwarding해주는 것을 말한다. 이 ssh 터널링을 이용해 암호화 접속을 사용하지 않는 네트워크 접속을 보다 안전하게 사용할수 있다.
POP
fetchmail을 사용하면 간단하게 ssh 터널안에서의 pop 메일 긁어오기를 구현할수 있다.
.fetchmailrc 설정예
          poll localhost with protocol pop3 and port 11110:

               preconnect "ssh -C -f 계정@메일서버.com -L 11110:메일서버.com:110 sleep 5"

               password xxxxx
       
자세한 문서는 : SSH 를 이용한 보안 POP
원격 계정의 이메일을 아예 복사해오는 방법도 생각해 볼수 있다. (Compressed TCP/IP-Sessions using SSH-like tools 참조)
IMAP
ssh 터널링과 fetchmail을 사용해서 imap 서버로부터 메일을 가져오려면, 다음과 같은 .fetchmailrc를 만들어 사용하면 된다.
          poll 메일서버.com with proto imap:

               plugin "ssh %h /usr/sbin/imapd" auth ssh;

               user babo is babo here
       
SMTP
역시 같은 문서에서 SSH 접속을 이용한 SMTP 사용법을 제시했는데 방법은 다음과 같이 간단하다.
           ssh -C -l loginid mailserver -L2525:mailserver:25
       
후에 메일 클라이언트를 localhost port 2525 를 통해 메일을 보내도록 하면 된다. 예를 들어 pine을 사용한다면, .pinerc의 smtp-server=localhost:2525 와 같이 해주면 되겠다.
ssh 윈도우 클라이언트인 SecureCRT를 사용해도 가능한데 Session Option -> Connection -> Hostname -> Advanced 탭을 선택해서, 같은 요령으로 사용할 로컬 포트와 원격 호스트 이름, 포워딩할 원격 포트를 선택한다. ssh 접속 후에는 OE의 경우 SMTP 서버를 127.0.0.1 로 지정하고 사용할 포트만 위에서 선택한 로컬 포트로 지정하면 된다. POP 포트도 같은 방법으로 사용 가능 하다.
SSH를 이용한 SMTP는 몇가지 장점을 가지는데 네트워크 트래픽의 감소와 계정 사용자만이 SMTP 서버를 사용할수 있으므로 함부로 릴레이를 열어놓지 않아도 된다는데 의미가 있겠다.
Webmin
Webmin는 웹상에서 브라우저로 서버 관리를 하는 툴이며, 당연히 보안에 민감하다.
webmin은 일반적으로 10000 포트를 사용하므로 다음과 같이 ssh 접속을 연다.
          ssh -f -l [원격 유저] [원격 서버] -L 1234:[원격 서버]:10000 tail -f /etc/motd
       
이제 브라우저에서 http://localhost:1234 로 접속할수 있다.
X
리모트 서버상의 X 어플리케이션들을 실행하고자 한다면 계정 홈 디렉토리의 ~/.ssh/environment 파일을 만들고 다음과 같은 내용을 넣어준다.
          XAUTHORITY=/home/계정 이름/.Xauthority
       
이제 로그아웃한후에 ssh를 다음과 같이 실행해본다. (계정 이름이 silver이고 서버는 gate.eunjea.org 라고 한다면)
          ssh -f -X -l silver gate.eunjea.org xterm
       
이제 xterm 이 로컬의 X에서 실행될 것이다. 다른 X 어플리케이션들도 이와 같이 실행시킬수 있다.
설정 파일
ssh 설정 파일은 ~/.ssh/config 파일 이다. 또는 전체 유저의 설정파일은 /etc/ssh/ssh_config 로 설정할수 있다.
다음은 내가 사용하는 설정 파일의 일부분이다. Host 지시자를 사용하여 접속할 서버마다 다른 옵션을 사용할수 있다.
          # *.eunjea.org 도메인을 가진 서버에 접속할때는 SSH2 프로토콜을 사용한다.

          Host *.eunjea.org

          Protocol 2

       

          # koru.org 에 접속할때는 SSH2 와 압축 옵션을 사용한다.

          Host koru.org

          Protocol 2

          Compression yes

          CompressionLevel 9

       

          # kldp.org에 접속할때는 SSH1 프로토콜을 사용하고

          # Cipher는 blowfish, 압축을 켠다.

          Host kldp.org

          Protocol 1

          Cipher blowfish

          Compression yes
       
그외 중요한 옵션으로는 CheckHostIP 가 있는데 이것은 접속할때 마다 리모트 서버의 IP 주소를 known_hosts 파일과 대조해본다. 이것은 DNS spoofing에 의해 호스트키의 변경을 알수 있는 옵션이다. 디폴트는 yes이다.
이외에도 많은 옵션들이 있는데 ssh의 man 페이지를 참고하라.
장 3. 서버 운영
설치
서버는 간단하게 패키지를 설치하거나 직접 소스를 설치할 경우 일단 보안을 위한 Privilege separation을 위해 sshd 유저와 디렉토리를 만들어 준다.
          $ mkdir /var/empty/sshd

          $ chown root:sys /var/empty/sshd

          $ chmod 755 /var/empty/sshd

          $ groupadd sshd

          $ useradd -g sshd -c 'sshd privsep' -d /var/empty/sshd -s /bin/false sshd
       
ssh 컴파일 옵션:
          configure --with-pam \

             --with-ipv4-default \

             --with-rsh=/usr/bin/rsh \

             --with-default-path=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin \

             --with-privsep-path=/var/empty/sshd
       
서버 설정
서버 설치가 끝난후 설정 파일(/etc/ssh/sshd_config)의 옵션들을 살펴보자. 대부분의 경우 기본 설정파일 그대로 사용하여도 좋지만, 특정 그룹이나 유저들에게만 로그인을 허용하도록 할 경우 다음 지시자를 사용할수 있다.
AllowGroups
ssh 로그인을 해당 그룹으로 제한한다. 각각의 그룹명은 공백으로 구분한다. 와일드 카드(* 와 ?)를 사용할수 있다.
AllowUsers
ssh 로그인을 해당 유저로 제한한다. 사용법은 AllowGroups과 같다.
DenyGroups
AllowGroups의 반대 역할을 한다. 지정된 그룹은 로그인이 거부된다.
DenyUsers
AllowUsers의 반대 역할을 한다. 지정된 사용자는 로그인이 거부된다.
이외 사용자들의 sftp 사용을 허용하려면 다음과 같은 라인이 있는지 확인한다.
          Subsystem   sftp  /usr/lib/openssh/sftp-server
       
이외 옵션들은 sshd 의 man 페이지를 참고한다.
장 4. 저작권, 관련/참고 문서
저작권
Copyright (C) 2001 임은재
이 문서는 GNU Free Documentation License 버전 1.1 혹은 자유 소프트웨어 재단에서 발행한 이후 판의 규정에 따르며 저작권에 대한 본 사항이 명시되는 한 어떠한 정보 매체에 의한 본문의 전재나 발췌도 무상으로 허용됩니다.
본 저자는 문서의 내용이 야기할 수 있는 어떠한 결과에 대해서도 책임을 지지 않습니다.
관련/참고 문서
http://www.linuxdoc.org/HOWTO/mini/Compressed-TCP.html
http://www.mandrakeuser.org/docs/secure/sssh.html