This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

telnet to 443 of particular IP passing no matter what - I don't want that

Hello Sophos friends,

I have trivial problem but I can't figure why is that happening. On our UTM SG330 box, I want to block all the possible communication to particular IP (in the internet)

Let's say we have bunch of users (in internal network) potentially communicating with that IP. The users are using the UTM as proxy. I have added the IP address to unwanted websites and I have set up that this IP address is malicious from proxy's point of view (category - Illegal software, characteristics - malicious web).

I have also created a firewall rule dropping any protocol going to that destination IP adderss from all the IPv4 and IPv6 addresses.

How come I can still do -> C:\telnet.exe a.b.c.d 443 and it goes through? a.b.c.d is the destination address I don't want to communicate with under any circumnstances.

Many thanks in advance.

ZS



This thread was automatically locked due to age.
Parents
  • You have transparent proxy? Then you should place the bad destination in Filtering Options/Misc/Skip Transparent Mode Destination

     

  • Hello Papa_,

    You are absolutely right. That was that. Fabulous.

    Communication closed and forbidden. Although I don't understand much why that makes such a difference. I assumed the transparent proxy won't allow the connection anyway since the IP address has the worst reputation possible.

    One possible explanation: Proxies are only for HTTP(s) traffic and telnet traffic (from L7 point of view) going over 443 did not matter anyway. Am I right or wrong?

    Thank you in advance for your feedback.

  • The web proxies evaluate URLs, so an FQDN is a different reputation lookup than an IP address.   The Sophos database has reputations assignments for both FQDNs and IP addresses, but they are conceptually independent.   

    You probably created an exception only for the FQDN.   Telnet knows nothing about http(s) protocols, so it just connected to an IP address without supplying the FQDN in the connection string as a browser would.   Transparent proxy would have intercepted the packet, but would not have applied a category override that was only assigned to the FQDN.

    This is not a design flaw.   One server on one IP address can host multiple websites from multiple organizations, so each such website could have different reputations.

    If you use HTTPS inspection, telnet to the site would have failed for two reasons.   First, UTM would have noticed that Telnet was not sending a proper client hello packet, so it would not have sent a server hello.  If you got past that hurdle, UTM would have blocked because of a certificate error -- the IP address in your connection request would not match the FQDN in the certificate offered by the server.   In transparent mode, certificate validity depends on the browser and the user, so those protections are weaker.

     

Reply
  • The web proxies evaluate URLs, so an FQDN is a different reputation lookup than an IP address.   The Sophos database has reputations assignments for both FQDNs and IP addresses, but they are conceptually independent.   

    You probably created an exception only for the FQDN.   Telnet knows nothing about http(s) protocols, so it just connected to an IP address without supplying the FQDN in the connection string as a browser would.   Transparent proxy would have intercepted the packet, but would not have applied a category override that was only assigned to the FQDN.

    This is not a design flaw.   One server on one IP address can host multiple websites from multiple organizations, so each such website could have different reputations.

    If you use HTTPS inspection, telnet to the site would have failed for two reasons.   First, UTM would have noticed that Telnet was not sending a proper client hello packet, so it would not have sent a server hello.  If you got past that hurdle, UTM would have blocked because of a certificate error -- the IP address in your connection request would not match the FQDN in the certificate offered by the server.   In transparent mode, certificate validity depends on the browser and the user, so those protections are weaker.

     

Children