IT정보보안

Traceroute는 ICMP 와 IP 헤더의 TTL필드를 사용한다. TTL필드(time-to- live)는 8 비트 필드로서 송신자는 그 값을 초기화한다. 현재 권고되고 있는 초기값은 구체적으로 64이다. 예전의 시스템은 15에서 32였다.

TTL 필드의 목적은 데이터그램이 전송도중 무한 라우팅 루프에 빠지는 것을 방지하기 위함이다. 예로서 라우터가 스톱하거나 두 라우터간의 접속이 끊겼을 경우 라우팅 프로토콜을 이용해서 잃어버린 경로를 검출하고 그것을 동작시킨다. 이 시간동안 데이터그램이 라우팅루프에서 사라지게 될 수도 있다. TTL필드는 루프를 도는 데이터그램에 상한선을 두게 된다.

만약 라우터가 TTL필드가 0또는 1인 IP 데이터그램을 받았다면, 라우터는 그 데이터그램을 포워드하지 않는다. (이와 같은 데이터그램을 수신한 목적지 호스트는 더 이상 라우트할 필요가 없으므로 이것을 응용 계층으로 보낸다. 그러나 TTL이 0인 데이터그램을 받는 호스트는 거의 없다)

대신에 라우터는 데이터그램을 버리고 원래 호스트에게 ICMP 메시지에 "시간초과"("time exceeded")를 알린다. Traceroute에 있어서의 요점은 ICMP메시지를 포함하고 있는 IP데이터그램이 송신자 주소인 라우터의 IP주소를 포함하고 있다는 것이다.

이제는 Traceroute의 동작에 대해 생각할 수 있을 것이다. 즉 TTL 이 1인 IP 데이터그램을 목적지 호스트에게 보낸다. 데이터그램을 다루는 첫번째 라우터는 TTL을 감소시키고, 데이터그램을 버리고 ICMP 시간 초과를 송신자에게 돌려보낸다. 이것을 통해 경로상에서 첫째 라우터의 위치를 발견한다. 다음에 Traceroute는 TTL 이 2인 데이터그램을 보낸다. 그리하여 두 번째 라우터의 IP 주소를 찾는다. 이것은 목적지 호스트까지 도착할 때까지 계속된다. 그러나 도착한 IP 데이터그램이 TTL 1의 값을 가진다 할 지라도 목적지 호스트는 버리려하지 않고 ICMP시간초과 메시지를 발생시킨다. 왜냐하면 데이터그램은 마지막 목적지에 도착했기 때문이다. 우리는 데이터그램이 어떻게 목적지에 도착했는지 결정할 수 있을까?

Traceroute는 목적지 호스트가 사용하지 않은 것 같은 UDP 포트 번호 (30,000 보다 큰 값)를 선택하여 데이터그램을 보낸다. 이것은 데이터그램이 도착될 때 목적지 호스트의 UDP 모듈이 ICMP "port unreachable" 에러를 발생하게 하는 원인이 된다. 모든 Traceroute는 도착된 ICMP 메시지간에 시간초과(time exceeeded)와 port unreachable를 구별하는 것이 필요하다.

Traceroute 프로그램은 출력 데이터그램의 TTL필드를 설정할 수 있어야 한다. TCP/IP로의 모든 프로그래밍 인터페이스가 이것을 제공하지는 않으며, 모든 구현이 이 능력을 지원하지 않는다. 그러나 대부분의 현재 시스템은 지원하기 때문에 Traceroute를 실행할 수 있다. 이 프로그래밍 인터페이스는 사용자가 슈퍼 유저 권한을 가질 것을 요구한다.

1) Traceroute 실행 결과

1-1) UNIX 환경

사용법: traceroute [ -m max_ttl ] [ -n ] [ -p port ] [ -q nqueries ]

[ -r ] [ -s src_addr ] [ -t tos ] [ -w ] [ -w waittime ]

host [ packetsize ]

옵션:

ㆍ-m

IP 패킷의 최대 time-to-live를 설정하는 옵션으로 기본값은 30 hops 임

ㆍ-n

홉 주소를 숫자로 표현하여 출력

ㆍ-p

사용되는 UDP port 번호(기본 33434)를 지정하는 옵션

ㆍ-r

목적 호스트가 직접 로컬로 연결되었다고 지정하는 옵션. 만약 목 적 호스트가 로컬 세그먼트가 아니면 에러를 보고

ㆍ-s

traceroute를 사용하는 호스트의 IP 주소를 지정(다른 IP로 지정가 능)하는 옵션

ㆍ-t

패킷에 type-of-service를 지정하는 옵션

ㆍ-v

자세하게 보고하는 옵션

ㆍ-w

전송한 패킷을 기다리는 시간을 설정하는 옵션(기본값 : 3초)

다음은 유닉스상에서 Traceroute 프로그램을 이용하여 조선일보의 홈페이지로의 패킷 전송 경로를 추적한 결과이다. 패킷이 무한대로 네트워크를 돌아다니는 것을 막기 위해 30개의 홉을 최대값으로 한다. Traceroute의 출력결과는 순서대로 1, 2, 3의 숫자로 증가하며 매 홉마다 세 개의 패킷을 보내 그 시간을 측정하여 출력한다.

$ traceroute www.chosun.com

traceroute to www1.chosun.com (203.235.118.2), 30 hops max, 40 byte packets

1 fastrouter.seri.re.kr (150.183.10.1) 1.379 ms 0.891 ms 0.716 ms

2 baram-m.seri.re.kr (134.75.99.1) 1.196 ms 1.189 ms 1.176 ms

3 134.75.3.2 (134.75.3.2) 20.614 ms 4.512 ms 14.256 ms

4 krnic (202.30.94.1) 7.094 ms 6.485 ms 5.260 ms

5 KRNIC-INET-GW.ixseoul.net (203.231.82.1) 7.655 ms 8.591 ms 17.544 ms

6 inet-fddi-fm.nuri.net (203.255.114.236) 16.653 ms 10.246 ms 8.361 ms

7 www1.chosun.com (203.235.118.2) 8.725 ms 7.814 ms 10.339 ms

위 결과의 1번 fastrouter.seri.re.kr (150.183.10.1)까지의 도달 시간중 첫번째가 1.379 ms 두번째가 0.891 ms 세 번째가 0.716 ms 만큼의 시간이 걸리는데 그중 첫번째 패킷이 걸린 시간이 두번째와 세번째 패킷이 가는데 걸린 시간보다 큰 것은 처음 목적지인 www.chosun.com을 DNS 에 문의하여 IP를 알아오고 그리고 로컬 라우터의 MAC 주소를 resolv하는데 거리는 시간이 있기 때문이다.

다음은 www.microsoft.com을 Traceroute하였을 때의 결과이다. 마이크로소프트사의 홈페이지로의 패킷 전달 경로를 정확히 아는 것은 매우 어렵다는 것을 다음의 결과로서 알 수 있다. 최대 30개의 홉까지 추적한 결과만을 다음과 같이 출력한다.

$ traceroute www.microsoft.com

traceroute to www.microsoft.com (207.46.130.14), 30 hops max, 40 byte packets

1 fastrouter.seri.re.kr (150.183.10.1) 1.316 ms 0.750 ms 0.796 ms

2 baram-m.seri.re.kr (134.75.99.1) 1.203 ms 1.104 ms 1.295 ms

3 134.75.3.2 (134.75.3.2) 52.014 ms 74.105 ms 49.307 ms

4 oversea-localix-f110-b93.kix.ne.kr(202.30.94.2)15.325 ms 5.288 ms 6.750 ms

5 krnic-inet-localT3.nuri.net(203.231.80.133) 6.590 ms 10.953 ms 19.722 ms

6 203.235.123.5 (203.235.123.5) 12.041 ms 13.303 ms 9.163 ms

7 210.103.218.2 (210.103.218.2) 8.783 ms * 11.408 ms

8 * INET-PA-GW.nuri.net (203.235.119.253) 169.561 ms 170.842 ms

9 * * *

10 * 146.188.147.226 (146.188.147.226) 166.020 ms *

11 * * 189.ATM3-0.TR1.SCL1.ALTER.NET (146.188.147.118) 170.223 ms

12 146.188.137.186 (146.188.137.186) 201.210 ms 206.853 ms 201.061 ms

13 * * 299.ATM7-0.XR1.SEA1.ALTER.NET (146.188.200.109) 203.734 ms

14 146.188.201.33 (146.188.201.33) 202.809 ms 207.260 ms *

15 157.130.177.154 (157.130.177.154) 201.528 ms 205.932 ms *

16 * * *

17 * * *

18 207.46.129.131 (207.46.129.131) 207.073 ms 201.673 ms *

19 * * *

20 * * *

21 * * *

22 * * *

23 * * *

24 * * *

25 * * *

26 * * *

27 * * *

28 * * *

1-2) Windows 환경

사용법 : tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] target_name

옵션 :

ㆍ-d

주소를 호스트 이름에 결합하지 않습니다.

ㆍ-h

maximum_hops 대상을 검색할 홉의 최대 개수입니다.

ㆍ-j

host-list host-list를 따라 원본 경로를 늦춥니다.

ㆍ-w

timeout 각각의 응답 대기 제한 시간(밀리초)입니다.

다음은 Windows95/98 도스창에서 tracert 프로그램을 실행한 결과이다.

C:WINDOWS>tracert www.hitel.co.kr

최대 30개의 홉에서 www.hitel.co.kr [204.252.145.1]로의 경로를 추적하는 중입니다.

1 1 ms 1 ms 1 ms fastrouter.seri.re.kr [150.183.10.1]

2 1 ms 1 ms 1 ms baram-m.seri.re.kr [134.75.99.1]

3 22 ms 22 ms 10 ms gurum.seri.re.kr [134.75.3.2]

4 27 ms 15 ms 18 ms localix-oversea-f50-b91.kix.ne.kr [202.30.94.1]

5 15 ms 23 ms * KRNIC-INET-GW.ixseoul.net [203.231.82.1]

6 12 ms 19 ms * 203.231.82.206

7 10 ms 13 ms 10 ms 210.114.0.66

8 14 ms 10 ms 15 ms www.hitel.co.kr [204.252.145.1]

추적이 완료되었습니다.

2). 관련표준

2-1). 개요 - RFC 792 (ICMP)

TRACERT

: 송신측 컴퓨터로부터 목적지 컴퓨터까지 경로상의 라우터 확인 및 지연 시간 검사

- TRACERT를 실행하는 컴퓨터는 TTL값을 1씩 증가하면서 IP 패킷을 송출

- 라우터들은 수신된 IP 패킷을 다음 라우터로 전달하기 전에 IP헤더의 TTL값을 1 감소

- TTL 값을 1감소 시킨 결과가 0이면 라우터는 그 패킷을 버린 후,

   그 패킷의 송신측 컴퓨터에 time exceeded error ICMP 패킷으로 응답

1. 동작원리

목적지까지 찾아가는 경로를 파악할 수 있음. 그러나 귀환경로를 알려주는 것은 아님. 즉, 목적지에서 출발지로 traceroute 하면 경로가 다를 수 있다.

Win95/98/NT/2K/XP에서는 tracert를 이용. Unix/Linux에서는 traceroute를 이용. (traceroute는 UDP, tracert는 ICMP를 사용) Sam Spade, VisualRoute를 이용하면 보다 시각적으로 결과를 알 수 있음.

Traceroute의 동작원리는 다음과 같음

1.1.1.1에서 목적지 10.10.10.10에 대해 TTL=1인 ICMP echo request를 생성/전달 (기본적으로 3개의 UDP 패킷을 보냄)

첫번째 IP네트웍장비가 TTL을 1을 감소시키고 TTL=0이 되므로 TTL이 모자라 더 이상 packet을 전달할 수 없다는 ICMP time exceeded를 1.1.1.1에게 전달

1.1.1.1에서는 이 ICMP time exceeded를 보고 목적지까지 가는 경로상의 첫번째 장비 ip address와 delay를 알아냄.

1.1.1.1에서 TTL=2인 ICMP echo request를 던짐. 목적지까지 가는 경로상의 두번째 장비가 ICMP time exceeded를 발생시키고 1.1.1.1에서는 이것으로 두번째 장비까지의 delay를 알아냄.

이것이 목적지까지 계속됨

2. * timeout

종종 목적지 중간경로에 있는 장비에서 timeout 현상(별표 *가 나타나는 현상)이 발생하는데 이것이 source와 destination간의 네트웍상태를 정확히 알려주는 것은 아님.

몇몇 IP네트웍장비에서는 ICMP packet이 아닌 다른 일반적인 packet에 보다 많은 시간을 할애하도록 설계된 경우가 있는데 해당 IP네트웍장비가 매우 바쁠경우에는 TTL=0인 packet에 대해서 ICMP time exceed등을 생성/전달하지 않는 경우가 많음. 또는 ICMP 메시지의 우선순위가 매우 낮아서 적절한 시간내에 돌아오지 않는 경우도 있음.

다른 경우는 중간경로에 있는 IP네트웍장비가 아예 ICMP echo reply 혹은 ICMP time exceeded를 발생하지 않는(막는) 경우인데 주로 이러한 장비들은 Firewall 인 경우가 많음. 그러나 Firewall이라고 해서 ICMP echo reply, ICMP time exceed를 생성하지 않는 것은 아니며, 관리자의 설정에 따라 좌우됨. 또한 몇몇 오래된 라우터는 TTL 값이 0 임에도 불구하고 패킷을 계속 전달하는 경우도 있음.

이러한 이유로 traceroute 수행시 중간경로상의 timeout 현상에 대해서는 무시해도 좋으며, 최종목적지와 ping의 상태가 좋은지를 파악하는 것이 보다 중요함.

3. no resolve

traceroute 의 수행상태가 매우 늦게 보여질 때 그 이유는?

source에서 기본적으로 reverse domain name을 점검하기 때문

따라서 noresolve 를 지정하면 결과가 보다 빠르게 보여짐

예)

traceroute –n 164.124.116.4 // UNIX

tracert –d 164.124.116.4 // Windows

[ unix : /usr/sbin ] traceroute 211.169.248.190

traceroute to 211.169.248.190 (211.169.248.190), 30 hops max, 40 byte packets

1 ysnacb81-e4-0.rt.dacom.net (164.124.102.3) 3 ms 1 ms 1 ms

2 211.60.241.2 (211.60.241.2) 1 ms 1 ms 1 ms

3 ysng12bb2-pos7-0.rt.bora.net (210.120.255.117) 1 ms 1 ms 2 ms

4 kidcg5-pos9-0.rt.bora.net (210.120.192.198) 2 ms 3 ms 1 ms

5 kidcg6-ge8-0.rt.bora.net (210.92.194.238) 1 ms 1 ms 1 ms

6 211.169.248.254 (211.169.248.254) 1 ms 1 ms 1 ms

7 211.169.248.216 (211.169.248.216) 2 ms 2 ms 2 ms

8 211.169.248.190 (211.169.248.190) 2 ms 2 ms 1 ms

[ win: /usr/sbin ] traceroute -n 211.169.248.190

traceroute to 211.169.248.190 (211.169.248.190), 30 hops max, 40 byte packets

1 164.124.102.3 3 ms 1 ms 1 ms

2 211.60.241.2 1 ms 1 ms 1 ms

3 210.120.255.117 1 ms 1 ms 1 ms

4 210.120.192.198 1 ms 1 ms 1 ms

5 210.92.194.238 1 ms 1 ms 1 ms

6 211.169.248.254 1 ms 1 ms 1 ms

7 211.169.248.216 2 ms 2 ms 2 ms

8 211.169.248.190 1 ms 1 ms 1 ms

4.

몇 가지 라우팅 문제가 있을 수 있다.

어떤 경우 traceroute는 행의 끝에 느낌표와 한 개의 문자 형식으로 된 추가 메시지를 덧붙인다.

!H, !N, !P 는 각각 호스트, 네트웍, 프로토콜에 도달하지 못했음을 나타냄.

!F 는 패킷 분할이 필요함. !S 는 소스 라우팅 실패를 나타냄.

sol:/hosting/elca% traceroute 210.116.117.100

traceroute 210.116.117.100

traceroute to 210.116.117.100 (210.116.117.100), 30 hops max, 40 byte packets

1 210.116.105.126 (210.116.105.126) 1 ms 1 ms 1 ms

2 203.231.224.246 (203.231.224.246) 1 ms 1 ms 1 ms

3 203.231.224.190 (203.231.224.190) 1 ms !H * 1 ms !H

5. Traceroute Options

-m : Set maximum TTL (default 30)

TTL 필드는 8비트 숫자로 되어 있어 255개 까지 홉을 지정할 수 있다.

대부분의 traceroute 구현은 30개 까지의 홉을 시도하고 중단한다.

-n : Report IP addresses only (not hostnames)

-q : Set the number of queries at each TTL (default 3)

보통 traceroute는 각 TTL 값에 3개의 검사용 패킷을 보내는 데 -q 옵션으로 한 집합 당 패킷의 개수를 변경할 수 있다.

-v : Verbose. 더 많은 정보(Source 주소 및 패킷 크기)를 보여준다.

-w : Set timeout for replies (default 5 sec)

-A : Report AS# at each hop

* 위의 옵션은 Unix (Solaris)를 기준으로 한 것임. Linux나 Windows의 경우 다른 옵션을 가지고 있음.

학생성적관리 프로그램 #C언어 #학생성적관리 #프로그램 #코딩 

#include <stdio.h>

#include <stdlib.h>

#define MAX        10

struct student{

int id;

char name[20];

int kor,eng,math;

};

void init(struct student *std){

int i;

for(i=0;i<MAX;i++){

std[i].id = -1;

}

}

void input(struct student *std){

int i;

for(i=0;i<MAX;i++){

if(std[i].id == -1){

break;

}

}

std[i].id = 100000 + i;

printf("이름 : ");

scanf("%s",std[i].name);

printf("국어 : ");

scanf("%d",&std[i].kor);

printf("영어 : ");

scanf("%d",&std[i].eng);

printf("수학 : ");

scanf("%d",&std[i].math);

}

void output(struct student *std){

int i;

for(i=0;i<MAX;i++){

if(std[i].id==-1){

printf("\n");

}else{

printf("%d | %s | %d | %d | %d |\n",

std[i].id,std[i].name,std[i].kor,std[i].eng,std[i].math);

}

}

}

int main(){

struct student std[MAX];

int menu;

init(std);

while(1){

printf("학생성적관리프로그램\n");

printf("1. 입력\n");

printf("2. 출력\n");

printf("3. 수정/삭제\n");

printf("0. 종료\n");

printf(" > ");

scanf("%d",&menu);

switch(menu){

case 1:

input(std);

break;

case 2:

output(std);

break;

case 3:

break;

case 0:

printf("프로그램을 종료합니다.\n");

exit(0);

break;

}

}

return 0;

}

어나니머스(영어:Anonymous)는 가상의 사회 운동 단체이다.

'어나니머스;라는 명칭은 일부 누리꾼들이 4Chan이라는 웹사이트의 사용자의 기본 이름인 '익명'(Anonymous)인것을

집단을 가리키는 말로 사용하면서 쓰이기 시작했다.

이런 경향에서 2003년부터 정부, 종교, 기업 관련 웹사이트를 공격한 해커들이 어나니머스(Anonymous)라는 집단의 구성원으로서 

지칭하자 어나니머스라는 명칭이 저명성을 갖기 시작했다. 어나니머스에 소속되어 있는 대한민국 회원 중에 

대한민국 국과수 소속으로 추정 되는 해커도 있다는 사실이 드러나면서 큰 관심을 주목받기도 하였다.

어나니머스는 사이버 검열과 감시 반대 운동을 비롯한 사이버 시민 불복종 운동을 목적으로 한다.

즉, 인터넷 행동주의의 한 방편인 핵티비즘(Hacktivism)을 활동 목적의 근간으로 하는 가상 단체.

이러한 어나니머스의 체계에 대해 "지시보다는 오히려 발상에 따라 작동하는 매우 느슨하고 분산된 명령 구조를 가진 하나의 인터넷 사의 모임

이라고 한 사회학자는 설명한다. 

프로그램 설명 오늘날의 보안은 도메인 내부 및 도메인 간 신원 및 ID 데이터의 협업 커뮤니케이션에 달려 있습니다. 고객의 디지털 신원은 종종 서비스에 액세스하고 인터넷을 통해 상호 작용하는 열쇠입니다. Microsoft는 소비자 (Microsoft 계정) 및 엔터프라이즈 (Azure Active Directory) ID 솔루션의 보안과 개인 정보 보호에 많은 투자를했습니다. 우리는 공식 표준 기관 내의 표준 전문가 커뮤니티의 일환으로 강력한 인증, 안전한 사인온, 세션, API 보안 및 기타 중요한 인프라 작업을 촉진하는 신원 관련 사양의 생성, 구현 및 개선에 집중적으로 투자 해 왔습니다. IETF, W3C, 또는 OpenID Foundation과 같은 사용자 인터페이스를 지원합니다. 고객의 보안에 대한 강한 의지를 인정하여 Microsoft Identity Bounty Program을 시작했습니다. 보안 연구원으로 ID 서비스의 보안 취약점을 발견 한 경우 개인 정보를 공개하고 기술 정보를 게시하기 전에 해결할 수있는 기회를 주신 데 대해 감사드립니다. 또한 우리가 공동체에서 정의 할 수 있도록 열심히 노력한 업계 정체성 표준 작업에 대한 우리의 공약에서 우리는 OpenID 표준을 인증 한 구현을 포괄 할 수있는 특혜를 제공합니다. 표준 프로토콜 또는 구현 보너스에 대한 제출은이 현상금 범위에서 완전히 승인 된 신원 표준을 가져야하며 인증 된 제품, 서비스 또는 라이브러리에 구현 된 프로토콜의 보안 취약점을 발견했습니다. 우리는 함께 디지털 신원이 안전하고 안전하다는 확신을 가질 수 있습니다. Microsoft Identity Bounty 프로그램은 여기에 설명 된 법적 조항의 적용을받으며이 프로그램 설명 내에서 수정됩니다.

유자격 제출물은 무엇을 구성합니까? Microsoft Bug Bounty 프로그램은 귀하의 발견에 반영한 연구 결과를 반영하여 고품질의 제출물을 보상하고자합니다. 보고서의 목표는 지식과 전문성을 Microsoft 개발자 및 엔지니어와 공유하여 사용자가 신속하고 효율적으로 결과를 이해하고 재현 할 수 있도록하는 것입니다. 이 방법으로 취약점을 해결할 수있는 배경과 배경이 있습니다. Microsoft에 제공된 취약점 제출은 지불 자격을 얻기 위해 다음 기준을 충족해야합니다. 범위 내에 나열된 Microsoft Identity Services에서 재현되는 원래보고되지 않은 중요하거나 중요한보고를 식별하십시오. Microsoft 계정이나 Azure Active Directory 계정을 인계하는 원래의보고되지 않은 취약점을 확인하십시오. 나열된 OpenID 표준 또는 인증 된 제품, 서비스 또는 라이브러리에 구현 된 프로토콜을 사용하여 원래보고되지 않은 취약점을 식별하십시오. Microsoft Authenticator 응용 프로그램의 모든 버전에 대해 제출하십시오. 그러나 현상금은 최신 공개 버전에 대한 버그가 재생 된 경우에만 지급됩니다. 이슈에 대한 설명과 쉽게 이해할 수있는 간결한 재현성 단계를 포함 시키십시오. (제출을 가능한 한 빨리 처리하고보고되는 ​​취약성 유형에 대해 가장 높은 지불을 지원합니다.) 취약점의 영향을 포함시킵니다. 명백하지 않은 경우 공격 벡터 포함

Scope:

• login.windows.net
• login.microsoftonline.com
• login.live.com
• account.live.com
• account.windowsazure.com
• account.activedirectory.windowsazure.com
• credential.activedirectory.windowsazure.com
• portal.office.com
• passwordreset.microsoftonline.com
• Microsoft Authenticator (iOS and Android applications)*

Standards Scope**:

표준 범위 ** : OpenID Foundation - OpenID Connect 제품군 OpenID Connect Core OpenID Connect Discovery OpenID Connect 세션 OAuth 2.0 복수 응답 유형 OAuth 2.0 양식 게시물 응답 유형 Microsoft 제품 및 서비스 여기에 나열된 인증 구현 (http://openid.net/certification) * 모바일 응용 프로그램의 경우 응용 프로그램 및 모바일 운영 체제의 최신 버전에서 연구를 재현해야합니다. ** 법적 참고 사항 : 신원 표준 실무 그룹에 대한 기고 나 제휴를 맺은 표준 전문가는 표준 관련 현상금을받을 자격이 없습니다.

지불 금액은 어떻게 책정됩니까? 현상금 범위가 500 달러에서 최대 100,000 달러에 이르는 신청에 대한 보상. 높은 지불금은 보고서의 품질과 취약점의 보안 영향에 따라 제공됩니다. 보안 연구원은 가능한 한 가장 높은 지불금 가능성이 높아지도록 제출 시점에 많은 양의 데이터를 제공하는 것이 좋습니다. 중요한 사용자 상호 작용이 필요한 취약성에 대해서는 일반적으로 더 적은 금액을 보상합니다. 서로 다른 당사자가 발행 한 동일한 문제에 대한 여러 버그 보고서를 받으면 첫 번째 제출물에 현상금이 부여됩니다. 중복 보고서가 이전에 Microsoft에 알려지지 않은 새로운 정보를 제공하는 경우 중복 제출을 차등책으로 인정할 수 있습니다. 제출물이 잠재적으로 여러 현상금 프로그램의 대상이 될 경우 단일 현상금 프로그램에서 단일 한 최고 지불금을 받게됩니다. Microsoft는 단독 재량에 따라 제출을 거부 할 권한이 있으며 위의 기준을 충족하지 않는다고 판단합니다.

고품질 제출 기본 품질 제출 불완전한 제출 중요한 인증 우회 최대 $ 40,000 최대 $ 10,000 $ 1,000부터 다중 요소 인증 우회 최대 $ 100,000 최대 $ 50,000 $ 1,000부터 표준 설계 취약점 최대 $ 100,000 최대 $ 30,000 2,500 달러부터 표준 기반 구현 취약점 최대 $ 75,000 최대 $ 25,000 2,500 달러부터 사이트 간 스크립팅 (XSS) 최대 $ 20,000 최대 $ 5,000 $ 1,000부터 교차 사이트 요청 위조 (CSRF) 최대 $ 10,000 최대 $ 3,000 $ 500부터 인증 결함 최대 $ 8,000 최대 $ 4,000 $ 500부터 민감한 데이터 노출 최대 $ 5,000 최대 2,500 달러 $ 500부터

연구 및 고객 데이터에 관한 중요한 정보 독립적 인 보안 연구는 제품과 서비스의 보안에 대한 전반적인 신뢰의 중요한 구성 요소입니다. 그 연구의 일환으로 지역 사회는 이러한 서비스가 지속적으로 고객을 사용하기위한 생산 환경에서 운영되고 실행되고 있음을 인식해야합니다. 우리는 보안 연구원들이 다음을 위해 선의의 노력을 기울 이도록 요청합니다. 연구 중 개인 정보 침해, 데이터 파괴 및 서비스 중단 또는 저하를 피하십시오. 조사하는 동안 고객 데이터를 발견하면 즉시 중지하고 Google에 문의하십시오. 취약점 테스트는 프로그램 참가자가 소유 한 가입 / 계정의 거주자 만 수행해야합니다. 아래 목록에서 <Tenant>는 귀하가 소유하고있는 구독자 중 다른 거주자를 대상으로 테스트를 실행하지 않는 테넌트를 나타냅니다. 서버 측 실행 문제에 대한 개념 증명 (proof of concept) 단계를 넘어서서 (즉, SQL Server에 대한 sysadmin 액세스 권한이 있음을 입증하면

금지 된 보안 연구 방법

보안 연구원이 서비스 범위 내에서 연구 범위를 이해하는 데 도움을주기 위해 다음 방법을 사용할 수 없습니다.

직원들에 대한 피싱 또는 기타 사회 공학 공격을 시도합니다. 이 프로그램의 범위는 지정된 Microsoft Online Services의 기술 취약점으로 제한됩니다.
모든 종류의 서비스 거부 테스트.
상당한 양의 트래픽을 생성하는 서비스의 자동화 된 테스트를 수행합니다.
전적으로 귀하의 데이터가 아닌 모든 데이터에 액세스하십시오. 예를 들어 교차 계정 또는 교차 거주자 데이터 액세스를 시연하고 입증하기 위해 적은 수의 테스트 계정 및 / 또는 시험용 세입자를 만들 수 있으며이를 권장합니다. 그러나 이러한 계정 중 하나를 사용하여 합법적 인 고객 또는 계정의 데이터에 액세스하는 것은 금지됩니다.
이러한 금지에도 불구하고 Microsoft는 악의적 인 것으로 보이는 네트워크상의 모든 작업에 응답 할 수있는 권한을 보유합니다. 의심 스러울 때, 우리의 서비스를 사용하는 고객에게 미칠 수있는 영향을 고려하고 그들의 경험과 데이터를 크게 존중하십시오.

마이크로 소프트 신원 파악을위한 부적절한 제출물은 무엇입니까? 현상금 프로그램의 목적은 사용자와 사용자의 데이터 보안에 직접적이고 명백한 영향을 미치는 심각한 취약점을 밝히는 것입니다. Google 서비스의 보안 취약점을 설명하는 제출을 권장하지만 다음은 현상금 보상을받지 못하는 취약점의 예입니다. 사용자 제작 콘텐츠 또는 응용 프로그램의 취약점. Man in-the-middle (MiTM) 공격을 허용하기 위해 저장소 계정에서 HTTP 액세스를 활성화하는 것과 같이 사용자가 서비스를 잘못 구성하는 보안. 누락 된 HTTP 보안 헤더 (예 : X-FRAME-OPTIONS) 또는 쿠키 보안 플래그 (예 : "httponly") IP, 서버 이름 및 대부분의 스택 추적과 같은 서버 측 정보 유출 서비스 거부 문제 희박한 사용자 작업을 요구하는 취약점 타사 및 고객의 하위 도메인 인수 Microsoft 및 광범위한 보안 커뮤니티에 이미 알려진 공개적으로 공개 된 취약점 갤러리 이미지 및 ISV 응용 프로그램과 같이 Azure에서 제공하는 타사 소프트웨어의 취약점 지원되지 않는 브라우저 및 플러그인에만 영향을주는 웹 응용 프로그램의 취약점 사용자 또는 세입자의 존재를 열거하거나 확인하는 데 사용되는 취약점

ZFW

• Interface마다 Zone을 구분
• (서로 다른 Zone은 통신 불가능)
• Zone들 사이의 통신은 관리자의 설정을 통해서 가능
• CPL(cisco policy Language)기반
• Stateful

• 작업의 순서

1. Zone 생성
2. Interface에 zone 할당(중복 할당 가능)
3. Zone-pair 생성 (하나의 zone에서 다른zone을 전송되는 흐름)
4. Class-map / policy-map생성
5. Zone-pair에 policy-map 적용

Vm2 10.10.2.10 windown 2000

Windown XP

R2

Config-sec-zone

Zone security INSIDE

OUTSIDE

DMZ

Int f 0/0

Zone-meber security OUTSIDE

Int f 0/1

Zone-member security INSIDE

F 1/0

Zon-member security DMZ

Show zeon

Conf t

Zon-pair se in->out se INSIDE de OUTSIDE

ACCE

CLASS0MAP TYPE INSPECT ALL_T

MATCH PROTOCOL HTTP

SLASS-MAP DNS_T

MATCH-ALL

MATCH ACCESS-GROUP 101

MATCH PROTOCOL HTTP

MATCH CLASS-MAP DNS_T

POLICY-MAP TYPE INS SPECT IN->OUT_P

CLASS TPE INSPECT ALL_T

INSPECT

POLICY-MAP TYPE INSPECT IN->DMZ_P

CLASS TYPE INSPECT HTTP_DNS_T

INSPECT

POLICY-MAP TYPE INSPECT OUT->DMZ-P

CLASS TYPE INSPECT HTTP_DNS_T

INSPECT

CLASS TYPE INSPECT SSH_T

INSPECT

 POLICY-MAP TYPE INSPECT DMZ->OUT_P

INSPECT

ZONE-PAIR SE IN->OUT

SERVICE-POLICY TY INS IN->OUT_P

SECURITY IN->DMZ

SERVI-POLICY TYE INS IN->DMZ_P

ZONE-PAIR SECURITY DMZ->OUT

SERVI -POLICY TY INS DMZ-OUT_P

SHOW ZONE-PAIR SECURITY

안녕하세요 CodeYK입니다. 

정보시스템보안이란 무엇일까요?

정보시스템 보안(Information System Security)의 정의

정보시스템 보안(Information System Security) 이란 정보시스템 운영 및 관리 안정성 등에 반하는 위험으로부터, 정보시스템의 기밀성,무결성,가용성,신뢰성 등을 확보하기 위한 제반 수단과 활동 체계

정보시스템 보안의 이해

정보시스템 보안은 대략 2003년을 기점으로 대학에서 하나의 과목을 개설 증대, 독자 분야 형성

정보시스템 보호 실패에 따른 대형 사고가 증대함에 따라 정보시스템보안의 중요성 점차 증대

정보시스템 보안 범위

창과 방배의 한자인 모순에서 보듯이 어떤 방패도 뚫을 수 있는 창과, 모든 창을 막을 수 있는 방패는 동시에 존재하기 힘들다.

하지만 시스템에 위협을 가하려는 해커와 불순 세력이 있는 한, 모든 위협으로부터 안전한 정보시스템을 구축해야 하기 때문에 정보시스템보안 분야는 점차 확대되고, 계속 발전될 것이다. 

정보시스템 보안 범위는 정보시스템 보안의 기본지식과 정보시스템의 관리적인 부분, 시스템, 네트워크, 데이터베이스 등 기술적 범위, 그리고 사회적인 보안 이슈에 대해 폭 넓게 다르고 있다. 

정보 보호 (Information Security)

정보 보호의 정의

정보의 생성, 처리, 저장, 전송, 출력 등 정보 순환의 모든 과정에서 정보의 기밀성, 무결성, 가용성, 책임 추적성, 인증성, 신뢰성을 확보하기 위한 제반 수단과 활동

"정보 보호"라 함은 정보의 수집, 가공, 저장, 검색, 송신, 수신 중에 정보의 훼손, 변조, 유출 등을 바지하기 위한 관리적, 기술적 수단을 강구하는 것(정보화 촉진 기본법 2조 용어 정의)

정보 보호의 필요성

1) 전자 상거래, 전자 정보 등 사이버 공간에서의 활동 증가에 따른 안전 신뢰성 해결

개인 프라이버시 보장

정보 범죄의 차단

2)글로벌화에 따른 국내 정보 유출 우려

3)국제 해커 및 적성국에 의한 정보 테러 차단

4)정보화된 국가 중요 기반에 대한 보호 필요

5)정보화 사회 완성의 필수 불가결한 요소

SNMP (Simple Network Management Protocol)

-네트워크 관리를 위한 프로토콜

-Manager 와 Agent의 구조로 이루어져 있따.

-Manager : Agent로부터 정보를 제공 받는다

-Agent : Agent가 설치된 시스템의 정보나 네트워크 정보등을 수집하여 MIB형태로 보관

SNMP 데이터 수집 방법

->네트워크를 관리하기 위한 프로토콜이다.

SNMP Version 

->버전의 취약점을 이용한다.

NMS (Network Managemenet System)

-네트워크 상의 자원들을 모니터링하고 제어하기 위한 시스템으로 일반적으로 스위치나 라우터 같은 네트워크 장비들을 관리

-Agent들과 Manager간 정보 교환을 위해 표준화 된 프로토콜인 SNMP나 CMIP등을 사용한다

CMIP (Common Management Information Protocol)

-SNMP와 같은 네트워크 관리 프로토콜

-SNMP보다 시스템 리소르를 많이 소모하는 단점이 있으나, 보안성이 우수하고 능률적으로 네트워크를 관리할 수 있다.

-구조가 너무 복잡해서 사용되지 않는다.

->트리구조로 되어 있다.

SNMP 서비스 탐지

-UDP Port Scanning

nmap -sU -p 161 <IP address>

UDP Scanning의 경우 방홥화벽에 차단되거나 패킷이 유실될 수 있으므로 100% 신뢰할 수 없다.

-SNMP Get Message를 보내는 툴 이용 

cisco -torch.pl -u 192.168.3.254

-community string을 public으로 설정해서 요청하므로 public이 아닌 경우에는 알아낼 수 없다.

Community String 획득

-Community String 획득

-SNMP를 잉이용하여 정보를 수집하거나 설정 값을 변경하기 위위해서는 인증에 설공해야 한다.

-SNMPv1 과 SNMPv2c는 Community String을 이용하여 인증을 수행하므로 Community String을 획득 해야 한다.

-Community String 획득 방법

-Default Community String

-Brute Forcing / Dictionary Attack

-Sniffing

->암호화가 되어 있찌 않으므로 

-net-snmp를 이용하여 시스템의 정보를 수집

snmpwalk -v 2c -c <community> <ip> system

snmpwalk -v 2c -c <community> <ip> interface

snmpwalk -v 2c -c <community> <ip> at

snmpwalk -v 2c -c <community> <ip> ip

snmpwalk -v 2c -c <community> <ip> icmp

snmpwalk -v 2c -c <community> <ip> tcp

snmpwalk -v 2c -c <community> <ip> udp

snmpwalk -v 2c -c <community> <ip> 1.3.6.1.2.1.1.2

etc..

CSRF의 특징

-Victim에 의해 Request가 발생하기 때문에 공격자의 IP 추적이 어렵다.

-XSS와 달리 자바스크립트를 사용할 수 없는 상황에서도 공격이 가능

공격조건

-공격자는 사이트에서 제공하는 해당 기능의 Request/Response를 분석해야 한다.

-사이트가 Session Token만으로 해당 기능의 권한을 인증하고 있을 때 가능

CSRF (Cross site Request Forgery)

-a.k.a XSRF

-Pronounce C-Surf

-One-click Attack / Zero-click Attack

-사이트에서 제공하는 기능을 신뢰된 사용자의 권한으로 요청하도록 하는 공격

-공격자는 악성코드를 읽은 Victim은 자신도 모르게 Request를 서버로 보내게 되고, 서버는 Victim의 권한으로 Request에 대한 처리를 하게 된다.

-즉 Session Hijacking과 유사한 권한 도용 공격이다.

공격의 범위

-서버에서 지원하는 모든 기능이 공격범위가 될 수 있다.

-DB를 모두 삭제하는 기능을 관리자에게 지원한다면 공격자는 이 공격을 이용해서 DB삭제도 가능하다.