서버에서 클라이언트로 TCP 접속을 시도하거나 UDP 패킷을 보낸 후 리턴되는지를 조사하면 어떨까요?
1. 클라이언트가 서버로 TCP로 접속한 후, 고유의 번호를 클라이언트로 전송한다.
2. 서버는 클라이언트의 접속 정보를 이용해서 고유의 번호를 담은 UDP 패킷을 클라이언트로 보낸 후 되돌아 오는 패킷을 대기한다.
3. 클라이언트는 서버에서 보낼 고유의 번호를 담은 UDP 패킷을 기다리고, 받으면 서버로 전송한다.
4. 일정시간 후 패킷이 오지 않으면 몇번 더 2~3번 과정을 반복한다.
5. 방화벽 존재를 판별한다.
서버에서 클라이언트쪽의 방화벽 존재 여부를 알 필요가 없다면 클라이언트가 패킷을 되돌려줄 필요는 없을 것입니다.
하지만, 이런식으로 하면, 뚫린 UDP 같은 것이 있을 수도 있으니 그런 경우는 어쩔 수 없을거구요.
방화벽 존재 여부를 확실히 판단할 수는 없습니다.
다만 몇가지 상황에선 방화벽의 존재 여부를 알 수는 있습니다.
예를 들어 연결 가능한 포트가 존재한다고 했을 때(TCP 80 같은),
다른 포트로 접속 시도를 하여 RST 패킷이나 ICMP error 메시지가
전달되지 않고 connect에서 timeout이 발생하면
중간에 방화벽이 해당 SYN 패킷을
blocking한것이므로 중간에 방화벽이 있다고 판단할 수 있습니다.
(다만 방화벽 설정 여부에 따라 방화벽에서 SYN패킷을 blocking한 후
RST 패킷을 전달 할 수도 있습니다.)
서버에서 클라이언트로 TCP 접속을 시도하거나 UDP 패킷을 보낸 후 리
서버에서 클라이언트로 TCP 접속을 시도하거나 UDP 패킷을 보낸 후 리턴되는지를 조사하면 어떨까요?
1. 클라이언트가 서버로 TCP로 접속한 후, 고유의 번호를 클라이언트로 전송한다.
2. 서버는 클라이언트의 접속 정보를 이용해서 고유의 번호를 담은 UDP 패킷을 클라이언트로 보낸 후 되돌아 오는 패킷을 대기한다.
3. 클라이언트는 서버에서 보낼 고유의 번호를 담은 UDP 패킷을 기다리고, 받으면 서버로 전송한다.
4. 일정시간 후 패킷이 오지 않으면 몇번 더 2~3번 과정을 반복한다.
5. 방화벽 존재를 판별한다.
서버에서 클라이언트쪽의 방화벽 존재 여부를 알 필요가 없다면 클라이언트가 패킷을 되돌려줄 필요는 없을 것입니다.
하지만, 이런식으로 하면, 뚫린 UDP 같은 것이 있을 수도 있으니 그런 경우는 어쩔 수 없을거구요.
그럼, 이만...
방화벽 존재 여부를 확실히 판단할 수는 없습니다.다만 몇가지 상황에선
방화벽 존재 여부를 확실히 판단할 수는 없습니다.
다만 몇가지 상황에선 방화벽의 존재 여부를 알 수는 있습니다.
예를 들어 연결 가능한 포트가 존재한다고 했을 때(TCP 80 같은),
다른 포트로 접속 시도를 하여 RST 패킷이나 ICMP error 메시지가
전달되지 않고 connect에서 timeout이 발생하면
중간에 방화벽이 해당 SYN 패킷을
blocking한것이므로 중간에 방화벽이 있다고 판단할 수 있습니다.
(다만 방화벽 설정 여부에 따라 방화벽에서 SYN패킷을 blocking한 후
RST 패킷을 전달 할 수도 있습니다.)
不狂不及
방법이 있는거 같은데요.syn 플러드 공격을 네트웍의 게이트 웨이
방법이 있는거 같은데요.
syn 플러드 공격을 네트웍의 게이트 웨이로 날려 보는 거죠. -_-
물론 이건 크래킹 시도로 간주 될 수 있습니다.
요즘 방화벽들이 syn플러드 공격에 대해서 대비를 하기때문에 방화벽이 있다면 이 공격에 버틸겁니다.
좀 과격한 가요. ㅎ ㅎ ㅎ ㅎ
새해 복받으세요.
Do you think that's the air you are breathing now?
댓글 달기