24 May
2017
24 May
'17
3:41 a.m.
I've added code to the rip sender that watches for
ICMP unreachable
packets coming back to amprgw during the rip sending cycle, which repeats
every 5 minutes.
Make sure you act only on ICMP unreachables that refer to the protocol 4, not
to the port 520!
When protocol 4 is unreachable, it sure means the gateway is not operational, as
it rejects operational traffic. When it rejects port 520, it could be that it
is not using RIP to update its tables (it could be downloading encap files!) or
even that it *is* using RIP but via raw sockets (ampr-ripd -r) and has a firewall
that rejects the packets. ampr-ripd would still see and process them!
That condition could be flagged in yet another status report, but it should not
be a base to declare the gateway inactive.
Also, we recently have seen some postings that indicate that some people operate
a gateway that has tunnels to all other gateways, but explicitly have excluded
a tunnel to amprgw. Because that brings mostly internet traffic and they don't
want to have that.
Of course another (not exclusively deciding) check on gateway activity could be
to check if you actually receive any tunneled packets from them. I do have that
as a byproduct of having an access list that accepts protocol 4 traffic only
from addresses of registered gateways. At the moment it shows traffic from 34
different gateways (including amprgw). Of course, when the external address of
a gateway changes, its history is lost.
Rob
24 May
24 May
5:10 a.m.
New subject: non-operational gateways
The collecting ripsender ICMP data is available for you to look at
on the web site in file /private/gwlog.txt. It has as the last two
columns the ICMP type and code, so 'port unreachable' (code 3) can be
distinguished from 'host unreachable' (code 1), 'net unreachable' (code
0), and 'protocol unreachable' (code 2), etc. I'm currently recording
all 16 kinds of 'unreachable' in that file.
The amprgw daily gateway statistics files show the number and size of
all sent and received traffic for each subnet and gateway, and the
age of the route. It should be quite possible to analyze these and
find gateways that aren't sending any traffic to amprgw. Of course,
there can be gateways such as the one in Germany which uses asymmetric
shortcut routing so it never does send any traffic to amprgw even though
it's quite active. These files are available via the web server as eg,
/private/gwstats.17-05-16.txt.
You're quite right that it's not an easy task to determine whether a
gateway deserves to be removed from the portal's encap list. I believe
it will take the combination of several factors before that decision
can be made. Collecting statistics toward that end is the first step;
we can't make decisions without data.
- Brian
On Wed, May 24, 2017 at 09:41:19AM +0200, Rob Janssen wrote:
Of course another (not exclusively deciding) check on
gateway activity could be
to check if you actually receive any tunneled packets from them. I do have that
as a byproduct of having an access list that accepts protocol 4 traffic only
from addresses of registered gateways. At the moment it shows traffic from 34
different gateways (including amprgw). Of course, when the external address of
a gateway changes, its history is lost.
9:23 a.m.
New subject: non-operational gateways
Brian,
I can't find the private data.
I see no link on portal.ampr.org, even if I log into the portal.
If I log in with FTP, I see only encap and gateways files.
How do I find this /private directory?
Off net reply: n6mef at the league.
Michael
N6MEF
-----Original Message-----
From: 44Net [mailto:44net-bounces+n6mef=mefox.org@hamradio.ucsd.edu] On
Behalf Of Brian Kantor
Sent: Wednesday, May 24, 2017 2:10 AM
To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
Subject: Re: [44net] non-operational gateways
(Please trim inclusions from previous messages)
_______________________________________________
The collecting ripsender ICMP data is available for you to look at
on the web site in file /private/gwlog.txt. It has as the last two
columns the ICMP type and code, so 'port unreachable' (code 3) can be
distinguished from 'host unreachable' (code 1), 'net unreachable' (code
0), and 'protocol unreachable' (code 2), etc. I'm currently recording
all 16 kinds of 'unreachable' in that file.
The amprgw daily gateway statistics files show the number and size of
all sent and received traffic for each subnet and gateway, and the
age of the route. It should be quite possible to analyze these and
find gateways that aren't sending any traffic to amprgw. Of course,
there can be gateways such as the one in Germany which uses asymmetric
shortcut routing so it never does send any traffic to amprgw even though
it's quite active. These files are available via the web server as eg,
/private/gwstats.17-05-16.txt.
You're quite right that it's not an easy task to determine whether a
gateway deserves to be removed from the portal's encap list. I believe
it will take the combination of several factors before that decision
can be made. Collecting statistics toward that end is the first step;
we can't make decisions without data.
- Brian
On Wed, May 24, 2017 at 09:41:19AM +0200, Rob Janssen wrote:
Of course another (not exclusively deciding)
check on gateway activity
could be
to check if you actually receive any tunneled
packets from them. I do
have that
as a byproduct of having an access list that
accepts protocol 4 traffic
only
from addresses of registered gateways. At the
moment it shows traffic
from 34
different gateways (including amprgw). Of
course, when the external
address of
a gateway changes, its history is lost.
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net 
10:11 a.m.
New subject: non-operational gateways
First of all thank you by the names of all of us
in the last few month you raised up the info of the AMPRNET to something that is not
shame high tech companies
Now
I dont know how to interprate the numbers
in the left colon i see 3 what is it ? and in right colon i see mostly 3 and 2 and
some 10 and 1 what are these ?
For example my gateway show 3 2 what is it is ?it good ? bad ? all i can tell is that
my gateway fully operational but dont know what these numbers reflect
can an explain to the numbers added to the stat colon ?
Thanks Forward
Ronen 4Z4ZQ
________________________________
10:34 a.m.
New subject: non-operational gateways
Ronen,
I assume you mean the gwlog.txt file.
This is raw data, designed for a program to read, not humans.
column 1 is the IP address of the gateway
columns 2 & 3 are the UTC date and time
column 4 is the icmp type, always '3' for 'destination unreachable'
column 5 is the icmp code why. '2' is 'unreachable protocol', '3'
is
'unreachable port'.
Refer to RFC792 and later RFCs, or the Unix/Linux source code
for the meanings of the type/code combinations. Or do a google
search for 'icmp type 3'.
For example:
69.85.86.85 17-05-24 02:30:00 3 2
So '3 2' means that the gateway rejected a packet with
the message 'unreachable protocol'.
I don't see your gateway '5.29.18.144' in the gwlog file, so it's
not rejecting packets from the RIP sender and you're ok.
- Brian
On Wed, May 24, 2017 at 02:11:44PM +0000, R P wrote:
I dont know how to interprate the numbers
in the left colon i see 3 what is it ? and in right colon i see mostly 3 and 2 and
some 10 and 1 what are these ?
For example my gateway show 3 2 what is it is ?it good ? bad ? all i can tell is that
my gateway fully operational but dont know what these numbers reflect
can an explain to the numbers added to the stat colon ?
10:45 a.m.
New subject: non-operational gateways
Thank U
So in other Other words gateways that appear there are ones that consider not responding
..... That what was missing to me....
Thank U
Ronen - 4Z4ZQ
________________________________
I don't see your gateway '5.29.18.144' in the gwlog file, so it's
not rejecting packets from the RIP sender and you're ok.
- Brian
10:57 a.m.
New subject: non-operational gateways
Well, not exactly. These are gateways or hosts/routers upstream of
the gateway that said 'no' to the RIP transmissions. A gateway that is
completely dead won't be there either, because it didn't respond at all.
So if they're in the list, something is probably wrong but it's not
enough information to declare it dead.
- Brian
On Wed, May 24, 2017 at 02:45:57PM +0000, R P wrote:
So in other Other words gateways that appear there
are ones that consider not responding ..... That what was missing to me....
12:47 p.m.
New subject: non-operational gateways
-----Original Message-----
So if they're in the list, something is probably wrong but it's not
enough information to declare it dead.
- Brian
If the gateway doesn't use RIP, then it may also not open that port in its
firewall. So it may either drop the packets silently or return ICMP
unreachables. Right? If so, then the most we can say about this situation
is that the site is not accepting RIP, not that something is "probably
wrong". Or am I missing something?
Likewise, regarding a point made in an earlier email: the lack of traffic
sent from a gateway to amprgw doesn't mean that the gateway is not
operational. In our case, we use amprnet tunnels to communicate directly
with other amprnet sites. And non-amprnet folks use our external IP. So,
none of our traffic passes through amprgw.
BTW, I applaud all of the stats, Brian. It will help us detect problems we
didn't even know existed. We just need to be careful about the conclusions
we draw from the data. I know you are. I just didn't see the above points
made yet (or perhaps I missed them).
Michael
N6MEF
12:51 p.m.
New subject: non-operational gateways
You're right, of course.
I think Rob made much the same points in an earlier email.
- Brian
On Wed, May 24, 2017 at 09:47:47AM -0700, Michael Fox - N6MEF wrote:
If the gateway doesn't use RIP, then it may also
not open that port in its
firewall. So it may either drop the packets silently or return ICMP
unreachables. Right? If so, then the most we can say about this situation
is that the site is not accepting RIP, not that something is "probably
wrong". Or am I missing something?
Likewise, regarding a point made in an earlier email: the lack of traffic
sent from a gateway to amprgw doesn't mean that the gateway is not
operational. In our case, we use amprnet tunnels to communicate directly
with other amprnet sites. And non-amprnet folks use our external IP. So,
none of our traffic passes through amprgw.
BTW, I applaud all of the stats, Brian. It will help us detect problems we
didn't even know existed. We just need to be careful about the conclusions
we draw from the data. I know you are. I just didn't see the above points
made yet (or perhaps I missed them).
Michael
N6MEF
1:20 p.m.
New subject: non-operational gateways
On 24.05.2017 19:47, Michael Fox - N6MEF wrote:
If the gateway doesn't use RIP, then it may also
not open that port in
its
firewall. So it may either drop the packets silently or return ICMP
unreachables. Right? If so, then the most we can say about this situation
is that the site is not accepting RIP, not that something is "probably
wrong". Or am I missing something?
Sorry to ask but what has accepting RIP to do with the gateway IP?
RIP is encapsulated into IPIP, so no firewall will ever care about that.
And no sane firewall setup will accept RIP on its WAN.
From both the gateway's point of view it's just protocol 4, nothing else.
1:29 p.m.
New subject: non-operational gateways
On 24.05.2017 19:47, Michael Fox - N6MEF wrote:
Marius,
I'm not sure I understand your question. But the answer to what I think
you're asking is:
Correct, for the external firewall. But an inner firewall that acts on the
traffic within the tunnel should only accept what it needs and block
everything else.
Michael
If the gateway doesn't use RIP, then it may
also not open that port in
its
firewall. So it may either drop the packets silently or return ICMP
unreachables. Right? If so, then the most we can say about this
situation
is that the site is not accepting RIP, not that
something is "probably
wrong". Or am I missing something?
Sorry to ask but what has accepting RIP to do with the gateway IP?
RIP is encapsulated into IPIP, so no firewall will ever care about that.
And no sane firewall setup will accept RIP on its WAN.
From both the gateway's point of view it's just protocol 4, nothing else.
1:57 p.m.
New subject: non-operational gateways
It is not a question, it is a statement. And it is about detecting
inactive gateways.
Brian proposed to collect ICMP unreachable from the gateway IPs, so he
could get a list of certainly unreachable gateways. This method is
sound, with very improbable false positive results, and could
successfully be used for this goal.
And then all started to talk about RIP and the fact that not all
gateways use it and so on.
As I said: Gateway reachability has nothing to do with the fact that a
certain gateway uses or not RIP, or if RIP passes its firewall or not.
The "ICMP unreachable" pertains only IPIP traffic to the public gateway
IP which will be classified as unreachable by the last router before it,
route which is totally agnostic about the firewall settings of the
(unreachable) target or about its ability to process or not RIP multicasts.
And this holds true as long as no "smart" network manager turns off all
ICMP for some delusional security advantages.
On 24.05.2017 20:29, Michael Fox - N6MEF wrote:
(Please trim inclusions from previous messages)
_______________________________________________
On 24.05.2017 19:47, Michael Fox - N6MEF wrote:
Marius,
I'm not sure I understand your question. But the answer to what I think
you're asking is:
Correct, for the external firewall. But an inner firewall that acts on the
traffic within the tunnel should only accept what it needs and block
everything else.
Michael
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net If the gateway doesn't use RIP, then it may
also not open that port in
its
firewall. So it may either drop the packets silently or return ICMP
unreachables. Right? If so, then the most we can say about this
situation
is that the site is not accepting RIP, not that
something is "probably
wrong". Or am I missing something?
Sorry to ask but what has accepting RIP
to do with the gateway IP?
RIP is encapsulated into IPIP, so no firewall will ever care about that.
And no sane firewall setup will accept RIP on its WAN.
From both the gateway's point of view it's just protocol 4, nothing else.
3:26 p.m.
New subject: non-operational gateways
Marius,
Not delusional at all, in my security instance, if I were to have
IPENCAP closed, I wouldn't configure my device to send ICMP Unreachable
messages for it. The perceived gain is that my router doesn't use CPU
resources to process a packet I don't want. This is a common
configuration of a Firewall that Drops by default - I'm not "forcing" my
firewall to do it. It takes additional configuration to
accept-then-reject. The drop by default is helpful in scenarios like a
DDoS attack at the border attempting to use you for an amplification attack.
- For example, If I don't have SSH open, I won't send ICMP Port
Unreachable if a scanner or hacker attempts to connect. Besides, a
scanner is probably ignoring them and looking for SYN-ACKs only.
- For something like PMTU Discovery, I simply allow ICMP - Fragmentation
Needed messages.
- On AMPR, the operators have made a troubleshooting case for a need to
Ping me, so I permit ICMP Echo Request from your GW IPs and 44 allocations.
- Traceroute causes CPU resources to be used on my router or other
downstream devices, even for a destination IP other than itself, so I
block TTLs >= 7.
- In any case, unsolicited packets on my WAN are not considered
"legitimate" to me, so DROPping is OK.
- In all cases, outbound is allowed, so the reverse path is OK.
http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject
When reading this link, recall:
- I have 0 "legitimate users" on the WAN
- The only knowledge I'm giving to an attacker whom I drop is my IP,
which they already possess
- I WANT port scans to fail, even from the LAN (the writer makes an
opposite assumption)
73,
- Lynwood
KB3VWG
for some delusional security advantages.
3:54 p.m.
New subject: non-operational gateways
It still doesn't improve your security at all. It will just impair
proper networking and prevent debugging.
But it's your system, your the boss :-)
On 24.05.2017 22:26, lleachii--- via 44Net wrote:
(Please trim inclusions from previous messages)
_______________________________________________
Marius,
Not delusional at all, in my security instance, if I were to have
IPENCAP closed, I wouldn't configure my device to send ICMP
Unreachable messages for it. The perceived gain is that my router
doesn't use CPU resources to process a packet I don't want. This is a
common configuration of a Firewall that Drops by default - I'm not
"forcing" my firewall to do it. It takes additional configuration to
accept-then-reject. The drop by default is helpful in scenarios like a
DDoS attack at the border attempting to use you for an amplification
attack.
4:22 p.m.
New subject: non-operational gateways
Marius,
LOL my friend, indeed true. In general, it doesn't matter, I
suppose...since everyone knows the IP exists on the Internet, but they
don't know for certain there's an endpoint on line, or what it serves.
The only people who "know" about my [dynamic] endpoint are:
- Me
- AMPR OPs
- those visiting my HTTP server
- those scanning IPs (which I work on blocking); and
- those to whom I initiate a connection
They're reduced to guessing and soliciting responses from IPs, while
uncertain a device is in fact on line. As for debugging, the only people
I permit to debug from the WAN....are you guys. You're all now allowed
by your IPs in the portal and your 44 addresses.
:)
73,
- KB3VWG
But it's your system, your the boss :-)
2739
days inactive
2739
days old
14 comments
6 participants
participants (6)
-
Brian Kantor -
lleachii＠aol.com -
Marius Petrescu -
Michael Fox - N6MEF -
R P -
Rob Janssen