Free ack software for linux

NetPacket::TCP is a Perl module to assemble and disassemble TCP (Transmission Control Protocol) packets.

SYNOPSIS

use NetPacket::TCP;

$tcp_obj = NetPacket::TCP->decode($raw_pkt);
$tcp_pkt = NetPacket::TCP->encode($ip_pkt);
$tcp_data = NetPacket::TCP::strip($raw_pkt);

NetPacket::TCP provides a set of routines for assembling and disassembling packets using TCP (Transmission Control Protocol).

Methods

NetPacket::TCP->decode([RAW PACKET])

Decode the raw packet data given and return an object containing instance data. This method will quite happily decode garbage input. It is the responsibility of the programmer to ensure valid packet data is passed to this method.

NetPacket::TCP->encode($ip_obj)

Return a TCP packet encoded with the instance data specified. Needs parts of the ip header contained in $ip_obj in order to calculate the TCP checksum.

Functions

NetPacket::TCP::strip([RAW PACKET])

Return the encapsulated data (or payload) contained in the TCP packet. This data is suitable to be used as input for other NetPacket::* modules.

This function is equivalent to creating an object using the decode() constructor and returning the data field of that object.

Instance data

The instance data for the NetPacket::TCP object consists of the following fields.

src_port

The source TCP port for the packet.

dest_port

The destination TCP port for the packet.

seqnum

The TCP sequence number for this packet.

acknum

The TCP acknowledgement number for this packet.

hlen

The header length for this packet.

reserved

The 6-bit "reserved" space in the TCP header.

flags

Contains the urg, ack, psh, rst, syn, fin, ece and cwr flags for this packet.

winsize

The TCP window size for this packet.

cksum

The TCP checksum.

urg

The TCP urgent pointer.

options

Any TCP options for this packet in binary form.

data

The encapsulated data (payload) for this packet.

NARC is a free firewalling package for Netfilter/Iptables. It attempts to simplify the setup of a firewall (stateful packet filter) via the iptables tools. NARC is a bash shellscript that generates sensible and secure rules for Netfilter based on a simple configuration file.
Netfilter is the framework in Linux 2.4 kernels that allow for firewalling, NAT, and packet mangling. Iptables is the userspace tools that works with the Netfilter framework (technically a lie; Iptables is also a part of the Netfilter framework in the kernel). Think of Netfilter as the kernel space, and Iptables as the userspace.
Main features:
- Quick setup via a simple configuration file
- Connection tracking (and fragmentation reassembly)
- Customized logging
- Probe detection (TCP & UDP)
- Illegal TCP packet filtering
- FIN, NULL, ACK scan detection
- ICMP message filtering and rate limiting
- SYN packet length checking
- General rate limiting (to prevent DoS type attacks)
- IP/network based TCP connection rate limiting
- SYN flood protection
- Smurf attack protection
- Spoofed IP address filtering
- DMZ support
- Port forwarding support

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.

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.

Fwctl is a Perl module to configure the Linux kernel packet filtering firewall.

SYNOPSIS

use Fwctl;

my $fwctl = new Fwctl( %opts );
$fwctl->dump_acct;
$fwctl->reset_fw;
$fwctl->configure;

Fwctl is a module to configure the Linux kernel packet filtering firewall using higher level abstraction than rules on input, output and forward chains. It supports masquerading and accounting as well.

Why Fwctl ? Well, say you are the kind of paranoid firewall administrator which likes his firewalls rules tight. Very tight. Say the kind, that likes to distinguish between a SYN and ACK packet when accepting a TCP connection (anybody configuring packet filters should care about that last point), or like to specify the interface name on each rules. (Whether this is really need, or such a stance is relevant, is not the point.) How would such an administrator proceed ? First of all you deny everything on all interfaces and on all chains (input, forward and output) and turn on logging. Now starting from this configuration (in which Fwctl puts the firewall on initialization), say you want to enable ping from the internal network to the internal ip. What rules do you need ? You need a rule on the input chain to accept the echo-request packet and a rule on the output chain to accept the echo-reply request. Right ? Well, what about the loopback. For sure, when we say from local net to local ip, this imply local ip to local ip ? Then you add a rule to the output chain with the loopback interface, and a rule on the input rule to the loopback chain. And we didnt even start forwarding yet ! Add masquerading to the lot and multi connections protocols like FTP and you got something unmanageable. So you start accepting things you shouldnt to get your job done and in the end your filters look like emmenthal.

Fwctl handles all the complexity of this, so that when you say

accept ftp -src FTP_PROXY -dst INTERNET -noport

you dont accept too much of what you didnt intend. (Well you just opened arbitrary TCP connections to unprivileged ports on the Internet from your proxy server, but thats because of the FTP protocol, not because your cheating on the firewall rules.)

Fwctl works with entity known as service. A service can be ftp, netbios, ping or anything else. The service abstraction handles all the communication necessary for that application. (The UDP and TCP communication in DNS, or the control, data and passive connections for FTP.)

Additionally, to handle all the special case with ANY specification, when the src of dst imply a local IP, or masquerading, in short for Fwctl to be able to deduce the interface implicated by the src and dst portion of a rules you need to provide it with your network topology. Fwctl must guess from your topology the routing decision that will be made in the kernel. In the best of worlds, Fwctl should contains the same routing algorithm as the one in the kernel. Well, it doesnt so if you are using fancy routing feature, Fwctl wont work. In fact, it can only handle something equivalent to simple static routing. You have been warned.

So in short, to configure your packet filters with Fwctl you need to
Define your network topology using the interfaces file.

(Optional) Define meaningful aliases for hosts and networks which are part of your configuration.

Implement your security policy using high level abstract rules in the rules file.
Finally, Fwctl is extensible. You can easily add services modules using the Fwctl::RuleSet module which contains all the primitive you need to handle all the special cases involved in the input, forward and output chain selection.

This software is used for the automatic probing of internet hosts at a timed interval (reconnaisance), checking host connectivity, especially ICMP support (information Gathering), automated running of third party tools when said host is online (automated testing).
Use of sonar shifts responsibility for the users actions solely to that user him or herself. In other words, the author cannot be held responsible for your actions.
Examples
Run nmap with a vanilla connect scan as soon as www.google.com is online. Check every 60 seconds, go into background, and log to probe.log:
sonar -c -1 --scan_delay=60 -f --output_plugin=L
-p fprobe.log -pe"nmap -sT www.google.com"
-sI www.google.com
Check red0xs site for online status 4 time in a row (just like ping):
sonar -sI genbukan.no-ip.com
Send the contents of payload.dat to www.secursite.com every 5 minutes:
sonar -c -1 --scan_delay=300 -p ppayload.dat -sI
www.secursite.com
Send an ACK probe to googles webserver every second.
sonar --scan_delay=1 -c -1 -sA www.google.com -pp80
Enhancements:
- src/mutex.h, src/plugin.h, src/types.h, libltdl/configure, plugins/network_icmp.h, doc/Makefile.in, Makefile.in, doc/Makefile.am: Major documentation update, more to come.
- plugins/rfc793.h, plugins/rfc793.c: Removed the bloody thread (which was causing so many problems) from the ack scan

Business::PayPal::SDK is an interface to paypals SDKs.

SYNOPSIS

use Business::PayPal::SDK;
my $pp = new Business::PayPal::SDK(
{
paypal_apiid => "sdk-seller_api1.sdk.com",
paypal_apipw => "12345678",
paypal_cert => "paypal_java_sdk/samples/Cert/sdk-seller.p12",
paypal_certpw => "password",
paypal_env => "sandbox",
java_sdk_dir => "/path/to/paypals/java/sdk",
}
);

my $res = $pp->SetExpressCheckout(
{
OrderTotal => 10.00,
ReturnURL => http:://mydomain.com/myreturn,
CancelURL => http:://mydomain.com/mycancel,
}
);

print $res->{token};

Business::PayPal::SDK is a perl interface to the SDK provided by paypal (http://www.paypal.com/sdk). You can use this module to implement paypal pro and paypal express transactions in perl. On the back end this modules uses Inline::Java to interface directly with the paypals java sdk. Consequently you will need to get a J2SDK and Inline::Java installed. This was done for 2 reasons. 1) Speed of development, didnt have to deal with all the SOAP stuff. 2) Easier maintanance regarding future changes. That is to say, I only have to make sure I keep this compatiable with paypals SDK, not thier underlying protocol changes.

This document assumes you have an understanding of the java SDK and API provided by PayPal.

All methods take a single hashref as an argument. All methods return a hashref, or undef if there is an internal failure of some sort. Check $ret->{ack} to see if the call to PayPal was successful. If $ret->{ack} is not Success than you can check the $res->{ErrorCodes}, this will be an hashref with the key being the error code from paypal and the value is the getLongMessage from the error. Check $obj->error for description of failure.

IPChains is a Perl module to create and manipulate ipchains via Perl.

SYNOPSIS

use IPChains;
$fw = IPChains->new(-option => value, ... ); $fw->append(chain);

This module acts as an interface to the ipchains(8) userspace utility by Paul "Rusty" Russell (http://www.rustcorp.com/linux/ipchains/). It attempts to include all the functionality of the original code with a simplified user interface via Perl. In addition, plans for log parsing facilities, an integrated interface to ipmasqadm, and possibly traffic shaping are slated for up and coming versions.
The new() and attribute() methods support the following options:

Source

Specifies origination address of packet. Appending hostmask to this address using a / is OK, as well as specifying it separately (see SourceMask).

SourceMask

Hostmask for origination address. Can either be in 24 or 255.255.255.0 style.

SourcePort

Specific port or port range (use xxx:xxx to denote range), requires specific protocol specification.

Dest

Specifies destination address of packet. Appending hostmask to this address using a / is OK, as well as specifying it separately (see DestMask)

DestMask

Destination address, (see SourceMask).

DestPort

Destination Port, (see SourcePort).

Prot

Protocol. Can be tcp, udp, icmp, or all. Required for specifying specific port(s).

ICMP

ICMP Name/Code (in place of port when ICMP is specified as protocol).

Here is a small table of some of the most common ICMP packets:

Number Name Required by

0 echo-reply ping
3 destination-unreachable Any TCP/UDP traffic.
5 redirect routing if not running
routing daemon
8 echo-request ping
11 time-exceeded traceroute

Rule

Target. Can be ACCEPT, DENY, REJECT, MASQ, REDIRECT, RETURN, or a user-defined chain. Note: This is case sensitive.

Interface

Specify a specify interface as part of the criteria (ie, eth0, ppp0, etc.).

Fragment

Rule only refers to second and further fragments of fragmented packets (1 or 0).

Bidir

Makes criteria effective in both directions (1 or 0).

Verbose

Set verbose option for setting rules or list() (1 or 0).

Numeric

Show output from list() in numeric format. No DNS lookups, etc.. (1 or 0).

Log

Enable kernel logging (via syslog, kern.info) of matched packets (1 or 0).

Output

Copy matching packets to the userspace device (advanced).

Mark

Mark matching packets with specified number (advanced).

TOS

Used for modifying the TOS field in the IP header. Takes 2 args, AND and XOR masks, (ie, (TOS => ["0x01", "0x10"])). This feature is highly untested.
The first mask is ANDed with the packets current TOS, and the second mask is XORed with it. Use the following table for reference:

TOS Name Value Typical Uses

Minimum Delay 0x01 0x10 ftp, telnet
Maximum Throughput 0x01 0x08 ftp-data
Maximum Reliability 0x01 0x04 snmp
Minimum Cost 0x01 0x02 nntp

Exact

Display exact numbers in byte counters instead of numbers rounded in Ks, Ms, or Gs (1 or 0).

SYN

Only match TCP packets with the SYN bit set and the ACK and FIN bits cleared (1 or 0).