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의 경우 다른 옵션을 가지고 있음.

안녕하세요 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삭제도 가능하다.

백트렉에서 Hydra사용한다.

which hydar

-Web server의 Password를 dictionary Attack을 이용해서 찾으시오

-Web server IP:192.168.41.2

-dictionary File : passwords.txt

기본인증 방식 : hydar이용

기본인증 방식이라 경로 지정 대신 포트로한다.

-V : 자세히

-f 패스워드 찾으면 멈춘다.

이런방식으로도 찾을수 있다.

회원등록 페이지의 ID부분 입력 제한이 12문자로 제한되어 있다.

우회하세요

XSS(Cross site sripting)

Clietn /server 운영

Preface

- 요즘의 웹사잍 과거의 정적인 페이지에서 벗어나 동적인 페이지를 제공

- 동적인 페이지에서는 사용자의 입력을 받아 어떤 작업을 처리하므로 사용자로부터 입력된 데이터를 적절히 검증하지 않으면 보안상 취약점이 발생할 수 있다.

-XSS 공격의 경우 서버를 장악하지 않고도 개인정보를 쉽게 유출할 수 있다.

- 요즘 Web2.0 환경으로 변하면서 JavaScript가 널리 사용됨에 따라 AJAX를 이용한 XSS나 UCC (User Create Contents)에 의한 XSS가 재조명 되고 있다.

XSS (cont)

Main Cause

-사용자로부터 입력된 데이터를 적절한 검증 없이 Web Document로 출력하는 경우 발생

-Attacker가 악성 Script를 입력했다면 Victim은 악성스크립트를 신뢰하는 웹 서버가 보낸 것으로 믿고 실행하게 된다.

-XSS는 서버를 공격하는 것이 아니라 서버를 경유하여 클라이언트를 공격하는 것.

Impact

-Cookie Access

-DOM (Document Object Mode) Access

-Clipboard Access

-Key logging

Type of XSS

Reflective XSS ( non-persistent )

-공격자는 악성 스크립트를 포함한 URL을 Victim에게 노출

-이메일,메신저, 웹 게시판 등을 이용

- 악성스크립트는 서버에 저장되지 않는다.

Stored XSS ( persistent )

-공격자는 악성 스크립트를 XSS에 취약한 웹 서버에 저장

- 웹 게시판, 방명록 등

-공격자는 해당 게시물을 Victim에게 노출시킨다.

XSS에 취약한 페이지 유형

-HTML을 지원하는 게시판

-Search Page

-Personalize Page

-Join Form Page

-Referer 를 이용하는 Page

-그 외 사용자로부터 입력 받아 화면에 출력하는 모든 페이지에서 발생 가능하다.

window XP : 10.10.10.10
web server : 10.10.10.20
ssh server : 10.10.10.22
Attacker : 10.10.10.30
GW : 10.10.10.1

Sniffing을 사용하기위한 선행작업
------------------------------------------------------------------
Router Nat 설정
내부IP : 10.10.10.x // 255.255.255.0
외부IP : DHCP
conf t
access-list 1 permit 10.10.10.0 0.0.0.255
!
ip nat inside source list 1 int f0/1 overload
!
int f0/0
ip nat inside
!
int f0/1
ip nat outside
!
end
------------------------------------------------------------------
icmpush -vv -red -sp [GW] -gw [redi-GW] -dest [Destination] -c host [victime]
ex ) icmpush -vv -red -sp 10.10.10.1 -gw 10.10.10.30 -dest 100.100.100.0 -c host 10.10.10.10
칼리 리눅스는 안되서 hping3으로 대체해야함
ec ) hping3 -1 --icmptype 5 --icmpcode 1 -a 10.10.10.1 --icmp-ipdst 100.100.100.100 icmp-gw 10.10.10.30 --icmp-ipsrc 10.10.10.10
------------------------------------------------------------------
macof ( swich jamming 공격 ) : 스위치를 바쁘게 하여 허브처럼 동작을 하게 만드는 방법 ( 패킷이 가끔 공격자에게 넘어온다 )
------------------------------------------------------------------
victim : 10.10.10.10
GW : 10.10.10.1
attacker : 10.10.10.30
arpspoof -i eth0 -t 10.10.10.10 10.10.10.1 (arp 속이기)
 : 패킷은 보내지지만 도착하지 않기 떄문에 forwarding 필요
echo 1 > /proc/sys/net/ipv4/ip_forward
 : tracert로 확인하면 10.10.10.30을 거쳐가는것이 보임

fragrouter -B1
 : tracert로 확인하면 10.10.10.30을 거쳐가는것이 보이지 않음

[실습] GW와 Host간 전달되는 모든 Packet을 Sniffing 해보고, Sniffing이 가능하지 않게 적절히 방어하세요.
 - 공격 arpspoof -i eth0 -t 10.10.10.10 10.10.10.1
 arpspoof -i eht0 -t 10.10.10.1 10.10.10.10
 fragrouter -B1
 - 방어 arp -s 10.10.10.1 c2-01-21-70-00-00 (host)
 arp 10.10.10.10 000c.2992.f49f arpa (router)

arp를 static으로 설정해도 reboot후 지워진다.
arp static cmd command 를 bat파일로 만든후 시작프로그램에 등록하면된다.
------------------------------------------------------------------
sterm : IP를 속여서 telnet접근을 하는것.
------------------------------------------------------------------
linux에서 설정이 잘 되지 않을때
vi /etc/udev/rules.d/70-persistent-net.rules
------------------------------------------------------------------
가상인터페이스를 만들어서 ssh 접근하기 ( ssh서버는 10.10.10.22 )
ifconfig eth0:0 100.100.100.100 netmask 255.255.255.0 up
ssh -b 100.100.100.100 10.10.10.22

ssh 서버에서 100.100.100.100의 위치를 모르기 때문에
attacker에서 ssh서버의 GW를 자신으로 arpspoof를 하면 된다.
arpspoof -i eth0 -t 10.10.10.22 10.10.10.1
fragrouter -B1
------------------------------------------------------------------
linux에서 통신 통제 ( TCP Wrapper )
/etc/hosts.allow
/etc/hosts.deny
바로 위 처럼 arpspoof를 통해 다른 IP로 ssh접근하는것을 막기위해서는
vi /etc/hosts.deny 로 들어가서
sshd : 100.100.100.100
sshd : 10.10.10.30
을 추가해주면 100.100.100.100 과 10.10.10.30 은 ssh접근이 막힌다.
만약 거부한IP에서 접근을 했을때 tail /var/log/secure 을 보게되면 refused로 거부됐다는것이 기록되어있다.
이것은 다른 IP로 우회할수 있기 때문에 deny보다는 allow에 설정한 후 deny에 모두 차단하는것이 좋다.
allow가 deny보다 우선순위가 높기 때문이다.
모두 선택하려면 all [ ex ) all : all ]
------------------------------------------------------------------
[실습] 위협을 느낀 SSH 서버 관리자가 자신의 IP주소만 접속 할 수 있도록 필터링 정책을 적용했다.
WinXP에서 SSH 서버에 접속하고 적업 중이라 가정한다.
공격자에서 접근 허용되어 있는 IP주소를 알아내고 알아 낸 IP 주소를 이용해 SSH 서버에 접속 가능한지 확인하세요.
현 상황에서의 적절한 방어대책을 수립하세요.
 - 공격 : nmap으로 스캔후 활성화 되어있는 IP로 차례대로 접근해본다. ( nmap -sP 10.10.10.0/24 )
 - 접근방법
1. Attacker에서 가상인터페이스를 만든다. ( ifconfig eth0:0 10.10.10.10 netmask 255.255.255.0 up )
2. arpspoof로 ssh서버의 10.10.10.10 arp를 수정 ( arpspoof -i eth0 -t 10.10.10.22 10.10.10.10 )
3. 접근 ( ssh -b 10.10.10.10 10.10.10.22 )
------------------------------------------------------------------
Window XP : 10.10.10.10/24 || GW : 10.10.10.1
Attacker : 20.20.20.20/24 || GW : 20.20.20.1
hping3 -S 10.10.10.1 -a 192.168.100.1
패킷의 source addr이 192.168.100.1로 변경된 상태에서 10.10.10.1로 전송됨
Router에서 Attacker쪽 포트에 ip verify unicast reverse-path 를 입력
똑같이 hping3을 이용하여 패킷을 보냈을때 Window XP에 패킷이 오지 않음.
------------------------------------------------------------------
Window XP : DHCP
Attacker : 10.10.10.30
Web Server : 10.10.10.20
DNS Server : 10.10.10.22

# Router에서 DHCP 서버 역할 하기
 - 제외할 IP 설정
R1(config)#ip dhcp excluded-address [IP]
 - DHCP 설정
R1(config)#ip dhcp pool [name]
R1(dhcp-config)#network [first_addr] [last_addr]
R1(dhcp-config)#dns-server [IP]
R1(dhcp-config)#default-router [Gateway IP]

ettercap -T -M dhcp:10.10.10.100-200/255.255.255.0/10.10.10.22
Discover패킷이 Broadcast로 전송
Offer패킷을 Attacker가 DHCP서버보다 빠르게 보냄
Request패킷 후 ACK패킷을 Attacker에서 보냄
 - DHCP 원리
1. Client에서 Discorver 패킷을 broadcast로 전송
2. 각 DHCP 서버에서 Offer 패킷을 broadcast로 전송
3. Client에서 Request 패킷을 broadcast로 전송
4. 각 DHCP 서버에서 ACK 패킷을 broadcast로 전송
5. ACK패킷중 제일 먼저 온 패킷을 사용 ( 제일 먼저 할당된 IP 사용 )

vim /usr/local/etc/etter.conf 에서 임대기간을 늘릴 수 있다.
 -> dhcp_lease_time을 늘려주면 된다.
------------------------------------------------------------------

ipsspoofing에서 했던 내용이다.

백트랙으로 가서

백트랙만 접속 가능하게 설정한뒤 단 XP에서는 접속이 안된다.

IP를 속여서 접속

라우터에서 Show user 로 사용자 IP 확인

패킷까지 확인해본다.

백트렉에서 SSH서버로 접근하는데 마치 외부에서 접근하는것 처럼 로그가 남게 접속 해보겠다.

우선 가상의 네트워크를 만들어준 다음

이 IP가 접근한 것 처럼

-b옵션을 써서 SA로 바꿔준다

->패킷이 가기만 가고 돌아오지는 않는다.

돌아오는 패킷을 잡아야하는데 arp를 spooping해줘야한다.

ssh서버에서 게이트웨이를 공격자로 인식하게 설정해야된다.

TCP Wrapper

ls -al /etc/hosts.allow

ls -al /etc/hosts.deny

sshd:100.100.100.100

sshd:10.10.10.30

? 아까와 같이 접속했음에도 불구하고 접속이 차단된다..

다른 IP로 우회 가능하다.

deny보단 allow로 설정