Oh, I thought you were worried about it being unsafe for you. That makes much more sense.
The servers already are public. If you play a game with Wireshark or TCPDump, you can see the IPs your computer is communicating with. If your computer doesn't know who to communicate with, it's not going to be able to play the game.
Firstly, I would ignore the others in this thread. Their elitism is a little overbearing. I'm going to assume that by "connecting to the OS appropriate shell" you mean scripting/using system commands. In all honesty being able to write shell scripts quickly is probably your best bet. If you really want to know how things are working, start on C. Try using something like PCAP, you can build packet inspectors pretty handily using it.
Good luck.
You could write a packet capturing/analyzing tool with pcap. I did that for a class this semester, and learned a fair bit about structuring C code and a cool application of structs (see the link in the next sentence for that). You can get started with this: http://www.tcpdump.org/pcap.html. Plus, knowing that kind of stuff could be useful in the IT sector (particularly in security, but I imagine it can be useful and just a good thing to have at least a rudimentary understanding of in general IT).
No, it's not even close to that simple.
Tcpdump is a Linux utility to capture network traffic passing through a network interface.
It'd be possible to get the password if you perform an SSL man-in-the-middle attack on the traffic, but it'd be much simpler to grab the HTTP cookie (stores login sessions) in transit and hijack the Facebook session using that cookie.
with tcpdump you can watch traffic going into a port.
BUT, that might not be the best solution. If possible, you should check to see if there is a way to tell how many players are on your server at a given time. Check every 10 minutes or so, and if 3 checks go by with the server population being 0, turn off the server.
Writing the script your self wouldn't limit yourself to AIM or other protocols. Essentially what you would be doing is reading the packet data and parsing out the relavent data in a particular protocol. In order to accomplish this however, you would need to study just how AIM, HTTP, TCP, etc encapselate there data so you can parse it in a meaningful way. The PCap library has a wide range of accomplishing this however. Try reading the PCAP Manpage, its not a light read but it is very informative.
> But to try to log all the front-side packets to disk would be brutal.
Heh, so don't log to disk =) Carve out a small RAM disk per VM, then set a snaplength and circular buffer:
mount -t tmpfs -o size=100m /mnt/ramdisk tcpdump -i enp0s1 -nn -s64 -w /mnt/ramdisk/pcap -C49m -W2
(I'm not necessarily recommending people do this, just playing devil's advocate.)
> TCPdump is a microscope - not a Radar installation.
You might be surprised what you can do. Our software developer has some services running PCAP for gathering data on somewhat-high-query-volume recursive nameservers. But he's probably a little biased toward it.
Yeah was going to say this too. I watched the report and (as a long-time InfoSec guy) was dubious to say the least. At one point they say the Computer Expert^tm was using "specialized software", which I'm sure he was, but the screen was just showing tcpdump traffic scrolling by (i.e. just network communication traffic.)
A fellow student mentioned making "driftnet" (picture-sniffing program) work for wireless networks.
I started learning libpcap and the pcap functions in C. Using this guide to learn my way through. Just dumping packets right now...
Nothing that can show you the results in real-time. There is TcpDump (not sure whether it works with hotspots though), but it saves the traffic to a file and you would have to open it with Wireshark on a computer.
Thanks, that's how I currently have it set up but I'm thinking of the future and different hosts.
As for the network monitoring - I agree that's the best way to tell. You could do this in a variety of languages, no? Or even with a pfSense instance running maybe. Is this a good place to start http://www.tcpdump.org/pcap.html ?
Do you have root access to the Linux system? If so, why don't you just shut Telnet down and be done with the whole problem? Also, every *nix distro I know has some sort of firewall capability which could close the port for you even if the server is still running.
Telnet does not use encryption - so TCPDump[1] will tell you if anything is connecting to it (by listing IPs or MAC addresses as needed) and what credentials it is using (provided you capture the beginning of the TCP session). You can do this either on the Linux box itself or by setting up a pass-through of some sort and play man-in-the-middle.
Also, you could check netstat[2] to see if any connections have been created and what state they are in as this will also provide clues.
Of course, you can always brute-force the passwd or shadow file as these should be the only accounts able to access the Telnet application. You might poke around the configuration files for Telnet on the server to see if it has any access restrictions which would narrow down which account to brute force.
I'm sure others with more experience than myself will have other ideas.
[1]http://www.tcpdump.org/manpages/tcpdump.1.html [2]http://linux.die.net/man/8/netstat
You're right that the network level infrastructure will determine what you can can and can't see. It also depends on the hosts machine location on the network. That being said, there are ways to get around those restrictions too, but every case is going to be different.
Check out the wiki page on packet analyzers.
Also check out the documentation for tcpdump (which is used by Wireshark)
It's actually down right now. It hasn't come on since this morning. I'm on and off borrowing the ethernet from my router rn. For TCP dump, I should be able to get enough info from this page right? I have to get up for a bit but I'll be giving it a shot when I get back.
Perhaps of note that if programmatic blocking is what you want, there's some more versatile options than the hosts file (which, by the way, is stupidly limited, at least on Windows).
To do so, you'd need a program that can intercept all network data. Fortunately, everything going out is going to be going through the OS, and modern OSes provide mechanisms to interact with them. It'd be simplest to use a library like libpcap to do this (that's what Wireshark uses).
Of course, that's not something a regular user would ever need. An example of a program that would provide a more powerful alternative to the Windows hosts file is Acrylic DNS Proxy, which would let you use regex and wildcards in the host file domains.
Considering there's another person who made a different one in the past, I don't think it's that hard given enough time. As I said, I would assume it's just sniffing the packets considering it requires winpcap. And then it's just a matter of parsing the information from the packets. Looking at pcap programming, there are some things to consider. Like how many packets you should sniff before you stop sniffing. I'm pretty sure that's essentially the gist of how the Elitist DPS Meter works.
It's not a really good idea to alienate the person who's working on the sole DPS meter for TERA. I don't think he doesn't care about the community just to make a quick buck. If he didn't care he would've just packed his bags like the other guy who developed the other meter. "After subs, there will be people who may not be able to afford it, i'll do my best to help some of those people out somehow." But hey, you can think whatever you want. Even if that were the case, he has the right to do whatever he wants because he wrote the code and spent a lot of time helping people with issues.
Yup. I have been cursed for doing this on our firewalls. :)
I keep forgetting to try executing tcpdump with the -c option using a (fairly) high, but finite number. That way, if I do forget about it, the process will eventually exit.
Maybe I should use a bash alias pointing at a wrapper to do this.
The problem with doing it on each client is that it requires that each network card be left in "promiscuous mode" (ie. so an application is able to see all the traffic that passes through it through something like libpcap). And then, it has to report back to some centralized location.
Essentially, it's a maintenance nightmare, and logistically crazy... it's also prone to intervention from the user standpoint on any one of several fronts (meaning that you can still "hide" things from it). If you want network monitoring, you're *best*off aiming for a choke point... ideally one that only you (or very few others) control.
I mean, for general network monitoring, I tend to just use a centralized server that monitors packet counts from each machine over SNMP and then reports it via a nice interface (eg. Cacti). But, sounds like that's far less detailed than what you want... though it's also prone to modification to suit your purpose, should you be that ambitious.