Teamspeak only Firewall/IPtables rules

Falzo

I am looking for help in generating some iptables/ipset config... I am trying to achieve a filtering which only allows outgoing connections to any teamspeak servers.

as there are a lot of teamspeak servers out there not running on the default port 9987 it is not an option to simply allow based on that port.

So I'd like to do something like matching initial outgoing packets against ??? to see if they are teamspeak related and if they do just add the destination IP to an ipset or even single iptables rules to be (temporarily) whitelisted and fully accessable.

I already found that there is a netfilter module related to teamspeak at https://github.com/TeamSpeak-Systems/ts3init_linux_netfilter_module - so this might be useful check for the initial packets at least?

And how to add the destination IP to an ipset or iptables rule if the first packet is a match (haven't done that before)?

Am I looking in the right direction and this might work, any suggestion, hints, what am I missing? ;-)

Thanks in advance...

MagicalTrain

How are you going to deal with encrypted teamspeak data?

Falzo

@MagicalTrain said:
How are you going to deal with encrypted teamspeak data?

that's most likely the point, one simply can't.

therefore my hopes are, I can at least match that teamspeak initiation packets with this netfilter module from github...
and once I have a match I'd like to add the destination IP to an ipset whitelist or alike (at least temporarily) which of course is ACCEPT before other rules ;-)

strategy is a bit like port knocking, but instead of using a port I would try to achieve the same by matching a packet (if possible that is)

I know about some weak spots in that design, but expecially haven't done something like "match packet and add IP to ipset" in a more general way, hence seeking help from someone who did something alike (maybe for other services).

teamacc

Run TS as a separate user, allow all outgoing connections from said user?

Falzo

@teamacc said:
Run TS as a separate user, allow all outgoing connections from said user?

thanks for the suggestion, but sadly in this case it is more like an external firewall setup and there is no direct TS client or even different users which I could use to separate...

Falzo

got this solved, so if someone might have similar idea I like to do a quick follow up on what I did:

Step 1 - install this netfilter extension - https://github.com/TeamSpeak-Systems/ts3init_linux_netfilter_module
this is officially maintained by teamspeak and we only need the functions of matching initial packets like get_cookie and get_puzzle

Step 2 - create a separate chain to add new identified destination IPs ( use of --rdest ) aka teamspeak servers to a recent list and accept connections for those (man iptables-extensions gives further hints on how to use the recent matching)

 iptables -N teamspeak  
 iptables -A teamspeak -m recent --name teamspeak --rdest --set
 iptables -A teamspeak -j ACCEPT

Step 3 - add rules to match initiating teamspeak packets and jump to teamspeak chain on a match (most likely the first rule will suffice)

 iptables -A FORWARD -p udp -m ts3init_get_cookie -j teamspeak
 iptables -A FORWARD -p udp -m ts3init_get_puzzle -j teamspeak

Step 4 - add a rule which ACCEPTs destination IPs already in the teamspeak list, also resetting the lifetime ( --update ) and purging entries ( --reap ) older then e.g. 10 minutes ( --seconds )

 iptables -A FORWARD -m recent --name teamspeak --rdest --reap --update --seconds 600 -j ACCEPT

Step 5 - of course finally have a last rule which REJECTs everything else depending on your setup. for me using this in a kind of external firewall the clients are on a private subnet. so I am simply going to reject forwarding anything (else) from that subnet, like

 iptables -A FORWARD -s 192.168.0.0/24 -j REJECT

a possible culprit or hole in this setup may be that a client could use his teamspeak client to try and connect to any IP, which might result in having that destination IP added to the recent list. even if it is not a teamspeak-server because there is no matching involved for the returning packets to check if there are any. but in my use case this is very unlikely after all ;-)

also a solution to this might be to just ACCEPT the ts3init_get_cookie and only jump to the teamspeak chain after the get_puzzle (step 3) - yet I haven't found the time to test and investigate more :-)
also setting the rule in step 4 to only udp might help in restricting the possible uses further...

please let me know if I am missing something or there are other/simplier solutions, thanks :-)

bap

Yep, thanks for the share