44net-request(a)hamradio.ucsd.edu wrote:
> Subject:
> [44net] ampr-ripd 1.8 released
> From:
> "Marius Petrescu" <marius(a)yo2loj.ro>
> Date:
> 02/11/2014 06:00 PM
>
> To:
> "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu>
>
>
> Hello OMs,
>
> Another addition and a new version.
>
> Added support for setting a specific route metric for the created routes
> using the -m option (regular routes until now had metric 0).
> This allows routes from other sources, e.g. BGP or OSPF to take precedence
> over those created by ampr-ripd.
When you make another version, consider:
- a -w option to set the window (now fixed at 840), setting 0 means no window setting.
- in the section to become a daemon, make use of the daemon() function. e.g.:
if (FALSE == debug)
{
if (daemon(0,verbose)<0)
{
PERROR("Can not become a daemon");
}
}
The advantage is that the program detaches from the terminal, which is required when
you want to start it in a /etc/init.d script and do not want to keep init waiting for the program.
Rob
>
>
> Any connects from ports
> below 1024 are highly suspect for being reflection attacks so above I
> block them all.
Another good trick is to block all outgoing connects to port 80 - this
makes it quite inconvenient for a virus to download its payload. In fact,
block all outgoing connects, and allow only what YOU want to do.
44net-request(a)hamradio.ucsd.edu wrote:
> Subject:
> Re: [44net] 44Net Digest, Vol 3, Issue 31
> From:
> John Ronan <jpronans(a)gmail.com>
> Date:
> 02/10/2014 10:01 AM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> Hi Rob/all,
> Well as long as it wasn't just me the packets were hitting, I'm happier :). I guess your 'firewall' is a chain you created yourself? Either that or my iptables/kernel is quite a bit older than yours.
>
> Thats a nice/handy ruleset actually, thanks for the reply.
>
> Oh, apologies for my slowness in replying, birthday party (my own) Saturday meant I was recovering yesterday.
>
> Regards
> John
> EI7IG
Yes, "firewall" is a chain that is joined to the INPUT chain for some of the traffic.
In a typical Linux tunneling server you first separate the raw input and the tunnel input, and then
deal with that in separate chains. In my tunnel router I have 4 of them, one for internet traffic
to the public IP address, one for traffic destined to the 44-net address of the router, one
for 44-net traffic routed thu to systems behind my router, and one for traffic destined to my
locally running copy of NETCHL (most others would use JNOS there).
It gets kind of difficult to handle all of that in one INPUT chain.
So my INPUT chain is built like this:
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i eth0 -d 111.222.333.444 -j firewall
iptables -A INPUT -i tunl0 -j firewall2
etc, and similar for the FORWARD chain.
BTW, the "attack" on http (which probably was not sourced from the addresses in the packets, but
was rather meant to be a reflection attack on some other party) continued through today and ended
a few hours ago.
The second example that I posted became the main attack later, and I added another rule below
the first line in my example:
iptables -A firewall -p tcp -m multiport --sport 0:1023 --syn -j DROP
This blocks any incoming connects that are coming FROM port numbers below 1024.
Those do not occur in normal practice. Port numbers below 1024 are "special" ports for protected
system services and normally are never the source port for connects. Any connects from ports
below 1024 are highly suspect for being reflection attacks so above I block them all.
Rob
44net-request(a)hamradio.ucsd.edu wrote:
> Subject:
> [44net] incoming traffic.
> From:
> John Ronan <jpronans(a)gmail.com>
> Date:
> 02/09/2014 05:10 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> Hi All,
>
> I've seeing continuous traffic coming in from amprgw.sysnet.ucsd.edu. from 5.135.135.42 to 44.155.6.1 port 80 over my tunnel. Anyone else seeing the same?
>
>
> I've disabled my tunnel for the moment as I don't have the time at the moment to chase it down.
>
> Regards
> John
> EI7IG
It is not specifically from that address. It appears to be a distributed attack on http servers, at least
to network 44. I see the same incoming stream of connects to several hosts in my subnet, all from
a different source IP. Sometimes after several hours it stops and starts from another IP.
I have crafted iptables rules that block it effectively:
iptables -A firewall -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A firewall -p tcp --syn -m recent --name tcp --set
iptables -A firewall -p tcp --syn -m recent --name tcp --update --seconds 30 --hitcount 15 -j DROP
iptables -A firewall -p tcp --dport 80 --syn -j ACCEPT
iptables -A firewall -p tcp --dport 443 --syn -j ACCEPT
iptables -A firewall -p tcp -j DROP
It just drops any source IP that sends more than 15 connects in 30 seconds.
Adjust for the port numbers that you want to accept (80 and 443 in this example)
There is also an internet-wide scan from source address 64.78.174.63 with traffic like this:
21:04:33.762663 64.78.174.63 -> 44.137.40.2 TCP 52 [TCP Port numbers reused] http > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
I see it on another server outside net-44 as well.
It is blocked by the same rule but I have just firewalled the entire 64.78.160.0/20 net as this does not look like someone I want to deal with.
Rob
Thanks to all that replied.
Got the iptables to forward the connects to my linux side where the
commercial postfix server is running.
Postfix doing what it's supposed to and killing it all if it's not a user
on my box.
Again, thank you to all who gave suggestions.
Bill
KG6BAJ
Hi All,
I've seeing continuous traffic coming in from amprgw.sysnet.ucsd.edu.
from 5.135.135.42 to 44.155.6.1 port 80 over my tunnel. Anyone else
seeing the same?
I've disabled my tunnel for the moment as I don't have the time at the
moment to chase it down.
Regards
John
EI7IG
Part of the beauty of our own IP address space is security provided by
knowing your neighbors.
I'd never run an open SIP or mail server on the wide internet anymore.
Spam filtering is a big headache.
Again, I'd firewall everyone but us for the mail port:
iptables -A INPUT -s ! 44.0.0.0/8 -p tcp --dport 25 -j DROP
If you have a google apps account (free for non profits) you can use
them as a mail exchanger.
Set your DNS records, to something like this:
gvcity.ampr.org MX 10 gvcity
gvcity.ampr.org MX 20 aspmx.l.google.com
Outside (non 44 net) IP will timeout with a direct connect to
44.2.14.1 and will move try the next exchanger preference, in this
case google.
Google will accept the mail on your behalf, and they have good spam
filtering (better than I could ever figure out how to incorporate with
sendmail) and then I typically use fetchmail to transfer the mail from
google back into my local mailboxes.
If someone else wants to document a mailserver setup with spam
protection, I'm all eyeballs on that one. I'm sure a number of people
would appreciate that tutorial.
Here is what I'd do.
Only allow 44 net to talk to the mail host directly:
iptables -A INPUT -s ! 44.0.0.0/8 -p tcp --dport 25 -j DROP
Set a MX record and set up an exchanger for any external mail you need
to deal with.
What we do is run all inbound and outbound email to/from the Internet through a mail gateway. Then the gateway can implement all of the modern spam avoidance functions, including even which specific user addresses will be relayed.
Michael
N6MEF
Sent from my Verizon Wireless 4G LTE smartphone
-------- Original message --------
From: William Lewis <kg6baj(a)n1oes.org>
Date:02/09/2014 11:54 AM (GMT-08:00)
To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
Subject: [44net] Mail Hacker
(Please trim inclusions from previous messages)
_______________________________________________
Hello group:
Need some collective help here on a mail system hacker issue I've been having.
First, the IP address on my system he's coming in on is 44.2.14.1
This person is dumping thousands of random emails into my system and some
of them will match BBS AREA patterns and get forwarded out to my forward
partners.
At first, I set up a log book scan script to look for bad logins, and then
ban the IP address, but then I found out that since my 44.2.14.1 ip address
goes "around" my firewall via UCSD, the block rules literally have zero effect.
I found a common "from" (online...@....) line in his emails, so in my
"rewrite" file I used this command "onl*@* | *@* refuse" but that also had
zero effect.
Then I tried telling JNOS "stop smtp" and "stop pop3" and that had zero effect.
JNOS's email system uses very old RFC rules, and none of the modern RFC
rules, so it's easy for this hacker to login to my JNOS mail server and
dump this junk. Luckily most get held, but as stated, a few match forward
patterns, so they slip through.
Right now I've completely taken my JNOS off-line until a fix can be found.
Anyone have some suggestions on blocking smtp and pop3 when my 44.2.14.1
address is live to global net ?
Any advise is appreciated in advance.
Thanks
Bill
KG6BAJ
