Is Data-Collection / Honeypot actually exploitable?

Hello, I have a Turris Omnia, Turris OS version 3.11.13
I participate in the Data Collection Opt-In.

My Questions is: Are those emulated services actually “working”? i.E. is it possible to exploit the emulated services, for example, for a DDOS Attack?

My understanding is, that those Serices don’t “do” anything but collecting data. My provider however, claims that I have an open Telnet Port + telnet funcionality which could be exploited for DDOS Attacks…?! The Service Guy on the phone sounded quite unhappy with this.

I guess one of us is wrong then.

/edit

I swiftly read through the EULA and the Wiki etc. but could not find an answer to that.

Not necessarily - the ISP staffer probably assumes that the telnet port provides means to potentially invade (brute force) and hijack the node and subsequently leverage the hijacked node for malicious intent.

However there is no actual telnet socket running in the emulated scenario, unless you have a real instance up and running.

You can check from the ssh for listening sockets with ss -tuwlpn

2 Likes

I’ll just add that it’s the main point of honeypots to appear as exploitable hosts but actually work against the attackers (through analyzing their behavior in some way).

Personally I would could caution running a honeypot that provides an active listening socket directly on a host that provides vital infrastructure, be that networking a/o data storage.

My preference would be to deploy any sort of honeypot with an active listening socket in an unprivileged virtual container environment and not sharing the same namespace with its host.


What is more that any open WAN port, whether for a honeypot or a real service, may attract the curiosity of actors with nefarious intent and thus can lead to an increase in packet volume arriving at such port - worst case overloading the capabilities of the host providing the service.

There’s no real command processing on Turris honeypots IIRC. The ssh and telnet are proxied to a service instead.

That’s what I told him. That there is no actual “real” service behind it and therefore you can not exploit it. He still claimed that this still would be possible… :thinking: He specifically described a DDOS Attack (sending 1kb to your router, your router sends 1MB to another website etc.). So I was wondering if there is an actual Telnet service behind this and I got it all wrong those years (the concept of a honeypot).

root@turris:~# netstat -lntup
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:2525            0.0.0.0:*               LISTEN      8475/python2.7
tcp        0      0 127.0.0.1:445           0.0.0.0:*               LISTEN      4324/smbd
tcp        0      0 192.168.0.1:445         0.0.0.0:*               LISTEN      4324/smbd
tcp        0      0 127.0.0.1:139           0.0.0.0:*               LISTEN      4324/smbd
tcp        0      0 192.168.0.1:139         0.0.0.0:*               LISTEN      4324/smbd
tcp        0      0 127.0.0.1:11883         0.0.0.0:*               LISTEN      3597/mosquitto
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      4356/lighttpd
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      12054/kresd
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      3719/sshd
tcp        0      0 127.0.0.1:9080          0.0.0.0:*               LISTEN      4336/python3.6
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      4356/lighttpd
tcp        0      0 ::1:445                 :::*                    LISTEN      4324/smbd
tcp        0      0 fd8a:9128:30e4::1:445   :::*                    LISTEN      4324/smbd
tcp        0      0 fe80::da58:d7ff:fe00:231f:445 :::*                    LISTEN      4324/smbd
tcp        0      0 :::9449                 :::*                    LISTEN      12556/ucollect
tcp        0      0 :::1449                 :::*                    LISTEN      12556/ucollect
tcp        0      0 ::1:139                 :::*                    LISTEN      4324/smbd
tcp        0      0 fd8a:9128:30e4::1:139   :::*                    LISTEN      4324/smbd
tcp        0      0 fe80::da58:d7ff:fe00:231f:139 :::*                    LISTEN      4324/smbd
tcp        0      0 :::3692                 :::*                    LISTEN      12556/ucollect
tcp        0      0 :::1392                 :::*                    LISTEN      12556/ucollect
tcp        0      0 :::80                   :::*                    LISTEN      4356/lighttpd
tcp        0      0 :::4497                 :::*                    LISTEN      12556/ucollect
tcp        0      0 :::6513                 :::*                    LISTEN      4879/socat
tcp        0      0 :::9492                 :::*                    LISTEN      12556/ucollect
tcp        0      0 :::53                   :::*                    LISTEN      12054/kresd
tcp        0      0 :::22                   :::*                    LISTEN      3719/sshd
tcp        0      0 :::443                  :::*                    LISTEN      4356/lighttpd
udp        0      0 0.0.0.0:7001            0.0.0.0:*                           -
udp        0      0 0.0.0.0:53              0.0.0.0:*                           12054/kresd
udp        0      0 0.0.0.0:67              0.0.0.0:*                           9510/dnsmasq
udp        0      0 192.168.0.255:137       0.0.0.0:*                           4325/nmbd
udp        0      0 192.168.0.1:137         0.0.0.0:*                           4325/nmbd
udp        0      0 0.0.0.0:137             0.0.0.0:*                           4325/nmbd
udp        0      0 192.168.0.255:138       0.0.0.0:*                           4325/nmbd
udp        0      0 192.168.0.1:138         0.0.0.0:*                           4325/nmbd
udp        0      0 0.0.0.0:138             0.0.0.0:*                           4325/nmbd
udp        0      0 :::546                  :::*                                7035/odhcp6c
udp        0      0 :::53                   :::*                                12054/kresd

That is true, I was also expecting that he will go this route with his arguments, but he did not.

Tthat describes a deflection attack and to the best of my knowledge is not particular to Telnet but can be achieved with any host’s firewall that does not drop packets but instead responses to spoofed source ip packets with a reject code, e.g. port unreachable or tcp reset.

But of course since the Telnet port shows open it is more inviting and as its sends a response, if I am not mistaken, it could be picked up for the purpose of a deflection attack with a spoofed source ip. Not sure if the proxy back-end perhaps has a rate limiting implemented, which would be sensible though.


He is just concerned that the ISP’s ASN gets a bad reputation with an open telnet port showing in its ip range.

Sure, but I was more generally referring to honeypots, which may vary in concepts - those on the TOS being of the proxy design but there are also other sorts. But then again this forum is pertinent to TOS and I probably should not have digressed.

Just to sort this out:

  1. HaaS emulates ssh service. On the client side (our routers), there is just a proxy (i.e. a forwarder) to dedicated servers where ssh is emulated. You can see more at the haas web, as referred and the code at CZ.NIC gitlab

  2. telnet (and other so-called minipots) runs on a router and emulates real service interface to collect login credentials from attackers. You can see further info at our docs and the code at gitlab

Anyway, it’s true none of them neither runs nor emulates any commands on a router.

1 Like

The concern of the ISP staffer seems that the open WAN ports attract actors with nefarious intent, well that is the purpose/nature of the honeypot, but that makes those ports also low hanging fruit for deflection attacks with spoofed source IPs - at least to my understanding both, Telnet as well as HaaS, respond with packets when accessed.

Question thus is there some sort of rate limiting in place that would mitigate the potential abuse of the honeypots as deflectors?

Is it possible to use a SYN-ACK packet of 3-way TCP handshake as an effective deflector to use it in some DDoS attack? If so, the Internet is full of listening TCP ports.

Not only but also any firewall

is a potential deflector for packets with spoofed source ip.

That is where rate limiting (synflood_rate) comes in, which the firewall also provides the facilities for. Plus advanced firewalls provide banning of IPs if a certain rate limit (within a given period) is exceeded .

Hello @darKing

as it was stated in the discussion already, telnet minipot is not a real service and it just collects credentials from attackers.

This service is not prone to DDoS you have mentioned (“sending 1kb to your router, your router sends 1MB to another website etc.”) as it runs on TCP and such amplification attack on spoofed address is usable on UDP services.

On top of that, it does not allow an attacker to execute any command on your device so it’s also less likely to be vulnerable to exploits. Please see documentation of our Data Collection I have posted in Is Data-Collection / Honeypot actually exploitable? - #10 by vojtech.myslivec - SW help - Turris forum for more information.

If your ISP cause you some troubles due to Telnet minipot, you are able to turn this particular service off while keep Data collection enabled (in Foris interface on TOS 3.11.x):

2 Likes

And for completeness I should response to other minor points posted here.

Minipot (honeypots running on router) have limited amount of slots. This limits CPU usage and prevents effectively DDOS trough minipot service.

You wrote it right. This type of attack is primarily feasible with packet size escalation with initial exchange. That is that servers is going to response to connection and small packet with huge packet. TCP handshake prevents this as @vojtech.myslivec wrote.

That saying this is not exactly true. The point is size escalation. Reject packet is small and technically there is no escalation. The only thing that attacker can do is to use your firewall to bounce attack but doing true escalation is not possible up to my knowledge.

That is technically already done. Minipots are run as subprocess with no capabilities and as user “nobody”. There are data rate limitation in place in form of limited buffer sizes and minipot is not allocating any memory. In case of HaaS it is run in cgroups limiting CPU usage. Containers are not something all mighty for security. That is common misconception. They are created as usage of components and features that were in Linux for long time to limit processes access. In reality the most of the work developers around containers done is to lessen these limitations so it is less strict and you can run system under them. This means that theoretically container is less secure over no capabilities and “nobody”.

1 Like

I did not imply such but explicitly stated

which is contrary to

since it does the opposite by adding an additional layer of protection - which may not be infallible as most code is not.


Point taken, however size escalation may not be necessary to stage a (successful) DDoS deflection attack if a sufficient number of nodes bouncing to a target with a combined large volume of packets, never mind the packet size, as depending on the target’s capabilities to fend off such attack.
Nodes being abused for such purpose may not even notice of such abuse.

Anyway, my preference is for the firewall to always drop packets rather than respond with a reject code, just to pre-empt such scenario.

Thank you very much to everyone :smiley: super nice and detailed answers. Very pleasent experience. :slight_smile:

1 Like

This topic was automatically closed after 2 days. New replies are no longer allowed.