Firewall, data collect and opened port 23

General discussion
1

I use (I hope) the default firewall rules and I said only three rules to redirect ports: 22, 443 and 50xx. These three ports are open. Still, it is an open port 23.

All ports with Data collection are closed with the exception of port 22 that is redirected.

Telnet (23/TCP)
Telnet-alternative port (2323/TCP)
Http (80/TCP)
Squid HTTP proxy (3128/TCP)
Polipo proxy HTTP (8123/TCP)
HTTP proxy (8080/TCP)

It is strange to me that I should for a single one port 23 create a rule for its close - please advice, why is open port 23 and what to do to not to spoil the statistics.

Port 23 is not even in the my Traffic Rules or Port Forwards.

Výstřižek.JPG1212×537 55 KB

Výstřižek 2.JPG1004×921 104 KB

2

Hi Jarda!

As you wrote, the port 23 is honeypot port. It is forwarded outside your router to NIC.CZ security tools for analysis purposes. There is not real telnet service or daemon running in your router.

See screenshot from Foris GUI (https://your_router_address):

Snímek obrazovky pořízený 2017-01-03 01-53-42.png1047×466 55.3 KB

Be aware that not all firewall rules are visible in LuCI firewall page.
First emulated service is Telnet (23/TCP). It is well known (vulnerable) service for remote terminal access and many hackers try to log in. You can disable it by clearing (un-checking) the Telnet box.

Port 23 is NOT real own listening port on Turris Omnia. It is forwarded to port 1392 by “hidden” iptables rule. See SSH terminal command outputs:

root@turris_jis:~# netstat -anpt | grep LIST | sort tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 2263/sshd tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 17108/kresd tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 6015/lighttpd tcp 0 0 0.0.0.0:8443 0.0.0.0:* LISTEN 6015/lighttpd tcp 0 0 :::1392 :::* LISTEN 2477/ucollect tcp 0 0 :::22 :::* LISTEN 2263/sshd tcp 0 0 :::3692 :::* LISTEN 2477/ucollect tcp 0 0 :::4497 :::* LISTEN 2477/ucollect tcp 0 0 :::53 :::* LISTEN 17108/kresd tcp 0 0 :::8080 :::* LISTEN 6015/lighttpd tcp 0 0 :::8443 :::* LISTEN 6015/lighttpd tcp 0 0 :::9449 :::* LISTEN 2477/ucollect tcp 0 0 :::9492 :::* LISTEN 2477/ucollect root@turris_jis:~# root@turris_jis:~# root@turris_jis:~# root@turris_jis:~# iptables-save | grep 23 -A ucollect_fake -p tcp -m tcp --dport 2323 -j REDIRECT --to-ports 3692 -A ucollect_fake -p tcp -m tcp --dport 23 -j REDIRECT --to-ports 1392 -A ucollect_fake -p tcp -m tcp --dport 8123 -j REDIRECT --to-ports 9492 -A ucollect_fake -p tcp -m tcp --dport 2323 -j MARK --set-xmark 0x40000/0xc0000 -A ucollect_fake -p tcp -m tcp --dport 23 -j MARK --set-xmark 0x40000/0xc0000 -A ucollect_fake -p tcp -m tcp --dport 8123 -j MARK --set-xmark 0x40000/0xc0000 root@turris_jis:~#

3

Port 23 is real own listening port on Turris Omnia. It is forwarded to port 1392 by “hidden” iptables rule.
???

I’m not sure. To capture traffic on ports occur only when they are not used by the user! even if it is tracking is enabled "

For example, monitoring the port 80 is enabled, but at the same time I enter the redirection rule 80–should be on the 8080 (port is opened). Then port 80 is not being monitored !

I’m now 23 port opened (I don’t know why) and in the statistics of data yesterday on port 23 = zero. Before changing settings, a few days before the port was closed and 23 in statistics has been.

Výstřižek.JPG339×577 33.3 KB

…
So my main question is why is port 23 be open, when I did not define a rule that would allow. Effect on the State of the port 23 had two strange default match rules - see red point checked in the picture the first post.

The port status (open-closed or dropped) has the effect of on whether it will be moninitored in the captured packets with the firewall.

Disable the port 23 I can, but better would be to know why is open when it is not a rule that would allow a default rule that on and it affects is incomprehensible.

4

Please, use following two commands to check which process is listening on port 23 and what rules in firewall are responsible that the port 23 is opened.

netstat -anpt | grep LIST
iptables-save | grep 23

Paste the command outputs here. We will see what is behind…

5

Konečně pro mně hloupého rada, která něco řeší :slight_smile:

root@turris:~# netstat -antp | grep LIST
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN     d
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     d
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN     d
tcp        0      0 0.0.0.0:58732           0.0.0.0:*               LISTEN     n
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN     d
tcp        0      0 :::9492                 :::*                    LISTEN     t
tcp        0      0 :::53                   :::*                    LISTEN     d
tcp        0      0 :::22                   :::*                    LISTEN     d
tcp        0      0 :::443                  :::*                    LISTEN     d
tcp        0      0 :::9449                 :::*                    LISTEN     t
tcp        0      0 :::1449                 :::*                    LISTEN     t
tcp        0      0 :::3692                 :::*                    LISTEN     t
tcp        0      0 :::80                   :::*                    LISTEN     d
tcp        0      0 :::1392                 :::*                    LISTEN     t
tcp        0      0 :::4497                 :::*                    LISTEN     t
root@turris:~# iptables-save | grep 23
-A ucollect_fake -p tcp -m tcp --dport 2323 -j REDIRECT --to-ports 3692
-A ucollect_fake -p tcp -m tcp --dport 23 -j REDIRECT --to-ports 1392
-A ucollect_fake -p tcp -m tcp --dport 8123 -j REDIRECT --to-ports 9492
-A OUTPUT -p udp -m multiport --ports 123,53 -j DSCP --set-dscp 0x24
-A ucollect_fake -p tcp -m tcp --dport 2323 -j MARK --set-xmark 0x40000/0xc0000
-A ucollect_fake -p tcp -m tcp --dport 23 -j MARK --set-xmark 0x40000/0xc0000
-A ucollect_fake -p tcp -m tcp --dport 8123 -j MARK --set-xmark 0x40000/0xc0000
-A zone_wan_forward -p tcp -m tcp --dport 23 -m comment --comment "23 port prohT
-A zone_wan_forward -p udp -m udp --dport 23 -m comment --comment "23 port prohT
root@turris:~#
6

First command result:
No process or service is listening in your system at TCP port 23. It is OK, you can be calm. Your system is not in danger. :slight_smile:

Second command:
Port 23 is redirected to 1392 and incoming traffic is marked. My opinion is that there is active forwarding from TCP 23 to NIC.CZ security center by special tunnel. There is traffic analyzed. It is not your concern.
Port 23 looks like opened, but possible incoming packets from WAN go through tunnel to NIC.CZ. Real listening device is not yours but NIC.CZ.
Sorry, I do not understand how the forwarding and tunnel is set. Therefore my explanation is very basic. But result is your router is OK concerning TCP 23.
Later we can ask Turris support to explain how tunnel and remote forwarding work.

(Pokouším se psát anglicky kvůli případným dalším čtenářům.)

7

Bing Translator to jistí na mé straně http://www.bing.com/translator/

Thank you for the effort.

Both rules are unchecked, port 23 is opened. My the current idea is - that he was instructed to monitor port, port must not be used by the user !

Example: do I enable tracking port 80 and at the same time I’ll redirect port 80 should be on the 8081.
Result: the port will be opened and the tracking will not occur.

Therefore, it is strange to me why is 23 open - nor is it a rule that it has authorised.
I was trying to port 23 of closed without result.

Sekce Firewall - Traffic Rules on the first line

23 port prohibit
Any tcp, udp From any host in wan
To any host, port 23 in lan Refuse forward

or

23 port prohibit
Any tcp, udp From any host in wan
To any host, port 23 in any zone Refuse forward

or

23 port prohibit
Any tcp, udp From any host in wan
To any router IP at port 23 on this device Refuse input

Port 23 is still open. No activity in the last captured data of my router on port 23

I’ll let it stand some days, I will observe. Then the query support

8

Have you selected “Emulated services: Telnet (23/TCP)”? Because that is the likely reason for firewall rule that redirects the port 23 to port 1392 and thus being “open”.

9

Yes, I see that’s the problem! Port 23 is behaving differently than the other collected ports. To enable emulation only for port 23 opens this port ! In other ports, the port does not be open ( and for collecting don`t must be used at the same time by users … forwarding).

Gott de gerechte! Problem solved …