> 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.
> Rob,
> I thought the script took care of routing. So I would have to create new routes for 44net to go to the IPIP tunnel?
It should not be required for 44net, but only for internet. I.e. for communication between your 44net hosts
and systems on internet outside 44net. That traffic has to be forced through the IPIP tunnel to UCSD (169.228.66.251)
instead of directly to your ISP, which will drop it.
This can be achieved by creating the 44net routes in a different routing table, I'll wait to see if Marius joins
the discussion to find how this is best achieved when using his script. I am not using IPIP myself on my MikroTik,
I have a VPN to another system and use BGP. There I have configured the BGP to put the routes in a separate
routing table named amprnet and configured some IP Route Rules so that this table is used for amprnet traffic only.
Rob
> 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?
When you want to route from net-44 addresses to internet (non-net-44), and
your ISP implements source address filtering (BCP38) you need to setup policy
routing, because you need a separate default route for traffic from your public
internet address (pointing to your ISP) and for traffic from your net-44
systems (pointing to the IPIP tunnel to UCSD).
Rob
Thank you to all that responded to my email, I made my request through the portal.
I would like to provide free tunnel services to any amateur that applies and issue 44net addresses to those who qualify. I also will be experimenting locally with RF.
I am currently connected to AT&T at 10gbits/sec, should be snappy.
Thanks!
John
KD5ZZH
> So my question is this: Is what I want to do feasable as a way to get a
> static address and act as an AMPR gateway?
Yes, this works quite well. I have the same setup here.
I have a colocated Raspberry Pi that is on the IPIP mesh using ampr-ripd in
the standard setup that is described on the WiKi, and it serves my subnet and
a couple of /32 addresses.
My subnet is tunneled to my home using IPsec in AH/Tunnel mode. Using AH
instead of ESP (as is usually used) reduces CPU usage, and encryption is not
required for this purpose anyway. At home I have a MikroTik router.
I do have a fixed IP at home so IPsec is easy, when you don't have that it
may be easier to use a VPN that does not care about addresses, e.g. OpenVPN.
I also run a couple of applications locally on the Pi, hence the /32 addresses.
Today, thanks to Marius' work, it is also possible to use a MikroTik router
instead of the Raspberry Pi. It may be easier to configure and is available
in rackmount formfactor.
Rob
