Free increase tcp connections software for linux

conn-close gives us possibility to get rid of entries in ip_conntrack about ESTABLISHED TCP connections that goes through our server.

conn-close script uses hping2 to send spoofed RST packets which will fool conntrack and cause specified connections to be considered by conntrack as closed (now these connections will be in ip_conntrack in CLOSE state), even though RST packets will be more likely discarded by destination host.

Information about connections is read of course from /proc/net/ip_conntrack.

Idea was taken from script seen somewhere on the internet.

Perl Advanced TCP Hijacking is a collection of tools for inspecting and hijacking network connections written in Perl. It consists of a packet generator, an RST daemon, a sniffer, an ICMP redirection tool, an ARP redirection tool, an IDS testing tool and other.

If your system supports Perl just do the following steps:
cd modules
su
perl Makefile.PL
make
make install
If the script tell you it cant install all required modules automatically youll find that module on CPAN [http://www.cpan.org].

reTCP is a user-space TCP connection redirector with special HTTP proxy support. It can fix common flaws in HTTP requests, log data transfer, and do arbitrary transformations on response headers and content.
Options:
-sPORT set source listen (incoming) TCP port to PORT
-SHOST set source listen/bind (incoming) hostname to HOST
-CHOST connect from this HOST to remote (bind() before connect())
-gBOOL do gethostby*() DNS lookups iff BOOL. default: true
-zBOOL go into the background iff BOOL. default: false
-qUINT print global messages of verbosity UINT to stdout. default: 2
-1UINT print per connection messages of verbosity UINT to stdout. default: 2
-el emulate fake Lynx browser (User-agent:, Accept: etc.)
-en emulate fake Netscape 4.61 browser (User-agent:, Accept: etc.)
-e0 dont change browser information. default.
-pBOOL purge HTTP cookies sent by the client iff BOOL. default: false
-rBOOL purge HTTP Referer: sent by the client iff BOOL. default: false
-mBOOL purge HTTP If-modified-since: by the client iff BOOL. default: false
-fBOOL fix browser URLEncode bugs (i.e spaces in the URL). default: true
-iSTR set external Server -> Client filter command. default: none
-HSTR use handshake ("STRn") with external filters. default: none
-v print software version information and exit immediately
-h print this help screen and exit immediately
Enhancements:
- This release fixes a bug related to truncating HTTP request headers to 1024 bytes, adds a -F0 switch to disable forking, and fixes minor memory leaks.

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.

Cubehub is a simple UDP over TCP tunnel application written in Java. It is designed to help people behind a firewall to connect through a TCP connection and play Quake and other UDP-based games.
SOCKS 4 and 5 are protocols that are supposed to allow users to send data through a firewall. However, they only work like this if the SOCKS server is on the firewall itself. Whilst TCP/IP traffic is frequently permitted through firewalls, UDP/IP (required by most online games) is often blocked. When a SOCKS 5 server relays UDP data (SOCKS 4 does not support UDP), the packets are simply relayed, there is no tunnelling involved.
This application provides a solution, tunnelling the data being relayed by a SOCKS server over one or (for better gaming performance) multiple TCP connections to help applications and games to work from behind a restrictive firewall.
Main features:
- Socks 4/5 server
- TCP and UDP tunnelling over single or multiple TCP connections
- Resilience against individual connection dropping

TCPCam is a video and audio point to point conference program for Linux that is very easy to use and modify. The connection uses a single TCP port that needs to be open on only one of the two ends.
TCPCam is possible to change the video compression and resolution at run-time to match the available bandwidth.
It uses the Speex encoder for audio compression (in both narrowband and wideband), JPEG compression for video, and works with most video4linux devices and audio boards supporting the OSS API.
Main features:
- It works using a single TCP port (port 7766). In order for TCPCam to work between two users, one of the users can be completly firewalled, while the other one must have port TCP 7766 open to the outside.
- Audio frames are encoded using the Speex encoder/algorithm.
- Video frames are encoded using JPEG at high compression level.
- The user can switch between ten different video quality levels at runtime using keys from 1 to 0.
- Support for multiple video resolution (up to 640x480), the user can switch at runtime using the right keys (see usage)
- Full screen mode (just press f to toggle).
- Capture screenshots in JPEG format (just press enter).
- Audio works in narrowband (8Khz) and wideband (16Khz).
- The protocol is very simple to implement in most operating systems and programming languages. It is based on frames with a simple header containing audio or video and transimtted over a TCP channel.

tcptunnel is a simple TCP tunnel written in Perl.

Also is a versatile tcp tunnel. The tcptunnel uses:
- tunnelling through a firewall or proxy
- redirecting tcp connections to other ports or machines
- debugging tcp connections in-place
- packet sniffing

The tcptunnel listens on local port < port > and when a connection is made it connects the other end of the tunnel as follows:
a) With no proxy specified, it connects the other end
to < srvport > on < srv >.
b) With a proxy, it connects to < srvport > on < proxy >.
It then directs the proxy to telnet to < srv >, and then it connects the ends of the tunnel.

Run a web server inside LAN is a simple script to run a WWW server inside a Local Area Network. Run a web server inside LAN script assume all iptables features are compiled statically in the kernel, or all modules are loaded.

Otherwise you may encounter some surprises trying to utilize the more featureful and creative commandlines that Ive come up with.

Sample:

#external and internal interfaces
EXT=eth0
INT=eth1

# clear everything, and create my cascading chains
iptables -F
iptables -N e0
iptables -N tcpin
iptables -N udpin

# e0 is the name of our chain for eth0
iptables -I INPUT -i $EXT -j e0

# OUTPUT Chain
iptables -A OUTPUT -o $EXT -j DROP -p icmp --icmp-type ! echo-request

# remote gnutella queries were really pissing me off one day
# iptables -A OUTPUT -o $EXT -j DROP -p tcp ! --syn --dport 6346
# iptables -A OUTPUT -o $EXT -j DROP -p tcp ! --syn --sport 6346

# $EXT Chain
# a single rule to accept SYN Packets for multiple ports (up to 15)
iptables -A tcpin -j ACCEPT -p tcp --syn -m multiport --destination-ports 873,993,995,143,80,113,21,22,23,25,53

# stateful connection tracking is wonderful stuff
# ESTABLISHED tcp connections are let through
# If we send a SYN out, the ACK is seen as RELATED
# then further communication is accepted by the ESTABLISHED rule
iptables -A e0 -j ACCEPT -m state --state ESTABLISHED
iptables -A e0 -j ACCEPT -m state --state RELATED

# certain ports I simply DROP
iptables -A tcpin -j DROP -p tcp --syn -m multiport --destination-ports 6346,139

# UDP rules...
iptables -A udpin -j DROP -p udp -m multiport --destination-ports 137,27960

# I run a DNS server, so we must accept UDP packets on port 53
iptables -A udpin -j ACCEPT -p udp -m state --state NEW --destination-port 53

# lets log NEW udp packets on ports 1024:65535, then let them through
iptables -A udpin -j LOG -p udp -m state --state NEW --destination-port 1024:65535 --log-level debug --log-prefix UDPNEW --log-ip-options
iptables -A udpin -j ACCEPT -p udp -m state --state NEW --destination-port 1024:65535

# lets log NEW tcp packets on ports 1024:65535, then let them through
iptables -A tcpin -j LOG -p tcp --syn --destination-port 1024:65535 --log-level debug --log-prefix TCPNEW --log-tcp-options --log-ip-options
iptables -A tcpin -j ACCEPT -p tcp --syn --destination-port 1024:65535

# lets log INVALID or NEW tcp packets on priveleged ports, then DROP
# (remember I have certain ACCEPT rules higher up the chain)
iptables -A tcpin -j LOG -p tcp -m state --state INVALID,NEW --destination-port 1:1023 --log-level warn --log-prefix TCPPRIV --log-tcp-options --log-ip-options
iptables -A tcpin -j DROP -p tcp -m state --state INVALID,NEW --destination-port 1:1023

iptables -A e0 -p tcp -j tcpin
iptables -A e0 -p udp -j udpin
iptables -A e0 -j LOG --log-level debug --log-prefix NETFILTER --log-ip-options -m state --state INVALID,NEW
iptables -A e0 -j DROP

# NAT Rules
# I run a web server inside...
iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 80 -j DNAT --to-destination 192.168.1.4:80