> Subject:
> [44net] Gateway filtering?
> From:
> Steve L <kb9mwr(a)gmail.com>
> Date:
> 07/03/2015 09:05 PM
>
> To:
> "44net(a)hamradio.ucsd.edu" <44net(a)hamradio.ucsd.edu>
>
>
> A few hosts behind my gateway want to accept general inbound internet
> connections.
>
> As discussed earlier there is a lot of crap and the gateway I run is
> off a residential internet connection. Combine that with some limited
> bandwidth radio links.
>
> I have been thinking about applying some IP blacklists using the ipset tool.
>
> ex:https://github.com/trick77/ipset-blacklist
>
> I am not super savvy on the more advanced functions of tcpip in the
> Linux networking stack.
>
> Since those in all the inbound packets from the internet are
> encapsulated at UCSD, how can I apply blacklisting? Can I apply them
> to the eth1 (wireless lan) output interface somehow?
>
> Examples are especially helpful.
>
> Thanks
>
> Steve, kb9mwr
>
I use this a lot in the Dutch gateway. First, I have an ipset that is loaded with the
list of allocated addresses within 44.137.0.0/16. You don't need to do that when you
are behind the UCSD gateway, but we have a BGP-advertised /16 so we get a lot of
crap for addresses that are not allocated.
Then, there is an ipset that is loaded with addresses of persistent abusers like shodan.io.
Finally, I have an ipset with those addresses for which the user has indicated that they
want to receive inbound connections from outside 44.0.0.0/8. This works in combination
with an iptables -m state --state ESTABLISHED,RELATED entry that passes the traffic
related to outgoing connections.
As a lot of hams are not interested in providing connectivity to the large internet, this filter
removes a lot of incoming traffic that would otherwise be blocked further down the path.
(at their incoming firewall)
The use of these ipset filters in the firewall is quite simple:
# Drop traffic from abusers
$ipt -A amprifwd -m set --match-set Hackers src -j DROP
# Drop traffic for addresses not registered in DNS
$ipt -A amprifwd -m set ! --match-set PAnet dst -j DROP
# Allow related traffic
$ipt -A amprifwd -m state --state ESTABLISHED,RELATED -j ACCEPT
# Drop traffic to stations that don't want incoming from internet to HAMnet
$ipt -A amprifwd ! -s 44.0.0.0/8 -m set ! --match-set HAMnet dst -j DROP
# Drop invalid traffic (not related to existing connections) except TCP close-down traffic
$ipt -A amprifwd -p tcp --tcp-flags ACK,FIN ACK,FIN -j ACCEPT
$ipt -A amprifwd -p tcp --tcp-flags RST RST -j ACCEPT
$ipt -A amprifwd -m state --state INVALID -j DROP
# Accept remaining traffic
$ipt -A amprifwd -j ACCEPT
Of course you need to apply this filter to the FORWARD chain for traffic incoming on your
tunnel interface and being forwarded to your radio interface.
You can write such a filter (without the ESTABLISHED,RELATED part) for traffic forwarded
outbound as well. E.g. to block traffic from nonregistered addresses.
When loading the ipsets, it is important to note that you cannot delete a set that is in use in
iptables. So I use this method (in a script that reloads the sets e.g. after an address update):
ipset create HAMnet bitmap:ip range 44.137.0.0/16 2>/dev/null
ipset create HAMnet_new bitmap:ip range 44.137.0.0/16
ipset flush HAMnet_new
grep '^44\.137\.' hamnet | cut -f1 | while read ip
do
ipset add HAMnet_new $ip || echo "Failed to insert $ip in HAMnet_new"
done
ipset swap HAMnet_new HAMnet
ipset destroy HAMnet_new 2>/dev/null
This creates a new set, loads it with the data, then swaps it with the currently used set and
destroys that one. This operation is allowed while the set is in use, and of course is preferred
over just flushing the set and loading it, as during that brief time the filter could drop traffic.
Rob
A few hosts behind my gateway want to accept general inbound internet
connections.
As discussed earlier there is a lot of crap and the gateway I run is
off a residential internet connection. Combine that with some limited
bandwidth radio links.
I have been thinking about applying some IP blacklists using the ipset tool.
ex: https://github.com/trick77/ipset-blacklist
I am not super savvy on the more advanced functions of tcpip in the
Linux networking stack.
Since those in all the inbound packets from the internet are
encapsulated at UCSD, how can I apply blacklisting? Can I apply them
to the eth1 (wireless lan) output interface somehow?
Examples are especially helpful.
Thanks
Steve, kb9mwr
I am trying to register amprnet gate at IP 147.229.242.130 (ok0nmg.ddns.net)
at portal.ampr.org but there is no offer to put a subnet (here
44.177.10.254/32).
I ahve already registered 2 gateways before succesfully with their
subnets but
this a/m one its not possible to put a subnet.
(The ampr-ripd system is running well on ok0nmg.ddns.net.)
I need some help please.
Best 73
Libor OK2PEN (PY2ZEN) sysop of gates ok2koj.ampr.org, ok2pen.ampr.org
and ok0nmg.ampr.org
All,
I've added a new tool that I'd like you to test. This web application
should provide the registration code required by APRS software suites.
In order to use it, you must browse to:
http://kb3vwg-010.ampr.org/tools/aprscode
or
http://44.60.44.10/tools/aprscode
If you're on AMPRNet, you should be able to enter the callsign and look
up the registration code. If you access it from outside of AMPRNet, you
will be prompted for an access code (1234).
Please let me know how it works
73,
KB3VWG
Today's power outage seems to have left my net 44 link DOA... If so I wanted
everyone to know I may be back.. No time to fix right now.. Just spent over
a week getting everything working after a virus attack. And was not really
done still had two systems down.. Now I have this.. I need a break, also..
May pick this back up in July... May not.
Anyone linked to me I will be back eventually.. Maybe Maybe not.
But now I have to figure out a few things.
Why does my Pi lose all its free space within 30 minutes of boot up. Went
from 73% to 100% cannot connect to it without rebooting over and over...
So until I feel like being a slave to linux and the PI I am off line.
73 Jerry N9LYA
Does anyone know the status of K3MMB? His system appears to be offline
and has been for a couple weeks or so.
--
A computer once beat me at chess, but it was no match against
me in kick-boxing - Emo Phillips
73 de Brian Rogers - N1URO
email: (see above)
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
http://uronode.sourceforge.nethttp://axmail.sourceforge.net
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
> Subject:
> Re: [44net] portal purge
> From:
> Don Fanning <don(a)00100100.net>
> Date:
> 06/20/2015 01:40 AM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> There is so much cruft in the DNS tables
> that I imported the information into a database and ran the FCC
> database against it. There were roughly 1800 entries out of 3700-ish
> that matched expired/cancelled/revoked callsigns. And that's just for
> the US alone - not including active licensees who just lost interest
> in 44net. As BrianK would point out, there is no way that the DNS
> table should be this big.
I do regular checks of the registered addresses in the 44.137.0.0/16 subnet against
the list of callsigns published by our local authority. I also delete registrations when
"silent key" announcements appear in the club magazine.
And a few weeks ago I deleted all dangling MX and CNAME records, most of them
for US hams. (see discussion on the list)
It appears to have been standard practice to create MX records for new registered
addresses, and to not delete them when addresses are deleted.
Do you have valid "callsign change" tables in the US? A problem for me is that
there is no official information on that from our authority, apparently for privacy
reasons. So sometimes I delete an address because the callsign is no longer valid,
to find later that the operator has changed to a higher license class or vanity
callsign. And not everyone changing their callsign notifies me.
Rob
> Subject:
> Re: [44net] Model gateway system
> From:
> Steve L <kb9mwr(a)gmail.com>
> Date:
> 06/19/2015 10:06 PM
>
> To:
> "44net(a)hamradio.ucsd.edu" <44net(a)hamradio.ucsd.edu>
>
>
> IPIP gateways should not use amprgw default route.
> Ex: ip route add default dev tunl0 via 169.228.66.251 onlink ....
That is incorrect. Such a route is OK as long as it is in an alternative routing table
for AMPRnet traffic. It can be to amprgw or to a more local gateway.
Such a route is required when you are on a source-address filtered internet connection
and want to be reachable on your AMPRnet address from other internet systems.
Rob
So is the architectural debate over, or are people just tired of arguing?
Frankly, there's been so much back and forth that I don't know what's
expected any more. As I understand it, some nodes are on the IPIP mesh,
some not. Some are reachable through amprgw, some not. What a mess.
If the debate is over and there is consensus on a standard gateway
architecture, then someone needs to publish it.
I'm thinking the design should include a diagram of how to address the
interfaces (which tunnels need AMPR addresses, which don't), where NATing
occurs, what the ampr routing table should look like, what the ip rules
should look like, etc.
Otherwise, I guess it's up to each individual person to parse through the
last 100 or so emails to figure out what they're going to do. Maybe I'll
find time to do that . Someday. And folks wonder why there's not more
participation .
Michael
N6MEF
