As I've mentioned, I'm now logging statistics for the amprgw router. I could make these available on a web site, but I'm hesitant to do so without consensus from the community because the per-gateway stats have the side effect of revealing what subnet goes to what gateway, thus giving the bad guys more insight into how the AMPRNet-Internet gateway works and what hosts to impersonate to inject bad packets into the network.
A sample of the statistics file is below.
What do you folks think about making this available? - Brian
started at Sat Apr 29 10:15:37 2017 snapshot at Sat Apr 29 10:45:00 2017 uptime: 0+00:29:23 (1763 seconds)
packets/bytes ---------/--------- 121781/76089093 ipip encapped input 117631/73371842 forwarded out 0/0 no source gateway
467445/48802372 raw input 467434/48801678 encapped out 0/0 no destination gateway
2646/175516 encap to encap dropped
7692 discarded 0 TTL exceeded 0 ICMP sent
615 routes loaded (gateway counters cleared) 1486 seconds ago at Sat Apr 29 10:20:14 2017
entry subnet encap gateway outpkts outbytes inpkts inbytes ----- ------------------- ----- ---------------- --------- --------- --------- --------- 0 44.0.0.1/32 ipip 169.228.66.251 2 175 0 0 [etc]
Brian,
What if we put this stats page behind the portal login? That way only registered AMPRNet users can access and view it and the outside world is non the wiser..
73,
Ruben - ON3RVH
-----Original Message----- From: 44Net [mailto:44net-bounces+on3rvh=on3rvh.be@hamradio.ucsd.edu] On Behalf Of Brian Kantor Sent: zaterdag 29 april 2017 19:52 To: 44net@hamradio.ucsd.edu Subject: [44net] amprgw router statistics
(Please trim inclusions from previous messages) _______________________________________________ As I've mentioned, I'm now logging statistics for the amprgw router. I could make these available on a web site, but I'm hesitant to do so without consensus from the community because the per-gateway stats have the side effect of revealing what subnet goes to what gateway, thus giving the bad guys more insight into how the AMPRNet-Internet gateway works and what hosts to impersonate to inject bad packets into the network.
A sample of the statistics file is below.
What do you folks think about making this available? - Brian
started at Sat Apr 29 10:15:37 2017 snapshot at Sat Apr 29 10:45:00 2017 uptime: 0+00:29:23 (1763 seconds)
packets/bytes ---------/--------- 121781/76089093 ipip encapped input 117631/73371842 forwarded out 0/0 no source gateway
467445/48802372 raw input 467434/48801678 encapped out 0/0 no destination gateway
2646/175516 encap to encap dropped
7692 discarded 0 TTL exceeded 0 ICMP sent
615 routes loaded (gateway counters cleared) 1486 seconds ago at Sat Apr 29 10:20:14 2017
entry subnet encap gateway outpkts outbytes inpkts inbytes ----- ------------------- ----- ---------------- --------- --------- --------- --------- 0 44.0.0.1/32 ipip 169.228.66.251 2 175 0 0 [etc] _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
That would be difficult to do, but is a possibility.
Alternatively, also difficult to do, I could possibly make it available by FTP with the same password as the encap file. - Brian
On Sat, Apr 29, 2017 at 06:10:26PM +0000, Ruben ON3RVH wrote:
What if we put this stats page behind the portal login? That way only registered AMPRNet users can access and view it and the outside world is non the wiser.. 73, Ruben - ON3RVH
I'd prefer individual subnets NOT be listed in any public location.
Michael N6MEF
-----Original Message----- That would be difficult to do, but is a possibility.
Alternatively, also difficult to do, I could possibly make it available by FTP with the same password as the encap file.
- Brian
On Sat, Apr 29, 2017 at 06:10:26PM +0000, Ruben ON3RVH wrote:
What if we put this stats page behind the portal login? That way only registered AMPRNet users can access and view it and the
outside world is non the wiser..
73, Ruben - ON3RVH
The current router statistics (updated every 15 minutes) are now available from https://gw.ampr.org/private/stats.txt using the same username and password as it takes to FTP the encap file from the portal. (This is NOT your portal login but rather the FTP access authorization.)
Because it contains somewhat sensitive data (the same data as in the 'encap' file), I've chosen to make it available using the same username and password.
In viewing the per-gateway counters, note that any gateway whose counters (all of them) are zero is omitted from the listing. - Brian
Now that's spooky: I hadn't even published the URL on this list when someone attempted to fetch it from host 4.79.123.3. - Brian
On Sat, Apr 29, 2017 at 04:55:00PM -0700, Brian Kantor wrote:
The current router statistics (updated every 15 minutes) are now available from https://gw.ampr.org/private/stats.txt using the same username and password as it takes to FTP the encap file from the portal. (This is NOT your portal login but rather the FTP access authorization.)
Because it contains somewhat sensitive data (the same data as in the 'encap' file), I've chosen to make it available using the same username and password.
Brian,
That is rather odd that someone had the URL before it left your mind (and server)...the few hits you saw from me were to check if directory browsing is disabled.
Chris,
Do you run anything else on that server? Basically, I'm asking...is the only thing of value to a hacker on that device the data that comprises The Portal...?
Marc,
Sharing lists may be a solution. I may be willing to make my netflow available. In principal, I stopped blocking IPs and blocs in 2013 or 2014. It's become easier to generally firewall and monitor the various protocols/ports they're randomly trying to access. This is more so necessary in the ecosystem of the Internet of Things, where a device in Country A can infect a device in Country B, and spread to Countries C ad infinitum.
73,
- Lywnood KB3VWG
All,
From the most recent 12-hour NetFlow sampling, these are the ports most commonly attempted to IPs in my subnet (for which I host no available inbound services and have a general firewall rule against):
tcp/22 - SSH tcp/23 - Telnet tcp/ 2323 - Telnet 'Alternative' tcp/2222 - SSH 'Alternative' tcp/631 tcp/3306 tcp/3389 - Microsoft Remote Desktop Protocol tcp/5358 tcp/5555 tcp/8081 tcp/8888 tcp/9200 udp/161 - Simple Network Management Protocol udp/523 udp/623 tcp/502 udp/5060 - Session Initiation Protocol - Voice over IP
ICMP Packets not corresponding to any sent packets:
ICMP Time-Exceeded-In-transit ICMP Destination-Host-Unreachable ICMP Destination-Port-Unreachable
Other:
ICMP Echo-Request (normal pinging)
These four particular NetFlow data are somewhat alarming, since it appears a RIP packet may have been attempted to be sent:
2017-04-29 20:56:05.866 0.000 TCP94.102.49.193:31430 http://192.168.7.9/nfsen/nfsen.php#null ->44.60.44.131:8099 http://192.168.7.9/nfsen/nfsen.php#null 1 40 1 2017-04-29 21:22:16.421 0.000 UDP94.102.49.193:12902 http://192.168.7.9/nfsen/nfsen.php#null ->44.60.44.2:520 http://192.168.7.9/nfsen/nfsen.php#null 1 52 1 2017-04-29 21:41:19.325 0.000 TCP94.102.49.193:1702 http://192.168.7.9/nfsen/nfsen.php#null ->44.60.44.131:9051 http://192.168.7.9/nfsen/nfsen.php#null 1 40 1 2017-04-29 22:06:55.283 0.000 TCP94.102.49.193:26459 http://192.168.7.9/nfsen/nfsen.php#null ->44.60.44.131:4911 http://192.168.7.9/nfsen/nfsen.php#null 1 40 1
This occurs 24x7x365. Those who do not run firewalls to block services from the Internet should really consider it.
- KB3VWG
The NetFlow data are from a computer search engine (finds machines, not websites)
*94.102.49.193 -> cloud.census.shodan.io*
IP range : 94.102.49.0 - 94.102.49.255 Network name : SC-QUASI61 Infos : QUASI Infos : Quasi Networks LTD (IBC) Country : Seychelles (SC) Abuse email : abuse@quasinetworks.com, abuse@quasinetworks.com Source : RIPE
https://en.wikipedia.org/wiki/Shodan_(website)
- KB3VWG
On 04/30/2017 10:01 AM, lleachii@aol.com wrote:
These four particular NetFlow data are somewhat alarming, since it appears a RIP packet may have been attempted to be sent:
2017-04-29 20:56:05.866 0.000 TCP94.102.49.193:31430 http://192.168.7.9/nfsen/nfsen.php#null ->44.60.44.131:8099 http://192.168.7.9/nfsen/nfsen.php#null 1 40 1 2017-04-29 21:22:16.421 0.000 UDP94.102.49.193:12902 http://192.168.7.9/nfsen/nfsen.php#null ->44.60.44.2:520 http://192.168.7.9/nfsen/nfsen.php#null 1 52 1 2017-04-29 21:41:19.325 0.000 TCP94.102.49.193:1702 http://192.168.7.9/nfsen/nfsen.php#null ->44.60.44.131:9051 http://192.168.7.9/nfsen/nfsen.php#null 1 40 1 2017-04-29 22:06:55.283 0.000 TCP94.102.49.193:26459 http://192.168.7.9/nfsen/nfsen.php#null ->44.60.44.131:4911 http://192.168.7.9/nfsen/nfsen.php#null 1 40 1
I assume it means that my ISP is running a caching proxy, or it could mean that some 3-letter agency is spying on my browsing habits.
Or of course, with the recent change in privacy law, the ISP or upstream could be building a database of where I've been browsing in order to sell advertising targeting me. - Brian
On Sun, Apr 30, 2017 at 09:21:32AM -0400, lleachii--- via 44Net wrote:
That is rather odd that someone had the URL before it left your mind (and server)...the few hits you saw from me were to check if directory browsing is disabled.
I'm workin an a HTBH (Honeypot Triggered Blackhole) project. Got the idea that honeypot traffic is non customer traffic and thus could be used to temp blackhole traffic on the border routers from originating IP's. This could also be used here. But it's still in design phase..
Ruben - ON3RVH
On 30 Apr 2017, at 15:22, lleachii--- via 44Net 44net@hamradio.ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________ Brian,
That is rather odd that someone had the URL before it left your mind (and server)...the few hits you saw from me were to check if directory browsing is disabled.
Chris,
Do you run anything else on that server? Basically, I'm asking...is the only thing of value to a hacker on that device the data that comprises The Portal...?
Marc,
Sharing lists may be a solution. I may be willing to make my netflow available. In principal, I stopped blocking IPs and blocs in 2013 or 2014. It's become easier to generally firewall and monitor the various protocols/ports they're randomly trying to access. This is more so necessary in the ecosystem of the Internet of Things, where a device in Country A can infect a device in Country B, and spread to Countries C ad infinitum.
73,
- Lywnood
KB3VWG _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Ruben,
I understand consensus amongst the operators (and from Brian, since he runs AMPRGW), that we not run honeypots. Since any traffic engaging with the remote host generates unnecessary bandwidth at AMPRGW.
This is why I simply block and keep detailed stats on all IP hits.
- KB3VWG
I agree it's best not to run it on AMPRNet. I do have one running on another subnet and once everything is set up and I have my API ready and stable, that data could be used by AMPRNet operators interrested in it to block/nullroute those hosts on their border
Ruben - ON3RVH
On 30 Apr 2017, at 16:39, lleachii--- via 44Net 44net@hamradio.ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________ Ruben,
I understand consensus amongst the operators (and from Brian, since he runs AMPRGW), that we not run honeypots. Since any traffic engaging with the remote host generates unnecessary bandwidth at AMPRGW.
This is why I simply block and keep detailed stats on all IP hits.
- KB3VWG
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Very true indeed Ruben.
I think all OPs should look at http://shodan.io/ for their IP addresses, hostnames, Gateway IPs, etc.
I see a lot of our devices on this search engine, giving brand, firmware type, ports accessible, etc.
- KB3VWG
On 04/30/2017 10:48 AM, Ruben ON3RVH wrote:
I agree it's best not to run it on AMPRNet. I do have one running on another subnet and once everything is set up and I have my API ready and stable, that data could be used by AMPRNet operators interrested in it to block/nullroute those hosts on their border
Ruben - ON3RVH
On 30 Apr 2017, at 16:39, lleachii--- via 44Net 44net@hamradio.ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________ Ruben,
I understand consensus amongst the operators (and from Brian, since he runs AMPRGW), that we not run honeypots. Since any traffic engaging with the remote host generates unnecessary bandwidth at AMPRGW.
This is why I simply block and keep detailed stats on all IP hits.
- KB3VWG
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Thanks Brian. As always, your continued enhancements are very much appreciated.
Michael N6MEF
-----Original Message----- From: 44Net [mailto:44net-bounces+n6mef=mefox.org@hamradio.ucsd.edu] On Behalf Of Brian Kantor Sent: Saturday, April 29, 2017 4:55 PM To: AMPRNet working group 44net@hamradio.ucsd.edu Subject: Re: [44net] amprgw router statistics
(Please trim inclusions from previous messages) _______________________________________________ The current router statistics (updated every 15 minutes) are now available from https://gw.ampr.org/private/stats.txt using the same username and password as it takes to FTP the encap file from the portal. (This is NOT your portal login but rather the FTP access authorization.)
Because it contains somewhat sensitive data (the same data as in the 'encap' file), I've chosen to make it available using the same username and password.
In viewing the per-gateway counters, note that any gateway whose counters (all of them) are zero is omitted from the listing.
- Brian
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Thank you! It's been kind of fun writing the router code; I haven't worked on a sizeable 'C' program in some time. (It's about 4,000 lines of code, all told.)
There's lots more to do still. - Brian
On Sat, Apr 29, 2017 at 05:08:44PM -0700, Michael Fox - N6MEF wrote:
Thanks Brian. As always, your continued enhancements are very much appreciated.
Michael N6MEF
I think I'm missing something obvious here, but how can I find the credentials for accessing this? I tried looking for instructions on how to FTP the encap file from the portal, but I could only find information about the API.
Thanks,
Zachary VA3ZTS
On Sat, Apr 29, 2017 at 04:55:00PM -0700, Brian Kantor wrote:
(Please trim inclusions from previous messages) _______________________________________________ The current router statistics (updated every 15 minutes) are now available from https://gw.ampr.org/private/stats.txt using the same username and password as it takes to FTP the encap file from the portal. (This is NOT your portal login but rather the FTP access authorization.)
Because it contains somewhat sensitive data (the same data as in the 'encap' file), I've chosen to make it available using the same username and password.
In viewing the per-gateway counters, note that any gateway whose counters (all of them) are zero is omitted from the listing.
- Brian
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Well, the login/password wouldn't be very secure if we posted them on the wiki, would they?
If you're a gateway operator, I'll mail them to you. Contact me off-list. - Brian
On Sat, Apr 29, 2017 at 11:17:25PM -0400, Zachary Seguin wrote:
I think I'm missing something obvious here, but how can I find the credentials for accessing this? I tried looking for instructions on how to FTP the encap file from the portal, but I could only find information about the API.
Thanks,
Zachary VA3ZTS
The gateway subnets available today from google .... ________________________________ From: 44Net 44net-bounces+ronenp=hotmail.com@hamradio.ucsd.edu on behalf of Brian Kantor Brian@UCSD.Edu Sent: Saturday, April 29, 2017 10:51:59 AM To: 44net@hamradio.ucsd.edu Subject: [44net] amprgw router statistics
(Please trim inclusions from previous messages) _______________________________________________ As I've mentioned, I'm now logging statistics for the amprgw router. I could make these available on a web site, but I'm hesitant to do so without consensus from the community because the per-gateway stats have the side effect of revealing what subnet goes to what gateway, thus giving the bad guys more insight into how the AMPRNet-Internet gateway works and what hosts to impersonate to inject bad packets into the network.
A sample of the statistics file is below.
What do you folks think about making this available? - Brian
started at Sat Apr 29 10:15:37 2017 snapshot at Sat Apr 29 10:45:00 2017 uptime: 0+00:29:23 (1763 seconds)
packets/bytes ---------/--------- 121781/76089093 ipip encapped input 117631/73371842 forwarded out 0/0 no source gateway
467445/48802372 raw input 467434/48801678 encapped out 0/0 no destination gateway
2646/175516 encap to encap dropped
7692 discarded 0 TTL exceeded 0 ICMP sent
615 routes loaded (gateway counters cleared) 1486 seconds ago at Sat Apr 29 10:20:14 2017
entry subnet encap gateway outpkts outbytes inpkts inbytes ----- ------------------- ----- ---------------- --------- --------- --------- --------- 0 44.0.0.1/32 ipip 169.228.66.251 2 175 0 0 [etc] _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On Sat, 29 Apr 2017 10:51:59 -0700, Brian Kantor wrote:
As I've mentioned, I'm now logging statistics for the amprgw router. I could make these available on a web site, but I'm hesitant to do so without consensus from the community because the per-gateway stats have the side effect of revealing what subnet goes to what gateway, thus giving the bad guys more insight into how the AMPRNet-Internet gateway works and what hosts to impersonate to inject bad packets into the network. ... What do you folks think about making this available?
Brian,
I suggest you make an anonymized version available to trusted list members, and ask those whom request access to refrain from distributing the information publicly.
Since I have little experience in this area, I would prefer to see summary info instead of the actual data. HTH.
73,
Bill W4EWH