Forum

Results 1 to 11 of 11
  1. #1
    Join Date
    November 2014
    Location
    Tulsa
    Posts
    16

    Post [Tutorial] ServerQuery, The Safe Way

    Hey folks, I'm happy to say I just joined the forum and this would be my first post! *insert first post gag here*

    Something I've come across, and anyone correct me if I'm wrong, is that there doesn't seem to be any kind of guide on here about securing one's ServerQuery. While I agree ServerQuery is AWESOME for when you don't want to connect via the client (for those sneaky ninja-kicks or ninja-bans, I've had to do a few of those :) ), I don't much like that you can connect to it via Telnet. So, here's a solution I've come up with that enables a nice and safe usage of ServerQuery away from prying eyes.

    (Again, anyone, even forum mods, let me know if this should be somewhere else or I've accidentally bashed the TeamSpeak software or cramped on the TOS for TeamSpeak, I love this software to death, and if it's already been addressed, I hate beating a dead horse. :) )

    FIRST OFF: Why am I addressing this? Why make such a big fuss about Telnet?

    Answer to that
    :Telnet is not safe to use on a multi-daemon server (Notice how I didn't say "secure". I'll explain here.)

    Reason: I'd like to quote Wikipedia, the host of all the knowledge in the world: (toot toot!)

    "Telnet is a client-server protocol, based on a reliable connection-oriented transport. Typically, this protocol is used to establish a connection to Transmission Control Protocol (TCP) port number 23, where a Telnet server application (telnetd) is listening. Telnet, however, predates TCP/IP and was originally run over Network Control Program (NCP) protocols."
    So what the heck does that all mean, right?
    1. Telnet is OLD. It was developed in the '60s (WAY before my time! :) ), and was designed for networks that were connected only to themselves. In fact, it predates the TCP/IP protocol stack that we use today for Internet communication.
    2. Follows up #1: Telnet is for TRUSTED networks, meaning everyone on that network can be trusted. With computers these days, that's hard to say.

    Trusted? What do you mean?

    I mean you're not trying to cause mayhem or actual physical damage to computers or users by breaking into a digital system. And you have authorization to use the network. Like if you're at your highschool in the computer lab, you're a trusted user because you're authorized to use their network. Doesn't mean you're COMPLETELY trusted, just means you're permitted to use the resources on it.

    So what does this have to do with TeamSpeak and ServerQuery?
    Well, a lot. Nowadays, if you're (especially) hosting an Internet-facing server, you have to be a little security-conscious. Sure, you're probably not the target of some giant scheme to take down all gaming-related hardware (*cue gasps from the audience* :) ), but that doesn't mean that someone with a little extra knowledge or skill can cause some grief for you and others just because he or she thinks they were "unfairly" banned.

    Since you can configure TeamSpeak servers via ServerQuery using Telnet, this opens up some (potential!) caveats:

    1. Someone can sniff
    your packets between
    (as in literally look at your communication with) your Telnet client and TeamSpeak server. This is not bueno in any case. I quote Wikipedia:

    "Telnet, by default, does not encrypt any data sent over the connection (including passwords), and so it is often practical to eavesdrop on the communications and use the password later for malicious purposes; anybody who has access to a router, switch, hub or gateway located on the network between the two hosts where Telnet is being used can intercept the packets passing by and obtain login, password and whatever else is typed with a packet analyzer."
    Notice the bit I underlined there? That means someone can watch your communication with your server in plain text.

    This is how plain text I mean (courtesy of the packet sniffer Wireshark):

    Attachment 11645

    The red boxes show where the Telnet daemon (server) on this computer (a virtual one, cause I'd never run this on a real computer! :) ) is "echoing", meaning writing to the client, "Hey! Thanks for connecting! I see you've provided a username, give me a password and we'll see if you're okay to use this service!"

    But see notice something: You can read that. You can read it said "Password: ". So, you know what's next, right?

    Attachment 11646

    For those of you that don't know what you're seeing, that's a user password being transmitted "on the wire". Clearly visible. Meaning someone with a pad and paper(or fancy-shmancy program) can write down your password and use it.

    That's not awesome. Like ever.


    You want someone knowing what you're bank card's PIN is? No? This is about the same deal. You NEVER want anyone to know your password (god forbid, for you Linux and Unix geeks out there, the root password), especially if you're the administrator for a server.



    2. People can watch your communication like I just did with an example server in the first point.

    This point really drives home the first one I made. To quoteth the Wikipedia...eth:

    "Most implementations of Telnet have no authentication that would ensure communication is carried out between the two desired hosts and not intercepted in the middle."

    See, that's what I just did.
    Granted, it was a virtual server in a test environment, but it's completely possible to do on an actual network. I intercepted the communication as it was happening and logged it.

    Think of it like those old cup telephones you used as a kid to talk to someone in the treehouse next to you. You had the cups at both ends and the string between the middle, and you had to change your "super secret passwords" with your friend across the way 'cause your sister learned your password...or something. (It's an example, humor me. :) )

    Now imagine your worst nemesis
    (we had those as kids :) ) comes along and attaches his own cup phone to yours and listens to your password exchange. That's what we just did in the first example, but the server can't say no to an authenticated user because it has no way of knowing you're who you say you are. Sure, you could just tell your nemesis "No" even though their password was right, but computers aren't that smart. They're only as smart as we make them.


    3. Telnet isn't safe. For the computer or your data.

    Now, this is just a general thing, I'm not going out and saying the Teamspeak ServerQuery is insecure. They work hard to give you a prime user experience with the security, and I don't discount them for that. But, anything is possible.

    Again (hopefully finally) from Wikipedia:

    "Several vulnerabilities have been discovered over the years in commonly used Telnet daemons."
    Vulnerabilities to a computer are like an Achillies heel to a human: They suck, and can really wreck things if they're severe enough. AGAIN, not saying the TeamSpeak ServerQuery is vulnerable without having done my research, but nowadays, anything is possible. Someone with a LOT of expertise could find a way to get administrative (root) access to your server and cause real mayhem, from editing a file that keeps your server from booting or connecting to the Internet (which defeats the purpose of the server in the first place :) ), to changing the voltage going through the CPU, causing very real physical damage that could destroy the computer. And silicon isn't necessarily easy to replace nowadays when it's been fried like an egg.

    SECOND: Why all this elaboration? Get to the good part!

    Never hurts to explain why you're writing something.

    NOW, the good part. So I've talked about all how this works, and how Telnet can be super dangerous. So, what do I propose to give yourself that extra layer of security? (if not slight peace of mind, for those of us out there that are a little paranoid? :) )

    Simple. We set up a kind of circular trap system.

    The heck does that mean, right? Well, I'll explain (much shorterly this time! :) ).

    Basically the Reader's Digest version is this: Set up Secure Shell (SSH) on your server, and set up your firewall so that only the server can access it.


    I'll explain how to do this from command line, using a Debian 7 "Wheezy" GNU/Linux server. The concept is pretty much the same on Windows and Mac, so follow along!

    1. Install the following programs on the target server:

    On Debian:
    Code:
    sudo apt-get update && sudo apt-get upgrade
    sudo apt-get install openssh-server telnet-ssl ufw
    On Windows:
    Code:
    http://hivelocity.dl.sourceforge.net/project/sshwindows/OpenSSH%20for%20Windows%20-%20Release/3.8p1-1%2020040709%20Build/setupssh381-20040709.zip
    
    Above link is for OpenSSH for Windows.
    
    Use the built-in Telnet client present on the server.
    
    And set up Windows Firewall to deny Teamspeak's ServerQuery port for incoming and outgoing transmissions.
    


    On Mac:
    Code:
    Apologies, folks! Never used a Mac before (well, for an extended period of time :) ), so I'm not 100% on how to go about this.

    2. Continuing with my Debian installation, we'll assume the TeamSpeak server is already set up and running.

    Now that we've installed OpenSSH and the Uncomplicated FireWall (ufw), we'll configure them.

    Tips for OpenSSH:
    Code:
    -Setting 
    
    PermitRootLogin no
    
    and
    
    StrictModes yes
    
    is always a good idea.
    
    -The setting
    
    PermitBlankPasswords
    
    SHOULD BE SET TO NO. Blank passwords are bad juju. :)
    Tips for ufw:
    Code:
    Not a whole lot to say, 'cept that it's straightforward.
    
    sudo ufw reject 10011/tcp
    
    should be enough to satisfy your needs.
    3. Once that's configured, you should be good to go!

    Log into your server (If you're on Windows, you don't have SSH built in, so I'd recommend either installing the client version of OpenSSH or using KiTTY, it's PuTTY but on steroids! :) ) using a username and password that's authorized to log in as if you were sitting in front of its keyboard.

    Once you're logged in, use:
    Code:
    telnet 127.0.0.1 10011
    And you should be presented with the TeamSpeak ServerQuery login!

    BONUS!:This helps keep out some of the bots because (if you're on a Debian-based Linux distro like I am) you set up ufw to explicitly say no to outside ServerQuery clients! Reject and deny are two different things, deny means quietly toss, reject is an explicit and outright "NO" to whoever sent the request.

    So, in an ironic way, the only computer authorized to access the ServerQuery is the server itself. Not only does this give you a secure way to use ServerQuery, it gives you the added bonus of keeping the cruft out that shouldn't be in there!


    WHEW! My hands are killing me! :)


    I hope this tutorial was useful to some of you folks out there that might be concerned with the security of your server. Let me remind you again: I AM IN NO WAY BASHING OR ACCUSING TEAMSPEAK OF BEING INSECURE OR ANYTHING ELSE. TeamSpeak's development team decided to create an easy way for people to configure the server via command line, and I have no kind of problem with it, it's a design choice, and I have no right to criticize it.

    I'm a very avid supporter of TeamSpeak and fond day to day user, and champion its use for any kind of application, gaming-related or not. As a security-conscious IT professional, I thought some of us might have this same concern, however, and as such have suggested a way to get that extra layer of security in there (Kind of like a child's security blanket. :) ).

    Hope this finds its way into some of those TeamSpeak servers out there! Keep the word worth the thousand keystrokes!

    ~ZaneOhOne
    Last edited by ZaneOhOne; November 24th, 2014 at 11:29 PM. Reason: Some tweaks. :D

  2. #2
    Join Date
    December 2004
    Location
    RF
    Posts
    3,006
    Tip for OP: Don't use ufw. Lots of ways to cripple your system, if you don't know what you are doing.
    Learn iptables, will save you hell of a lot of headache.
    And you forgot an important step: binding query console to 127.0.0.0:30033.

  3. #3
    Join Date
    June 2011
    Location
    Germany
    Posts
    4,350
    Why was my post deleted? I accurately just summed up the whole post in one sentence without leaving anything important out. For people who do not want to read such a long post with only one statement in it, my post was just about perfect.

    Quote Originally Posted by ANR Daemon View Post
    And you forgot an important step: binding query console to 127.0.0.0:30033.
    This will either break file transfer, query or both. Not sure which.

  4. #4
    Join Date
    November 2014
    Location
    Tulsa
    Posts
    16
    Quote Originally Posted by ANR Daemon View Post
    Tip for OP: Don't use ufw. Lots of ways to cripple your system, if you don't know what you are doing.
    Learn iptables, will save you hell of a lot of headache.
    And you forgot an important step: binding query console to 127.0.0.0:30033.

    See, that's two sides of the same coin (Or at least the way I see it ).

    I learned to use iptables (a considerable upgrade after I learned I was still using ipchains! ) on an old openSUsE installation running Linux 2.6 and considered 64-bit support to be "brand-new", and I had come to the conclusion that, yes, while iptables is the superior software and definitely is better to use if you're using a pretty good size server (or even server array), I suggested ufw because it takes about 3 commands to get the firewall up and running.

    Code:
    sudo ufw enable
    sudo ufw default deny incoming
    sudo ufw default allow outgoing
    I'll probably stick an iptables implementation in here for those who prefer iptables over ufw, but either way, thanks for the tip, forgot iptables is still a thing.

  5. #5
    Join Date
    November 2014
    Location
    Tulsa
    Posts
    16
    Quote Originally Posted by numma_cway View Post
    Why was my post deleted? I accurately just summed up the whole post in one sentence without leaving anything important out. For people who do not want to read such a long post with only one statement in it, my post was just about perfect.
    Huh...odd. I never got a message from the forum bot saying you posted in the first place. I apologize good sir!

    This will either break file transfer, query or both. Not sure which.
    30033 is the file transfer, query is 10011. 30033 is a bad idea to block to incoming traffic (unless you're concerned about your users uploading no-no content ), 10011 is the port I suggested blocking and accessing via SSH.

    And I agree, this post is definitely a little wordy, I'll trim it down a little!

  6. #6
    Join Date
    December 2004
    Location
    RF
    Posts
    3,006
    Yes, sorry, I messed the ports. Indeed that may mess both, if you bind one port to another service.

  7. #7
    Join Date
    November 2014
    Location
    Tulsa
    Posts
    16
    Quote Originally Posted by ANR Daemon View Post
    Yes, sorry, I messed the ports. Indeed that may mess both, if you bind one port to another service.
    Well, you're not nessecarily binding it to another port, you're using one service to access another. In this instance, we're prohibiting access to ServerQuery directly, but we can still indirectly use it by SSHing into the target computer and using the target's Telnet client to access ServerQuery via 127.0.0.1. So in a sense we're tunneling services rather than competing for binding.

  8. #8
    Join Date
    December 2004
    Location
    RF
    Posts
    3,006
    Indeed, if you put the correct port (10011) in it, you can access the query service using any address in 127/8 range.

  9. #9
    Join Date
    November 2014
    Location
    Tulsa
    Posts
    16
    Precisely what this tutorial is getting at, once i clean up the wording and whatnot.

  10. #10
    Join Date
    December 2004
    Location
    RF
    Posts
    3,006
    I would add to the trusted article, that it's not only YOU trusted to not cause harm, but, more importantly, other participants in the network are trusted to not interfere with whatever you are doing.

  11. #11
    Join Date
    November 2014
    Location
    Tulsa
    Posts
    16
    Quote Originally Posted by ANR Daemon View Post
    I would add to the trusted article, that it's not only YOU trusted to not cause harm, but, more importantly, other participants in the network are trusted to not interfere with whatever you are doing.
    Precisely, the rule I learned was: "All computers on your network cannot be trusted, even if you set them up and manage them yourself."

Thread Information

Users Browsing this Thread

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

Similar Threads

  1. Is teamspeak safe enought to use?
    By MECER 24 in forum General Questions
    Replies: 4
    Last Post: June 6th, 2014, 01:02 AM
  2. Teamspeak safe without antivirus software?
    By Zab1111 in forum General Questions
    Replies: 2
    Last Post: January 28th, 2014, 11:35 AM
  3. [Tutorial] The Ultimate Permissions Tutorial
    By cbroughton in forum Permission System
    Replies: 0
    Last Post: May 24th, 2011, 01:31 AM
  4. Is Teamspeak Safe Urgent
    By BBery15 in forum General Questions
    Replies: 1
    Last Post: July 28th, 2010, 11:22 PM

Tags for this Thread

Posting Permissions

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