44net

44net@mailman.ampr.org

3198 discussions

ampr-ripd 1.8 released
by Marius Petrescu 12 Feb '14

12 Feb '14

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. For those not needing "fancy" routing, there's no need to upgrade. Download from http://www.yo2loj.ro/hamprojects/ or http://yo2tm.ampr.org/hamprojects/ (as usual), or get it via github: https://github.com/yo2loj/ampr-ripd/ Direct links: http://www.yo2loj.ro/hamprojects/ampr-ripd-1.8.tgz http://yo2tm.ampr.org/hamprojects/ampr-ripd-1.8.tgz Have fun, Marius, YO2LOJ

2 2

Re: [44net] ampr-ripd 1.8 released
by Rob Janssen 12 Feb '14

12 Feb '14

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

2 1

Re: [44net] 44Net Digest, Vol 3, Issue 33
by Steve Wright 11 Feb '14

11 Feb '14

> > > 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.

1 0

Re: [44net] 44Net Digest, Vol 3, Issue 32
by Rob Janssen 10 Feb '14

10 Feb '14

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

1 0

Re: [44net] 44Net Digest, Vol 3, Issue 31
by Rob Janssen 10 Feb '14

10 Feb '14

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

2 1

Reg Exp
by William Lewis 10 Feb '14

10 Feb '14

BTW.... Anybody in the group good at formulating REGEX expressions ? If so, contact me off-list. kg6baj(a)n1oes.org Thanks Bill

1 0

Mail Hacker
by William Lewis 10 Feb '14

10 Feb '14

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

1 0

incoming traffic.
by John Ronan 10 Feb '14

10 Feb '14

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

6 7

Re: [44net] Mail hacker
by kb9mwr＠gmail.com 09 Feb '14

09 Feb '14

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.

1 0

Re: [44net] Mail Hacker
by kb9mwr＠gmail.com 09 Feb '14

09 Feb '14

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.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net