ike-scan

IKE 호스트(IPsec VPN 서버)를 탐색하고 지문을 식별합니다.

빌드 및 설치

ike-scan은 표준 GNU autoconf 및 automake 도구를 사용하므로 설치 절차는 일반적입니다:

git clone https://github.com/royhills/ike-scan.git를 실행하여 프로젝트 소스 코드를 가져옵니다.
cd ike-scan을 실행하여 소스 디렉터리로 이동합니다.
autoreconf --install을 실행하여 사용 가능한 ./configure 파일을 생성합니다.
./configure 또는 OpenSSL 라이브러리를 사용하려면 ./configure --with-openssl을 실행합니다.
make를 실행하여 프로젝트를 빌드합니다.
make check를 실행하여 모든 것이 정상적으로 작동하는지 확인합니다.
make install을 실행하여 설치합니다(이 부분에는 root 또는 sudo 권한이 필요합니다).

사전 공유 키 크래킹을 수행할 계획이라면 ike-scan이 내장 함수 대신 OpenSSL 해시 함수를 사용하도록 구성하는 것이 좋습니다. OpenSSL 함수가 일반적으로 더 빠르기 때문입니다. 이를 위해 OpenSSL include 파일과 라이브러리가 설치되어 있는지 확인하고 ./configure --with-openssl로 configure를 실행하십시오. OpenSSL 사용 여부는 ike-scan의 기능에 영향을 미치지 않으며, psk-crack을 이용한 사전 공유 키 크래킹 속도에만 영향을 줍니다.

일부 운영 체제는 OpenSSL 헤더와 라이브러리를 기본적으로 설치합니다. 다른 운영 체제는 선택적 패키지를 설치해야 합니다. 예를 들어 Debian Linux에서는 libssl-dev 패키지를 설치해야 합니다. 또는 http://www.openssl.org/ 에서 OpenSSL tarball을 다운로드하여 설치할 수 있습니다.

대부분의 최신 Unix 계열 OS에서 빌드되어야 합니다. Cygwin이 설치된 Windows에서도 작동하며, cygwin1.dll이 있는 경우 독립 실행형 Windows 실행 파일로 사용할 수 있습니다.

Windows-32 바이너리 패키지를 사용하는 경우, Windows 플랫폼에서 실행할 때의 차이점을 설명하는 README-WIN32 파일도 함께 읽어 주시기 바랍니다.

이 프로그램은 Linux, FreeBSD, OpenBSD, NetBSD, Win32/Cygwin, Solaris, MacOS X, HP Tru64, HP-UX, SCO OpenServer에서 빌드 및 실행되는 것으로 알려져 있습니다. 자세한 내용은 아래 "지원 플랫폼" 섹션을 참조하십시오.

개요

ike-scan은 IKE 호스트를 탐색하고 재전송 백오프 패턴을 사용하여 지문을 식별할 수도 있습니다.

ike-scan은 다음 기능을 수행할 수 있습니다:

탐색 주어진 IP 범위에서 IKE를 실행 중인 호스트를 확인합니다. 이는 ike-scan이 보낸 IKE 요청에 응답하는 호스트를 표시하여 수행됩니다.
지문 식별 호스트가 사용하는 IKE 구현을 확인하고, 경우에 따라 실행 중인 소프트웨어 버전을 확인합니다. 이는 두 가지 방식으로 수행됩니다. 첫째, UDP 백오프 지문 식별: 대상 호스트의 IKE 응답 패킷 시간을 기록하고 관찰된 재전송 백오프 패턴을 알려진 패턴과 비교합니다. 둘째, 벤더 ID 지문 식별: VPN 서버의 벤더 ID 페이로드를 알려진 벤더 ID 패턴과 비교합니다.
변환 열거 VPN 서버가 IKE Phase-1에서 지원하는 변환 속성(예: 암호화 알고리즘, 해시 알고리즘 등)을 찾습니다.
사용자 열거 일부 VPN 시스템의 경우 유효한 VPN 사용자 이름을 발견합니다.
사전 공유 키 크래킹 사전 공유 키 인증을 사용하는 IKE 공격 모드에 대해 오프라인 사전 또는 무차별 대입 암호 크래킹을 수행합니다. 이는 ike-scan을 사용하여 해시 및 기타 매개변수를 얻고, psk-crack(ike-scan 패키지의 일부)을 사용하여 크래킹을 수행합니다.

재전송 백오프 지문 식별 개념은 ike-scan 키트에 포함된 UDP 백오프 지문 식별 논문에서 더 자세히 설명됩니다.

이 프로그램은 지정된 호스트에 IKE phase-1(Main Mode 또는 Aggressive Mode) 요청을 보내고 수신된 모든 응답을 표시합니다. 패킷 손실에 대처하기 위해 재시도 및 백오프를 통한 재전송을 처리합니다. 또한 나가는 IKE 패킷에 사용되는 대역폭을 제한합니다.

IKE는 IPsec에서 사용하는 키 교환 및 인증 메커니즘인 인터넷 키 교환(Internet Key Exchange) 프로토콜입니다. 거의 모든 최신 VPN 시스템은 IPsec을 구현하며, 대부분의 IPsec VPN은 키 교환에 IKE를 사용합니다. Main Mode는 IKE 교환의 phase-1에 대해 정의된 모드 중 하나입니다(다른 정의된 모드는 Aggressive Mode입니다). RFC 2409 섹션 5는 main mode를 구현해야 한다고 명시하므로 모든 IKE 구현이 main mode를 지원할 것으로 예상됩니다. 많은 구현에서 Aggressive Mode도 지원합니다.

사용법

현재 사용법 정보를 보려면 다음과 같이 ike-scan 바이너리를 실행하십시오:ike-scan -h

Additional documentation is provided on the NTA Monitor Wiki

To report bugs or suggest new features, please create a GitHub issue.

Implementation Details

Host Input and Memory Requirements

The hosts to scan can be specified on the command line or read from an input file using the --file=<fn> option. The program can cope with large numbers of hosts limited only by the amount of memory needed to store the list of host_entry structures. Each host_entry structure requires 45 bytes on a 32-bit system, so a class B network (65534 hosts) would require about 2.8 MB for the list. The hosts can be specified as either IP addresses or hostnames, however the program will store all hosts internally as IP addresses and will only display IP addresses in the output (ike-scan calls gethostbyname(3) to determine the IP address of each host, but this can be disabled with the --nodns option).

Rate Limiting

The program limits the rate at which it sends IKE packets to ensure that it does not overload the network connection. By default it uses an outbound data rate of 56000 bits per second. This can be changed with the --bandwidth option.

If you want to send packets at a specific rate, you can use the --interval option.

ike-scan generates unique IKE cookies for each host, and it uses these cookies to determine which host the response packets belong to. Note that it does not rely on the source IP address of the response packets because it is possible for a response packet to be sent from a different IP address than it was originally sent to. See the PROGRAM OUTPUT section for an example of this.

The cookies are generated by taking the first 64 bits of an MD5 hash of the current time in seconds and microseconds as returned by gettimeofday(), the unique host number, and the host IP address. This ensures that the cookies are unique with a reasonable degree of certainty.

If --verbose is in effect, any packets that are received with cookies that do not match will result in a message like:

Ignoring 84 bytes from 172.16.2.2 with unknown cookie 195c837e5a39f657 If --verbose 옵션이 활성화되지 않은 경우, 이러한 패킷은 자동으로 무시됩니다.

이러한 쿠키 불일치는 다음과 같은 이유로 발생할 수 있습니다:

호스트가 이전 ike-scan 실행에 대한 IKE 응답을 계속 반환하고 있는 경우;
패킷이 IKE 패킷이 아니거나 어떤 방식으로든 손상된 경우; 또는
ike-scan과 관련 없는 IKE 패킷이 수신된 경우.

IKE 패킷 상세 정보

전송되는 메인 모드 패킷에는 ISAKMP 헤더와 SA 페이로드가 포함됩니다. SA 페이로드는 단일 제안을 포함하며, 제안은 아래에 설명된 대로 가변적인 수의 변환(transform)을 포함할 수 있습니다.

기본적으로 SA 제안은 8개의 변환을 포함합니다. 이 8개의 변환은 다음의 모든 가능한 조합을 나타냅니다:

암호화 알고리즘: DES-CBC 및 3DES-CBC;
해시 알고리즘: MD5 및 SHA-1;
DH 그룹: 1 (MODP 768) 및 2 (MODP 1024).

기본 변환 세트를 사용하여 ike-scan이 전송한 메인 모드 패킷의 예시 tcpdump 출력은 아래와 같습니다. 이는 8개의 변환과 전송 순서를 보여줍니다:

16:57:16.024536 192.168.124.8.500 > 172.16.2.2.500:  [udp sum ok]isakmp 1.0 msgid 00000000: phase 1 I ident:
  (sa: doi=ipsec situation=identity
    (p: #1 protoid=isakmp transform=8
      (t: #1 id=ike (type=enc value=3des)(type=hash value=sha1)(type=auth value=preshared)(type=group desc value=modp1024)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080))
      (t: #2 id=ike (type=enc value=3des)(type=hash value=md5)(type=auth value=preshared)(type=group desc value=modp1024)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080))
      (t: #3 id=ike (type=enc value=1des)(type=hash value=sha1)(type=auth value=preshared)(type=group desc value=modp1024)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080))
      (t: #4 id=ike (type=enc value=1des)(type=hash value=md5)(type=auth value=preshared)(type=group desc value=modp1024)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080))
      (t: #5 id=ike (type=enc value=3des)(type=hash value=sha1)(type=auth value=preshared)(type=group desc value=modp768)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080))
      (t: #6 id=ike (type=enc value=3des)(type=hash value=md5)(type=auth value=preshared)(type=group desc value=modp768)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080))
      (t: #7 id=ike (type=enc value=1des)(type=hash value=sha1)(type=auth value=preshared)(type=group desc value=modp768)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080))
      (t: #8 id=ike (type=enc value=1des)(type=hash value=md5)(type=auth value=preshared)(type=group desc value=modp768)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080)))) (DF) (ttl 64, id 0, len 364)```

이 기본 변환 세트는 대부분의 IKE 구현에서 수용할 수 있도록 설계되었습니다. 대부분은 제시된 변환 중 적어도 하나를 수락할 것입니다. 그러나 때로는 다른 인증 방법(사전 공유 키가 가장 일반적이지만 항상 지원되는 것은 아님)을 사용해야 하며, 가끔 256비트 AES와 같은 다른 암호를 지정해야 할 수도 있습니다. 더 드물게는 수명(lifetime)을 변경해야 할 수도 있습니다. 마지막으로, 일부 구현에서는 클라이언트가 응답하기 전에 특정 "Vendor ID" 문자열을 전송하도록 요구합니다. 이는 --vendor 옵션으로 지정할 수 있습니다.

기본 변환 세트는 패킷 데이터 길이가 336바이트이며, IP 및 UDP 헤더가 추가되면 총 패킷 크기는 364바이트가 됩니다.

--auth 옵션으로 인증 방법을 지정할 수 있으며 (기본값은 1 - 사전 공유 키), --lifetime 옵션으로 IKE 수명을 초 단위로 지정할 수 있습니다 (기본값은 RFC 2407 권장값인 28800초 또는 8시간). --lifetime을 0으로 지정하면 수명 속성이 변환 페이로드에 포함되지 않습니다. 사용자 정의 변환을 지정하는 경우 이 옵션을 여러 번 사용하여 다른 수명을 가진 변환 페이로드를 생성할 수 있습니다. 각 --trans 옵션은 이전에 지정된 수명 값을 사용합니다.

--trans=e[/l],h,a,g 형태로 사용자 정의 변환 세트를 지정할 수 있습니다. 여기서 "e"는 암호화 알고리즘, "l"은 가변 길이 암호의 키 길이, "h"는 해시 알고리즘, "a"는 인증 방법, "g"는 DH 그룹입니다. 이들은 숫자 값으로 지정됩니다. 사용할 값에 대한 자세한 내용은 RFC 2409 부록 A를 참조하십시오.

예: --trans=5,2,1,2는 다음을 지정합니다:Enc=5 (3DES-CBC), Hash=2 (SHA1), Auth=1 (shared key), DH Group=2 (modp 1024)

and --trans=7/256,1,1,5 specifies: Enc=7 (AES), Keylen=256 bits, Hash=MD5, Auth=shared key, DH Group=5 (modp 1536) --trans 옵션을 여러 번 사용하여 제안서에 원하는 수의 사용자 정의 변환을 보낼 수 있습니다.

사용자 정의 변환 세트를 지정하면 --auth로 지정된 모든 인증 방법이 무시됩니다. 그러나 마지막 --lifetime 옵션에 지정된 수명 값은 계속 사용됩니다.

복잡한 사용자 정의 변환 세트의 예는 다음과 같습니다:--trans=5,2,1,2 --lifetime=0 --trans=7/256,1,3,5 --lifetime=600 --trans=7/128,1,3,5

This would specify the following three transforms:

3DES Encryption with SHA1 hash, shared key authentication, DH group 2, and the default lifetime;
256-bit AES Encryption with MD5 hash, RSA authentication, DH group 5, and no lifetime; and
128-bit AES Encryption with MD5 hash, RSA authentication, DH group 5, and lifetime of 600 second.

If a custom transform set is specified, the packet length will differ from the default. Fewer than 8 transforms will make it smaller, and more than 8 transforms will make it larger. If the packet size exceeds the MTU, then it will be fragmented. You may need to increase the --interval setting for large packets to avoid overloading your network connection. Some VPN servers may ignore very long packets.

A custom transform can be useful in the following situations:

If none of the transforms in the default transform set is acceptable to the remote IKE implementation;
If you know that a particular transform will be acceptable, and you want to minimise bandwidth use or allow faster scanning rates; or
If you want to determine exactly which transforms a remote IKE implementation supports for fingerprinting.

The default mode used is Main Mode. However, it is possible to specify Aggressive Mode with the --aggressive option. When this is done, three additional payloads will be included: Key Exchange, Nonce and ID. This will increase the packet size, and you may need to increase --interval to ensure that ike-scan doesn't try to use too much bandwidth as a result. If you use Aggressive Mode, you can also use the following options:

--id Set identification value.
--idtype Set identification type (Default 3 (ID_USER_FQDN)).
--dhgroup Specify Diffie-Hellman group (Default 2 - MODP 1024).

If you use Aggressive Mode, then you can only use one Diffie Hellman group in the transform set. If you specify custom transforms with the --trans option, you should ensure that they all use the same group, and that this group matches the DH group specified with the --dhgroup option, or the default of 2 if --dhgroup is not specified.

IKE hosts may respond in one of two ways:

With an IKE main or aggressive mode response packet containing the cookie that was originally sent to the host. This is a "handshake" response and indicates that the host supports IKE and finds our proposal acceptable; or
With an IKE notify message containing the cookie that was originally sent to the host. This is a "notify" response and indicates that the host is running IKE, but does not accept our proposal.

An example tcpdump output for a "handshake" response is:

16:57:48.068698 172.16.2.2.500 > 192.168.124.8.500:  [udp sum ok]isakmp 1.0 msgid 00000000: phase 1 R ident:
  (sa: doi=ipsec situation=identity
    (p: #1 protoid=isakmp transform=1
      (t: #1 id=ike (type=enc value=3des)(type=hash value=sha1)(type=auth value=preshared)(type=group desc value=modp1024)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080)))) (ttl 126, id 37891, len 112)

This shows that the IKE host has responded with an ISAKMP header and an SA payload containing a single proposal. This proposal contains a single transform representing the transform chosen from the proposal sent by ike-scan.

An example tcpdump output for a "notify" response is:

17:12:55.038554 192.168.89.22.500 > 192.168.37.1.500:  [udp sum ok]isakmp 1.0 msgid 00000000: phase 1 R inf:
  (n: doi=0 proto=1 type=NO-PROPOSAL-CHOSEN) (ttl 52, id 39577, len 68)

This shows that the IKE host has responded with an ISAKMP header and a notify payload. The notify payload is an informational message with the type "NO-PROPOSAL-CHOSEN".

ike-scan does not respond to any of the IKE responses it receives, so the IKE main mode handshake will never complete. Some IKE implementations do not log handshakes that don't complete; these implementations will not log the scanning and therefore the owners of these systems will not be aware of the scanning. It is possible to use ike-scan to determine if a given implementation will log these scanning attempts if you have access to the system logs.

Backoff Fingerprinting

For those hosts that respond, ike-scan records the times of the received IKE responses. The backoff between IKE responses varies between different IKE implementations and can therefore be used as a fingerprint. The --showbackoff option is used to display the backoff times for each host which responded. Note that using the --showbackoff option will cause ike-scan to wait for 60 seconds after the last received packet to ensure that it has seen all of the responses. This 60 second wait can be altered by specifying a different value in seconds to the --showbackoff option.

When all of the packets have been received, the backoff table is displayed, and the program attempts to match the backoff pattern against the known backoff patterns contained in the text file ike-backoff-patterns. It is possible to add new patterns to this file.

Note that only hosts which respond with a handshake can be fingerprinted by backoff timings; hosts which respond with a notify message cannot. This is because notify messages are only ever sent once and are not subject to retransmission with backoff.

If you discover IKE hosts with backoff patterns which are not recognised by ike-scan, then you are encouraged to submit the pattern and details of the IKE implementation to me so I can incorporate it into future versions of ike-scan. You can do this by opening an issue, or a pull request on github.

Note that any packet loss will prevent the backoff fingerprinting from working because the program needs to see all of the responses.

ike-scan can also be used to fingerprint IKE hosts in other ways. For example:

Some systems (such as Checkpoint Firewall-1) allow the use of any source port (e.g. --sport=0) whereas others (e.g. Windows 2000) only respond to IKE requests from source port 500 (actually, Windows 2000 responds to requests from any port, but always sends the responses back to port 500 which amounts to the same thing).
Some systems use proprietary notify message codes which allows them to be identified. For example, Checkpoint Firewall-1 4.0, 4.1 and NG Base use notify message code 9101. ike-scan recognises this and will identify the system as "Checkpoint Firewall-1 4.x or NG Base".
Different systems support different transforms, and this support can be determined by trying all possible combinations with --trans. Note however, that the user can usually change the transform set, so this cannot be relied upon by itself.
Different implementations require different IKE Lifetimes. Some implementations will accept any lifetime, whereas others will only accept lifetimes below a certain value.
By using another tool (e.g. tcpdump) to sniff the returned IKE packets, the IP ID and IP TTL can be determined. These can be useful in fingerprinting the IP stack which can help to determine the IKE implementation.
The IKE host may send Vendor ID payloads which uniquely identify the implementation. This Vendor ID fingerprinting method was first proposed by Brett Eldridge [email protected]. ike-scan will display any vendor ID payloads that it receives, and will attempt to match these against known Vendor ID patterns.

Program Output

The program output consists of two sections:

The IKE host detection section; and
The IKE backoff pattern section (if --showbackoff is specified).

The IKE host detection section contains one line for each host that responds. The response can either be a successful handshake or an informational message. Only the first packet returned by any given host is displayed in this section.

Some examples of the IKE host detection section are:

10.0.1.98        IKE Handshake returned (1 transforms)
10.0.1.22        Notify message 14 (NO-PROPOSAL-CHOSEN)
10.0.1.189        (10.0.1.130) Notify message 9101 (No common authentication method with Firewall.)

In the above example output, host 10.0.1.98 has returned an IKE handshake, 10.0.1.22 has returned notify message 14 (decimal) which corresponds to the RFC-defined error message "NO-PROPOSAL-CHOSEN" (see RFC 2408 section 3.14.1), and 10.0.1.189 has returned a non-standard notify message 9101 but the response has come from the IP address 10.0.1.130 rather than the address which the request was sent to (presumably this is a multi-homed system). Notify message 9101 is not defined by RFC 2408, but it is known to be a Checkpoint proprietary notify code (therefore the system is probably Firewall-1) and the program displays the text included in the notify message.

Some examples of the IKE backoff pattern section are:

IP Address      No.     Recv time               Delta Time
172.16.2.2      1       1042549209.247980       0.000000
172.16.2.2      2       1042549211.239254       1.991274
172.16.2.2      3       1042549213.241935       2.002681
172.16.2.2      4       1042549215.244731       2.002796
172.16.2.2      5       1042549217.247512       2.002781
172.16.2.2      6       1042549219.250254       2.002742
172.16.2.2      7       1042549221.253044       2.002790
172.16.2.2      8       1042549225.258551       4.005507
172.16.2.2      9       1042549229.264074       4.005523
172.16.2.2      10      1042549233.269605       4.005531
172.16.2.2      11      1042549237.275145       4.005540
172.16.2.2      12      1042549241.280654       4.005509
172.16.2.2      Implementation guess: Firewall-1 4.1/NG

IP Address      No.     Recv time               Delta Time
10.0.1.98        1       1042549209.426540       0.000000
10.0.1.98        2       1042549224.425435       14.998895
10.0.1.98        3       1042549239.422251       14.996816
10.0.1.98        Implementation guess: Cisco IOS / PIX

Here, host 172.16.2.2 returned a total of 12 packets and the pattern matched "Firewall-1 4.1/NG", and host 10.0.1.98 returned 3 packets matching the pattern for "Cisco IOS / PIX". The recv time column shows the absolute time when the packet was received in seconds and microseconds since the epoch; delta time shows the elapsed time between packets in seconds and microseconds.

Examples

The below example will run IKE detection against the single host 172.16.2.2. No backoff fingerprinting will be done, and all options (timeouts, retrys, transform set Etc) will be the default.

ike-scan 172.16.2.2

This will read the target hosts from the file "hostlist.txt".

ike-scan --file=hostlist.txt

This reads the hosts from stdin and performs both IKE detection and backoff fingerprinting. The backoff wait is specified as 20 seconds.

cat hostlist.txt | ike-scan --file=- --showbackoff=20

This will run ike-scan against all hosts in the network specified by 172.16.0.0/16 (including network and broadcast addresses). In this case, this will result in a total of 65536 hosts being scanned - from 172.16.0.0 to 172.16.255.255 inclusive.

ike-scan 172.16.0.0/16

This uses the range notation to scan a total of 65536 hosts from 172.16.0.0 to 172.16.255.255 inclusive.

ike-scan 172.16.0.0-172.16.255.255

Supported Platforms

ike-scan has been built and tested on the following platforms:

Debian Linux 1.3.1 on IA32 with gcc 2.7.2.1, libc5 and 2.0.29 Kernel
Debian Linux 2.2r7 (Potato) on IA32 with gcc 2.95.2 and 2.2.17 Kernel
Debian Linux 3.0r1 (Woody) on IA32 with gcc 2.95.4 and 2.4.18 Kernel
Debian Linux 3.1 (Sarge) on IA32 with gcc 3.3.4 and 2.4.27 Kernel
Debian Linux 3.0 (Woody) on PA-RISC with gcc 3.0.4 and 2.4.17-64 Kernel
Debian Linux 3.0 (Woody) on Alpha with gcc 3.3.1 and 2.4.18-smp Kernel
Redhat Advanced Server 3.2 on IA64 with gcc 3.2.3 and 2.4.21-19.EL Kernel
HP-UX 11.11 on PA-RISC with gcc 3.4.1
HP-UX 11.11 on PA-RISC with HP cc HP92453-01 B.11.11.32003.GP
FreeBSD 4.3 on IA32 with gcc 2.95.3
OpenBSD 3.1 on IA32 with gcc 2.95.3
NetBSD 1.6 on IA32 with gcc 2.95.3
SCO OpenServer 5.0.7 on IA32 with gcc 2.95.3
Windows NT 4.0 / Cygwin 1.5.12 on IA32 with gcc 3.3.3
Solaris 2.8 on SPARC with gcc 2.95.3
HP Tru64 Unix v5.1 on Alpha with Tru64 cc
MacOS X (Darwin 7.7.0) on PowerPC

I've also had reports that it builds OK on the following systems:

RedHat Linux 7.1 with 2.4 Kernel
RedHat Linux 8.0 with 2.4 Kernel
Debian Linux 3.1 on Alpha
Debian Linux 3.1 on ARM
Debian Linux 3.1 on HP PA-RISC
Debian Linux 3.1 on Intel IA64
Debian Linux 3.1 on Motorola 68000
Debian Linux 3.1 on MIPS
Debian Linux 3.1 on PowerPC
Debian Linux 3.1 on IBM S390
Debian Linux 3.1 on SPARC

It should work, or be capable of working, on any Unix-like system which has a 64-bit integer type, supports sockets and has the system calls malloc, gethostbyname, gettimeofday, inet_ntoa, memset, select, socket, and strerror.

If you port ike-scan to a system not listed above, please let me know the details of the changes required so I can add them to future releases.

Contact Information

The best way to contact me is via the ike-scan repository on github.

I would like to hear from you if you have any of the following:

A modern Unix-like OS which ike-scan won't build on;
An OS not listed in the list above which ike-scan builds and runs OK on;
Any IKE implementation patterns that are not already in the ike-backoff-patterns file.
- Please include details of the pattern and also details of the IKE implementation;
Any Vendor ID pattern that is not already in the ike-vendor-ids file; or
Any comments or suggestions about the program.

If you need to contact me offline, please email me at [email protected]

ike-scan

인기

ike-scan

목차

빌드 및 설치

개요

사용법

Implementation Details

Host Input and Memory Requirements

Rate Limiting

Cookie Generation and Remote Host Identification

IKE 패킷 상세 정보

Backoff Fingerprinting

Program Output

Examples

Supported Platforms

Further Reading and RFCs

Contact Information