XGS - V19.0.2 - WAN Side Telnet (23) Open!

This tcpdump: Did you do it on port 23? 

Try: tcpdump -ni any port 23 

Yes.

tcpdump -i Port2 port 23

and this is from Log...

Update:

we are under heavy attacks.

The DNAT Rule does not match. What Service is answering here?

So i tried this with a couple of Firewalls. None had Port23 open.

Telnet was a old setting from V17.0 (if i remember correctly). 

Please check the tcpdump of all ports to verify the appliance is actually answering. 

Is this installation / backup old? 

This is a NEW firewall. Installed yesterday.

Can you provide us/me your access ID? 

Hi,

I provided the access key in the Support Case: 06220855 

Hello Guenter,

Thank you for the Case ID, I have found the Access ID.

We’re currently checking the device.

Regards,

Do you see this telnet traffic in firewall log? If so, which firewall rule is it matching? 

I suspect you have a firewall rule forwarding/allowing the telnet traffic from WAN to SFOS. 

Hello Guenter,

GES has found that somebody has configured "Appliance Access" to be enabled; this will cause all the ports to accept incoming traffic.

console> sys appliance_access show
Appliance access enabled.

To disable this, you can run 

console> sys appliance_access disable

Regards,

Hi,

Some misunderstanding by me.

After running

console>sys appliance_access disable

closes the open Port.

But, WHY is there no warning in the GUI? This should be. This is a very dangerous setting which underruns some rules.

Hello,

When you run the command via the console to enable it, it warns you about what is going to happen:

"This will override the configured Appliance Access and allow access to all the services. All internet traffic will be dropped."

The documentation states, "Allows you to override or bypass the configured device access settings and allow access to all the Sophos Firewall services."

This setting isn’t meant to be left turned on and only used in "emergency" situations when you have let yourself out of the firewall.

But I will pass your feedback to PM about having a banner or alert when this setting has been enabled.

Regards,

@The documentation states, "Allows you to override or bypass the configured device access settings and allow access to all the Sophos Firewall services.

Yes, you are right.

But my opening question was:

Why is Telnet on Port 23 on WAN open?

Which - I hope documented - Service on XG(s) is running on Telnet?

Guenter.

@The documentation states, "Allows you to override or bypass the configured device access settings and allow access to all the Sophos Firewall services.

Yes, you are right.

But my opening question was:

Why is Telnet on Port 23 on WAN open?

Which - I hope documented - Service on XG(s) is running on Telnet?

Guenter.

Essentially this is a relic from back in the day.

SFOSv17.5 and below supported Telnet for administration. 

This was removed to be configurable via Device Access. See: https://youtu.be/zkD1kZFssCg?t=36

So by using the Appliance Access Switch, it will also open this old Port and 4444/22 etc.

So essentially, you will have the same problem for Port23 like 22. This option should only be used in Emergency Situation and is actually outdated in case of Central Management, as Central Management always gives you access to the Firewall. So the use case of this switch (device access) is more likely a relic for absolute edge cases. 

Lets discuss, why you enabled the switch in the first place? 

Hi Toni,

thank for your answer.

@sys appliance_access enable: Yes i now. This will insert a any-any-any iptables rule at first place.

XGS2100_RL01_SFOS 19.0.2 MR-2-Build472# iptables -L -n -v --line-numbers
Chain INPUT (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination optimization
1 105K 5441K ALLOW_ALL all -- * * 0.0.0.0/0 0.0.0.0/0 skip_ip_match <<<<
2 181K 9832K HA_TRAFFIC all -- * * 0.0.0.0/0 0.0.0.0/0 skip_ip_match
3 25227 1735K LOGIN_SECURITY all -- * * 0.0.0.0/0 0.0.0.0/0 skip_ip_match
4 25132 1729K ADMIN_SERVICES_ALLOW all -- * * 0.0.0.0/0 0.0.0.0/0 skip_ip_match RULEID match --fwruleid 0
:
:

Chain ALLOW_ALL (1 references)
num pkts bytes target prot opt in out source destination optimization
1 105K 5454K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 skip_ip_match <<<<

But this is not the problem and the initial reason for my posting.

The reason is the - non documented - open telnet port.

In the GUI/Deviceaccess there is also no service which is related to telnet.

On the other hand, if one guy has forgotten that "sys appliance_access enable" is set, currently there is no hint about this dangerous setting.

Up to this time, we as customer, have no efficient way to check such settings. A "show running-config" would be fine, as many times requested by us customers.

Why do we want this? It simple, we do not service only one or two firewall in a static well documented environment. If we take over a system (customer), we have to check all this settings command by command. This is unefficient. And not each show command starts with show.

In my case, the nearest Sophos-Firewall is more then 300km far away, in another Country.
So in the most cases I have to setup the Firewallclusters remote.

This customer have already a working firewall environment. For some reasons in the setupprocess, the XG had two default gateways.
One on LAN, and one via DHCP on the WAN site (with an internal IP).

If you try access to the XG-GUI via VPN which terminates on the existing system you will find some performance issues since V19.0. Also you'll find, that the Loginpage is not loaded correct.
The Command - sys appliance_access enable - makes the performance in this situation better.

Guenter

Hi Toni,

thank for your answer.

@sys appliance_access enable: Yes i now. This will insert a any-any-any iptables rule at first place.

XGS2100_RL01_SFOS 19.0.2 MR-2-Build472# iptables -L -n -v --line-numbers
Chain INPUT (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination optimization
1 105K 5441K ALLOW_ALL all -- * * 0.0.0.0/0 0.0.0.0/0 skip_ip_match <<<<
2 181K 9832K HA_TRAFFIC all -- * * 0.0.0.0/0 0.0.0.0/0 skip_ip_match
3 25227 1735K LOGIN_SECURITY all -- * * 0.0.0.0/0 0.0.0.0/0 skip_ip_match
4 25132 1729K ADMIN_SERVICES_ALLOW all -- * * 0.0.0.0/0 0.0.0.0/0 skip_ip_match RULEID match --fwruleid 0
:
:

Chain ALLOW_ALL (1 references)
num pkts bytes target prot opt in out source destination optimization
1 105K 5454K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 skip_ip_match <<<<

But this is not the problem and the initial reason for my posting.

The reason is the - non documented - open telnet port.

In the GUI/Deviceaccess there is also no service which is related to telnet.

On the other hand, if one guy has forgotten that "sys appliance_access enable" is set, currently there is no hint about this dangerous setting.

Up to this time, we as customer, have no efficient way to check such settings. A "show running-config" would be fine, as many times requested by us customers.

Why do we want this? It simple, we do not service only one or two firewall in a static well documented environment. If we take over a system (customer), we have to check all this settings command by command. This is unefficient. And not each show command starts with show.

In my case, the nearest Sophos-Firewall is more then 300km far away, in another Country.
So in the most cases I have to setup the Firewallclusters remote.

This customer have already a working firewall environment. For some reasons in the setupprocess, the XG had two default gateways.
One on LAN, and one via DHCP on the WAN site (with an internal IP).

If you try access to the XG-GUI via VPN which terminates on the existing system you will find some performance issues since V19.0. Also you'll find, that the Loginpage is not loaded correct.
The Command - sys appliance_access enable - makes the performance in this situation better.

Guenter

Hi Toni,

thank for your answer.

@sys appliance_access enable: Yes i now. This will insert a any-any-any iptables rule at first place.

XGS2100_RL01_SFOS 19.0.2 MR-2-Build472# iptables -L -n -v --line-numbers
Chain INPUT (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination optimization
1 105K 5441K ALLOW_ALL all -- * * 0.0.0.0/0 0.0.0.0/0 skip_ip_match <<<<
2 181K 9832K HA_TRAFFIC all -- * * 0.0.0.0/0 0.0.0.0/0 skip_ip_match
3 25227 1735K LOGIN_SECURITY all -- * * 0.0.0.0/0 0.0.0.0/0 skip_ip_match
4 25132 1729K ADMIN_SERVICES_ALLOW all -- * * 0.0.0.0/0 0.0.0.0/0 skip_ip_match RULEID match --fwruleid 0
:
:

Chain ALLOW_ALL (1 references)
num pkts bytes target prot opt in out source destination optimization
1 105K 5454K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 skip_ip_match <<<<

But this is not the problem and the initial reason for my posting.

The reason is the - non documented - open telnet port.

 In the GUI/Deviceaccess there is also no service which is related to telnet.

On the other hand, if one guy has forgotten that "sys appliance_access enable" is set, currently there is no hint about this dangerous setting.

Up to this time, we as customer, have no efficient way to check such settings. A "show running-config" would be fine, as many times requested by us customers.

Why do we want this? It simple, we do not service only one or two firewall in a static well documented environment. If we take over a system (customer), we have to check all this settings command by command. This is unefficient. And not each show command starts with show.

In my case, the nearest Sophos-Firewall is more then 300km far away, in another Country. So in the most cases I have to setup the Firewallclusters remote.

This customer have already a working firewall environment. For some reasons in the setupprocess, the XG had two default gateways.  One on LAN, and one via DHCP on the WAN site (with an internal IP).

If you try access to the XG-GUI via VPN which terminates on the existing system you will find some performance issues since V19.0. Also you'll find, that the Loginpage is not loaded correct. The Command - sys appliance_access enable - makes the performance in this situation better.

 Guenter

Hi,

why don't you setup a CM account and you can then add your supported firewall and manage them remotely without direct connections.Ian

Not every customer accept connects a firewall into a cloud system. Some written policies forbid such things.

I still would suggest you use CM of those customers that do allow remote access. CM is way more secure than leaving the XG external interface open to attack by opening ports to allow remote access.

I would hope that the customers that don't allow access fro cloud based devices do not have the XG support ports open but use a VPN to an internal server which can access the XG internal interface?

Ian

Hello,

Thank you for your answer.

There is no point in discussing basic decisions of the customer here. That is not the topic here.
The customer specifies the environment and how to deal with it. We all have to abide by that. It does not matter what is "subjectively" better or more elegant.

The customer has strict guidelines that he has to follow and that we have to follow as well.

One requirement is to have all running IP services documented.
This is for prevention and assessment of possible IT security risks.

And 7 days ago it was just discovered that the XG firewall has a telnet service running that is not documented anywhere. Allegedly a legacy issue.

For the documentation of the same it doesn't matter at all whether this service is "normally" sealed off. The only thing that is relevant here is whether such a service exists or not.

The knowledge about this would have required a different procedure for the setup.

As you can see, there are also very restrictive customers and environments.

By the way: The customer is not very pleased.

Guenter

I would assume you have or will be performing an audit on the XG to determine when the change was made? Maybe e en why?
ian

First of all, i would agree in adjusting product and documentation to explain this outcome.

But nevertheless this approach, so actively setup a Emergency option on the CLI and "forget to turn it off(?)" seems to be a security breach itself. 

So the questions should be - Who enabled this setting and why was it enabled in the first place. 

We are going to document this service on docs soon and might pickup changes for the product later.