All,
I need to ask if any of the following have been noticed or by anyone before.
As I try to test a few things today, I:
- cannot forward IPENCAP traffic to another LAN destination while running ampr-ripd 1.16 on my router - cannot block IPENCAP traffic whatsoever at my WAN while running ampr-ripd 1.16 on my router - cannot block receipt of RIP44 packets from AMPRGW running ampr-ripd 1.16 on my router
Procedure:
When setting up LEDE:
-I observed that I no longer had firewall hits for RIP44 from AMPRGW - I removed the rule, and I still receive routes
Testing receipt of MACs on tunl0 today:
- I removed my rule allowing -p 4 from the IPSET of our GW IPs - I made a port forward rule for -p 4 to a LAN machine I setup with a tunl0 of 44.60.44.2 - I set up routes to use tunl0 - I pinged - Using Wireshark I never received traffic - My router saw no hits - I connected to http://44.60.44.10 to perform a traceroute to 8.8.8.8 - It still worked, even though I have no firewall rule! - the device is still in this configuration - and I noticed one 'leaked' packet that never made it to my test tunl0 interface - I notice that ampr-ripd 1.16 listens on protocol 4 instead of udp/520 as version 1.13 did
BUG:
It appears my firewall rules regarding IPENCAP/A.K.A. 'dev tunl0' packets - after upgrading from 1.13 to 1.16 are infective.
Need to test:
- If I configure a valid 44 IP on my router's tunl0, I assume ALL iptables rules for it COULD POSSIBLY be ineffective (since the RIP44 rule is) - If I can send routes in this configuration - If I can receive routes from someone else (with correct PW, of course) - If I receive IPENCAP packets from a non GW (since I have no method of it blocking, except if it exists ampr-ripd.c). Note - I'm not requesting this feature
I will test later today.
- Lynwood KB3VWG
All,
Some of my issues are in the behavior of tunl0 (which is helping me troubleshoot Rob's issue of not seeing the MAC).
It seems as if 'ip set tunl0 down' doesn't work in the same way as it did in other Linux versions, nor does it respond to iptables in the same way - either.
I'm seeing some differences between versions, for example, I'm unable to receive RIP44 on another device. I'll keep wokring.
- KB3VWG
All,
Looking at the changelog, I see what may have occurred (since I upgraded from 1.13 to 1.16):
Version 1.13 (20.Nov.2014): - Ignore subnets for which the gateway is inside their own subnet - Reconstruct RIP messages to be forwarded and send them about every 30 sec - Forwarded RIP messages do not use authentication Version 1.14 (21.Sep.2016): - Password in included in the daemon. Only need to set it should it ever change (OK from Brian Kantor - Tnx.) - Added man page courtesy of Ana C. Custura and the DebianHams * Version 1.15 (21.Sep.2016):** ** - Removed multicast access mode. Only raw sockets are used. Parameter '-r' is ignored
------------------------------------------------------------------------------------- * Version 1.16 (3.Feb.2017): - Added support for BGP announced 44net endpoints Version 1.16.1 (4.Feb.2017): - Added route cleanup on exit via CTRL-C in console mode. - No functional changes Version 1.16.2 (5.Feb.2017): - Reconnect RIP forwarding interface after interface down (Tnx. Gus, I0OJJ). - No functional changes * Version 1.16.3 (19.**Feb**.2017): <think month is off** ** - Correction for host routes on big endian machines.** ** - No functional changes** * If I revert to 1.13/1.14, I loose functionality. If I continue with 1.16, I cannot:
- send to other gateways with proper password (lost in versions <=1.13) *- OPTION to FIREWALL receipt of IPENCAP on WAN-facing side on Linux machine using iptables/netfilter (broken in 1.15)* *- correctly process routes on RISC-based CPUs (fixed in 1.16.3)* - enjoy the bug fix if tunl0 goes down while system is up (fixed in 1.16.2) - clear routes stored in the table when the process ends (added in 1.16.1) *- contact BGPed subnets (fixed in 1.16.0)* - POSSIBLY SEE ENCODED MAC ON LAN-facing SIDE OF TUNL0 (reported by Rob)
(I highlighted 3 major 'physical' and 'logical' bugs with 1.16.3.)
- Lynwood KB3VWG
- Also, I cannot block receipt of RIP44 packets - SECURITY - a malicious person could craft a packet of AGW and still change routes - a password is sufficient, so we can still distribute routes via ampr-ripd
Feature request:
- keep password default - keep the -p argument - add an argument to include a password in the -f argument packets (this allows the person to specify a password if they want to receive RIP44 form and agreed 2nd source using the -p argument on their device)
- KB3VWG
*- OPTION to FIREWALL receipt of IPENCAP on WAN-facing side on Linux machine using iptables/netfilter (broken in 1.15)*
On 2017-05-11 04:13, lleachii--- via 44Net wrote:
(Please trim inclusions from previous messages) _______________________________________________
- Also, I cannot block receipt of RIP44 packets
If you don't want those RIP44 packets, why use ampr-ripd? The current implementation was a change to get it running an all machines, even if they don't support proper multicast handling. I could get the -r option back.
- SECURITY - a malicious person could craft a packet of AGW and still
change routes
Yes, that is a possibility and always was.
- a password is sufficient, so we can still distribute routes via
ampr-ripd
It distributes standard RIP. If you want RIP44, setup a propergateway, or use quagga instead. It can co-exist with ampr-ripd on the same machine. Since RIP needs to be on the same subnet for it to work in multicast mode, one can secure the channel. In unicast mode, you can always filter the RIP source. The password is by no means a security measure, since any plain RIP password can be found by sniffing the traffic.
Feature request:
- keep password default
See above.
- keep the -p argument
The -p argument is still there and works. It is just not needed by default.
- add an argument to include a password in the -f argument packets
(this allows the person to specify a password if they want to receive RIP44 form and agreed 2nd source using the -p argument on their device)
This could be done, but why is this needed? See above.
- KB3VWG
*- OPTION to FIREWALL receipt of IPENCAP on WAN-facing side on Linux machine using iptables/netfilter (broken in 1.15)*
Again, why do you need to firewall something you want? Don't use the daemon if you don't need them. As I said, the -r option can be made active again, but why?
Marius, YO2LOJ
Marius,
It's always assumed a.) the operator "wants" ALL packets and b.) that they always want them to be processed on the same device, at all times. Day by day, we increasingly see that because something isn't YET exploited...but could be, or even other GWs are misconfigured...In truth, I only need to:
- See any packet bound for my WAN (broken) - INSPECT/DROP any packet on my WAN that doesn't match my network security policy (broken) - Accept IPENCAP only from assigned 44 IP endpoints (broken) - Accept other multipoint IPENCAP packets (broken) - Accept RIP44 from AMPRGW, Forward it, or to cut it off (broken) - Ability to Forward IPENCAP routing to a downstream device (broken) - get ping from your WAN interfaces - get ping from your tunl0's - Accept connections to services I offer: DNS, NTP, HTTP to 44.60.44.0/24
- The -r only model assumes that all packets on WAN are trusted, and hence accepts ANY IPENCAP packet on the WAN and drops them off on the secure side of my router, unchecked though iptables/etc. Only other iptables/ip rule/ip route statements I've added (prior) prevent this from being a security risk. - The -r uses creates a pseudo Layer 2 on my WAN, just to filter-out and process 1 particular of Layer 3 packet, from 1 particular endpoint - while forwarding the rest, unfiltered - To use the Encap File from the site and not rely on/process any packets from 44.0.0.1 (Stratum 1 redundancy/sanity checking of process AMPRGW uses to obtain the routes) - Temporally stop receipt, remove routes, etc. (more so important since ampr-ripd removes routes on exit, perhaps add an argument to make this an optional feature) - If we could see Rob's 'MAC,' we could possibly efficiently filter between the IPENCAP and inside header (i.e. detect spoofed 44.0.0.1 packet - and possibly, all other 44 addresses) - See firewall hits for this outer traffic - To firewall the other approximately 4 billion IP addresses that can send an kmod-ipip-compatible packet - that my Kernel/ampr-ripd now processes - Prevent unknown issues with interaction with kmod-ipip and ampr-ripd in raw-only mode (e.g. bypassing netfilter) - Prevent a GW/rogue machine from sending packets to - and my sending a response via AMPRGW (there's other ways to do this, but I still need to use other resources to process the outer header as an agent for netfilter, which I NO LONGER HAVE) - Block all other traffic from the Internet without use of additional CPU resources - Block traffic from individual GWs - Distribute packets to routers/sensors//LANs - based on outer header (at this point, I can't run point-to-multipoint IPENCAP tunnels for any reason - except AMPRNet). - Forward traffic to a backup router on-the-fly via change of iptables INPUT rule to a NAT FORWARD rule (possibly implement VRRP, especially for those who use BGPed tunnels) - When running point-to-multipoint kmod-ipip tunnels through your router, needing to end ampr-ripd for any reason would now also crash other non AMPR tunnels (unless the same, but now redundant iptables rule is added; but its effect on connection states are untested).
- Lynwood KB3VWG
Again, why do you need to firewall something you want? Don't use the daemon if you don't need them. As I said, the -r option can be made active again, but why?
Example:
- I add a serial port to my router and connect a TNC and radio. - I Kissattach it, assign an AX.25 address and 44.60.44.0/24 IP, etc. - A spoofed or rogue or scan packet enters my router... - Can that traffic be firewalled now (by default)??? - Now that has to be tested into dummy loads, Wireshark in advance, etc. because now that's unknown
- Lynwood KB3VWG
Ok. I understood a lot of your points. Let me see what can be done ;-)
On 2017-05-11 13:52, lleachii--- via 44Net wrote:
(Please trim inclusions from previous messages) _______________________________________________ Example:
- I add a serial port to my router and connect a TNC and radio.
- I Kissattach it, assign an AX.25 address and 44.60.44.0/24 IP, etc.
- A spoofed or rogue or scan packet enters my router...
- Can that traffic be firewalled now (by default)???
- Now that has to be tested into dummy loads, Wireshark in advance,
etc. because now that's unknown
- Lynwood
KB3VWG _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
-
lleachii＠aol.com -
Marius Petrescu