Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 6 subscribers
  • Views 10195 views
  • Users 0 members are here
Options
Suggested
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

zszszs

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.
  • 0

    Blackhole definition?  Here's an example.  I noticed many attempts on daily bases from 216.218.206.102 performing various port scans.  This rule took care of it.  It works in both directions.  No traffic in, and cannot be reached from the local lan. 

    Chances are firewall block is not working because web filtering is letting it through.  Web filtering rules are processed before firewall rules.  For a particular packet, rules are only processed once.  If it's done in web filtering then firewall block has no effect.

  • 0

    Hello Jay Jay,

    Thank you for the feedback. Blackhole route is a brilliant idea. Haven't thought of that.

    Anyway, It seems traffic was filtered (based on sophos proxy logs) even before I asked the question above on this forum. I have seen records like "that user tried to access this a.b.c.d IP. Forbidden -> classification - malicious page, category - illegal software)". What made me think that connection is still working was the fact, that telnet didn't write out "connection attempt rejected, dropped" but it behaved like it went through.

    Little did I know I was communicating with proxy (i.e. transparent proxy accepted request on 443 going to that address), not the target IP itself.

    Case closed, we can go home now.

    Take care.

     

  • 0 in reply to zszszs

    Sooo.... status update.

     

    What I wrote in my previous post is not entirely true. The communication is passing through. Why do I think that? Observe the TCPDUMP output from the SG330 below. Criteria for TCPDUMP was to print only the packets that have forbidden IP as src or dst. Actual hosts were replaced with src_internal_host and forbidden_dst_ip_addr placeholders. As you can see below, forbidden dst IP has sent me R flag. The countermeasures in place are: blackhole and classification of dst IP as malicious webpage with illegal software (latter is done in proxy settings).

     

    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
    09:33:03.738946 IP src_internal_host.29651 > forbidden_dst_ip_addr.https: Flags [S], seq 2399154794, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
    09:33:03.738986 IP forbidden_dst_ip_addr.https > src_internal_host.29651: Flags [S.], seq 2931350169, ack 2399154795, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
    09:33:03.741317 IP src_internal_host.29651 > forbidden_dst_ip_addr.https: Flags [.], ack 1, win 2053, length 0
    09:33:15.983612 IP src_internal_host.29651 > forbidden_dst_ip_addr.https: Flags [P.], seq 1:3, ack 1, win 2053, length 2
    09:33:15.983649 IP forbidden_dst_ip_addr.https > src_internal_host.29651: Flags [.], ack 3, win 229, length 0
    09:33:20.942955 IP src_internal_host.29651 > forbidden_dst_ip_addr.https: Flags [P.], seq 3:5, ack 1, win 2053, length 2
    09:33:20.943005 IP forbidden_dst_ip_addr.https > src_internal_host.29651: Flags [.], ack 5, win 229, length 0
    09:33:22.141324 IP src_internal_host.29651 > forbidden_dst_ip_addr.https: Flags [P.], seq 5:7, ack 1, win 2053, length 2
    09:33:22.141396 IP forbidden_dst_ip_addr.https > src_internal_host.29651: Flags [.], ack 7, win 229, length 0
    09:33:22.638822 IP src_internal_host.29651 > forbidden_dst_ip_addr.https: Flags [P.], seq 7:9, ack 1, win 2053, length 2
    09:33:22.638858 IP forbidden_dst_ip_addr.https > src_internal_host.29651: Flags [.], ack 9, win 229, length 0
    09:33:23.029875 IP src_internal_host.29651 > forbidden_dst_ip_addr.https: Flags [P.], seq 9:11, ack 1, win 2053, length 2
    09:33:23.029924 IP forbidden_dst_ip_addr.https > src_internal_host.29651: Flags [.], ack 11, win 229, length 0
    09:33:23.581342 IP src_internal_host.29651 > forbidden_dst_ip_addr.https: Flags [P.], seq 11:13, ack 1, win 2053, length 2
    09:33:23.581361 IP forbidden_dst_ip_addr.https > src_internal_host.29651: Flags [.], ack 13, win 229, length 0
    09:33:23.581498 IP forbidden_dst_ip_addr.https > src_internal_host.29651: Flags [R.], seq 1, ack 13, win 229, length 0

    I am clueless.

    ZS

  • 0

    You have transparent proxy? Then you should place the bad destination in Filtering Options/Misc/Skip Transparent Mode Destination

     

  • 0 in reply to papa_

    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.

  • +1 in reply to zszszs

    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.

     

  • 0 in reply to DouglasFoster

    Hello,

    thank you DouglasFoster for the clarification. All understood now, it behaves exactly as I wanted it to behave.

    Thank you all for participation, ticket can be closed now.

    Take care.

    ZS

Unfiltered HTML