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

2009년 6월 25일 목요일

AAA RADIUS에 관하여

AAA RADIUS에 관하여

 

1. AAA 개요

AAA 서버란 인증(Authentication), 권한검증(Authorization), 과금(Accounting)을 제공하는 서버를 말한다. 이러한 AAA를 구현하는 프로토콜로는 RADIUS(Remote Authentication Dial-In User Service)와 DIAMETER가 있다. 여기에서는 현재까지 AAA를 위해 대표적으로 사용되어온 RADIUS에 대해 설명하고자 한다.

RADIUS 서버가 사용될 수 있는 실제 망 구성의 간단한 예를 들어 설명을 시작하도록 하겠다.

 

예1) ADSL 접속.

일반적으로 ADSL은 아래와 같을 것이다.

PC --- ADSL modem --- 전화국의 NAS(Network Access Server) --- 인터넷 --- RADIUS server.

 

1. PC는 ADSL 접속을 위해 NAS 서버에 접속을 요청할 것이다. 이것은 layer 2에서 PPP 프로토콜에 의한 접속 요청이 된다.

 

2. 접속을 위한 PPP 핸드쉐이크가 끝난 후 인증을 위한 인증 패킷을 NAS에게 전달할 것이다(참고로, NAS가 받는 패킷은 PPP protocol에 의한 패킷이다).

 

3. 그러면, NAS는 PPP protocol에 의거해 받은 패킷을 실제 인증 데몬 및 DB를 가지고 있는 RADIUS 서버에게 유효한 사용자인지 물어보아야 한다. 이 때 NAS와 RADIUS 서버 사이에 패킷이 왔다갔다 하는데, 이 패킷은 RADIUS protocol(layer 3임)에 기반한 패킷 포맷을 가지고 왔다갔다 한다. 즉, NAS는 PPP protocol(Layer 2)에 기반한 패킷을 access 개체(PC)로부터 받아 이를 다시 RADIUS protocol(Layer 3)에 기반한 패킷으로 만들어 RADIUS 서버에게 물어보게 된다(결국 NAS는 RADIUS client가 됨).

 

4. 인증 확인 요청을 받은 RADIUS server는 해당 사용자에 대한 인증 확인 후 accept인지 reject인지의 답변을 NAS에게 주게된다.

 

5. NAS는 RADIUS 서버에세 받은 응답 패킷을 이용해 다시 PPP쪽에 적당한 응답을 주게 된다.

 

예2) 무선랜 접속.

일반적으로 무선랜 접속은 아래와 같을 것이다.

PC --- 무선 ------무선 AP ----- 인터넷 --- RADIUS server.

1. PC는 802.11에 기반한 무선 AP로의 접속 및 핸드쉐이크를 실시한다.

2. 그리고 나서 PC는 802.1x에 기반에 인증 데이터을 무선 AP에게 전송한다.

3. 무선 AP는 RADIUS 서버에게 이에 대한 인증 확인을 요청한다.

4. RADIUS 서버로 부터 인증 확인에 대한 응답이 오면 무선 AP는 다시 PC에게 인증 확인해 대한 패킷을

    802.1x에 기반해 전송해 준다.

5. 다음 과정을 실시한다..

 

다음으로 RADIUS 서버가 왜 필요한가에 대한 설명이다.

RADIUS 서버가 없다고 가정해 보면, 위의 예에서 NAS, 무선 AP 등  access 개체(일반적으로 PC라 생각하면 됨)로부터 연결 요청을 받는 장비는 모두 모든 사용자 정보를 각각 가지고 있어야만 한다. 이것은 간단한 NAS, 무선 AP 장비에  올리기도 어렵거니와 각각의 NAS, 무선 AP가 가지고 있는 사용자 정보도 동기화 시켜야 하는 엄청난 일이 발생할 것이다. 이것 말고도 문제가 더 많을 듯 하다. 그런데, AAA 역할을 해주는 서버를 따로 빼두면, NAS, 무선 AP 등은 AAA 역할의 서버에게만 이러한 질의를 해보면 될 것이다. 관리자 측면에서도 AAA 관련된 것은 모두 해당 RADIUS 서버를 이용하면 되므로 편리할 것이다..

 

2. RADIUS 개요

RADIUS(Remote Authentication Dial-In User Service) 프로토콜은 다이얼업 네트워킹을 통해 본사 네트워크에 접속할 때, 보안을 위해 사용자 이름과 암호 그리고 가능한한 필요한 보호 조치들을 통해 외부 사용자들을 인증하는 프로토콜이다.


RADIUS 구성 요소
RADIUS 환경은 ▲RADIUS 서버 ▲RADIUS 클라이언트 ▲원격 액세스 클라이언트 ▲RADIUS 프록시 서버로 이뤄져 있다(www.ietf.org/rfc.html의 RFCs 2138과 2139를 참조). RADIUS 서버는 각 네트워크 액세스 서버가 아닌 중앙 원격 액세스 사용자 인증, 계정 데이터를 담당하며, 원격 사용자를 위한 정책을 중앙 관리할 수 있다.

 

RADIUS의 주요 특징

- Client/Server Model
NAS는 RADIUS의 client로서 동작함. RADIUS server는 사용자의 연결, 인증, 모든 configuration 구성 요청에 대해 응답함.

 

- Network Security
Client와 Radius server 사이의 transaction은 shared secret을 사용해 인증되어짐. shared secret은 network을 통해 보낼 수 없슴. 추가적으로 사용자 패스워드는 client와 RADIUS server 사이에 encrypt되어 보내짐.

 

- Flexible Authentication Mechanisms
RADIUS 서버는 사용자 인증을 위한 방법을 제공함. PPP PAP or CHAP, UNIX login, and other authentication mechanisms.

 

-Extensible Protocol
모든 transaction은 variable length Attribute-Length-Value 3-tuples를 포함한다. 새로운 Attribute 값은 기존 protocol에 영향없이 추가할 수 있다.

 

3. 표준 문서

RADIUS는 아래의 두 표준문서가 있다.

 

RFC 2138 - Remote Authentication Dial In User Service(RADIUS)

Authentication와 Authorization을 위한 RADIUS protocol을 설명함. 즉, 아래 패킷 포맷의 Code 4(Accounting-Request), 5(Accounting-Response)를 제외한 코드의 패킷을 설명함. UDP 1812 port를 사용(기존 1645 포트는 "datametrics" 서비스와 충돌).

 

RFC 2139 – RADIUS Accounting

Network Access Server(NAS)로부터 RADIUS accounting server로의 accounting 정보를 설명함. 즉, 아래 패킷 포맷의 Code 4(Accounting-Request), 5(Accounting-Response)번 코드의 패킷을 설명함. UDP 1813 port를 사용(기존 1646은 "sa- msg-port" 서비스와 충돌)

 

4. Packet Format

RADIUS client(NAS or 무선 AP)와 RADIUS Server 사이는 정해진 포맷에 의한 패킷을 주고 받아야 한다. 이 포맷을 아래와 같다.

 


    0                       1                        2                          3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier      |                  Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                                             |
   |                         Authenticator                                 |
   |                                                                             |
   |                                                                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attributes ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-


Code :

Code field는 one octet이며, RADIUS packet의 타입을 식별한다.


RADIUS Codes(decimal)
        1       Access-Request  - RFC 2138
        2       Access-Accept  - RFC 2138
        3       Access-Reject  - RFC 2138
        4       Accounting-Request  - RFC 2139
        5       Accounting-Response  - RFC 2139
       11       Access-Challenge  - RFC 2138
       12       Status-Server (experimental)
       13       Status-Client (experimental)
      255       Reserved

 

Identifier : request, replies에 매칭되는 one octet이다.

Length : code, identifier, length, authenticator, attribute field를 포함하는 패킷의 길이.

             mininum length는 20, maximum length는 4096.

Authenticator : 16 octet으로 radius client와 server가 상호 인증하는데 사용하는 정보.

Attribute : RADIUS Attribute는 요청과 응답을 위한 특정 authentication, authorization, information

               and configuration을 포함한다.

 

4.1 Attributes

RADIUS Attribute는 요청과 응답을 위한 특정 authentication, authorization, information and configuration을 포함한다. 즉, ID, password 등의 정보가 attribute에 해당한다.

 

Attribute Format

 

    0                          1                         2

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   |     Type      |    Length     |  Value ...

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

 

      A RADIUS client MAY ignore Attributes with an unknown Type.

          1      User-Name

          2      User-Password

          3      CHAP-Password

          4      NAS-IP-Address

          5      NAS-Port

          6      Service-Type

          7      Framed-Protocol

          8      Framed-IP-Address

          9      Framed-IP-Netmask

         10      Framed-Routing

         11      Filter-Id

         12      Framed-MTU

         13      Framed-Compression

         14      Login-IP-Host

         15      Login-Service

         16      Login-TCP-Port

         17      (unassigned)

         18      Reply-Message

         19      Callback-Number

         20      Callback-Id

         21      (unassigned)

         22      Framed-Route

         23      Framed-IPX-Network

         24      State

         25      Class

         26      Vendor-Specific

         27      Session-Timeout

         28      Idle-Timeout

         29      Termination-Action

         30      Called-Station-Id

         31      Calling-Station-Id

         32      NAS-Identifier

         33      Proxy-State

         34      Login-LAT-Service

         35      Login-LAT-Node

         36      Login-LAT-Group

         37      Framed-AppleTalk-Link

         38      Framed-AppleTalk-Network

         39      Framed-AppleTalk-Zone

         40-59   (reserved for accounting)

         60      CHAP-Challenge

         61      NAS-Port-Type

         62      Port-Limit

         63      Login-LAT-Port

  

Length : 해당 Type, Length, Value fields를 포함하는 이 attribute의 길이를 가리킴.

Value : Value filed는 attribute에 정보 spec을 포함하며, 사이즈는 zero or more octets.

 

다음은 4가지의 data type에 대한 설명이다.

 string : 0-253 octets

 address : 32bit value, most significant octet first.

 integer : 32bit value, most significant octet first.

  

username format :

- monolithic : alphanumeric character로 구성됨.

- simple : printable ASCII characters로 구성됨

- name@fqdn : SMTP address.

- distinguished name : ASN.1 form의 이름.

  

4.1.1 Vendor-Specific Attribute

RADIUS 프로토콜은 fix 되어 있으므로, RADIUS를 구현하는 벤더에서 새로운 attribute를 넣을려면 이 attribute를 이용하면 된다.

 

0                  1                    2                 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |  Length       |            Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Vendor-Id (cont)      | Vendor type  | Vendor length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Attribute-Specific...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+
 
5. Example
 아직까지 설명해온 RADIUS protocol에 의해 주고 받는 패킷의 내용이다.


5.1 User Telnet to Specified Host
 The NAS at 192.168.1.16 sends an Access-Request UDP packet to the RADIUS Server for a user named nemo logging in on port 3.


      Code = 1        (Access-Request)
      ID = 0
      Length = 56
      Request Authenticator = {16 octet random number}
      Attributes:
          User-Name = "nemo"
          User-Password = {16 octets of Password padded at end with nulls,
                                      XORed with MD5(shared secret|Request Authenticator)}
          NAS-IP-Address = 192.168.1.16
          NAS-Port = 3
 
   The RADIUS server authenticates nemo, and sends an Access-Accept UDP
   packet to the NAS telling it to telnet nemo to host 192.168.1.3.
 
      Code = 2        (Access-Accept)
      ID = 0          (same as in Access-Request)
      Length = 38
      Response Authenticator = {16-octet MD-5 checksum of the code (2),
                                              id (0), Length (38), the Request Authenticator from
                                              above, the attributes in this reply, and the shared secret}
      Attributes:
          Service-Type = Login-User
          Login-Service = Telnet
          Login-Host = 192.168.1.3


 5.2.  Framed User Authenticating with CHAP

    The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
   RADIUS Server for a user named flopsy logging in on port 20 with PPP,
   authenticating using CHAP.  The NAS sends along the Service-Type and
   Framed-Protocol attributes as a hint to the RADIUS server that this
   user is looking for PPP, although the NAS is not required to do so.
 
 
      Code = 1        (Access-Request)
      ID = 1
      Length = 71
      Request Authenticator = {16 octet random number also used as CHAP challenge}
      Attributes:
          User-Name = "flopsy"
          CHAP-Password = {1 octet CHAP ID followed by 16 octet
                           CHAP response}
          NAS-IP-Address = 192.168.1.16
          NAS-Port = 20
          Service-Type = Framed-User
          Framed-Protocol = PPP
 
The RADIUS server authenticates flopsy, and sends an Access-Accept UDP packet to the NAS telling it to start PPP service and assign an address for the user out of its dynamic address pool.
 
      Code = 2        (Access-Accept)
      ID = 1          (same as in Access-Request)
      Length = 56
      Response Authenticator = {16-octet MD-5 checksum of the code (2), id (1),

                                              Length (56), the Request Authenticator from above,

                                              the attributes in this reply, and the shared secret}
      Attributes:
          Service-Type = Framed-User
          Framed-Protocol = PPP
          Framed-IP-Address = 255.255.255.254
          Framed-Routing = None
          Framed-Compression = 1      (VJ TCP/IP Header Compression)
          Framed-MTU = 1500
 
5.3  User with Challenge-Response card
    The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
   RADIUS Server for a user named mopsy logging in on port 7.
 
      Code = 1        (Access-Request)
      ID = 2
      Length = 57
      Request Authenticator = {16 octet random number}
      Attributes:
          User-Name = "mopsy"
          User-Password = {16 octets of Password padded at end with nulls, XORed with MD5

                                      (shared secret|Request Authenticator)}
          NAS-IP-Address = 192.168.1.16
          NAS-Port = 7
  
The RADIUS server decides to challenge mopsy, sending back a challenge string and looking

for a response.  The RADIUS server therefore and sends an Access-Challenge UDP packet to the NAS.
 
      Code = 11       (Access-Challenge}
      ID = 2          (same as in Access-Request)
      Length = 78
      Response Authenticator = {16-octet MD-5 checksum of the code (11), id (2),

                                              length (78), the Request Authenticator from above,

                                              the attributes in this reply, and the shared secret}
      Attributes:
          Reply-Message = "Challenge 32769430.  Enter response at prompt."
          State =     {Magic Cookie to be returned along with user's response; in this example

                           8 octets of data}
 
The user enters his response, and the NAS send a new Access-Request with that response, and includes the State Attribute.
 
      Code = 1        (Access-Request)
      ID = 3          (Note that this changes)
      Length = 67
      Request Authenticator = {NEW 16 octet random number}
      Attributes:
          User-Name = "mopsy"
          User-Password = {16 octets of Response padded at end with nulls, XORed with MD5

                                      checksum of shared secret plus above Request Authenticator}
          NAS-IP-Address = 192.168.1.16
          NAS-Port = 7
          State =     {Magic Cookie from Access-Challenge packet, unchanged}
 
The Response was incorrect, so the RADIUS server tells the NAS to reject the login attempt.
 
      Code = 3        (Access-Reject)
      ID = 3          (same as in Access-Request)
      Length = 20
      Response Authenticator = {16-octet MD-5 checksum of the code (3), id (3),

                                              length(20), the Request Authenticator from above,

                                              the attributes in this reply if any, and the shared secret}
      Attributes:
              (none, although a Reply-Message could be sent)

 

ps> 위의 문서는 syleenet 블로그의 문서를 참조한것입니다.

 

2009년 6월 23일 화요일

보안에 관한 이슈

 보안에 관한 이슈

TLS(Transport Layer Security) - 전송 계층 보안

 

현재 널리 사용되고 있는 SSL(Secure Sockets Layer)을 대신하는 차세대 안전 통신 규약. SSL에 비해 강력한 암호화를 실현할 수 있고 폭이 넓은 망의 통신 규약에 대응하는 점에서 주목을 끌고 있다. 암호화에는 3개의 다른 데이터 암호화 표준(DES) 키를 사용한 트리플 DES 기술이 응용되고 있다. SSL은 TCP/IP에만 대응하지만 전송 계층 보안(TLS)은 네트웨어나 순차 패킷 교환(SPX), 애플토크(Apple-Talk) 등의 통신망 통신 규약에도 대응하고 있다. 또 오류 메시지 처리 기능이 다소 개선된 것으로 평가되고 있으며 미국 마이크로소프트사, 넷스케이프 커뮤니케이션스사가 TLS의 대응을 진행시켰다.

 

 

Kerberos

 

커베로스는 개방된 컴퓨터 네트웍 내에서 서비스 요구를 인증하기 위한 안전한 방법이다. 커베로스는 미국 MIT의 Athena 프로젝트에서 개발되었다. 이 이름은 그리스 신화에서 따왔는데, 커베로스는 저승의 신 하데스의 문을 지키는 머리가 셋 달린 개이다. 커베로스는 사용자가 인증 과정으로부터 암호화된 "티켓"을 요청할 수 있게 해주는데, 이 티켓은 서버에 특정 서비스를 요구하는데 사용될 수 있다. 사용자의 암호는 네트웍을 지나가야 할 필요가 없다. 커베로스의 클라이언트 및 서버 버전은 MIT로부터 다운로드 하거나, 또는 상용 버전을 구입할 수 있다.

 

아래에 커베로스의 동작원리를 간단하게 설명하였다.

 

당신이 지금 텔넷이나 기타 이와 비슷한 로그인 요청을 통해, 다른 컴퓨터에서 서버에 액세스하기 원한다고 가정해 보자. 이 서버는 당신의 요청을 받아들이기 전에, 커베로스 "티켓"을 요구한다.

티켓을 받기 위해, 당신은 먼저 인증 서버에 인증을 요구한다. 인증 서버는 당신이 입력한 패스워드에 기반하여 "세션 키"와, 서비스 요구를 나타내는 임의의 값을 만든다. 세션 키는 사실상 "티켓을 부여하는 티켓"이다.

그 다음에 세션 키를, 티켓 부여 서버, 즉 TGS (ticket-granting server)에 보낸다. TGS는 인증 서버와 물리적으로는 동일한 서버에 있을 수 있지만, 그러나 지금은 다른 서비스를 수행한다. TGS는 서비스를 요청할 때 서버에 보낼 수 있는 티켓을 돌려준다.

그 서비스는 티켓을 거절하거나, 또는 받아들여서 서비스를 수행한다.

 

TGS로부터 받은 티켓은 발송일자와 시간이 적혀있기 때문에, 일정 시간 동안 (대체로 8시간 동안) 내에는 재인증 없이도 동일한 티켓으로 다른 추가 서비스를 요청할 수 있다. 티켓을 제한된 시간 동안에만 유효하게 만듦으로써, 후에 어떤 사람이 그것을 사용할 수 없도록 만든다.

 

 

PGP (Pretty Good Privacy)

 

PGP SMS e-mail과 자료 파일을 보호하기 위하여 'public key encryption'을 사용하므로, 사전에 키를 교환할 필요 없이 안전한 채널을 통해 처음 보는 사람과도 통신을 할 수가 있다.

 

PGP는 복잡한 키 관리, 패스워드, 자료압축이 가능하며 인간공학적으로 설계되어 있다. Phil's Pretty Good Software에서 개발한 Pretty Good Privacy (PGP)는 MS-DoS, Unix, VAX/VMS, 이외의 여러 시스템을 위한 고도의 암호화 응용프로그램이다, PGP를 사용하여 파일이나 메시지를 교환하는 경우, 자료의 보안을 위하여 세 가지의 특징을 사용한다.

 

1. 메시지를 수신하는 사람 외에는 내용을 볼 수 없다.

2. 메시지에 적혀 있는 보내는 사람 이름이 정확히 송신인과 일치해야 한다.

    즉 , 다른 사람 이름으로는 메시지를 보낼 수 가 없다.

3. 위의 두 가지 특징이 프로그램에 연결된 키의 충돌 없이 편리하게 제공된다.

   안전한 채널을 위해서 사용자들 사이에 키를 교환할 필요가 없어 사용이 편리하다.

   이것이 PGP가 'public key cryptography' 라고 불리는새롭고 강력한 기술을 사용하기 때문에 가능하다고 한다.

 

자신의 키는 처음 생성하게 되면 자신의 컴퓨터에 개인키와 공개키가 저장된다.

등록서버에 등록을 하게 되면 이 때 등록되는 것은 자신의 공개키이다.

 

그리고 자신의 개인키는 자신만 알고 저장을 해두어야 하며, 상대방에게 암호화 메일을 보내고 싶을 때는 search를 통해서 import를 수행하고, 클립보드에서 암호화를 선택하게 되면 이 때 자신의 PGP KEYS로 import되어 있는 키 목록(PGPtray - Key Selection) 을 상대방의 키를 마우스로 끌어서 수령자(Recipients)부분으로 가져오면 된다.

 

그런 다음 상대방의 공개키로 암호화가 된 결과를 메일로 발송하면 된다.

 

 

S/MIME(Security Services for MIME)

: Security Services for Multipurpose Internet Mail Extension

 

이메일의 안전성을 지키는 전송 방식의 하나. 인터넷 환경은 본래 보안이 취약하여 온라인 구매 등 전자 상거래 보급에 걸림돌이 되고 있기 때문에 이러한 기술이 급격히 향상되고 있다. 또 하나의 유력한 방식인 PEM이 전자 인증국(CA:certification authority)에 의한 운용을 전제로 하고 있는 반면, S/MIME는 CA 없이도 실현할 수 있다. 이용자는 1조의 공통 키와 비밀 키를 사전에 가질 필요가 있다. 이메일의 표준 시방인 MIME를 확장해서 이메일 본체에 대한 암호 처리와 이메일에 첨부하는 전자 서명을 제공하고 있다. 안전(보안)의 필요성이 높아지고 있는 만큼 차세대 이메일 표준 규격으로 기대되고 있다.

 

 

SET (Secure Electronic Transaction)

 

97년 10월 부터 일반적으로 이용이 가능하게 되었다.

 

Internet을 base로 한 금융거래를 하기 위한 안전기준. 인증 Center가 구입자와 판매자 쌍방에 관하여, 등록내용을 확인하고 digital 증명서를 교부하는 것으로 신용도가 높은 거래를 실현 한다.

 

Visa, Master Card, American Express가 복수의 Pilot system의 운영을 세계 각국의 은행과 거래하고 있다. SET I/O에 의하여, 이용자는 Credit Card번호를 상점에 알릴 필요가 없어지고, Internet상의 거래를 촉진하는 계기가 될 것으로 보여지고 있다.

 

SET는 RSA의 Public Key와 DES의 Private Key/Secret Key을 Pair로 사용하는 암호법 (Cryptography)에 의하여, Message와 서명의 암호화(encrypt, encipher)와 decrypt화를 행하는 방식으로 되어있다. Message는 public key으로 decrypt 할 수 있는 발주 message를 가상점포에 보내면, 결재 data는 Credit Card회사에 전송된다. 여기서 인증국이 구입자, 판매자, Card회사가 올바른 존재인가를 확인하고, private key로 decrypt하는 Digital 서명이 붙은 증명서를 각각 교부한다.

 

Digital서명 된 증명서를 가진 당사자간에서만, public key과 private key에 의한 decrypt가 가능케 되고 상대가 본인인지를 확인 된다. 이렇게 해서 거래를 할 것인가 아닌가를 구입자와 판매자가 주거니 받거니 한 후 합의한 후에, Credit Card회사가 구입자의 Authorize를 한다. 성립한 거래는, 관계한 당사자의 한쪽이 일방적으로 파기할 수 없도록 한다. public key는 구입자의 browser로 생성되어, private key는 인증국이 발행하여 당사자가 되는 구입자, 판매자, Card회사가 사용 할 수 있도록 한다. digital 서명은 public key으로 여는 정보를 관련 공식으로 수치화한 hush치로 digital finger printer라고도 불리 운다.

 

SET에서는 인증국 (Certification Authority; CA)의 서명 된 증명서는 인증서 (E-Certificate with certified keys)라고 불리 우며, 이는 공히 public key 방식의 거래 infra (Public Key Infrastructure: PKI)가 형성 된다. 신용 할 수 있는 제3자를 세움으로, 구입자와 판매자의 의사를 확인 하고 인증서를 교부함으로써, 부정 Access에 의한 정보의 누출을 방지한다.

 

이제부터는 Internet상에서 개업하는 의사나 학교도 등장한다. 정말 의사인지, 교사인지는, digital 서명이 된 인증서의 발행이 본인을 특정하는 유일의 수단이 된다.

 

인증서의 발행은 공적 기관인 인증국의 이름으로, 이용자명, PIN (Personal identification Number), 인증국 code, 발행일, 이용기한 및 public key가 기재된다. 이 정보에 digital서명 (certified keys)을 인증국이 기록 발행한다.

 

현실의 세계의 Credit거래에서는, 서명의 확인이나 여신check의 명제가 있으나, SET에서는 모든 거래에 서명과 여신check가 자동적으로 check 이행된다. 기존의 credit card처리 system의 연장으로써 기능 하도록 설계 되여 왔으나, Debit card나 Smart card로의 대응으로도 고려되고 있다. 97년 말에 규격화가 설정된 SET 2.0은, 은행구좌의 직접거래에 의해, transaction의 감소기능으로도 대처 되고 있다.

 


2009년 6월 19일 금요일

솔라리스(solaris)의 보안관련 참조 사이트

솔라리스(solaris)의 보안관련 참조 사이트

1. 솔라리스의 패치정보

 

   SUN은 정규적으로 보안패치 및 권고사항정보를 Update한다. 이러한 정보는 다음의 사이트를 방문하여 확인 할 수 있다.

 

ftp://sunsolve1.sun.com/pub/patches/
http://sunsolve1.sun.com/

 

2. Security Bulletins

 

SUN사의 Security Bulletin 웹사이트 및 SunSolve(SUN제품의 Solution)웹사이트는 다음의 사이트를 참조하면 된다.

 

http://sunsolve.sun.com/
http://www.sun.com/security/

 

 Sun BluePrints

 

 BluePrint는 SUN의 솔루션들을 사용한 최고의 실제사례에 대한 깊이있는 정보들에 대하여 참고할 만한 자료들을 모아놓은 사이트이다.

 

http://www.sun.com/blueprints/

 

특히 이러한 BluePrints자료들중에 보안관련 섹션은 다음과 같다.
http://www.sun.com/blueprints/browsesubject.html#security

 

다음은 보안관련 각 호스트, 네트워크등의 부분에 대한 자료들의 참조 링크들이다.

 

Solaris에 대한 운영체제 환경에 대한 보안 설정 :  

http://www.sun.com/blueprints/0401/security-updt1.pdf


 

Solaris의 네트워크 운영환경의 보안 설정 :

  http://www.sun.com/blueprints/1200/network-updt1.pdf


 

Solasis의 보안에 대한 Minimization :

  http://www.sun.com/blueprints/1100/minimize-updt1.pdf

 

Solaris Security Toolkit (JASS : JumpStart Architecture and Security Scripts 툴킷)

 

JASS는 솔라리스의 운영환경의 보안에 대한 유연성있고, 확장가능하며 자동화된 스크립트를 지원한다. 관련 추가정보 및 Download는 다음사이트를 참조하면 된다.

 

http://www.sun.com/security/jass/

 

3. IP Forwarding and Source Routing

 

IP Forwarding, Source Routing은 SUN서버 시스템을 배스천호스트(Bastion Host) 또는 Dual Homed시스템으로 구성시에는 반드시 주의하여 구성하여야 한다. IP Forwarding, Source Routing은 사용하지 않는 것이 보안상 바람직하며, /etc/rc2.d/S69.inet파일을 수동으로 편집하여 조작할 수 있으며, ndd 툴을 사용하여 IP Forwarding, Source Routing을 사용하지 않도록 설정할 수 있다. 다음은 이러한 명령어를 사용하여 해당 플래그 값을 0으로 설정하는 예를 보여준다. 이때 주의 해야 할 점은 이렇게 설정한 환경이 적용되도록 하기 위해서 반드시 시스템을 재부팅해주어야 한다.

 

ndd -set /dev/ip ip_forwarding 0
ndd -set /dev/ip ip_ip_forward_src_routed 0

 

4. Stack Execution 

 

버퍼오버플로우(Buffer Overflow)공격에 대한 "stack smashing"공격를 디폴트로 차단시키기 위해 실행가능한 스택모드를 실행불가능하도록 설정하여 운영하는 것이 바람직하다. 이는 /etc/system파일에 다음 2개의 라인을 추가하고 시스템을 재부팅하면 된다.

 

set noexec_user_stack=1
set noexec_user_stack_log=1 

 

 

Reference : CERTCC-KR : 한국정보보호진흥원


출처 SMBW | smbw15
원본 http://blog.naver.com/smbw15/20019991079