Into.the.Void.

GrRBL
In the beginning of the year I announced my RBL for Greek spam emails. The blacklist is growing larger by the day, thanks to some really kind people forwarding me their Greek spam emails, and has reached more than 120 IP addresses of verified Greek spammers.This alone though is not enough.

Why
Some spammers use their aDSL lines which have dynamic IPs to send their massive email “newsletters”. These people are split into 2 sub-categories. The ones that use their own PC as an SMTP server and the ones who use their ISP’s mail server as SMTP. I’ve tried to complain to some of their ISPs…some replied back saying that they were willing to look into the issue (but did nothing at all in the end) and others did not even reply to me. For both sub-categories, GrRBL is ineffective since I can’t add dynamic IPs in the blacklist nor can I add the IPs of the email servers of those major Greek ISPs.

Another category of spammers is the one that uses their gmail/yahoo accounts to send their emails. GrRBL is ineffective for this category as well since I can’t add gmail/yahoo to the blacklist…

What
So there was no alternative but to gather all those email addresses of these 2 categories above and add them to a new blacklist, one that will contain email addresses. I use this blacklist with my spamassassin configuration to eliminate Greek spam that GrRBL can’t. Each time I receive (or someone forwards me) a new Greek spam, I add the “From:” email address to this new blacklist. This new blacklist grows far more aggressively than GrRBL since it’s a lot easier to gather the data and already has more than 140 addresses.

Distribution
There are two available formats of the blacklist, one ready for use by spamassassin and another one with clear formatting ready to be used even by SMTPs to drop these spam emails without even touching your inbox.
The blacklist is currently only distributed to a group of well trusted people and it is available only through rsync with a username/password.

I don’t want to make the list completely public yet, but if you are interested you can request it at the contact email of GrRBL and I will reply to you about accessing it.

Sidenote
If you need a good tool to check a host again some RBLs, adnsrblcheck by Yiorgos Adamopoulos is the way to go (and it includes GrRBL!)

Filed by kargig at 23:15 under Linux, Networking
Tags: blacklist, email, Greek, greek spam, grrbl, Internet, Linux, Networking, spam, spamassassin
3 Comments | 2,157 views

I have an OpenVPN server that has the push "redirect-gateway" directive. This directive changes the default gateway of the client to be the OpenVPN server, what I wanted though was to connect to the VPN and access only a specific subnet (eg. 100.200.100.0/24) through it without changing the server config (other people use it as a default gateway).

In the client config I removed the client directive and replaced it with these commands:
tls-client
ifconfig 172.18.0.6 172.18.0.5
route 172.18.0.0 255.255.255.0
route 100.200.100.0 255.255.255.0

What the previous lines do:
tls-client: Acts as a client! (“client” is an alias for “tls-client” + “pull” … but I don’t like what the pull did–>it changed my default route)
ifconfig 172.18.0.6 172.18.0.5: The tun0 interface will have ip 172.18.0.6 on our side and 17.18.0.5 on the server side. The IPs are not random, they are the ones OpenVPN used to assign to me while I was using the “client” directive.
route 172.18.0.0 255.255.255.0: Route all packets to 172.18.0.0 on the tun0 interface. In order to access services running on the OpenVPN server (172.18.0.1) I needed a route to them.
route 100.200.100.0 255.255.255.0: Route all packets to 100.200.100.0 on the tun0 interface

A traceroute to 100.200.100.1 now shows that I accessing that subnet through the vpn.

Filed by kargig at 11:25 under Linux, Networking, Privacy
Tags: client, Linux, Networking, openvpn, Privacy, route, server, vpn
4 Comments | 1,216 views

During some QoS tests on Linux I needed to measure the traffic of the system in realtime without being able to compile any new software on it. The system had already perl installed so I googled to find a script that could monitor in/out traffic of an interface. The first script I found was this: http://perlmonks.org/?node_id=635792

While it’s actually doing what it says, it only runs just once. I wanted the script to run for a period of time. So I changed it a bit.
Here’s the outcome:
#!/usr/bin/perl
my $dev=$ARGV[0];
sub get_measures {
my $data = `cat /proc/net/dev | grep "$dev" | head -n1`;
$data =~ /$dev\:(\d+)\D+\d+\D+\d+\D+\d+\D+\d+\D+\d+\D+\d+\D+\d+\D+(\d+)\D+/;
my $recv = int($1/1024);
my $sent= int($2/1024);
return ($recv,$sent);
}
my @m1 = get_measures;
while(1) {
sleep 1;
my @m2 = get_measures;
my @rates = ($m2[0] - $m1[0], $m2[1]-$m1[1]);
foreach ('received' , ' transmit') {
printf "$_ rate:%sKB",shift @rates;
}
print "\n";
@m1=@m2;
}

I’ve changed it so that it’s:
a) running continuously until someone presses ctrl+c to stop it,
b) parsing the /proc/net/dev output instead of the ifconfig output. I think this is more efficient/fast than parsing the ifconfig output.

Sample output:

$iftraffic.pl eth0
received rate:1564KB transmit rate:71KB
received rate:1316KB transmit rate:44KB
received rate:1415KB transmit rate:48KB
received rate:1579KB transmit rate:76KB

I am sure that someone with more insight into perl than me can make it even more efficient.

You can also download a version with comments that I made so that one can make the script run for X number of repetitions instead of running until someone stops it.
Download: iftraffic.pl

Filed by kargig at 22:29 under Linux, Networking
Tags: incoming, Linux, monitor, Networking, outgoing, perl, realtime, traffic
4 Comments | 1,717 views