vpn程序-icmpxfr （客户端仅能运行在linux桌面系统）

 Data Transfered over ICMP

Many sys admins, network engineers, and even IDS/IPS systems focus their network monitoring on TCP and UDP protocols. ICMP is often overlooked, but is nearly as viable for data transfer. So I wrote a pair of programs to demonstrate the viability and relative simplicity of data transfer over the unusually-monitored protocol.
In this post I use the word “client” to refer to the sender of an ICMP echo request and “server” to refer to the receiver, the piece that responds with an ICMP echo response.

Two things about ICMP data transfer

1. It’s possible
2. It probably happening somewhere to exfiltrate data, tunnel other protocols, or bypass IDS/filters/ACLs/who-knows?

At the bottom of the post are client and server proofs of concept that can be used to transfer a single file. Though the code below has a minimal featureset, it is possible to incorporate compression, encryption, sophisticated detection evasion, reliable and snazzy protocols, and other stuff of which I haven’t thought.

Notes on the code

• In order to increase throughput, the server process does not send echo responses back to the client
• As with UDP, ICMP does not provide re-transmission of unreceived packets, so SHA1 hash is calculated on the whole payload in the client and sent to the server ICMP process in order to verify file integrity on the back end
• Consequently, this code depends on OpenSSL’s library for hashing
• A more reliable protocol can be developed and more robust error handling should be in place
• I haven’t yet investigated why I needed to slow down the client’s transmission rate. The server couldn’t keep up with the ICMP packets without the artificial handicap even without the server sending echo responses. Anybody know what I’m overlooking?

Ways to identify this type of ICMP data transfer/tunneling/shenanigans

• Echo requests and responses implemented in ping utilities typically use a common payload protocol where the client sends a known quantity and the server echoes it back verbatim. Know your platform and what data to expect from your ping utilities.
• The implication of the previous item is that the ICMP payload is of static length in both echo and response packets. Beware of dynamic length ICMP echo/response packet payloads.
• Typical ping utilities contain an ASCII payload. If payload is non-ASCII, the payload may be compressed or encrypted–probably both. In either case, ain’t no pinging taking place.
• ICMP packets are small. Common ping utilities send 56-byte ICMP payloads in addition to an 8-byte ICMP header and a 20-byte IP header (84 bytes). At that size, transferring files of even 10 kilobytes in size will take 1024*10/84 seconds to transfer if the traditional one-packet-per-second ping scheme is followed. So be on the lookout for traffic attempting to skirt these details with A) ICMP payloads of many bytes and B) ICMP packet throughput at a faster-than-expected rate.
• In a similar vein: in order to maintain high throughput, echo responses may never be sent back to the client. Many systems out there do drop ICMP echo requests on the floor and do not respond, but beware of long-standing ICMP packet streams to the same IP address that see few echo replies or none at all.
• ping utilities and probably other legit ICMP tools properly set the ICMP sequence number, icmp_seq. It’s my experience that this usually starts at zero and increments by one for each packet in the exchange.
• Keep in mind the client IP address may be…less than accurate. Eek!

How to use the programs to transfer a single file or any input from client to server:

1. Start server first (optionally writes to stdout): ./server [-f ]
2. Next, fire up the client (optionally reads from stdin): ./client -h [-f ]

from  http://www.unixist.com/security/data-transfer-over-icmp/index.html
项目地址：https://github.com/unixist/icmpxfr