Free ack software for linux

Cutter is an TCP/IP Connection cutting on Linux Firewalls and Routers.

Cutter is an open source program that uses the FIN-ACK-RST packet technique described above to abort TCP/IP connections routed over the firewall or router on which it is run. It can be called using one of the following four syntaxes.

cutter ip-address

Example: "cutter 10.10.0.45"

Cuts all connections passing through the firewall between any ports on the specified ip-address (either a "private" or "public" address) and any other hosts. This can be used to close down all incoming connections to a particular server, all outgoing connections from a particular client or all outgoing connections to a server.

cutter ip-address port

Example: "cutter 200.1.2.3 80"

Cuts all connections to or from the specified ip-address/port pair. This allows the user to be a little more specific than the previous example and allows targetting of specific services on specific hosts.

cutter ip-address-1 port-1 ip-address-2

Example "cutter 200.1.2.3 22 10.10.0.45"

Cuts all connections between ip-address-2 and ip-address-1/port-1. This allows the user to cut connections between a specified "client" and a particular service on a specified host. Our example closes host 10.10.0.45s SSH connection to server 200.1.2.3.

cutter ip-address-1 port-1 ip-address-2 port-2

Example: "cutter 200.1.2.3 22 10.10.0.45 32451"

Cuts the specific connection between the two ip/port number pairs given.

IMPORTANT WARNING

Cutter has been designed for use as a administrators tool for Linux firewalls. Its use (as is, or modified) for any other purpose is not sanctioned by the author. So - do not use this tool as a parachute, or to dry your cat, chill meat, answer your phone, drive you car, teach your kids to read or attack other peoples computer systems or networks.

This software has been designed for "legal" and "appropriate" use by network security administrators and the like. It has been written as part of a larger Linux firewall project, targetting at controlling traffic from peer-to-peer software such as Kazaa, iMesh and others into and out of a private network. It is not designed as a tool for malicious use and the author in no way sanctions such use.

Users of the software should be aware that its actions are easily detectable using a number of readily available network monitoring tools, and it makes no attempt to disguise its actions. Malicious use of "cutter" could result in a jail sentance in a number of countries around the world.

Aps is a small tool for analyzing network traffic. It prints out a great deal of information about the relevant protocols including TCP, UDP, ARP, and ICMP.
It allows you to filter IP addresses, hardware addresses, ports, and specific protocols. It comes with a little GTK-GUI displaying packet counters for each protocol.
APS tries to print detailed info about network frames that are received from the SOCK_RAW (ETH_P_ALL) socket. I am not sure if this is the clean way, but it works fine. APS prints info about the hardware layer and the IP and TCP/UDP/ICMP header.
The tail of the packet (mostly the data) wich could not be interpreted is written on the screen as ascii/hex-dump or both (your choice).
Example
HW-ADDR: 00:60:8c:f6:40:96 -----> 00:80:ad:30:8f:3b
IP-ADDR: 192.168.17.52 -----> 192.168.17.50
IP-Ver4 || Head:0x0a (bytes) || Service(TOS):16 || Length over all:0061
Fragmentation: ID:0x4079 - Flags: 0 1 0 - Offset:00000
TTL:064 || Protokoll:006 (TCP) || HeaderCRC:0x567b
TCP-HEADER:
Ports: 0023-->1034 (telnet) Seq./Ack. Nr.:0x70843468 / 0xeae29434
Data-Offset:0x05 Reserved-6Bit:00 Flags:-urg-ACK-PSH-rst-syn-fin-
Window:0x7fe0 CRC:0x9420 Urgent-Pointer:0x0000
73 61 74 75 72 6e 32 3a 2f 73 72 76 2f 70 72 69 6e 74 71 23 20
HW-ADDR: 52:54:40:25:8d:88 -----> ff:ff:ff:ff:ff:ff
SAMBA/NetBios
e0 e0 03 ff ff 00 22 00 11 00 00 00 00 ff ff ff ff ff ff 04 52 00 00 00 00 52
40 25 8d 88 40 08 00 03 00 04 20 20 20 20 20 20 20 20 20
HW-ADDR: 00:80:ad:30:8f:3b -----> 00:60:8c:f6:40:96
IP-ADDR: 192.168.17.50 -----> 194.112.123.200
IP-Ver4 || Head:0x0a (bytes) || Service(TOS):0 || Length over all:0029
Fragmentation: ID:0x29ae - Flags: 0 0 0 - Offset:00000
TTL:064 || Protokoll:001 (ICMP) || HeaderCRC:0x411f
echo request CODE:0x0 CRC:0xf9f5 SIG:0x602 NUM:0x0
00 ea
Enhancements:
- added break for Packet-counter and fixed some minor bugs

LLgen is a LL parser in the style of yacc.
The Amsterdam Compiler Kit is fast, lightweight and retargetable compiler suite and toolchain written by Andrew Tanenbaum and Ceriel Jacobs, and was Minix native toolchain.
The ACK was originally closed-source software (that allowed binaries to be distributed for Minix as a special case), but in April 2003 it was released under a BSD open source license.
The ACK achieves maximum portability by using an intermediate byte-code language called EM. Each language front-end produces EM object files, which are then processed through a number of generic optimisers before being translated by a back-end into native machine code.
Unlike gccs intermediate language, EM is a real programming language and could be implemented in hardware; a number of the language front-ends have libraries implemented in EM assembly.
EM is a relatively high-level stack-based machine, and one of the tools supplied with ACK is an interpreter capable of executing EM binaries directly, with a high degree of safety checking. See the em document referenced below for more information.
ACK comes with a generic linker and librarian capable of manipulating files in the ACKs own a.out-based format; it will work on files containing EM code as well as native machine code. (You can not, however, link EM code to native machine code without translating the EM binary first.)
Enhancements:
- LLgen was previously part of the Amsterdam Compiler Kit, but has been split out into a standalone component.
- This version has been updated from its original 1991 vintage source and has a completely rewritten, much more streamlined build system.

Berkley Snoop for Linux is a module which adds support for the Snoop protocol, a TCP-aware link layer protocol designed that can improve the performance of TCP over networks of wired and single-hop wireless links.
While TCP adapts well to network congestion, it does not adequately handle the vagaries of wireless media. In this thesis, we address these challenges in detail and design solutions to them. These solutions incorporate link-layer techniques as well as enhancements to TCP at the sender and receiver. The Snoop protocol is a TCP-aware link layer protocol designed to improve the performance of TCP over networks of wired and single-hop wireless links.
The implementation is for kernels of 2.6.x series. This software is intended to use on routers acting between big fat pipe(BFP) link and wireless link.
The problem: The wireless link is error prone by its nature and BFP links such as satellite one has very big round-trip time. When error occurs on wireless segment it causes in speed reduction because the TCP protocol on sending side treats this error as link congestion although the error was just a temporary link quality loss and the connection cannt recover its speed.
The fix: The module will cache TCP segmets passing to host on wireless segment until the ACK(nowledgmet) is received or timeout expired. In case of timeout the segment will be retransmitted again. And by the way the module will drop all DUP(licate) ACK(nowledgmets) caused by packet loss on wireless segment and prevent the reduction of speed of flow from the host beyond the satellite link. The module works now only with connections initiated from wireless hosts.
Enhancements:
- fixed issues with improper use of locks & memory allocation the memory allocates now with GFP_ATOMIC priority

LaBrea is a intrusion detection / "sticky" honey pot technology using virtual servers to detect malware. LaBrea takes over unused IP addresses, and creates virtual servers that are attractive to worms, hackers, and other denizens of the Internet. The program answers to connection attempts in a way that the machine at the other end gets "stuck", sometimes for a very long time.
LaBrea works by watching ARP requests and replies. When the pgm sees consecutive ARP requests spaced several seconds apart, without any intervening ARP reply, it assumes that the IP in question is unoccupied. It then "creates" an ARP reply with a bogus MAC address, and fires it back to the requester.
An example (from a tcpdump of LaBrea running on my network):
14:18:28.832187 ARP who-has xx.xx.xx.13 tell xx.xx.xx.1
14:18:29.646402 ARP who-has xx.xx.xx.13 tell xx.xx.xx.1
14:18:31.707295 ARP who-has xx.xx.xx.13 tell xx.xx.xx.1
14:18:31.707574 ARP reply xx.xx.xx.13 is-at 0:0:f:ff:ff:ff
There is no xx.xx.xx.13 machine on my network. In this case, the timeout was set to 3 seconds (its a command line parameter), and when that final "who-has" came in, the "is-at" reply that you see was generated by LaBrea.
There isnt a MAC address of 0:0:f:ff:ff:ff either. It doesnt exist.
But now, the router (xx.xx.xx.1) believes that there some machine at xx.xx.xx.13, and that it resides on the MAC address 0:0:f:ff:ff:ff, and so it dutifully sends packets on. In
essence, weve created a "virtual machine" on that IP address.
Now, LaBrea also watches for TCP traffic destined for the ether address 0:0:f:ff:ff:ff. When it sees an inbound TCP SYN packet, it replies with a SYN/ACK that "tarpits" that connection attempt. Everything else is ignored. (Well... sort of. LaBrea also tries to give its "virtual machines" some character... you can ping them, and they respond to a SYN/ACK with a RST.
Theres more to it than that (obviously...) but youll need to read further.
Enhancements:
- src/ctl.c (ctl_init_arrays): Remove call to sleep since not supposed to mix with alarm calls on linux.
- src/utils.c (util_alarm), src/labrea.c: Set alarm and signal handlers after going into daemon mode so that child will get signal
- src/labrea_init.c, src/lbio.c: Take out fudge code since libdnet 1.7 ethopen now uses the libdnet device names (ie eth1, etc).

pkdump is a port scanning detection tool. The program detect any TCP ,UDP port scanning or open connection attempt from foreign host over the internet with IP protocol version 4
or IP protocol version 6 .
The program can detect:
TCP connect , TCP syn , TCP fin , TCP xmas, TCP ack, TCP null(no flags), UDP port (connect) and UDP null (0 bytes, UDP packets lengt ) , whether the IP packet are fragmented or not. (Please consult "Nmap"... man Nmap).
The program make a directory like this : "Pkdump-[date][time]" and in this directory make a file "PKDATA" that contains all IP packet sent and received during the transmission ,and during scanning attack make files that contains the data of the attack ;the data of the port scanning will displayed on the screen with a short beep;
Enhancements:
- Fixed bug in read-write operation.
- Show the number of IP fragment.

TCP Knocking provides a port knocking implementation.
Often a secure system needs a port open so that only authorized persons can access a particular service and also the service should not exposed to attackers and worms that may use vulnerabilities that exist in the listening server. Port knocking is designed to be used as a complementary service to the existing authentication mechanism. But one of the biggest problems with port knocking is manipulating the firewall with timeouts.
When the correct knock sequence is sent, the firewall is modified for couple of seconds. Having the firewall open automatically for a time period will make any system administrator uncomfortable. TCP knocking attempts to solve the problem by incorporating the knock into the TCP handshake. Tcp knocking is similar to port knocking, but instead sending UDP packets with secret ports, the TCP handshake packets must include secrete codes. It is at least as secure as port knocking and it can be made secure with more hardening.
Modified TCP handshake:
In normal TCP handshake, the client sends the syn packet and chooses a random initial sequence number. The server responds with a packet that has both syn and ack flags set, choosing a random
The modified TCP handshake uses the empty fields in the header. The server does not respond to connection requests without a special code generated along with the syn packet. The server also encrypts the ISN in the ack packet (2) and the final packet of the three-way handshake must have the correct acknowledgment for the servers ISN. The system is further protected from brute-force attacks by closing the connection if the first attempt for the third packet does not have the expected acknowledgment sequence.
Also, rather than use conventional encryption techniques like HMAC for verification, this system uses a file with random numbers as the key. This is because of the limited unused space available in the TCP/IP header which makes HMAC very weak. By using a shared file, the length of the key can be much greater than traditional systems and even though some parts of the key can be revealed by attacks, the server can protect itself from replay attacks.
The handshake:
1) Syn
The syn packet does not use the 32 bit acknowledgment field in the TCP header as it the the first packet to initiate the connection. Further the 16 bit IPID can be used to transmit information. In the current implementation only the 32 bit acknowledgment field is used. Currently the 32 bit ack is derived from a 64 KB file which contains random numbers. The ISN and the source IP address along with the random numbers are used to generate this value.
2) Syn/Ack
The ISN is encrypted using the random numbers from the 64 KB file using the destination IP address as well as a 16 bit random number used as IPID. I do not have code for this part yet.
3) Ack
The client decrypts the syn number from the encrypted syn, the key file, the 16 bit IPID and its own IP address and sends the ack packet. The server closes all connections from the client for couple of minutes if it sends a wrong ack value. Part of the security relies on the fact that the ISN generated by Linux 2.6 is fairly random.
Implementation:
I have implemented only the first part, which is the server expecting secret code along with the first syn packet from the client. Hence it is very possible to brute-force the server. Also the system is designed with the second phase in mind, which is the encrypted Initial Sequence Number in the ack packet and closing the connection if the correct ack is not sent on the first try. I do not have an implementation for that yet. The security will be increased greatly when the second phase is incorporated. Also the ability to detect brute-force attacks can be added to this system.
But the current system can be used for protecting the server from worms and random scanning. The use-case is similar to port knocking but it does not use the ugly system of opening the firewall for a couple of seconds. Vanilla port knocking is susceptible to brute-force attacks as well. Besides, inserting a kernel module to just ssh into your server will increase your mad sysadmin points.
Enhancements:
- TCP knocking with Phase 1 of the protocol was implemented.

The Wonder Shaper is a very special network shaper script with a lot of features. Works on Linux 2.4 & higher.

Goals

I attempted to create the holy grail:

* Maintain low latency for interfactive traffic at all times.

This means that downloading or uploading files should not disturb SSH or even telnet. These are the most important things, even 200ms latency is sluggish to work over.

* Allow surfing at reasonable speeds while up or downloading

Even though http is bulk traffic, other traffic should not drown it out too much.

* Make sure uploads dont harm downloads, and the other way around

This is a much observed phenomenon where upstream traffic simply destroys download speed. It turns out that all this is possible, at the cost of a tiny bit of bandwidth. The reason that uploads, downloads and ssh hurt eachother is the presence of large queues in many domestic access devices like cable or DSL modems.

Why it doesnt work well by default

ISPs know that they are benchmarked solely on how fast people can download. Besides available bandwidth, download speed is influenced heavily by packet loss, which seriously hampers TCP/IP performance. Large queues can help prevent packetloss, and speed up downloads. So ISPs configure large queues.

These large queues however damage interactivity. A keystroke must first travel the upstream queue, which may be seconds (!) long and go to your remote host. It is then displayed, which leads to a packet coming back, which must then traverse the downstream queue, located at your ISP, before it appears on your screen.

This HOWTO teaches you how to mangle and process the queue in many ways, but sadly, not all queues are accessible to us. The queue over at the ISP is completely off-limits, whereas the upstream queue probably lives inside your cable modem or DSL device. You may or may not be able to configure it. Most probably not.

So, what next? As we cant control either of those queues, they must be eliminated, and moved to your Linux router. Luckily this is possible.

Limit upload speed somewhat

By limiting our upload speed to slightly less than the truly available rate, no queues are built up in our modem. The queue is now moved to Linux.

Limit download speed

This is slightly trickier as we cant really influence how fast the internet ships us data. We can however drop packets that are coming in too fast, which causes TCP/IP to slow down to just the rate we want. Because we dont want to drop traffic unnecessarily, we configure a burst size we allow at higher speed.

Now, once we have done this, we have eliminated the downstream queue totally (except for short bursts), and gain the ability to manage the upstream queue with all the power Linux offers.

Let interactive traffic skip the queue

What remains to be done is to make sure interactive traffic jumps to the front of the upstream queue. To make sure that uploads dont hurt downloads, we also move ACK packets to the front of the queue. This is what normally causes the huge slowdown observed when generating bulk traffic both ways. The ACKnowledgements for downstream traffic must compete with upstream traffic, and get delayed in the process.

We also move other small packets to the front of the queue - this helps operating systems which do not set TOS bits, like everything from Microsoft.

Allow the user to specify low priority traffic (new in 1.1!)

Sometimes you may notice low priority OUTGOING traffic slowing down important traffic. In that case, the following options may help you:

NOPRIOHOSTSRC
Set this to hosts or netmasks in your network that should have low priority

NOPRIOHOSTDST
Set this to hosts or netmasks on the internet that should have low priority

NOPRIOPORTSRC
Set this to source ports that should have low priority. If you have an unimportant webserver on your traffic, set this to 80

NOPRIOPORTDST
Set this to destination ports that should have low priority.

See the start of wshaper and wshaper.htb

Results

If we do all this we get the following measurements using an excellent ADSL connection from xs4all in the Netherlands:

Baseline latency:
round-trip min/avg/max = 14.4/17.1/21.7 ms

Without traffic conditioner, while downloading:
round-trip min/avg/max = 560.9/573.6/586.4 ms

Without traffic conditioner, while uploading:
round-trip min/avg/max = 2041.4/2332.1/2427.6 ms

With conditioner, during 220kbit/s upload:
round-trip min/avg/max = 15.7/51.8/79.9 ms

With conditioner, during 850kbit/s download:
round-trip min/avg/max = 20.4/46.9/74.0 ms

When uploading, downloads proceed at ~80% of the available speed. Uploads at around 90%. Latency then jumps to 850 ms, still figuring out why.

What you can expect from this script depends a lot on your actual uplink speed. When uploading at full speed, there will always be a single packet ahead of your keystroke. That is the lower limit to the latency you can achieve - divide your MTU by your upstream speed to calculate. Typical values will be somewhat higher than that. Lower your MTU for better effects!

A small table:

Uplink speed | Expected latency due to upload
--------------------------------------------------
32 | 234ms
64 | 117ms
128 | 58ms
256 | 29ms

So to calculate your effective latency, take a baseline measurement (ping on an unloaded link), and look up the number in the table, and add it. That is about the best you can expect. This number comes from a calculation that assumes that your upstream keystroke will have at most half a full sized packet ahead of it.

This boils down to:

mtu * 0.5 * 10
-------------- + baseline_latency
kbit

The factor 10 is not quite correct but works well in practice.

Your kernel

If you run a recent distribution, everything should be ok. You need 2.4 with QoS options turned on.

If you compile your own kernel, it must have some options enabled. Most notably, in the Networking Options menu, QoS and/or Fair Queueing, turn at least CBQ, PRIO, SFQ, Ingress, Traffic Policing, QoS support, Rate Estimator, QoS classifier, U32 classifier, fwmark classifier.

In practice, I (and most distributions) just turn on everything.

The scripts

The script comes in two versions, one which works on standard kernels and is implemented using CBQ. The other one uses the excellent HTB qdisc which is not in the default kernel. The CBQ version is more tested than the HTB one!

See wshaper and wshaper.htb.

Tuning

These scripts need to know the real rate of your ISP connection. This is hard to determine upfront as different ISPs use different kinds of bits it appears. People report success using the following technique:

Estimate both your upstream and downstream at half the rate your ISP specifies. Now verify if the script is functioning - check interactivity while uploading and while downloading. This should deliver the latency as calculated above. If not, check if the script executed without errors.

Now slowly increase the upstream & downstream numbers in the script until the latency comes back. This way you can find optimum values for your connection. If you are happy, please report to me so I can make a list of numbers that work well. Please let me know which ISP you use and the name of your subscription, and its reputed specifications, so I can list you here and save others the trouble.

Installation

If you dial in, you can copy the script to /etc/ppp/ip-up.d and it will be run at each connect.

If you want to remove the shaper from an interface, run wshaper stop. To see status information, run wshaper status.

KNOWN PROBLEMS

If you get errors, add an -x to the first line, as follows:

#!/bin/bash -x

And retry. This will show you which line gives an error. Before contacting me, make sure that you are running a recent version of iproute!

Recent versions can be found at your Linux distributor, or if you prefer compiling, here:
ftp://ftp.inr.ac.ru/ip-routing/iproute2-current.tar.gz