Free duplicate icmp echo reply software for linux

Duplicate Music Matcher is a script to quickly find duplicate MP3 files based on letter matching.
Duplicate Music Matcher is helpful for weeding out duplicates that may not be of the same encoding, format, or even the same filename.
Enhancements:
- pymad pyvorbis python-flac deps were all removed in favor of mutagen
- GUI code was updated (no more SimpleGladeApp)
- Delete key have been bound in the GUI
- More accurate matching for ogg and flac files
- The filename column is now resizable
- The GUI play and stop buttons now use audacious.FLAC should now also give a length value
- Some oggs might have a huge bitrate value due to a bug in mutagen.

Packet filtering setup script by Anthony C. Zboralski. Adapted by Didi Damian for iptables version 1.0.0

Sample:

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# Set up variables
EXT_IF="eth0"
INT_IF="eth1"
EXT_IP=24.x.x.x/32
INT_IP=192.168.0.1/32
EXT_NET=24.x.x.0/24
INT_NET=192.168.0.0/24
MASQ_NETS="192.168.0.0/24"
LOCAL_ADDRS="127.0.0.0/8 192.168.0.1/32 24.x.x.x/32"
MAIL_RELAY=24.x.x.x/32
SMB_ACCESS="192.168.0.2/32"
SMB_BCAST="192.168.0.255/32"

# Turn on IP forwarding
echo Turning on IP forwarding.
echo 1 > /proc/sys/net/ipv4/ip_forward

# Load the ip_tables module
echo Loading ip_tables module.
/sbin/modprobe ip_tables || exit 1
# I let the kernel dynamically load the other modules

echo Flush standard tables.
iptables --flush INPUT
iptables --flush OUTPUT
iptables --flush FORWARD
echo Deny everything until firewall setup is completed.
iptables --policy INPUT DROP
iptables --policy OUTPUT DROP
iptables --policy FORWARD DROP

CHAINS=`iptables -n -L |perl -n -e /Chains+(S+)/ && !($1 =~ /^(INPUT|FORWARD|OUTPUT)$/) && print "$1 "`
echo Remove remaining chains:
echo $CHAINS
for chain in $CHAINS; do
iptables --flush $chain
done
# 2nd step cause of dependencies
for chain in $CHAINS; do
iptables --delete-chain $chain
done

for net in $MASQ_NETS; do
# I delete all the rules so you can rerun the scripts without bloating
# your nat entries.
iptables -D POSTROUTING -t nat -s $MASQ_NETS -j MASQUERADE 2>/dev/null
iptables -A POSTROUTING -t nat -s $MASQ_NETS -j MASQUERADE || exit 1
done
iptables --policy FORWARD ACCEPT

# Create a target for logging and dropping packets
iptables --new LDROP 2>/dev/null
iptables -A LDROP --proto tcp -j LOG --log-level info
--log-prefix "TCP Drop "
iptables -A LDROP --proto udp -j LOG --log-level info
--log-prefix "UDP Drop "
iptables -A LDROP --proto icmp -j LOG --log-level info
--log-prefix "ICMP Drop "
iptables -A LDROP --proto gre -j LOG --log-level info
--log-prefix "GRE Drop "

iptables -A LDROP -f -j LOG --log-level emerg
--log-prefix "FRAG Drop "
iptables -A LDROP -j DROP

# Create a table for watching some accepting rules
iptables --new WATCH 2>/dev/null
iptables -A WATCH -m limit -j LOG --log-level warn --log-prefix "ACCEPT "
iptables -A WATCH -j ACCEPT


echo Special target for local addresses:
iptables --new LOCAL 2>/dev/null
echo $LOCAL_ADDRS
for ip in $LOCAL_ADDRS; do
iptables -A INPUT --dst $ip -j LOCAL
# iptables -A INPUT --src $ip -i ! lo -j LDROP # lame spoof protect
done
echo Authorize mail from mail relay.
iptables -A LOCAL --proto tcp --syn --src $MAIL_RELAY --dst $EXT_IP --dport 25 -j ACCEPT


echo Authorizing samba access to:
echo $SMB_ACCESS
iptables --new SMB 2>/dev/null
for ip in $SMB_ACCESS; do
iptables -A SMB -s $ip -j ACCEPT
done
iptables -A LOCAL --proto udp -i ! $EXT_IF --dport 135:139 -j SMB
iptables -A LOCAL --proto tcp -i ! $EXT_IF --dport 135:139 -j SMB
iptables -A LOCAL --proto tcp -i ! $EXT_IF --dport 445 -j SMB
iptables -A INPUT -i ! $EXT_IF --dst $SMB_BCAST -j ACCEPT #lame samba broadcast

echo Drop and log every other incoming tcp connection attempts.
iptables -A LOCAL -i ! lo --proto tcp --syn --j LDROP

echo Authorize dns access for local nets.
for net in $MASQ_NETS 127.0.0.0/8; do
iptables -A INPUT --proto udp --src $net --dport 53 -j ACCEPT
done


echo Enforcing up ICMP policies, use iptables -L ICMP to check.
# If you deny all ICMP messages you head for trouble since it would
# break lots of tcp/ip algorythm (acz)
iptables --new ICMP 2>/dev/null
iptables -A INPUT --proto icmp -j ICMP
iptables -A ICMP -p icmp --icmp-type echo-reply -j ACCEPT
iptables -A ICMP -p icmp --icmp-type destination-unreachable -j WATCH
iptables -A ICMP -p icmp --icmp-type network-unreachable -j WATCH
iptables -A ICMP -p icmp --icmp-type host-unreachable -j WATCH
iptables -A ICMP -p icmp --icmp-type protocol-unreachable -j WATCH
iptables -A ICMP -p icmp --icmp-type port-unreachable -j ACCEPT
iptables -A ICMP -p icmp --icmp-type fragmentation-needed -j LDROP
iptables -A ICMP -p icmp --icmp-type source-route-failed -j WATCH
iptables -A ICMP -p icmp --icmp-type network-unknown -j WATCH
iptables -A ICMP -p icmp --icmp-type host-unknown -j WATCH
iptables -A ICMP -p icmp --icmp-type network-prohibited -j WATCH
iptables -A ICMP -p icmp --icmp-type host-prohibited -j WATCH
iptables -A ICMP -p icmp --icmp-type TOS-network-unreachable -j WATCH
iptables -A ICMP -p icmp --icmp-type TOS-host-unreachable -j WATCH
iptables -A ICMP -p icmp --icmp-type communication-prohibited -j WATCH
iptables -A ICMP -p icmp --icmp-type host-precedence-violation -j LDROP
iptables -A ICMP -p icmp --icmp-type precedence-cutoff -j LDROP
iptables -A ICMP -p icmp --icmp-type source-quench -j LDROP
iptables -A ICMP -p icmp --icmp-type redirect -j LDROP
iptables -A ICMP -p icmp --icmp-type network-redirect -j LDROP
iptables -A ICMP -p icmp --icmp-type host-redirect -j LDROP
iptables -A ICMP -p icmp --icmp-type TOS-network-redirect -j LDROP
iptables -A ICMP -p icmp --icmp-type TOS-host-redirect -j LDROP
iptables -A ICMP -p icmp --icmp-type echo-request -j WATCH
iptables -A ICMP -p icmp --icmp-type router-advertisement -j LDROP
iptables -A ICMP -p icmp --icmp-type router-solicitation -j LDROP
iptables -A ICMP -p icmp --icmp-type time-exceeded -j WATCH
iptables -A ICMP -p icmp --icmp-type ttl-zero-during-transit -j WATCH
iptables -A ICMP -p icmp --icmp-type ttl-zero-during-reassembly -j WATCH
iptables -A ICMP -p icmp --icmp-type parameter-problem -j WATCH
iptables -A ICMP -p icmp --icmp-type ip-header-bad -j WATCH
iptables -A ICMP -p icmp --icmp-type required-option-missing -j WATCH
iptables -A ICMP -p icmp --icmp-type timestamp-request -j LDROP
iptables -A ICMP -p icmp --icmp-type timestamp-reply -j LDROP
iptables -A ICMP -p icmp --icmp-type address-mask-request -j LDROP
iptables -A ICMP -p icmp --icmp-type address-mask-reply -j LDROP
iptables -A ICMP -p icmp -j LDROP

echo Authorize tcp traffic.
iptables -A INPUT --proto tcp -j ACCEPT

echo Authorize packet output.
iptables --policy OUTPUT ACCEPT

#echo reject ident if you drop em you gotta wait for timeout
#iptables -I LOCAL --proto tcp --syn --dst $EXT_IP --dport 113 -j REJECT

echo Drop and log all udp below 1024.
iptables -A INPUT -i ! lo --proto udp --dport :1023 -j LDROP

echo Drop rpc dynamic udp port:
RPC_UDP=`rpcinfo -p localhost|perl -n -e /.*udps+(d+)s+/ && print $1,"n"|sort -u`
echo $RPC_UDP
for port in $RPC_UDP; do
iptables -A LOCAL -i ! lo --proto udp --dport $port -j LDROP
done

echo Authorize udp above 1024.
iptables -A INPUT --proto udp --dport 1024: -j ACCEPT

Duplidel finds and removes the duplicate messages that often occur when downloading email from multiple accounts.

Duplidel supports maildir and mbox formats. It works, seems quite stable, and makes a backup of your email before doing anything to it.

Echo is a framework for developing object-oriented, event-driven Web applications.
Echo removes the developer from having to think in terms of "page-based" applications and enables him/her to develop applications using the conventional object-oriented and event-driven paradigm for user interface development.
Knowledge of HTML, HTTP, and JavaScript is not required. Echo is open-source software distributed under the terms of the Mozilla Public License or the GNU LGPL License.
Enhancements:
- Version 1.1.4 adds support for specifying the order of tab-based navigation of components. The release also fixes bugs reported in previous versions, including the issues discovered with setting component focus.

Check Your Network Address Translator for Compatibility with Peer-to-Peer Protocols.
If you are accessing the Internet from behind a Network Address Translator (NAT) of some kind, I would appreciate your help in surveying the behavior of different NATs, in terms of how and whether they support a certain technique for enabling peer-to-peer communication between NATted hosts (particularly when both endpoints are behind NATs). Down, you can understand what NAT is.
Suppose there are three communicating hosts: A, B, and C. Host A is a "well-known" Internet server with a permanent IP address, which acts as an "introducer" for the other two nodes. (For example, Host A might be a well-known ultrapeer or a game catalog server of some kind.) Host B, using Host As "introduction" services, would like to establish a direct peer-to-peer connection with host C. Both B and C, however, are behind (probably different) network address/port translators, and neither of them has exclusive use of any public IP address.
To initiate a peer-to-peer connection with host C, host B first sends A a message requesting an "introduction" to host C. A sends B a reply message containing Cs IP address and UDP port number as reported by host C, in addition to Cs IP address and UDP port number as observed by A. (If C is behind a NAT, then these two address/port combinations will be different.) At the same time, host A sends host C a message containing Bs IP address and UDP port numbers - again, both the ones reported by B and the ones observed by A, which will be different if B is behind a NAT.
Now B and C each know that they want to initiate a connection with each other, and they know each others public (NATted) as well as original IP addresses and UDP port numbers. Both B and C now start attempting to send UDP messages directly to each other, at each of the available addresses. If B and C happen to be behind the same NAT, then they will be able to communicate with each other directly using their "originally reported" IP addresses and UDP port numbers.
In the more common case where B and C are behind different NATs, the "originally reported" addresses will be useless because they will both be private IP addresses in different addressing domains. Instead, the IP address/UDP port combinations observed by A can be used in this case to establish direct communication. Although Bs NAT will initially filter out any UDP packets arriving from Cs public (NATted) UDP port directed at Bs public port, the first UDP message B sends to C will cause Bs NAT to open up a new UDP session keyed on Cs public port, allowing future incoming traffic from C to pass through the NAT to B. Similarly, the first few messages from B to C may be filtered out by Cs NAT, but will be able to start passing through the firewall as soon as Cs first message to B causes Cs NAT to open up a new session. In this way, each NAT is tricked into thinking that its respective internal host is the "initiator" of this new session, when in fact the session is fully symmetrical and was initiated (with As help) simultaneously in each direction.
Required NAT Behavior
There is one important requirement that the NATs must satisfy in order for this technique to work: the NATs must be designed so that they assign only one (public IP address, public UDP port) pair to each (internal IP address, internal UDP port) combination, rather than allocating and assigning a new public UDP port for each new UDP session. Recall that a "session" in Internet terminology is defined by the IP addresses and port numbers of both communicating endpoints, so host Bs communication with host A is considered to be one session while host Bs communication with host C is a different session. If Bs NAT, for example, assigns one public UDP port for Bs communication with A, and then assigns B a different public UDP port for the new session B tries to open up with C, then the above technique for peer-to-peer communication will not work because Cs messages to B will be directed to the wrong UDP port.
RFC 3022 explicitly allows and suggests that NATs behave in the former, "desirable" fashion, by maintaining a single (public IP, public port) mapping for a given (internal IP, internal port) combination independent of the number of active sessions involving this mapping. This behavior is not only good for compatibility with UDP applications, but it also helps to conserve the NATs scarce pool of public port numbers. Maintaining a consistent public port mapping does not adversely affect security in any way, either, because incoming traffic can still be filtered on a per-session basis regardless of how addresses are translated. There in fact appears to be no good reason not to implement the desirable behavior in a NAT, except perhaps for the implementation simplicity of naively allocating a new public port for every new session. Unfortunately, RFC 3022 does not require NATs to implement the desirable behavior, which has led me to wonder just how many real NATs actually do, and hence this page.
What NAT Check Does
The program natcheck.c is basically just a program that "pings" a well-known UDP port at two different servers that are publically accessible on the Internet. Both of these servers run the program natserver.c, with the command-line arguments "1" and "2" respectively. In addition, there a third "conspiring" server runs natserver with the command-line argument "3". Whenever each of the first two servers receives a UDP request, it not only sends a reply directly to the sender of that request, but also sends a message to the third server, which in turn "bounces" the reply back to the original client. The effect is that the client will receive not only solicited "ping" replies from the server the request was directed to, but also "unsolicited" replies from the third server.
To determine if the network address translator in use is implementing the desirable behavior of maintaining a single (public IP address, public port) mapping for a given (client IP address, client port), the client program natcheck.c basically just initiates a sequence of simultaneous pings to the first two servers (in case some of the requests or replies are lost in transit) and checks that the clients address and UDP port as reported by both servers is the same. If the NAT naively allocates a new public port for each new session, then the source port as reported by the two servers will be different, and its time to upgrade your NAT.
The replies echoed from the third server are used only to check whether the NAT properly filters out unsolicited incoming traffic on a per-session basis. Since the client never sends any messages to the third server, if the NAT is properly implementing firewall functionality, the client should never see the third servers echoed replies even after opening up active communication sessions with the first two servers.
Enhancements:
- The NAT Check client no longer attempts to guess whether you have Basic NAT or Network Address/Port Translation (NAPT). It turns to be quite difficult to test for this property reliably, because many NAPTs attempt to bind a private UDP port to a public port with the same port number if that port number is available, causing NAT Check to falsely report Basic NAT. The only way to test for this property reliably would be to run NAT Check on at least two client machines simultaneously, and since this property isnt terribly important to P2P apps its just not worth the trouble.
- The NAT Check client now tests for one additional NAT feature, which I call loopback translation. If a NAT supports loopback translation, it means that a host on the private network behind the NAT can communicate with other hosts on the same private network using public (translated) port bindings assigned by the NAT. Most NATs probably do not support this feature yet, but it may become increasingly important in the future where P2P clients may be located behind a common ISP-deployed NAT as well as individual home NATs. More details on loopback translation will appear in the next version of my Internet-Draft, to be released soon.
- The NAT Check client program now has a command-line option, "-v", which turns on verbose messages during the test.

Host enumeration is the act of determining the IP address of potential targets on a network. This can be done in both layer 2 and layer 3. Icmpenum project can send ICMP traffic for such enumeration.

The ICMP packets supported are: Echo, Timestamp, Information and Netmask. Furthermore, it supports spoofing and promiscuous listening for reply packets. Icmpenum is great for enumerating networks which allow ICMP traffic.

Icmpenum sends ICMP traffic to potential targets on a network.
Introduction:
Host enumeration is the act of determining the IP address of potential targets on a network. This can be done in both layer 2 and layer 3. Icmpenum sends ICMP traffic for such enumeration. The ICMP packets supported are: Echo, Timestamp, Information and Netmask. Furthermore, it supports spoofing and promiscuous listening for reply packets. Icmpenum is great for enumerating networks which allow ICMP traffic.
Installation:
1. Install the latest libpcap (libpcap 0.4, ftp://ftp.ee.lbl.gov/libpcap.tar.Z).
2. Install the latest Libnet (http://www.packetfactory.net/libnet/).
3. Compile icmpenum as follows:
gcc `libnet-config --defines` -o icmpenum icmpenum.c -lnet -lpcap
4. Copy icmpenum to your fave directory and (as root) start enumerating.
Usage:
Running icmpenum -h gives you the following screen:
# ./icmpenum -h
USAGE: ./icmpenum [opts] [-c class C] [-d dev] [-i 1-3] [-s src] [-t sec] hosts
opts are h n p r v
-h this help screen
-n no sending of packets
-p promiscuous receive mode
-r receiving packets only (no
-v verbose
-c class C in x.x.x.0 form
-i icmp type to send/receive, types include the following:
1 echo/echo reply (default)
2 timestamp request/reply
3 info request/reply
-d device to grab local IP or sniff from, default is eth0
-s spoofed source address
-t time in seconds to wait for all replies (default 5)
host(s) are target hosts (ignored if using -c)
Examples:
Here are some example uses of icmpenum to enumerate hosts.
Example 1:
[Host1]# icmpenum 192.168.1.1 192.168.1.2
This will use the default of Echo packets to try and determine if
192.168.1.1 and 192.168.1.2 are up and running.
Example 2:
[Host1]# icmpenum -i 2 -v 192.168.100.100 192.168.100.200
This will enumerate the two hosts using Timestamp packets in
verbose mode.
Example 3:
[Host1]# icmpenum -i 3 -s 10.10.10.10 -p -v 192.168.1.1 192.168.1.2
This will enumerate hosts 192.168.1.1 and 192.168.1.2 using
Information packets with a spoofed address of 10.10.10.10, since our real address is 10.10.10.11 we use the -p option to listen for the replies.
Here are some more advanced uses of icmpenum.
Example 4:
Assuming Host1 is 6.6.6.6 and Host2 is 7.7.7.7, and that the network 1.1.1.0 has potential hosts to enumerate, we use the following two entries to enumerate with Information packets:
[Host2]# icmpenum -r -t 30 -i 3 -c 1.1.1.0
[Host1]# icmpenum -s 7.7.7.7 -i 3 -c 1.1.1.0
Host2 starts first in receive mode with a timeout of 30 seconds and starts listening for Information packets from the 1.1.1.0 network. Then Host1 starts sending spoofed packets with Host2 as the source address, sending exactly what Host2 is listening for. It should be noted that this is hardly stealthy, as logs at 1.1.1s site could have 7.7.7.7s address all over them, but the -r function is good for testing.
Example 5:
Assuming Host1 is 6.6.6.6 and Host2 is 7.7.7.7, and that Host2 can sniff traffic between 1.1.1.0 and 2.2.2.0, we use the following entries to enumerate the 1.1.1.0 network:
[Host2]# icmpenum -t 20 -n -p -i 2 -c 1.1.1.0
[Host1]# icmpenum -s 2.2.2.2 -i 2 -c 1.1.1.0
Host2 starts first with a timeout of 20 seconds, makes sure not to send the packets with the -n option, listens promiscuously for Timestamp packets from the 1.1.1.0 network. Host1 sends the exact packets Host2 is listening for with a 2.2.2.2 spoofed source address. Yes, one could simply replace the -n option in Host2s command line with -s 2.2.2.2 and do the same thing from one workstation, but were demonstrating a distributed concept.
Enhancements:
- I have added ICMP MASK (type 17 and 18) requests and replys. Simply use the -i 4 option on the command line, such as; icmpenum -i 4 -c 1.2.3.1 (sends ICMP MASK requests to the Class C range 1.2.3.1/24 and reports any system as.
- Due to the use of some older versions of Libnet and Libpcap. I can see problems for some people compiling this and hence have placed two statically linked versions within the tarball

Shell over ICMP consists of two free and open source applications: one server and one client. Shell over ICMP project allows a user to connect to a remote shell daemon, by using ICMP protocol instead of classical TCP.
Entirely written in Python, soicmp is a working proof-of-concept to demonstrate that data can be transmitted across a network by hiding it in traffic that normally does not contain payloads.
How does it work?
The soicmp server is a daemon that must be started on the remote server. When the server receives a request from the client it looks into the packets payload. The payload must respect certain protocol rules. In detail the client must specify:
command
communication mode (echo|echo/reply)
authentication (y|n)
This is an example of a correct payload string sent by client to server:
$CMD ls -a $MODE echo/reply $PWD root2005 $END
If the payload matches with the server protocol specification then it will pipe the command to "/bin/sh" or "cmd.exe" and execute it. The server then reads the result from the pipe and sends it back to the client that will print it to stdout.
Moreover every client will send ICMP packets having id equal to the clients current process ID and will accept only ICMP replies having the same id value. This prevents output to be printed by other client instances running on the same workstation (this argument is also treated in the FAQs section).
Main features:
- Platform independent.
- Possibility to run soicmp daemon on multiple ethernet interfaces simultaneously handling multiple client connections.
- Possibility to specify the buffer size of outgoing packets.
- Client side source IP address spoofing.
- Remote client case-sensitive (plain texted) authentication.
- Possibility to select two communication types:
- One based on encapsulating command output in unique "one way" ICMP_ECHOREPLY (type 0) packets sent by server to client (see fig. 1).
- Another one that guarantees the correct packets delivering by using the request/response nature of ECHO and ECHOREPLY ICMP packet types (see fig.2)
- No listening sockets are listed by netstat or similar programs.