Forum


Notice to all users

We are migrating towards a new forum system located at community.teamspeak.com, as such this forum will become read-only on January 29, 2020

Results 1 to 13 of 13
  1. #1
    Join Date
    January 2010
    Location
    El Prat de Llobregat (Barcelona, Spain)
    Posts
    2,698

    Some kind of "query_ip_blacklist" in the virtual server

    In rented servers by slots there's a problem with the query and the TS3-Viewer services: there's no way for blocking the unwanted services.

    The TS3 hoster says he can't include the ip in the "query_ip_blacklist" because other "owners" could be interested in that service. If I block the permissions in my 'virtual server' then all the viewer services are blocked so, case of rented server by slots, this is an On-Off matter: if you want use a viewer service any other viewer will get and show the virtual server.

    Lately this kind of services are taking and showing information without any option to delete the server from its list, so once your server is IN the list you can't get it out.

    The suggestion is having some kind of "query_ip_blacklist" in the virtual server for limiting the access of unwanted query services.

  2. #2
    Join Date
    August 2013
    Posts
    56
    If you didn't want the IP for those services to connect to your virtual server couldn't you just add those IPs to your ban list?

    Also if you don't have the permissions set that those services need then they wont be able to query your server and those permissons should only affect your virtual server.

  3. #3
    Join Date
    June 2011
    Location
    Germany
    Posts
    4,368
    Query clients cannot be banned (or kicked from the server).

  4. #4
    Join Date
    September 2012
    Posts
    6,079
    We're not sure we'd want that, but we'll discuss it further.
    In the event this does get added however, it will still be limited to the hoster, ie. the hoster will need to add entries to the server specific blacklist.
    When sending PMs please make sure to include a reference link to the thread in question in the body of your message.

  5. #5
    Join Date
    January 2010
    Location
    El Prat de Llobregat (Barcelona, Spain)
    Posts
    2,698
    Quote Originally Posted by Chris View Post
    In the event this does get added however, it will still be limited to the hoster, ie. the hoster will need to add entries to the server specific blacklist.
    No problem if I have to ask my hoster for including an IP in "the list".

    And maybe the hoster could offer a tab in its control panel for modifying the file.

  6. #6
    Join Date
    April 2011
    Location
    Germany
    Posts
    1,266
    Quote Originally Posted by PotaBlava View Post
    No problem if I have to ask my hoster for including an IP in "the list".

    And maybe the hoster could offer a tab in its control panel for modifying the file.
    All this will work as long as there aren't any customer wishes in contradiction to the wishes of another customer.

    For example... customer A wants a whole 8 bit network (e.g. 2.0.0.0/8) blocked and customer B is from exactly that network what then? If you make customer A satisfied you'll probably enrage customer B. Having a blacklist for the whole instance works as long as all virtual servers share the same black list wishes.

    I can see the point in the request but I don't like it personally. I think that there should only be one black list per instance and not one for every virtual server.

  7. #7
    Join Date
    June 2008
    Posts
    18,513
    Barungar, are you sure you understand the feature reqest?
    This request is exactly a soloutuion to avoid what you tell us.

    We wan't to avoid, that costumer A bans the IP, that customer B want's to use on his own server.
    Such a ban would be per virtual server and their can't be a second customer, who comes in that range.
    When sending me private messages: Please make sure to include reference link to your forum thread or post.

    TeamSpeak FAQ || What should i report, when i open a client thread?

  8. #8
    Join Date
    April 2011
    Location
    Germany
    Posts
    1,266
    Quote Originally Posted by dante696 View Post
    Barungar, are you sure you understand the feature reqest?
    Yes, and personally I still don't like it.

    Quote Originally Posted by dante696 View Post
    This request is exactly a soloutuion to avoid what you tell us.
    Right, the example I delivered reflects the actual situation you have right now with only an instance based black list, where situation can occur that you have black listing requests which are in contradiction. It is also correct that a black list per virtual server would be a solution to avoid such situations.

    Quote Originally Posted by dante696 View Post
    We wan't to avoid, that costumer A bans the IP, that customer B want's to use on his own server.
    Such a ban would be per virtual server and their can't be a second customer, who comes in that range.
    Still to my mind this isn't a real black list feature. There should only be one black list per instance and not several onces. I would suggest a kind of a query client ban. That would be database stored (like the voice client bans) and not as a black list file in the file system.

    In fact you might want to consider to simply let the "use" command check against the already existing ban list of the virtual server. So if there is a ban for an IP or even for a client UID you disallow "using" the virtual server.

  9. #9
    Join Date
    January 2010
    Location
    El Prat de Llobregat (Barcelona, Spain)
    Posts
    2,698
    Quote Originally Posted by Barungar View Post
    I would suggest a kind of a query client ban. That would be database stored (like the voice client bans) and not as a black list file in the file system.
    An alternative suggestion: The virtual server has a new permission, in the 'Misc' tab: "Allow unknown user queries"

    If you activate it, then all follows as it is now.
    If you deactivate it, then the user query must use the login (Tools --> ServerQuery Login). In this case, the viewer services should ask for "Username" and "Password" instead of using the current unknown.

    So this 'Unknown/unwanted from' connection will not exist even if it was done from a dynamic IP... (something, for example, that the 'black list' can't control).
    Code:
    13/05/2014 19:45:05	VirtualServer	Info	query client connected 'Unknown from 9y.1y.3y.3y:52010'(id:111073)	
    13/05/2014 19:45:12	VirtualServerBase	Info	query client disconnected 'Unwanted Viewer'(id:111073) reason 'reasonmsg=connection lost'	
    
    13/05/2014 19:46:10	VirtualServer	Info	query client connected 'PotaBlava' from 8x.2x.1x.9x:14006'(id:1733)	
    13/05/2014 19:47:02	VirtualServerBase	Info	query client disconnected 'Pota (Yatqa)'(id:1733) reason 'reasonmsg=disconnecting'

  10. #10
    Join Date
    June 2008
    Posts
    18,513
    This is no good idea, every ServerQuery can rename himself to "Uknown".
    We leave this feature request as explained.
    When sending me private messages: Please make sure to include reference link to your forum thread or post.

    TeamSpeak FAQ || What should i report, when i open a client thread?

  11. #11
    Join Date
    December 2009
    Location
    Germany
    Posts
    2,360
    Quote Originally Posted by dante696 View Post
    This is no good idea, every ServerQuery can rename himself to "Uknown".
    We leave this feature request as explained.
    I think a virtual server permission to login first would solve this issue. So guest query clients can't switch to the specified virtual server, if this permission is set. So the query client have to login first before doing use X.

  12. #12
    Join Date
    January 2010
    Location
    El Prat de Llobregat (Barcelona, Spain)
    Posts
    2,698
    Quote Originally Posted by dante696 View Post
    This is no good idea, every ServerQuery can rename himself to "Uknown".
    Well, for me "Unknown" it's a query user that connects to the query port 'as is'. A "well-known" one is a query user that connects using the 'Username' and 'Password' obtained from Tools --> ServerQuery Login, that means that the voice user has the b_client_create_modify_serverquery_login activated.

    The 'well-known' query is already available (and it's a kind of 'white-list'): Yatqa uses it as optional. The Viewer services don't use it because there isn't any limitation that force them to use it.


    Scenario 1: A specific blacklist for virtual server that the hoster fills.
    Devs have to program this option.
    Everytime a Viewer service decides to connect to "my" virtual server I have 1) to 'detect' the intrusion, 2) fill a support ticket in my hoster and 3) he has to proceed with the blacklist.
    A viewer working with a dynamic IP will be a headache.

    Scenario 2: A check box in 'Edit virtual server' --> 'Misc' tab to force the 'well-known' queries or to allow the 'unknown' ones (a check similar to the "Enable reporting to server list").
    Dev has to program this option
    Viewer Services will have to include the 'Username' and 'Password' in the form as optional fields.
    I decide what viewer service to use, I prepare the query login and I fill the form in the viewer service. If the viewer service doesn't allow to delete the suscription then I revoke the query login and end of the history.

    I think number 2 is better than number 1 because the 'extra' work goes to the viewer services and the virtual server owners but no to the hosters.

  13. #13
    Join Date
    January 2010
    Location
    Catalunya
    Posts
    2,350
    I think this post #12 reflects a brilliant idea, and it would be nice to have it considered.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. [Rejected] [Suggestion] Maximum virtual server disk size for file"hosting"
    By orDian in forum Suggestions and Feedback
    Replies: 15
    Last Post: February 24th, 2016, 07:16 AM
  2. [Rejected] TSDNS like a option in "Manage Virtual Server"
    By Nicocaps in forum Suggestions and Feedback
    Replies: 1
    Last Post: April 19th, 2012, 12:45 PM
  3. Replies: 4
    Last Post: October 24th, 2010, 07:00 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •