Free tightly software for linux

Tightly secured firewall for general use is an iptables firewall script.

Sample:

#!/bin/sh
echo "Initializing modules..."
cd /lib/modules/2.4.1/kernel/net/ipv4/netfilter
insmod ip_tables
insmod ip_conntrack
insmod ipt_state
insmod ipt_limit
#insmod iptable_mangle
#insmod ipt_PERS
echo "Flushing rules.."
#iptables -F PREROUTING
#iptables -t mangle -F OUTPUT
iptables -F INPUT
iptables -F FORWARD
iptables -F OUTPUT
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
if [ "$1" == "start" ]; then
echo "Setting up spoof protection..."
for blah in /proc/sys/net/ipv4/conf/*/rp_filter; do
echo "1" > $blah
done
echo "Setting default routes..."
iptables -P INPUT DROP
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
echo "Configuring external interface rulesets..."
#iptables -t mangle -A PREROUTING -j PERS --local --tweak dst --conf /etc/win9x.conf
#iptables -t mangle -A OUTPUT -j PERS --local --tweak src --conf /etc/win9x.conf
iptables -A INPUT -i eth0 -s 127.0.0.0/8 -j DROP
iptables -A INPUT -i eth0 -s 10.0.0.0/8 -j DROP
iptables -A INPUT -i eth0 -s 255.255.255.255/32 -j DROP
iptables -A INPUT -i eth0 -s 0.0.0.0/8 -j DROP
iptables -A INPUT -i eth0 -s 169.254.0.0/16 -j DROP
iptables -A INPUT -i eth0 -s 172.16.0.0/12 -j DROP
iptables -A INPUT -i eth0 -s 192.0.2.0/24 -j DROP
iptables -A INPUT -i eth0 -s 192.168.0.0/16 -j DROP
iptables -A INPUT -i eth0 -s 224.0.0.0/4 -j DROP
iptables -A INPUT -i eth0 -s 240.0.0.0/5 -j DROP
iptables -A INPUT -i eth0 -s 248.0.0.0/5 -j DROP
iptables -A INPUT -i eth0 -f -j DROP
iptables -A INPUT -i eth0 -p TCP -m state --state INVALID -j DROP
iptables -A INPUT -i eth0 -p TCP --syn -m limit --limit 1/s -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 1024:5000 --dport 20 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 1024:5000 --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 1024:5000 --dport 23 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 1024:5000 --dport 25 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 1024:5000 --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 1024:5000 --dport 110 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 1024:5000 --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 1024:5000 --dport 113 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 1024:5000 --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT
#iptables -A INPUT -i eth0 -p TCP -s 0/0 --sport 1024:5000 -d 0/0 --dport 1998 -j ACCEPT
#iptables -A INPUT -i eth0 -p TCP -s 0/0 --sport 1024:5000 -d 0/0 --dport 1999 -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --dport 32768:61000 -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 32768:61000 --dport 20 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 32768:61000 --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 32768:61000 --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 32768:61000 --dport 23 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 32768:61000 --dport 25 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 32768:61000 --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 32768:61000 --dport 110 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 32768:61000 --dport 113 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 32768:61000 --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT
#iptables -A INPUT -i eth0 -p TCP --sport 32768:61000 --dport 1998 -j ACCEPT
#iptables -A INPUT -i eth0 -p TCP --sport 32768:61000 --dport 1999 -j ACCEPT
#iptables -A INPUT -i eth0 -p UDP -j DENY
iptables -A INPUT -i eth0 -p UDP -s 0/0 --sport 53 -j ACCEPT
#iptables -A INPUT -i eth0 -p UDP -s 0/0 --dport 53 -j ACCEPT
#iptables -A INPUT -i eth0 -p UDP -s 0/0 --sport 161 -j ACCEPT
iptables -A INPUT -i eth0 -p UDP -s 0/0 --sport ntp -j ACCEPT
iptables -A INPUT -i eth0 -p UDP -s 0/0 --dport ntp -j ACCEPT
iptables -A INPUT -i eth0 -p ICMP --icmp-type echo-reply -j ACCEPT
echo "Configuring routing rulesets..."
iptables -A FORWARD -i eth0 -d 205.188.153.139/32 -j DROP
iptables -A FORWARD -i eth0 -d 205.188.153.140/32 -j DROP
iptables -A FORWARD -i eth0 -d 205.188.153.141/32 -j DROP
iptables -A FORWARD -i eth0 -d 205.188.7.168/32 -j DROP
iptables -A FORWARD -i eth0 -d 205.188.7.164/32 -j DROP
iptables -A FORWARD -i eth0 -d 205.188.7.178/32 -j DROP
iptables -A FORWARD -i eth0 -d 205.188.7.172/32 -j DROP
iptables -A FORWARD -i eth0 -d 205.188.7.176/32 -j DROP
iptables -A FORWARD -i eth0 -d 205.188.5.208/32 -j DROP
iptables -A FORWARD -i eth0 -d 205.188.4.159/32 -j DROP
iptables -A FORWARD -i eth0 -d 205.188.3.160/32 -j DROP
iptables -A FORWARD -i eth0 -d 205.188.3.176/32 -j DROP
iptables -A FORWARD -i eth0 -d 205.188.5.204/32 -j DROP
iptables -A FORWARD -i eth0 -d 205.188.153.139/32 -j DROP
iptables -A FORWARD -i eth0 -d 209.185.128.132/32 -j DROP
iptables -A FORWARD -i eth0 -d 152.163.241.128/32 -j DROP
iptables -A FORWARD -i eth0 -d 152.163.242.24/32 -j DROP
iptables -A FORWARD -i eth0 -d 152.163.242.28/32 -j DROP
iptables -A FORWARD -i eth0 -d 152.163.241.120/32 -j DROP
iptables -A FORWARD -i eth0 -p TCP --sport 1024: --dport 9898 -j DROP
iptables -A FORWARD -i eth0 -d 10.0.0.0/8 -j DROP
iptables -A FORWARD -i eth0 -d 127.0.0.0/8 -j DROP
iptables -A FORWARD -i eth0 -p igmp -j DROP
iptables -A FORWARD -i eth0 -p TCP --syn -m limit --limit 10/s -j ACCEPT
iptables -A FORWARD -i eth0 -p TCP --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 10/s -j ACCEPT
echo "Configuring internal interface rulesets..."
iptables -A INPUT -i lo -j ACCEPT
echo "IPtables firewall configuration completed."
fi

Major Features:

1. Better Thunderbird integration
2. emailtask linkage
3. Integration with the Thunderbird address book
4. iMIP support (meeting invitations)
5. Improved CalDAV support
6. Cached calendar support for offline calendar use
7. Device synchronization

Enhancements:

• Events spanning days now have a visual indicator indicating them as connected events
• When reloading a remote calendar a progress indicator is now shown
• The so-called "minimonth" (small calendar month in the upper left) has been given a visual overhaul
• The calendar views (day, week, multiweek, month) have been given a visual overhaul
• The today pane can now be displayed in calendar mode and task mode as well
• CalDAV support and interoperability with various CalDAV servers has been improved
• iMip/iTip support (support for email invitations) has been greatly improved
• The application stability and memory consumption has been greatly improved
• Lightning 0.9 is intended to be the last release for the Thunderbird 2 series. For the future we are planning to integrate Lightning fully into the upcoming Thunderbird 3 release
• A full list of changes that have gone into this release can be found on The Rumbling Edge website

Requirements:

• Software Requirements Please note that Linux distributors may provide packages for your distribution which have different requirements.
• • Linux kernel - 2.2.14 or higher with the following libraries or packages:
  • glibc 2.3.2 or higher
  • XFree86-3.3.6 or higher
  • gtk+2.0 or higher
  • fontconfig (also known as xft)
  • libstdc++5 (Many modern Linux distributions only package libstdc++6, which is incompatible with Lightning. Therefore please install the package "libstdc++5" or "compat-libstdc++" on your system before installing Lightning)
• Minimum Hardware
• • Intel Pentium II or AMD K6-III+ 233 MHz CPU (Recommended: 500MHz or greater)
  • 64 MB RAM (Recommended: 128 MB RAM or greater)
  • 52 MB hard drive space

FTwall is short for Fast Track traffic Firewall, a P2P traffic filtering script, for Kazaa blocking.
Ftwall-2 is an updated version of the original ftwall-1 software which adds new P2p protocols to the set it can control.
Ftwall-2 is an add-on for linux firewalls that allows the control of "Fast Track" peer-to-peer traffic (such as is used by "Kazaa" and its derivatives), WinMX and others using the OpenNAP protocol.
It is designed to block network traffic from P2P client applications running in the "home" (or "green") network from making access to any peers on the public internet. It is designed primarily for use in networks where the security reigme allows "open access" for outbound connections and "tightly limited" access for inbound ones. Ftwall-2 can be used in networks like this to prevent outbound P2P access from the supported protocols, hence restricting illegal file downloads and uploads.
A Fast track "home network" client that establishes an "outbound" connection is (worryingly) immediately available to accept inbound connections through the established TCP/IP socket - even if the gateway firewall blocks all in-bound connections via "normal" TCP/IP and UDP mechanisms. This is a kind of limited "tunnelling" and gives rise to a number of concerns. Other P2P applications and protocols present similar security challenges. Ftwall solves this (and other) problems for the protocols it understands.
Version 1 of ftwall controlled the Fast Track protocol only (Kazaa et al).
Version 2 of ftwall (the version discussed on this page) adds logic to allow blocking of traffic from WinMX and OpenNap clients using a mechanism based on DNS name wildcards. One simple example is the control of WinMXs native protocol which can be blocked by preventing access to IP addresses resolved from any domain name that ends "winmx.com". OpenNAP is similarly controlled using DNS wildcards to "train" ftwall. See the man page (etc) for these new features by following the links at the bottom of the page.
FTwall-2 runs on Linux-based firewalls using kernel 2.4 (tested with 2.4.20) or later and iptables (test with version 1.2.6). This combination of version numbers is the current set employed by RedHat 8.0 - which is the system on which the software has been developed. The software has also been tested briefly on RedHat 9 and Fedora - but I am awaiting more in-depth news of these and other Linux distributions.
FTwall-2 runs well on the "ipcop" firewall, version 1.3.0 (GPL) with the QUEUE target and string match modules added manually. I believe that it will similarly run on Smoothwall 2 (GPL) although I have not tested this. It will NOT run on Smoothwall 1.0 since this is an "ipchains" based firewall, not an "iptables" one.
FTwall-2 has been tested with the following P2P client applications:
Kazaa 2.1.1, 2.5-beta2, 2.5.1
Kazaa Lite 2.0.2, K++ 2.4.3
iMesh 4.1 build 132, 4.2 build 138
Grokster 1.7
WinMX 3.31
Version restrictions:
- Ftwall requires Linux kernel version 2.4, equipped with "iptables" and the "QUEUE" target. The "ip_string" match module of iptables is desirable, but not required.
- Ftwall works with the "current" version of the Fast track, WinMX and OpenNAP network protocols at the time of writing (July 2004). It is possible that it will need to be re-worked if the protocols are changed in future.
- Ftwall does not block the "SOCKS PROXY" connection option of FastTrack. For a complete lock-down, the firewall must block this style of traffic.

The doorman guards the door of a server, manipulating firewall rules to admit only recognized parties.
The doorman is intended to run on systems which have their firewall rules turned down tightly enough as to be effectively invisible to the outside world. The doorman adds and removes extra rules in a very controlled manner.
Using metaphor 1...
The doorman daemon "guards the door" of a host, admitting only recognized parties. It allows a server which is not intended for general public access to run with all of its TCP ports closed to the outside world. A matching "knocker" is provided, with which to persuade the doorman to open the door a crack, just wide enough for a single TCP connection from a single IP address.
And now, switching to metaphor 2... :)
A private server thus rigged for silent running has greatly enhanced security. Port scans cannot reveal its existence. Even if its existence is known by other means (or the firewall isnt all that tight), possible bugs in server code cannot be exploited; packets from unknown sources simply never get to the bug.
The current implementation of the doorman, "doormand", is suitable for protecting only TCP services on Unix-type systems. The door-knocker, "knock", can be run under Unix, GNU/Linux, or Microsoft Windows.
The doorman is based on an original idea of Martin Krzywinski, who proposed watching firewall logs for a sequence of packets directed to closed ports, which method he described in Sysadmin magazine and linuxjournal.com.
You might also visit his pages at www.portknocking.org.
This particular implementation deviates a bit from his original proposal, in that the doorman watches for only a single UDP packet. To get the doorman to open up, the packet must contain an MD5 hash which correctly hashes a shared secret, salted with a 32-bit random number, the identifying user or group-name, and the requested service port-number.
Enhancements:
- Added support for linux cooked socket header len; thanks to Markus Hoffmann.
- Fixed guestlist hostname-parsing bug; also thanks to Markus.
- Changed method of remembering old knock hashes, without use of Berkeley DB.
- Kinda-fixed a bug handling pcapnext-returns-null condition. I hope.
- Included lexer.c (flex output from lexer.l) in distribution. Duh.
- Fixed doorman bug when creating new new hashfile; thanks to Robert Koropcak
- No changes made to knock.c; however, it will report being V0.81

Inflex is a solution to the problem of scanning emails which are passing through your server, both local and outbound.
Inflex give to you the ability to block or pass email based on any set of tests you choose, varying from Virus scans to Email text content.
Inflex can do this because it unpacks all email sent through it in such a way that normal UNIX tests can be performed to determine the nature of the email.
The need for a system as Inflex arose out of the need to be able to tightly control and filter emails at a central location, existing scanning systems could only scan local mail.
Local mail only scanning is a serious limitation when a corporation is trying to prevent unwanted email from getting out to the world.
Inflexs ability to scan for arbitary file names and types allows administrators to react instantly to virus threats which may not yet be detectable in antivirus packages [typical
delays between virus deployment and antivirus updates can be as long as 48 hours, more than ample to cause an entire network to be crippled].
Installation:
./install.sh
Enhancements:
- Updated ripMIME engine
- Added Fedora support
- Added HBEV AV support

Sort::Versions is a Perl 5 module for sorting of revision-like numbers.

SYNOPSIS

use Sort::Versions;
@l = sort { versioncmp($a, $b) } qw( 1.2 1.2.0 1.2a.0 1.2.a 1.a 02.a );

...

use Sort::Versions;
print lower if versioncmp(1.2, 1.2a) == -1;

...

use Sort::Versions;
%h = (1 => d, 2 => c, 3 => b, 4 => a);
@h = sort { versioncmp($h{$a}, $h{$b}) } keys %h;

Sort::Versions allows easy sorting of mixed non-numeric and numeric strings, like the version numbers that many shared library systems and revision control packages use. This is quite useful if you are trying to deal with shared libraries. It can also be applied to applications that intersperse variable-width numeric fields within text. Other applications can undoubtedly be found.

For an explanation of the algorithm, its simplest to look at these examples:

1.1 < 1.2
1.1a < 1.2
1.1 < 1.1.1
1.1 < 1.1a
1.1.a < 1.1a
1 < a
a < b
1 < 2
1.1-3 < 1.1-4
1.1-5 < 1.1.6

More precisely (but less comprehensibly), the two strings are treated as subunits delimited by periods or hyphens. Each subunit can contain any number of groups of digits or non-digits. If digit groups are being compared on both sides, a numeric comparison is used, otherwise a ASCII ordering is used. A group or subgroup with more units will win if all comparisons are equal. A period binds digit groups together more tightly than a hyphen.

Some packages use a different style of version numbering: a simple real number written as a decimal. Sort::Versions has limited support for this style: when comparing two subunits which are both digit groups, if either subunit has a leading zero, then both are treated like digits after a decimal point. So for example:

0002 < 1
1.06 < 1.5

This wont always work, because there wont always be a leading zero in real-number style version numbers. There is no way for Sort::Versions to know which style was intended. But a lot of the time it will do the right thing. If you are making up version numbers, the style with (possibly) more than one dot is the style to use.

USAGE

The function versioncmp() takes two arguments and compares them like cmp. With perl 5.6 or later, you can also use this function directly in sorting:

@l = sort versioncmp qw(1.1 1.2 1.0.3);

The function versions() can be used directly as a sort function even on perl 5.005 and earlier, but its use is deprecated.

Dream Print Tracking System is a powerful and user-friendly system for tracking print distribution and circulation.
It uses many principles from customer relationship management (CRM) systems, but in a way specific to print publishers.
The Media Development Loan Fund commissioned Dream based on its experience in working with print publishers in more than 30 countries worldwide, where it provides support to independent media in the form of financing, training and technology.
In many of these countries, print distribution is one of the biggest difficulties independent publishers face because it is tightly controlled. Many countries have print distribution monopolies or cartels, which are either politically tied to the government, corrupt or incompetent.
Dream is a tool for tracking print circulation. In a similar way to customer relationship management (CRM) systems such as Campwares Cream software, Dream allows you to maintain a clear picture of your distribution business based on regularly entered contracts, orders, and shipment information. This is handled primarily through Dreams Report functions. Dream is designed to look and feel like an email application. Its inbox is used for tracking inbound communications such as new customer e-mails and customer phone calls.
Because Dream works with any standard SMTP mail server, it also manages outbound customer communications and keeps records of your responses.
Dream does two things: It is a database that stores all the relevant information you supply about the publications you produce, who distributes, who sells it, and how you connect with these people.
It is also a tool for retrieving and presenting this information in several different ways. It contains utilities for tracking products, promotions, and communications.
Dream handles four types of information:
1. Information about what you produce and the people to whom you provide it. This information is entered on the Options tab of the screen and appears primarily in the menus on the Main tabs screens. One example is a product category in which you describe a periodical you produce.
2. Information about specific products such as books or individual issues of what you produce, specific distributors and specific sellers, and tracking of these items from contract to order to shipment to return.
3. Communications, including records of incoming messages from various sources, outgoing emails to individuals, and newsletters.
4. User information including usernames, passwords, preferences and permissions.
Enhancements:
- Minor bugfixes were made.
- A Russian localization was added.

subPersistence is an abstract, light-weight yet flexible framework for working with O/R persistence mappers. It provides for independence of a specific O/R mapper such as Hibernate or Castor.
While you can use Hibernate or Castor (or other O/R mappers) directly, coupling your application too tightly to those can be a bad thing. subPersistence makes it easy to switch underlying O/R mappers, thereby decoupling the application layer from those.
It abstracts away differences between the mappers, while still making it possible to use their specific features if needed.
Enhancements:
- This version updates to Java 5 features such as Generics and is the first version to require Hibernate 3.