First I wanted to mention I am glad to read Bjorn's message about
adding some content to the network.
Keeping in contact is key. Be that a coordinator or any host on the
amprnet. Seems every few months on here we are discussing how someone
is sending out random packets, and a straight forward way to get a
hold of people would be helpful.
Some time back it was brought up to have a whois server or something
like that. I bet I can guess the status of that.
As for everyone having an ampr.org email address, perhaps a forwarding
service like the arrl.net addresses? Then there is the possible spam
problem, and the fact that someone would need to set up such a
service.
Overall a lot of good ideas are brought up on this list, so few ever
happen. The only solution I am offering is everyone should help
spread the word and try and get more people involved with moving this
network forward. I wish I had better coding skills.
One of the core problems at least in my country where the ampr/44net
space is not well utilized is the lack of higher speed equipment to
build a network. You really have to be part of a well organized club
with site connections to do anything microwave on any big scale from
what I have seen.
> The unanswered SYN traffic to port 23 is much, much more. Especially before the "allow only
> registered hosts" filter. We are dropping around 80 Mbyte/day of traffic for our /16 subnet due
> to the address not being registered, so that would be about 20 GByte/day for amprgw....
Of course it is way more than that. I forgot that the about count is only for the subnets within our /16
that are actually routed. That is about 1/5 of our space. So the total "noise" traffic is more like
400 MB/day and would be like 100 GB/day for the entire AMPRnet.
Rob
> I usually allow remote access (SSH, RDP, etc...) through VPN only.
> When access from Internet is absolutely required (because it's not
> possible to have a VPN), then I usually add a firewall rule to allow
> access only from a list of known WAN IP addresses.
That is certainly the best approach!
Also, whenever possible, I run those protocols on IPv6 only, preferably on an
address that is not as well in DNS for other services on the host. They
cannot viably scan the IPv6 range so this obscurity hides the remote access
quite well.
Rob
> >/When I had SSH open to the world, I saw similar usernames in the failure log as I now /> >/see on this telnet honeypot. /
> If your connectivity to the world is via a tunnel from amprgw, please
> resist the temptation to run a honeypot - we're trying to reduce the
> amount of bandwidth, not increase it. Although a honeypot isn't
> necessarily a big bandwidth consumer, every bit helps.
> - Brian
It is on our BGP-routed subnet so the traffic is via our own gateway through a direct IPIP tunnel
to that system. However, it is not really something to worry about. It attracts about 10-20 kbytes
of internet->host traffic per day (the usernames and passwords that I log).
Those attackers are trying maybe 10-15 different logons then move on. It is not like they try
a list of 100,000 most often use passwords, they probably have the default passwords for some
commonly used routers and other IoT devices, in some cases probably only a single one.
(the worms that infect one particular device)
The unanswered SYN traffic to port 23 is much, much more. Especially before the "allow only
registered hosts" filter. We are dropping around 80 Mbyte/day of traffic for our /16 subnet due
to the address not being registered, so that would be about 20 GByte/day for amprgw....
Rob
> As always, the best practice recommendation is to disable telnet logins
> entirely as it represents a security issue because passwords pass over
> the connection in clear plaintext.
> - Brian
Well, the issue is not really the passwords being in plaintext. The issue is the availability
of a remote login feature with possibly weak passwords. It affects SSH just as much as it
affects telnet. The malvolents are scanning the IPv4 space and when they can connect
to a remote logon service (telnet, SSH, RDP, VNC) they try a number of common usernames
and passwords. They are not listening in on your traffic. While it is clear that telnet is not
the most secure login service, it really doesn't make a difference.
I have a fake telnetd running on one of my systems that simply presents the user with a
login prompt and logs what is being typed, and it shows endless connections trying things
like root/12345 root/password admin/admin etc. They probably get into certain routers
or other systems like that, then install some trojan that does further scanning. This is also
indicated by certain loggings where they apparently believe they got logged in and then
send a long string like "wget something; chmod a+x something; ./something" or similar.
Rob
> The term to search for is 'honeypot'. There are many such scripts out there
> on github and on the web in general.
That is correct. In my case I quickly hacked something together but there are lots
of examples to be found that are probably much more advanced.
When I had SSH open to the world, I saw similar usernames in the failure log as I now
see on this telnet honeypot.
Rob
Hello Lynwood, I had in my JNOS virtually a lot of attempts connections to
port 23 from all part of the world, to achieve forwarding to other BBS had
change the telnet port to 2323 and substantially lower these attempts.
When I speak attempts to port 23 are evidence of brute force, it is almost
impossible to have open this port, also same the 20, 21, 443, etc.
73 Gabriel YV5KXE.
Venezuela AmprNet Coordinator
yv5kxe.ampr.org
Date: Thu, 29 Sep 2016 12:15:57 -0400
From: lleachii(a)aol.com
To: 44net(a)hamradio.ucsd.edu
Subject:Date: Thu, 29 Sep 2016 12:15:57 -0400
From: lleachii(a)aol.com
To: 44net(a)hamradio.ucsd.edu
Subject: [44net] Security - Telnet (port tcp/23)
Message-ID: <8c28faa2-76ff-45a9-06c6-1705433cf307(a)aol.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
All,
In June, we discussed a topic entitled: "Odd Username attempts at login"
where Bill, KG6BAJ noticed odd connection attempts to his JNOS system
via Telnet.
I have recently been working on my SNMP and NetFlow servers, and noticed
quite a bit of Telnet connection attempts from Asia, Europe and South
America. While I have also seen SSH, RDP, NTP, ICMP and VNC, by far the
largest amount of traffic reaching my border interface is Telnet.
Doing some research, I discovered that NIC.CZ <http://nic.cz/> has been
operating the
Turris Project. They have determined that these attempts are coming from
a botnet of embedded devices that have Telnet vulnerabilities.
I have provided a link to those findings here:
https://en.blog.nic.cz/2016/09/01/telnet-is-not-dead-at-
least-not-on-smart-devices/
09-28 19:57:36 0.000 TCP 60.189.137.98:28940 -> 44.60.44.128:2323
09-28 19:57:55 0.000 TCP 115.219.124.37:49067 -> 44.60.44.133:23
09-28 19:57:55 0.000 TCP 222.124.85.17:34905 -> 44.60.44.133:23
09-28 19:57:52 5.552 TCP 190.67.215.114:29593 -> 44.60.44.6:23
09-28 19:58:03 0.123 TCP 115.219.124.37:21070 -> 44.60.44.133:23
09-28 19:58:54 0.000 TCP 116.102.62.182:37311 -> 44.60.44.135:23
Please be mindful.
73,
- Lynwood
KB3VWG
All,
In June, we discussed a topic entitled: "Odd Username attempts at login"
where Bill, KG6BAJ noticed odd connection attempts to his JNOS system
via Telnet.
I have recently been working on my SNMP and NetFlow servers, and noticed
quite a bit of Telnet connection attempts from Asia, Europe and South
America. While I have also seen SSH, RDP, NTP, ICMP and VNC, by far the
largest amount of traffic reaching my border interface is Telnet.
Doing some research, I discovered that NIC.CZ has been operating the
Turris Project. They have determined that these attempts are coming from
a botnet of embedded devices that have Telnet vulnerabilities.
I have provided a link to those findings here:
https://en.blog.nic.cz/2016/09/01/telnet-is-not-dead-at-least-not-on-smart-…
09-28 19:57:36 0.000 TCP 60.189.137.98:28940 -> 44.60.44.128:2323
09-28 19:57:55 0.000 TCP 115.219.124.37:49067 -> 44.60.44.133:23
09-28 19:57:55 0.000 TCP 222.124.85.17:34905 -> 44.60.44.133:23
09-28 19:57:52 5.552 TCP 190.67.215.114:29593 -> 44.60.44.6:23
09-28 19:58:03 0.123 TCP 115.219.124.37:21070 -> 44.60.44.133:23
09-28 19:58:54 0.000 TCP 116.102.62.182:37311 -> 44.60.44.135:23
Please be mindful.
73,
- Lynwood
KB3VWG
> You need to use mangle rules in firewall to mark the incoming packets from the gateway interface and then using route marking route them back out the way they came.
That is another approach, but you will have to handle outgoing connections as well.
Rob
Good evening/morning folks!
I have some dumb questions about setting up the MicroTik. I currently have
everything set(I got all the RIP records and routes created), however, it
can't talk to the internet. I'm trying to figure out, would this be a
firewall issue? Do I need to create a whole new NIC just for the 44net?
Basically, where should I go from here?
Thanks,
Miguel Rodriguez
12th Grade Student
miguemely101(a)gmail.com
<javascript:_e(%7B%7D,'cvml','miguemely101(a)gmail.com');>
Tel: *561-758-0631*
*Accredited District Since 2008; Re-certification - January 2013*
Home of Florida's first LEED Gold Certified School
*Disclaimer*: Under Florida law, e-mail addresses are *public records*. If
you do not want your e-mail address released in response to a public
records request, do not send electronic mail to this entity. Instead,
contact this office by phone or in writing.
--
Miguel Rodriguez
12th Grade Student
miguemely101(a)gmail.com
Tel: *561-758-0631*
*Accredited District Since 2008; Re-certification - January 2013*
Home of Florida's first LEED Gold Certified School
*Disclaimer*: Under Florida law, e-mail addresses are *public records*. If
you do not want your e-mail address released in response to a public
records request, do not send electronic mail to this entity. Instead,
contact this office by phone or in writing.
