Multi-processing
여러 개의 CPU에서 동시에 여러 개의 프로세스가 수행
Ex) Dual CPU


Multi-tasking
하나의 CPU에서 동시에 둘 이상의 작업을 수행
Ex) 한글을 사용하면서 동시에 웹 브라우저를 실행시킴


Multi-threading
하나의 프로세스내에서 여러 개의 스레드가 작업을 수행
Ex) 스타트를 하면서 정찰과 자원획득, 건물 건축을 동시에 수행
모든 활동들이 하나의 스레드로 작동함

Denial of Service에 대해서



1 개요

Denial of Service란 multi-tasking을 지원하는 운영체제에서 발생할 수 있는 공격 방법으로서 구체적으로 한 사용자가 시스템의 리소스를 독점(hogging)하거나, 모두 사용해 버리거나, 파괴하여서 이 시스템이 다른 사용자들에게 올바른 서비스를 제공하지 못하게 만드는 것을 말한다. 그러므로 시스템의 정상적인 수행에 문제를 야기시키는 모든 행위를 denial of service(DoS) 공격이라고 부르기 때문에 이를 위해서는 매우 다양한 방법이 존재할 수 있다. 여기서 한가지 재미 있는 사실은 이러한 DoS가 고의적으로 발생할 수도 있지만 사용자의 의도와는 상관없이 실수로 발생 할 수도 있다는 사실이다.



비록 denial of service는 시스템에 치명적인 문제(루트 권한의 획득, 시스템이나 사용자 데이타의 파괴나 변조)를 끼치지는 못하지만 시스템의 정상적인 수행에 문제(네트웍이나 시스템 서비스등의 마비)를 야기시킴으로써 사용자들의 많은 불편을 주게 된다. 그러므로 시스템 관리자들은 denial of service가 고의적으로 발생했던 실수로 발생하게 되었든 이를 재빨리 감지하여 신속히 문제를 해결함으로써 사용자들에게 적절한 서비스를 제공할 수 있게 해주어야 한다. 하지만 대부분의 denial of service공격의 특징이 공격을 감지하여 이를 막기가 매우 어렵다는 것이므로 이 공격의 심각도를 가히 인식할 수 있겠다.



참고로 이 문서에서 논의되는 denial of service는 모두 고의적으로 발생하였다고 가정함으로써 denial of service 공격(attack)과 혼용하여 사용하겠고 앞으로는 denial of service는 DoS로 줄여서 말하겠다. 여기서 예로 사용되는 소스들은 인터넷에서 얻을 수 있는 것들로써 출처가 분명한 것들은 가능하면 만든 사람의 이름을 명시하고 있다.




2 Denial of Service 공격(Attack)의 유형

대부분의 전문가들이 구분하기를 DoS공격을 다음과 같이 두가지 유형으로 나누고 있다.



*외부에서의 공격

*내부에서의 공격



DoS 공격에 있어서 관심이 되고 있는 부분은 대부분이 내부에서의 공격보다는 외부에서 공격이고 실제로 공격 방법을 살펴보면 내부에서의 공격은 간단한 스크립트 몇 줄로써도 가능한데 비해서 외부에서의 공격은 좀더 복잡하고 고도의 기술을 요하고 있다. 또한 내부에서의 공격은 이미 그 시스템에 계정을 가지고 있어야만 가능하기 때문에 DoS가 시스템의 루트 권한을 획득하는 공격법이 아니라는 것을 고려한다면 큰 의미를 가질 수 있다고 볼 수는 없다. 하지만 일반 사용자의 권한으로 시스템을 마비시킬 수 있다는 사실 자체는 관과할 수 없음에 분명하다.




2.1 내부에서의 공격

대부분의 내부에서의 공격은 시스템이 보유하고 있는 리소스를 점유하거나 모두 고갈시켜 버림으로써 가능해 진다. 실제로 이를 위해서는 간단한 C 코드나 셸 스크립트를 이용하여 가능하다. 하지만 이러한 공격 방법의 문제점은 반드시 시스템에 계정을 가지고 있어야 한다는 사실이다. 대부분의 침입자들이 시스템을 침입할 경우 일단 루트를 먼저 획득하는 데 관심을 가지기 때문에 내부에서의 공격은 사실상 고의에 의해서라기보다는 사용자들의 실수로 인해서 발생하는 경우가 대부분이라고 볼 수 있다.

아래의 간단한 예들을 통해서 DoS 공격이 어떻게 가능해지는지 살펴 보도록 하자. 주의할 점은 DoS 공격에는 아래에서 소개되는 예제 말고도 다른 수 많은 방법이 존재한다는 사실이다.




1. 디스크 채우기

아래의 방식은 임의의 파일을 만들어서 파일 시스템을 가득차게 하는 방식이다. 소스코드를 보면 알 수 있듯이 임의의 파일을 열고나서(open) 그 파일을 unlink시킨다. 이 부분에 대해서는 아래의 메뉴얼 페이지를 유심히 읽어 볼 필요가 있다.

unlink() removes the directory entry named by the pathname pointed to by path and decrements the link count of the file referred to by that entry. If this entry was the last link to the file, and no process has the file open, then all resources associated with the file are reclaimed. If, however, the file was open in any process, the actual resource reclamation is delayed until it is closed, even though the directory entry has disappeared.

unlink시킨 후에 파일의 크기를 무한정 증가시킴으로써 파일 시스템을 가득차가 함으로써 시스템을 마비 상태로 만들게 된다.



/*  Creates massive files with no Inode info, making deletion difficult */

/*  The files do not appear under du or ls b/c they have no dir entries */

/*#include <io.h>

#include <stdio.h>

#include <process.h>

*/

#include <stdio.h>

#include <sys/file.h>



void main()

{

int ifd;

char buf[8192];



ifd=open("./attckfil",O_WRONLY|O_CREAT,0777);

unlink("./attckfil");

while(1)

        write(ifd,buf,sizeof(buf));

}



해결 방안으로는 문제의 프로세스를 알아내어서 죽이는 방법뿐이다. 하지만 이 경우에 문제의 프로세스를 알아내는 것은 매우 어렵다. 왜냐하면 ps나 다른 방법을 이용하여 문제의 프로세스를 알아내려고 하여도 시스템이 거의 정상적이지 못하기 때문에 이러한 방법을 적용시키려고 하여도 잘 동작하지 않는다는 사실 때문이다. 그러므로 어쩔 수 없는 경우에는 최후의 방법으로 시스템을 다시 시작하게 하는것도 하나의 방법일 수 있다. 이 경우 프로세스가 죽게 되면 늘어났던 파일도 자연적으로 사라지게 되므로 파일 시스템이 다시 정상적으로 돌아오게 된다(이는 운영체제의 경우에 따라 차이가 있을 수 있다고 본다). 이를 위한 대비책으로 각 사용자들에 대해서 quota를 할당하는 것도 하나의 좋은 방법이 될 수 있다. 하지만 이 tmp 디렉토리와 같이 여러 사용자 프로세스들이 공동으로 사용하는 디렉토리에 이 공격을 한다면 quota를 할당하는 것 또한 무용지물이 된다.




2. 메모리 고갈

아래의 예제는 메모리 리소스를 고갈시킴으로써 시스템을 마비시키는 코드이다. 이는 실제 메모리를 모두 사용한 후에 스왑(swap) 공간까지 모두 잡아 먹다가 결국에는 몇 초 안에 시스템이 제공할 수 있는 모든 메모리를 고갈시킴으로서 심지어는 ps까지 동작하지 않게 하여 프로세스를 죽이는 일조차 하지 못하게 된다.

매우 간단한 예제이므로 쉽게 이해할 수 있을 것이고 실제로 이러한 방식의 DoS는 누구나 프로그래밍을 하다가 한번쯤은 경험할 수 있는 경우이므로 자세한 설명은 생략하겠다.




/* For information use only.  Watch as your avg. CPU and MEM use climb to */

/* new heights...                                                         */

/* daemon9@netcom.com                                                     */



#include<stdio.h>



void main()

{

char c;



while(1)

        c=malloc(1000);

}



해결방안으로는 메모리가 모두 고갈된 후에는 더 이상 메모리를 할당 받을 수 없기 때문에 다른 프로세스(ex. hanterm or xterm)를 죽여서 약간의 메모리를 확보한 다음 ps를 이용하여 문제의 프로세스를 죽이는 것이다. 하지만 이 방법이 모든 UNIX에서 가능한 것이 아니고 시스템이 따라서 완전히 죽어버리는 경우도 있음을 기억하기 바란다. 물론 문제의 프로세스를 알아내는 방법은 관리자의 재량에 맏길 수 밖에 없다. 프로세스가 죽게 되면 잡혔던(allocated) 메모리가 모두 사용 가능하게(free)되므로 다시 시스템이 정상적으로 돌아오게 된다. 이는 운영체제가 반드시 제공해야할 특징중의 하나이므로 대부분의 UNIX에서 지원되리라고 본다. 문제의 프로세스를 찾아내는 방법이 곤란할 경우 최후의 방법으로 시스템을 다시 시작하게하는 방법이 있을 수 있겠다.



3. 모든 프로세스 죽이기

아래의 예제는 존재하는 모든 프로세스를 죽이는 방법이다. 이는 init 프로세스에 SIGTERM 시그날을 보냄으로써 가능하다.

#define SIGTERM 15 /*software termination signal from kill */



이 경우는 모든 프로세스를 죽이기 위해서는 루트 권한을 가지고 있어야 한다. 그러므로 사실은 침입자가 시스템에 침입을 한 후 이미 루트 권한을 획득한 후에야 가능한 방법이다. 그러므로 이는 침입 후 사용자나 시스템의 데이타를 파괴하는 방법은 아니지만 시스템을 사용 불능상태로 만드는 방법이므로 루트 권한 획득 후 할 수 있는 일중에서 그래도 상당히 얌전한 것으로 생각 할 수도 있다.

관련되 메뉴얼의 내용은 다음과 같다.



To shut the system down and bring it up single user the super-user may send the initialization process a TERM (terminate) signal by `kill 1'; see init(8). To force init to close and open terminals according to what is currently in /etc/ttytab use `kill -HUP 1' (sending a hangup signal to process 1).

init terminates multi-user operations and resumes single-user mode if sent a terminate (SIGTERM) signal: use `kill -TERM 1'. If there are processes outstanding which are deadlocked (due to hardware or software failure), init does not wait for them all to die (which might take forever), but times out after 30 seconds and prints a warning message.



이는 다음과 같은 간단한 스크립트로써 가능해 진다.



# run as root to kill all processes

#!/bin/sh

sync

kill -15 1



해결책으로는 시스템을 다시 재 가동하는 방법이 있다.



4. 프로세스 만들기

아래의 예제는 시스템의 프로세스 테이블을 모두 고갈(full) 시킴으로써 이루어지는 공격 방법이다. 일반적으로 커널이 만들어질때 가능한 프로세스의 수를 한정시켜 놓게 되는데 이때 이 정해진 수를 넘어서게 되면 프로세스 테이블이 모두 고갈되면서 시스템의 모든 서비스가 거의 중단되게 된다. 실제로 테스트해 본 결과 시스템을 정상화시키기 위해서 재시동을 시키게 되는 상태가 되었다.

/* Will paralyze some systems */

void main()

{

        while(1) fork();

}



또는



void main()

{

        fork();

        main();

}



이 경우에는 그때그때의 상황에 따라 관리자가 능동적으로 대처하도록 하자. 한 예로 그 문제의 프로세스를 알아내어 죽이는 것인데 이 방법이 어려울 경우에는 시스템을 재시동시키는 수 밖에 없다.



앞에서 소개한 간단한 예들은 인터넷에서 쉽게 구할 수 있는 내부에서 공격에 해당되는 수많은 예들중에서 몇가지 대표적인 것만을 골라 보았다. 이 예들에서 알 수 있듯이 내부에서의 공격은 모두가 시스템이 가기고 있는 리소스를 독점하여서 문제를 야기시키고 있는데 이러한 방법들의 공통적인 문제점은 시스템의 재시동을 재외하고는 현재로서는 확실한 해결책이 없다는 것이다. 운영체제가 보다 더 안전하게(robust) 설계되는 것이 이 문제의 근본적인 해결책이라고 생각된다.




2.2 외부에서의 공격

외부에서 시도되는 DoS 공격은 내부에서의 공격과는 달리 사용자의 실수에 의해서 발생될 수도 있는 여지를 가지고 있지 않다. 이 경우에는 거의 대부분이 실제 목표로하는 시스템을 공격할 목적으로 행해지게 된다.

대부분의 외부에서의 공격은 운영체제에서 제공하는 네트웍 기능을 이용하여 이루어지게 되는데 거의 모든 경우가 특정 포트를 관찰(listen)하고 있는 프로세스를 마비시키거나 오동작하게 하여 시스템의 전체적인 네트웍 기능을 마비시키는 것이다.



외부에서의 공격을 접근 방법에 의해서 임의로 분류해 보았다. 크게 세가지로 나누어 보았는데 서로가 겹치는 부분이 있기 때문에 이 분류가 반드시 옳다고 볼 수는 없다.




응용 프로그램 수준

응용 프로그램 수준이라면 sendmail, talkd, inetd, httpd 등의 응용 프로그램의 정상적인 동작을 하지 못하게 함으로써 시스템의 네트웍 기능을 마비시키는 것이다.



1. Mail Storm(sendmail)

이 경우는 한 호스트에 계속 메일을 보냄으로서 그 호스트의 메일 시스템을 마비시는 것이다. 한 호스트에 집중적으로 메일을 보내면 시스템이 미처 메일을 처리하기도 전에 계속 메일이 오기 때문에 /var/spool/mqueue에 쌓여서 시스템의 부하를 가증시키게 된다. 결국 이로 인해서 시스템의 기능을 마비시키게 되는 것이다. Sun sendmail의 경우에는 시스템의 부하에 상관없이 계속 메일을 받지만 BSD sendmail의 경우에는 시스템의 부하가 어느 정도 올라가 메일을 받는 작업을 중단하게 되므로 가능하면 BSD sendmail을 이용하는 것을 추천하고 싶다.

메일 폭풍이 발생하였을 경우에 이를 위한 해결방안으로는 메일을 보내는 곳과 그 사용자 아이디를 알아내어서(오고 있는 메일의 머리(head)부분을 보면 이 메일이 어디서 오고 있는지를 알 수 있다) 작업을 중단시키게 하거나 현재 시스템의 메일 서비스를 중단하게 하는 방법 뿐이다. 이는 현재 실행중인 sendmail 데몬의 실행을 중단시킴으로써 가능하다.




2. Java Applet

Java applet의 경우에는 실제로 applet 자체가 클라이언트로 전송되어 동작하게 되므로 실제로 클라이언트의 CPU나 메모리를 사용하게 된다. 그러므로 침입자가 CPU나 메모리 리소스를 고갈시키는 applet을 만들어 놓았을때 이 applet이 클라이언트로 전송되어 동작하게 되면 순식간에 클라이언트는 시스템이 마비상태에 이르게 된다. 그래도 이 공격 방법은 침입자가 직접 원하는 호스트를 고르는 것이 아니라 덧을 치고 기다리는 입장이므로 클라이언트가 접속을 할 경우에만 이루어 질 수 있다. 실제로 인터넷에 이러한 applet이 많이 존재하고 있으므로 Java applet을 받아온 후 시스템이 이상한 동작을 하게되면 한번쯤 의심을 해보는 것이 좋다. 이 방법에 대해서는 뾰족한 대안이 없다고 말할 수 있겠다. 추가로 Java applet은 DoS말고도 다른 많은 보안 문제점을 가지고 있는것으로 알려져 있다. 문제점에 대해서는 Java applet의 동작원리를 이해하고 있다면 쉽게 생각해 볼 수 있을 것이다.



3. inetd

inetd 4.1 혹은 인터넷 슈퍼 서버라고도 불리는 이 데몬의 기능은 거의 모든 유닉스에서 공통적인 기능을 수행하도록 구현되어 있다. 그러므로 이 데몬을 올바로 동작하지 못하게 만들 경우에 일반적으로 그 시스템의 네트웍 기능은 거의 마비된다고 볼 수 있다. 그러므로 DoS 공격에서 이 데몬을 공격하여 기능을 상실하게 만드는 침입자는 매우 영리한 침입자라고 볼 수 도 있겠다. 실제로 Solaris 2.4에서 이 버그가 발견되기도 하여 패치가 나오기도 한 경우가 있었다.

그리고 추가로 inetd.conf에는 아래와 같은 내용을 담고 있다.



#

# Echo, discard, daytime, and chargen are used primarily for testing.

#

echo    stream  tcp     nowait  root    internal

echo    dgram   udp     wait    root    internal

discard stream  tcp     nowait  root    internal

discard dgram   udp     wait    root    internal

daytime stream  tcp     nowait  root    internal

daytime dgram   udp     wait    root    internal

chargen stream  tcp     nowait  root    internal

chargen dgram   udp     wait    root    internal



여기서 정의 되어있는 echo, discard, daytime, chargen은 위어서도 설명되어 있겠지만 테스트를 위해서 만들어져 있기 때문에 실제로는 필요하지 않으며, DoS 공격에 이용되기 쉽다. 그러므로 보안을 위해서 이 부분들을 코멘트로 처리하는 것이 좋다. 실제로 이들에 대해서 UDP 패킷 스톰(storm)에 의해 공격당하는 방법이 소개되어 CA-96.01.UDP_service_denial에서 경고하기도 하였다.




패킷 수준

응용 프로그램 수준 보다는 조금더 낮은 수준에서 이루어지는 공격 방법이 될 수 있겠는데 실제로 TCP/IP, 이더넷 층에서 이루어지는 공격방법으로 분류할 수가 있겠다. 이 경우는 실제로 이 층에서 돌아다니는 패킷들을 임의로 조작하여서 목표로 하는 시스템의 네트웍 기능을 마비시키게 하는 것이다. 이는 대부분이 운영체제의 TCP/IP 모듈을 거쳐서 정상적으로 데이타가 패킷형태로 만들어져 전송 되는것이 아니라 SOCK_RAQ(raw socket)를 이용하여 공격자가 직접 임의의 페킷을 조작하여 만들어 보내는 식으로 구현되고 있는데 여기에 대해서는 뚜렷한 대응책이 없다.

이때는 프로토콜과 네트웍 층에 심도있는 이해가 필요하므로 뛰어난 침입자의 경우에 가능한 공격법이지만 이를 위한 소스들을 인터넷이서 쉽게 구할 수 있으므로 요즘에는 초보자들에 의해서도 많이 이루어지고 있다. 이 공격의 대표적인 예로는 SYN Flooding 공격을 들 수 있다.

윈도우에도 업데이트가 있듯이 솔라리스도 업데이트가 있습니다. 이미 잘 아시는 분들도 계시겠지만 도움이 되었으면 합니다.

http://sunsolve.sun.com/private-cgi/show.pl?target=patchk
이 사이트로 가면 패치체크 툴이 있습니다.

우선 첫번째로 패치체크 툴을 다운받구요 , 압축이 되어 있으니 압축을 풀어주세요.

두번째로 cross-reference file을 받는데요.
이게 원래는 TXT라서 그냥 클릭하면 브라우저에서 열려버립니다.
그러니깐 Shift를 누른상태에서 클릭한뒤 Save AS... 하셔서
patchdiag.xref 란 이름으로 패치체크툴의 압축을 해제한곳에 저장합니다.
다운을 받으면은 .xref.txt 파일로 받기 때문에 확장자 .txt 삭제 해야 합니다.
만약 다운로드 받기가 어려우면 첨부파일에 있는 파일을 다운 받아 사용 하면 됩니다.

(e220>root)/data# unzip patchcheck.zip
Archive:  patchcheck.zip
  inflating: patchcheck_1.2.tar.gz 
  inflating: patchdiag.xref         
(e220>root)/data#

  사이트에서 다운 받은 파일을 unzip 으로 압축을 풀고.......

(e220>root)/data#
(e220>root)/data# gunzip -d patchcheck_1.2.tar.gz
(e220>root)/data# tar xvf patchcheck_1.2.tar
x patchcheck_1.2, 0 bytes, 0 테이프 블록
x patchcheck_1.2/COPYRIGHT, 8299 bytes, 17 테이프 블록
x patchcheck_1.2/patchk.pl, 69755 bytes, 137 테이프 블록
x patchcheck_1.2/userguide, 11921 bytes, 24 테이프 블록
(e220>root)/data#

  tar 묶인 파일도 같이 풀어 줍니다.

다음으로 unzip 에 같이 풀었던 patchdiag.xref 파일을 patchcheck_1.2 폴더로 이동 시킵니다.

(e220>root)/data# mv patchdiag.xref patchcheck_1.2

(e220>root)/data# cd patchcheck_1.2
(e220>root)/data/patchcheck_1.2#

(e220>root)/data/patchcheck_1.2# perl patchk.pl -b -l
       
============================= WARNING =============================
The date of the cross-reference (patchdiag.xref) file is Feb/10/06,
while the date reported by your system is Feb/14/06. Processing
of this program will continue, but you may have an out-of-date
cross-reference file. If you are not sure that you have the most
up-to-date cross-reference file, please visit
  http://sunsolve.Sun.COM/private-cgi/patchDownload.pl?target=patchdiag.xref&method=H
or
  ftp://sunsolve.sun.com/pub/patches/patchdiag.xref
to retrieve it, and run this program again.
===================================================================

processing...

위와 같이 perl pathck.pl -b -l 옵션을 주고 실행을 시키면......

The patch report file
  /tmp/patches1139880538.html
has been created. Would you like to open it in your Web browser? (Y|N)Y

Please enter the path to your preferred browser: (enter C to cancel)

There was an error launching the browser.
Please launch the browser manually and load /tmp/patches1139880538.html.
(e220>root)/data/patchcheck_1.2#

하면 웹에서 패치에 대한 정보를 얻어옵니다. 작업이 끝나면, 이파일을 열겠냐고 물어봅니다. yes를 선택합니다.파일이 저장 되는 곳은 /tmp 에 저장이 됩니다. 서버에서 지원하는 네스케이프를 이용 한다면.....열리는 시간이 걸리고.....파일 에러가 나타 납니다.
아니면 클라이언트 PC에서 확인도 가능 합니다.

 설치된 patch 확인.

(e220>root)/data/patchcheck_1.2# showrev -p | grep "113100-01"
Patch: 112785-49 Obsoletes: 113100-01, 113762-02, 112783-01 Requires: 113096-03, 112963-10 Incompatibles:  Packages: SUNWxwfnt, SUNWxwplt, SUNWxwplx, SUNWxwacx, SUNWxwopt, SUNWxwman, SUNWxwpmn, SUNWxwinc, SUNWxwslb, SUNWxwsrv
Patch: 112785-52 Obsoletes: 113100-01, 113762-02, 112783-01 Requires: 113096-03, 112963-10 Incompatibles:  Packages: SUNWxwfnt, SUNWxwplt, SUNWxwplx, SUNWxwacx, SUNWxwopt, SUNWxwman, SUNWxwpmn, SUNWxwinc, SUNWxwslb, SUNWxwsrv

이제부터는 CDE에서 작업을 전부 종료하고, 명령줄로그인을 합니다.
로그인계정은 root로 합니다. 그리고 init s 명령을 내려서 모드를 바꿉니다.
단독사용자 모드로 바꾼뒤에 패치를 하나씩 적용합니다.

(e220>root)/data/patchcheck_1.2#patchadd patch-id
명령어로 하나씩 패치를 해야합니다.
OS가 구버전이거나 혹은 패치가 많다면 상당한 시간이 걸립니다.^^

(e220>root)/data/patchcheck_1.2#patchrm patch-id
이렇게 하면 패치가 제거됩니다.
출처 : 조재구 강사님의 OS SCHOOL

solaris9 version 부터 sshd 가 기본적으로 설치가 되어 보안 통신을 가능하게 합니다.
기존에 telnet,ftp,rsh,rlogin,rcp 등의 프로그램은 snoop 등의 명령을 이용하면
네트웍상의 패킷을 바로 모니터링되어 사용자의 중요한 password 나 정보들을
바로 바로 scan 되어져 정보를 누출 할 수 있지만, 보안shell 을 이용하면 모든 패킷이
암호화 되어 통신되기때문에 안전하게 통신 할 수 있습니다.
이 방법을 사용하기 위해 다음과 같습니다.

1. root 사용자의 권한 설정
- 기본적으로 solaris9 버젼에서는 일반 사용자는 모두 외부에서 보안shell로 
  접속할 수 있지만 root 사용자는 보안shell 로 접근할 수 없습니다.
  그래서 외부에서 자신의 서버로 'root' 사용자로 접근하고 자 할 때
  다음의 파일에서 내용을 수정하고 데몬을 restart 하여야 합니다.

1) sshd 데몬 구성파일 수정

myhost[/] # vi /etc/ssh/sshd_config      <== 파일의 131번째 라인을 수정함
   131: PermitRootLogin yes                   <== "no" "yes" 설정함
                       ---

2) sshd 데몬을 restart 함
myhost[/] # /etc/init.d/sshd  stop         <== 데몬 정지
myhost[/] # /etc/init.d/sshd  start         <== 데몬 시작

3) 원격지 host 에서 접근해 보기
(% 처음 접근시에만 아래와 같이 RSA key 생성함.)

yourhost[/]# ssh myhost
  The authenticity of host 'myhost' can't be established.
  RSA key fingerprint in md5 is: 91:93:40:40:81:fd:7b:40:e4:a2:12:c6:42:e3:cb:ce
  Are you sure you want to continue connecting(yes/no)? yes <== yes선언
Warning: Permanently added 'sun185,203.234.247.185' (RSA) to the list of known hosts.
root@myhost's password: abcdedf       <== myhost 의 root 패스워드 입력

  myhost[/] #                                      <== 접속 완료..



2. 보안 접속 프로그램들
  1) ssh : 보안 shell 로 접속 rsh 과 비슷함.
  - yourhost 에서 myhost 로 접속
   yourhost[/] # ssh myhost
   root@myhost's password: abcdedf
   myhost[/] #

2) scp : 보안 shell 로 접속하여 원격지의 파일을 복사 하기 ,rcp 와 비슷
   yourhost[/] # cd /tmp
   yourhost[/tmp] # scp  myhost:/etc/passwd   .
   root@myhost's password: abcdedf
   passwd 100% |*****************************| 551 00:00

   yourhost[/tmp] # ls -al   passwd

3) sftp : 보안 접속으로 ftp 하기
   yourhost[/] # sftp myhost
   Connecting to myhost...
   root@myhost's password:
   sftp > get /etc/passwd        <== 파일 가져오기
   sftp > exit                           <== 종료 하기

OS에서 설치된 바이너리 실행 파일은 MD5 알고리즘으로 16진수 암호화된 고유 번호를

가지고 있어서 이 번호의 일치 여부로 파일의 변조 여부를 확인할 수 있습니다.


일단 암호화 번호를 알기 위해서는 아래 URL에서 프로그램을 다운 받으세요.


http://sunsolve.sun.com/md5/md5.tar.Z


다운 받은 후 압축을 풉니다.


#> zcat md5.tar.Z | tar xvf -


압축을 푼 다음 다음과 같이 실행합니다.


#> ./md5-sparc /usr/bin/csh

MD5 (/usr/bin/csh) = 00e416f3d48289c0e192a202450c9ada


위 숫자 부분을 복사해서 아래 사이트로 들어가서


http://sunsolve.sun.com/pub-cgi/fileFingerprints.pl


맨 아래 부분에 입력하는 텍스트란에다 넣고 submit 버튼을 누르면 결과가 나옵니다.


정상적인 경우는


Results of Last Search


00e416f3d48289c0e192a202450c9ada - - 1 match(es)
canonical-path: /usr/bin/csh
package: SUNWcsu
version: 11.8.0,REV=2000.01.08.18.12
architecture: sparc
source: Solaris 8/SPARC
patch: 110898-02


변조되거나 훼손된 경우는


Results of Last Search


47762485d0c3e7fe0387421619db3776 - - 0 match(es)
Not found in this database.
이런식으로 나옵니다.


==== 출처 : 솔라리스/해킹/정보보안 테크넷 ====


+ Recent posts