![]() With this configuration (removed other firewall rules, which do not match the intended traffic) Teamviewer seems to be able to create a direct connection over UDP between two hosts, each connected to one context. Set connection random-sequence-number disable ![]() Match access-list timeout_sistore_videoueberwachung No threat-detection statistics tcp-interceptĬlass-map timeout_sistore_videoueberwachung Timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute Ip address 192.168.0.4 255.255.255.0 standby 192.168.0.5Īccess-list INSIDE extended permit ip any anyĪccess-group OUTSIDE in interface outside The very much simplified configuration of those two transparent context interfaces looks like this: I thought that should be blocked? I think I'm lacking some basic UDP firewall function knowledge, could anybody please enlighten my why those two clients were able to directly communicate with each other? What did buffle me now though, client1 was able to directly communicate with client2, although neither firewall ruleset allows an incoming UDP connection! They (ab)used the seemingly two other connections, of which each client opened one, to communicate that way. So far I still understand what's going on. We tested teamviewer today, client1 was the admin-host and client2 was the destination-host.Ī wireshark showed now, as did the firewall log, that both clients opened a UDP connection to each other with the same IP/Port combination, just vice versa. There is no permitted firewall rule that allows incoming UDP traffic on Port >50000 to any IP in the subnet, which my CSM also confirms with a query.Ĭlient 1 is 192.168.0.10 and client 2 is 192.168.1.20. Outgoing traffic is allowed with protocol IP.Īccess-list OUTSIDE extended deny ip any any log The firewall rules are in the IN direction on the OUTSIDE interface. Also seems very unreliable as someone can just try older versions until they hit one that works. What is the best practice solution to this? I have searched the forums and there seems to be no definite solution.I'm running an ASA in transparent mode with several contexts.įor simplicity lets assume I have two context, one for the 192.168.0.0/24 and one for the 192.168.1.0/24. Even then the application still works. Even making the DNS resolve to nothing in the host file does nothing, it still works. So then I thought about blocking the executable name, but if someone renames their executable won't this just circumvent it easily? Looking deeper I got into file fingerprints for Application and Device Control, and that seems to be a lackluster solution as once it gets any updates at all, the hash will obviously change and I'll have to manage it again. I decided to go hardcore and block all ports for. Obviously I can't block those ports as other applications use them. ![]() ![]() I have tried blocking the TCP port 5389 (listed on their site) and it seems to work at first, but then it seems to fail over to either 80 or 443 and starts working again. Has anyone here successfully blocked TeamViewer? ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |