royhills/ike-scanماسح IKE
اكتشف وتحقق من مضيفات IKE (خوادم VPN باستخدام IPsec)
يستخدم ike-scan أدوات GNU autoconf و automake القياسية، لذا فإن التثبيت هو العملية العادية:
git clone https://github.com/royhills/ike-scan.git للحصول على الكود المصدري للمشروعcd ike-scan للدخول إلى دليل المصدرautoreconf --install لإنشاء ملف ./configure قابل للتشغيل./configure أو ./configure --with-openssl لاستخدام مكتبات OpenSSLmake لبناء المشروعmake check للتحقق من أن كل شيء يعمل كما هو متوقعmake install للتثبيت (ستحتاج إلى صلاحيات الجذر أو sudo لهذا الجزء)إذا كنت تخطط لتنفيذ اختراق المفاتيح المشتركة مسبقاً (Pre-Shared Key cracking)، فيجب عليك تهيئة ike-scan لاستخدام دوال التجزئة (hash functions) الخاصة بـ OpenSSL بدلاً من الدوال المدمجة، لأن دوال OpenSSL عادةً ما تكون أسرع. للقيام بذلك، تأكد من تثبيت ملفات الرأس ومكتبات OpenSSL، ثم قم بتشغيل configure كـ ./configure --with-openssl. سواء استخدمت OpenSSL أم لا، فلن يؤثر ذلك على وظائف ike-scan، بل فقط على سرعة اختراق المفاتيح المشتركة مسبقاً باستخدام psk-crack.
تقوم بعض أنظمة التشغيل بتثبيت ملفات الرأس (headers) ومكتبات OpenSSL بشكل افتراضي؛ بينما تتطلب أخرى تثبيت حزمة اختيارية، على سبيل المثال في Debian Linux تحتاج إلى تثبيت حزمة libssl-dev. بدلاً من ذلك، يمكنك تنزيل وتثبيت حزمة OpenSSL المضغوطة من http://www.openssl.org/
يجب أن يعمل البناء على معظم أنظمة التشغيل الحديثة الشبيهة بـ Unix. يعمل على Windows مع Cygwin ويمكن استخدامه كملف تنفيذي مستقل على Windows عند وجود cygwin1.dll.
إذا كنت تستخدم حزمة Windows-32 الثنائية، فيرجى قراءة ملف README-WIN32 الذي يوضح الاختلافات عند التشغيل على منصة Windows.
يُعرف أن البرنامج يُبنى ويُشغل على Linux، FreeBSD، OpenBSD، NetBSD، Win32/Cygwin، Solaris، MacOS X، HP Tru64، HP-UX، و SCO OpenServer. لمزيد من التفاصيل، راجع القسم "المنصات المدعومة" أدناه.
يقوم ike-scan باكتشاف مضيفات IKE ويمكنه أيضًا بصمتها (fingerprint) باستخدام نمط التباطؤ في إعادة الإرسال (retransmission backoff pattern).
يمكن لـ ike-scan القيام بالوظائف التالية:
تتم مناقشة مفهوم بصمة التباطؤ في إعادة الإرسال بمزيد من التفصيل في ورقة بصمة التباطؤ في UDP (UDP backoff fingerprinting paper) والتي يجب تضمينها في حزمة ike-scan كـ UDP Backoff Fingerprinting Paper.
يقوم البرنامج بإرسال طلبات المرحلة الأولى من IKE (الوضع الرئيسي أو الوضع العدواني) إلى المضيفات المحددة ويعرض أي ردود يتم استلامها. يتعامل مع إعادة المحاولة وإعادة الإرسال مع التباطؤ لمواجهة فقدان الحزم. كما يحد من عرض النطاق الترددي المستخدم في حزم IKE الصادرة.
IKE هو بروتوكول تبادل المفاتيح عبر الإنترنت (Internet Key Exchange) وهو آلية تبادل المفاتيح والمصادقة المستخدمة بواسطة IPsec. تقريبًا جميع أنظمة VPN الحديثة تنفذ IPsec، والغالبية العظمى من شبكات VPN باستخدام IPsec تستخدم IKE لتبادل المفاتيح. الوضع الرئيسي هو أحد الأوضاع المحددة للمرحلة الأولى من تبادل IKE (الوضع الآخر المحدد هو الوضع العدواني). تحدد RFC 2409 القسم 5 أن الوضع الرئيسي يجب تنفيذه، لذلك يمكن توقع أن تدعم جميع تطبيقات IKE الوضع الرئيسي. العديد منها يدعم أيضًا الوضع العدواني.
لعرض معلومات الاستخدام الحالية، قم بتشغيل الملف الثنائي 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.
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).
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
إذا لم يكن --verbose مفعّلاً، فسيتم تجاهل هذه الحزم بصمت.
قد يكون سبب عدم تطابق ملف تعريف الارتباط هذا هو:
تحتوي الحزم المرسلة في الوضع الرئيسي على رأس ISAKMP وحمولة SA. تحتوي حمولة SA على اقتراح واحد، ويمكن أن يحتوي الاقتراح على عدد متغير من التحويلات كما هو موضح أدناه.
بشكل افتراضي، يحتوي اقتراح SA على 8 تحويلات. تمثل هذه التحويلات 8 جميع المجموعات الممكنة من:
فيما يلي مثال على مخرجات tcpdump لحزمة الوضع الرئيسي المرسلة بواسطة ike-scan باستخدام مجموعة التحويل الافتراضية. يوضح هذا التحويلات الثمانية ويوضح أيضًا الترتيب الذي يتم إرسالها به:
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 - سيقبل معظمها واحدًا على الأقل من التحويلات المعروضة. ومع ذلك، من الضروري أحيانًا استخدام طريقة مصادقة مختلفة (المفتاح المشترك مسبقًا هو الأكثر شيوعًا، ولكن لا يتم دعمه دائمًا)، وأحيانًا يكون من الضروري تحديد تشفير مختلف مثل AES بسعة 256 بت. وفي حالات نادرة، قد يكون من الضروري تغيير العمر الافتراضي. أخيرًا، تتطلب بعض التطبيقات إرسال سلسلة "معرف البائع" المحددة من قبل العميل قبل أن تستجيب. يمكن تحديد ذلك باستخدام الخيار --vendor.
يؤدي مجموعة التحويل الافتراضية إلى طول بيانات الحزمة 336 بايت، والتي عند إضافة رؤوس IP و UDP تعطي حجم حزمة إجمالي يبلغ 364 بايت.
من الممكن تحديد طريقة المصادقة باستخدام --auth (الافتراضي هو 1 - مفتاح مشترك مسبقًا) والعمر الافتراضي لـ IKE بالثواني باستخدام --lifetime (الافتراضي هو 28800 ثانية أو 8 ساعات كما هو موصى به في RFC 2407). إذا قمت بتحديد --lifetime بقيمة 0، فلن يتم تضمين أي سمة عمر افتراضي في حمولات التحويل. إذا كنت تحدد تحويلات مخصصة، يمكنك استخدام هذا الخيار أكثر من مرة لإنتاج حمولات تحويل بأعمار افتراضية مختلفة. كل خيار --trans سيستخدم قيمة العمر الافتراضي المحددة مسبقًا.
من الممكن تحديد مجموعة تحويل مخصصة باستخدام --trans=e[/l],h,a,g حيث "e" هي خوارزمية التشفير، "l" هو طول المفتاح للتشفير متغير الطول، "h" هي خوارزمية التجزئة، "a" هي طريقة المصادقة، و "g" هي مجموعة DH. يتم تحديد هذه القيم رقمية؛ راجع RFC 2409 الملحق أ للحصول على تفاصيل حول القيم التي يجب استخدامها.
على سبيل المثال: --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:
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:
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:
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.
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:
--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).--trans. Note however, that the user can usually change the transform set, so this cannot be relied upon by itself.The program output consists of two sections:
--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.
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.2This will read the target hosts from the file "hostlist.txt".
ike-scan --file=hostlist.txtThis 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=20This 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/16This 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.255ike-scan has been built and tested on the following platforms:
I've also had reports that it builds OK on the following systems:
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.
For an in-depth coverage of IPsec including IKE, I recommend the book "IPsec The New Security Standard for the Internet, Intranets and Virtual Private Networks" by Doraswamy and Harkins, ISBN 0-13-011898-2. I used this book together with the RFCs to learn about IKE.
The following RFCs relate to IKE:
All of these RFCs can be obtained from: http://www.ietf.org/rfc
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:
If you need to contact me offline, please email me at [email protected]