Teamviewer, powershell and tsiska
Then they gave me a task to cover access to the outside network via Teamviewer software. The background of the question is a bit sad - historically, in this way the programmer-contractor remotely connected to the server with 1C databases. Yes, everything is wrong and difficult, and attempts to change something both technically and organizationally, stumbled upon the counteraction of accounting. But it's not about that, but about blocking this Teamviewer itself.
First of all I, of course, got into the search. I found a couple of dozens of topics with a discussion of this issue, looked at how people block this software with varying success. The problem is that there are too many servers to which it connects, it is easy to miss something, and in the comments to the lists of found ranges people often complained that this solution does not work for them.
')
Well, we put two computers side by side, we install Teamviewer programmers on them - to see it live right away, it turns out or not.
Blocking port tcp 5938, judging by the comments, has long ceased to work, since the release of the previous version. Just in case, I made, of course, the rule to block incoming and outgoing ports on this port, as well as on the tcp 9997 found somewhere. There was no instant effect, but the counter on the tsiska recorded responses. Well, let it be.
Then I began to wool all the ranges found by my comrades. Somewhere on the fifth read topic and the fourth added ten ranges a reliable lock was fixed, after several attempts the software reports about the impossibility of connecting. Hooray! The primary goal is achieved, but I want more. Eighty, ninety, or even ninety-five percent is insufficient reliability.
I decided to tackle this problem deeper. For a start, I wanted to understand how you can create a more complete list of Teamviewer hosts. In principle, the comrades on the forums expressed the idea that you need to block servers of the type serverN.teamviewer.com, where N is a number. But, firstly, I have not figured out how to make _tritable_ blocking by host name using tsisk, and secondly, blocking “bare” IP in any case will be very useful as an additional protection.
There was a simple idea - to loop through all the names and to resolve them to IP. I'm a big fan of the command line, so I first looked for approaches to solving a problem using a batch file. I figured it out - yes, in principle, you can parse the output of nslookup, but somehow it will be clumsy. And what if through Powershell?
Googling, quickly found a suitable .Net class. After a bit of experimentation, I realized that this scheme works great - I especially liked that if the name resolves to several IPs, they are all neatly placed in an array. Each aypishnik is added to an array of results, which is then sorted and cleaned of duplicates with a single Sort command, and dropped into a text file. At the end of a small stroke for convenience - a text file opens in Notepad, so as not to search for it on the disk. Yes, Powershell is a very convenient and powerful tool.
Script text (Powershell v2):
Some moments on this script:
- The string $ servers = @ () initiates an array; without this, Powershell is confused in types.
- [System.Net.Dns] :: GetHostAddresses () is a .NET class that receives IP addresses by name.
- IPAddressToString - a method that converts the result to a regular string.
As an intermediate result: Powershell is terribly convenient for such specific admin tasks.
(How the resulting subnets, about two hundred in number, fell into a tsiska - a subject for a separate topic, and even so it turns out many letters. I plan to refine this process)
Results - six and a half hundreds of received addresses, reliable solution of the problem and +5 to the “administration” skill :-)
At first, there may be a desire to block these ranges with a large margin. However, I quickly stumbled upon the fact that one of the moskva.fm servers, 85.17.138.68, got into the thus closed 85.17. *. * Range - it is much safer to make the rules of a more particular type, per subnet / 24 (85.17.136. * and 85.17.87. *). Alternatively, you can block individual IPs in the list, but this is less reliable from the point of view of the original task of blocking Teamviewer - I think the emergence of its new servers “side by side” with the existing ones is much more likely than in new ranges.
First of all I, of course, got into the search. I found a couple of dozens of topics with a discussion of this issue, looked at how people block this software with varying success. The problem is that there are too many servers to which it connects, it is easy to miss something, and in the comments to the lists of found ranges people often complained that this solution does not work for them.
')
Well, we put two computers side by side, we install Teamviewer programmers on them - to see it live right away, it turns out or not.
Blocking port tcp 5938, judging by the comments, has long ceased to work, since the release of the previous version. Just in case, I made, of course, the rule to block incoming and outgoing ports on this port, as well as on the tcp 9997 found somewhere. There was no instant effect, but the counter on the tsiska recorded responses. Well, let it be.
Then I began to wool all the ranges found by my comrades. Somewhere on the fifth read topic and the fourth added ten ranges a reliable lock was fixed, after several attempts the software reports about the impossibility of connecting. Hooray! The primary goal is achieved, but I want more. Eighty, ninety, or even ninety-five percent is insufficient reliability.
I decided to tackle this problem deeper. For a start, I wanted to understand how you can create a more complete list of Teamviewer hosts. In principle, the comrades on the forums expressed the idea that you need to block servers of the type serverN.teamviewer.com, where N is a number. But, firstly, I have not figured out how to make _tritable_ blocking by host name using tsisk, and secondly, blocking “bare” IP in any case will be very useful as an additional protection.
There was a simple idea - to loop through all the names and to resolve them to IP. I'm a big fan of the command line, so I first looked for approaches to solving a problem using a batch file. I figured it out - yes, in principle, you can parse the output of nslookup, but somehow it will be clumsy. And what if through Powershell?
Googling, quickly found a suitable .Net class. After a bit of experimentation, I realized that this scheme works great - I especially liked that if the name resolves to several IPs, they are all neatly placed in an array. Each aypishnik is added to an array of results, which is then sorted and cleaned of duplicates with a single Sort command, and dropped into a text file. At the end of a small stroke for convenience - a text file opens in Notepad, so as not to search for it on the disk. Yes, Powershell is a very convenient and powerful tool.
Script text (Powershell v2):
### -- Teamviewer. , , . ## $result_ips = "C:\!scripts\teamviewer\result_tv_IPs.txt" $result_addresses = "C:\!scripts\teamviewer\result_tv_addresses.txt" del $result_ips del $result_addresses $servers=@() ## serverN.teamviewer.com - 101-11500, 646 [2011-11] for ($i=1; $i -le 11500; $i++) { echo $i; $cur_server="server" + $i + ".teamviewer.com" echo $cur_server [System.Net.Dns]::GetHostAddresses($cur_server)|% { if ($? -eq $true) {echo $cur_server |out-file -append $result_addresses}; $servers+=$_.IPAddressToString } } # masterN.teamviewer.com - 1-16 [2011-11] for ($i=0; $i -le 20; $i++) { echo $i; $cur_server="master" + $i + ".teamviewer.com" echo $cur_server [System.Net.Dns]::GetHostAddresses($cur_server)|% { if ($? -eq $true) {echo $cur_server |out-file -append $result_addresses}; $servers+=$_.IPAddressToString } } # pingN.dyngate.com - 2-3 for ($i=0; $i -le 10; $i++) { echo $i; $cur_server="ping" + $i + ".dyngate.com" echo $cur_server [System.Net.Dns]::GetHostAddresses($cur_server)|% { if ($? -eq $true) {echo $cur_server |out-file -append $result_addresses}; $servers+=$_.IPAddressToString } } # $servers | sort-object -unique | out-file $result_ips notepad.exe $result_ips start-sleep -milliseconds 800 # , notepad.exe $result_addresses Some moments on this script:
- The string $ servers = @ () initiates an array; without this, Powershell is confused in types.
- [System.Net.Dns] :: GetHostAddresses () is a .NET class that receives IP addresses by name.
- IPAddressToString - a method that converts the result to a regular string.
As an intermediate result: Powershell is terribly convenient for such specific admin tasks.
(How the resulting subnets, about two hundred in number, fell into a tsiska - a subject for a separate topic, and even so it turns out many letters. I plan to refine this process)
Results - six and a half hundreds of received addresses, reliable solution of the problem and +5 to the “administration” skill :-)
At first, there may be a desire to block these ranges with a large margin. However, I quickly stumbled upon the fact that one of the moskva.fm servers, 85.17.138.68, got into the thus closed 85.17. *. * Range - it is much safer to make the rules of a more particular type, per subnet / 24 (85.17.136. * and 85.17.87. *). Alternatively, you can block individual IPs in the list, but this is less reliable from the point of view of the original task of blocking Teamviewer - I think the emergence of its new servers “side by side” with the existing ones is much more likely than in new ranges.
Source: https://habr.com/ru/post/133740/
All Articles