44net-request(a)hamradio.ucsd.edu wrote:
> Subject:
> Re: [44net] 44Net Digest, Vol 3, Issue 33
> From:
> Steve Wright <stevewrightnz(a)gmail.com>
> Date:
> 02/11/2014 11:41 PM
>
> To:
> 44net(a)hamradio.ucsd.edu
>
>
>> >
>> >
>> > 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.
Well, I do have that on the webserver at work. What those injection-attacks on
PHP programs often do is include something that is fetched from a remote webserver.
As the webserver cannot make outgoing connects, this always fails.
However, for a typical hamradio computer that serves both as a server and a client,
blocking outgoing port 80 is a bit unpractical.
The attack is still/again going on, this time with source port 119:
21:49:23.716879 216.18.208.109 -> 44.137.41.97 TCP 52 nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
21:49:24.514385 216.18.208.109 -> 44.137.41.101 TCP 52 nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
21:49:24.819003 216.18.208.109 -> 44.137.41.97 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
21:49:25.914034 216.18.208.109 -> 44.137.41.97 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
21:49:25.927587 216.18.208.109 -> 44.137.41.101 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
21:49:27.009032 216.18.208.109 -> 44.137.41.97 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
21:49:27.349359 216.18.208.109 -> 44.137.41.101 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
21:49:28.106015 216.18.208.109 -> 44.137.41.97 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
Rob
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.
