The Infmaous Rider pointed out to me that I should change a port setting on the RemoteDesktop.

twgs.spaceballtw.com is maintained by Remote, as the server is located in the great state of Michigan. Which anyone who cares to look can see.

I've made a script to scan the Windows Firewall Log to count the number of attempts on the RD port and came up with a number of attempted connections but found one attempt on the 13th of June from 213.145.97.42, made 19 attempts of over the course of an hour. There've been other attempts on the DemoteDesktop Port and none of the IP's matched up with IP's found in all the game logs. So I'm happy to report that it appears none of the active players have made any hacking attempts to the server itself.

With Riders help I've changed the Remote Desktop Port to a non-standard number. I'm new to this Server Security issue, and would like to let everyone know that:

Nothing Much is wrong, But I'm Working on it

LOL. Yes, that's a definite problem if you have ppl trying to exploit your RDC port. Mine is behind a firewall. But uhm, using a combination of tor and a port scanner someone could still find your non-standard RDC port with little work while hiding their IP.

Even w/o the password, RDC requests are slow and processor intensive. It's possible to DDoS a machine using RDC connect requests. This could be exploited during a game if, for instance, someone is running a planet defense script and you need to knock them off for an invasion. Or, perhaps, during a grid run where you can't seem to catch the gridder.

A better approach is to build a firewall rule. Filter out all traffic to your new RDC port that doesn't come from a preset range of IP addresses. For instance if you have a class C dynamic IP from work and home, you'd add both IP ranges to the white list, while blacklisting everything else.

That, combined with a change in port numbers, combined with a solid password on the RDC should fix the problem for good.

Looks like problems persist. Server crashed again last night under suspicious circumstances. It's frustrating for me as I'm not able to baby sit and gather proper evidence of foul play. Also. Adding firewall 'hardware' is probably next to impossible.

Since the server only runs TWGS and nothing else, I'm thinking this problem is a toss-up between poor-sportsmanship and personal-vendetta. Whatever the case may be, I hope to have the issue cleared up asap with a little expert assistance.

Not necessary. A software firewall will work fine. The goal is just to block and log bad requests.

You might think about a Linux front-end that forwards only specific ports to your private network.

A simple iptables script is easy to implement provided your kernel supports NAT/Masquerade and the many other iptables handles.

Slackware with full installation is capable of using iptables.
Remember it takes 2 network interfaces. eth0 is my public and eth1 is private. Any machine connected to the private network can also access the internet. Photos can be found at http://scolfax.us/pics of the network here. Email me with any questions.

Ok, now the good stuff-------->
Here's my firewall: /etc/rc.d/rc.firewall

echo 1 > /proc/sys/net/ipv4/ip_forward

# Setup default actions
iptables -P INPUT DROP
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

# Flush (-F) all specific rules
iptables -F INPUT
iptables -F FORWARD
iptables -F OUTPUT
iptables -F -t nat

# Forwarding for TWGS and the web-based telnet client
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p tcp -i eth0 -d 0/0 --dport 23 -j ACCEPT
iptables -A FORWARD -p tcp -i eth1 -d 0/0 --dport 23 -j ACCEPT
iptables -A FORWARD -p tcp -i eth0 -d 0/0 --dport 15000 -j ACCEPT
iptables -A FORWARD -p tcp -i eth1 -d 0/0 --dport 15000 -j ACCEPT
iptables -A FORWARD -p tcp -i eth0 -d 0/0 --dport 15010 -j ACCEPT
iptables -A FORWARD -p tcp -i eth1 -d 0/0 --dport 15010 -j ACCEPT

# Permit packets in to firewall itself that are part of existing and related connections.
iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow all inputs to firewall from the internal network and local interfaces
iptables -A INPUT -i eth1 -s 0/0 -d 0/0 -j ACCEPT
iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT
iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE

# Continuing TWGS rules --> This is where we forward the connections to internal box
iptables -A PREROUTING -t nat -p tcp -i eth0 -d 0/0 --dport 23 -j DNAT --to 192.168.0.41:23
iptables -A PREROUTING -t nat -p tcp -i eth0 -d 0/0 --dport 15000 -j DNAT --to 192.168.0.41:23
iptables -A PREROUTING -t nat -p tcp -i eth1 -d 0/0 --dport 15000 -j DNAT --to 192.168.0.41:23
iptables -A PREROUTING -t nat -p tcp -i eth0 -d 0/0 --dport 15010 -j DNAT --to 192.168.0.41:32000
iptables -A PREROUTING -t nat -p tcp -i eth1 -d 0/0 --dport 15010 -j DNAT --to 192.168.0.41:32000

# Deny any packet coming in on the public internet interface eth0
# which has a spoofed source address from our local networks
iptables -A INPUT -i eth0 -s 192.168.0.0/16 -j DROP
iptables -A INPUT -i eth0 -s 127.0.0.0/8 -j DROP
iptables -A INPUT -i eth0 -s 98.172.178.51/32 -j DROP

# Drop all these llamas (also this is where you kill hacker's ip addys from ever reaching a port) #
# Handy to know the CIDR but you can make your own if you know what you're doing ##### #
iptables -A INPUT -i eth0 -s 216.75.0.0/18 -j DROP
iptables -A INPUT -i eth0 -s 71.41.84.120/32 -j DROP
iptables -A INPUT -i eth0 -s 220.240.0.0/16 -j DROP

# SSH
# SSH vanilla lets everybody connect to ssh port #
# DISABLED for security reasons (also notice ssh isnt on standard port 22)
#iptables -A INPUT -p tcp -s 0/0 -d 0/0 --dport 55555 --syn -j ACCEPT

# FTP # vanilla plus higher ports cuz transfers happen there esp c mac #
# notice we're not including port 55555 cuz thats our protected ssh port #
iptables -A INPUT -p tcp -s 0/0 -d 0/0 --dport 21 --syn -j ACCEPT
iptables -A INPUT -p udp -s 0/0 -d 0/0 --dport 21 -j ACCEPT
iptables -A INPUT -p tcp -s 0/0 -d 0/0 --dport 20 --syn -j ACCEPT
iptables -A INPUT -p udp -s 0/0 -d 0/0 --dport 20 -j ACCEPT
iptables -A INPUT -p tcp -s 0/0 -d 0/0 --dport 1024:55550 --syn -j ACCEPT
iptables -A INPUT -p udp -s 0/0 -d 0/0 --dport 1024:55550 -j ACCEPT

# scolfax (the boss) needs to get in and access almost everything so here goes
iptables -A INPUT -p tcp -s 192.168.0.0/16 --dport 21:65535 --syn -j ACCEPT
iptables -A INPUT -p tcp -s 98.172.178.54/32 --dport 21:65535 --syn -j ACCEPT

# SMTP defunct (mail moved elsewhere since 2004)
# iptables -A INPUT -p tcp -s 0/0 -d 0/0 --dport 25 --syn -j ACCEPT

# DNS & DHCP - soon to disappear - and they're gone lol
#iptables -A INPUT -p tcp --sport 68 --dport 67 -j ACCEPT
#iptables -A INPUT -p udp --sport 68 --dport 67 -j ACCEPT
#iptables -A INPUT -p udp -s 0/0 --sport 53 -d 0/0 --dport 1024:65535 -j ACCEPT
#iptables -A INPUT -p udp -s 0/0 --sport 53 -d 0/0 -j ACCEPT
#iptables -A INPUT -p udp -s 0/0 -d 0/0 --dport 53 -j ACCEPT
# Allow connects to apache server
iptables -A INPUT -p tcp -s 0/0 -d 98.172.178.51/32 --dport 80 --syn -j ACCEPT

# IDENT outgoing # arcti servercentral easynews blessed dks blackened #
# IDENT has been blocked because IRC connections from this machine are forbidden #
# Which is why they are all commented out. #
########## ### ### ### ### ##########
#iptables -A INPUT -p tcp -s 198.163.216.60/32 -d 0/0 --dport 113 --syn -j ACCEPT
#iptables -A INPUT -p tcp -s 208.247.17.2/32 -d 0/0 --dport 113 --syn -j ACCEPT
#iptables -A INPUT -p tcp -s 69.16.172.2/32 -d 0/0 --dport 113 --syn -j ACCEPT
#iptables -A INPUT -p tcp -s 66.225.225.225/32 -d 0/0 --dport 113 --syn -j ACCEPT
#iptables -A INPUT -p tcp -s 204.92.73.10/32 -d 0/0 --dport 113 --syn -j ACCEPT
#iptables -A INPUT -p tcp -s 198.175.186.5/32 -d 0/0 --dport 113 --syn -j ACCEPT
#iptables -A INPUT -p tcp -s 64.18.134.74/32 -d 0/0 --dport 113 --syn -j ACCEPT
#iptables -A INPUT -p tcp -s 208.51.40.2/32 -d 0/0 --dport 113 --syn -j ACCEPT
#iptables -A INPUT -p tcp -s 198.3.160.3/32 -d 0/0 --dport 113 --syn -j ACCEPT
#iptables -A INPUT -p tcp -s 64.161.255.2/32 -d 0/0 --dport 113 --syn -j ACCEPT
#iptables -A INPUT -p tcp -s 205.188.234.121/32 -d 0/0 --dport 113 --syn -j ACCEPT

# IDENT incoming - hybchat links (server->server) #
iptables -A INPUT -p tcp -s 72.20.37.227/32 -d 0/0 --dport 113 --syn -j ACCEPT
iptables -A INPUT -p tcp -s 67.220.81.124/32 -d 0/0 --dport 113 --syn -j ACCEPT

# IDENT incoming - hybchat clients
iptables -A INPUT -p udp -s 0/0 -d 98.172.178.51/32 --sport 113 -j ACCEPT

# HybChat irc server, must let people connect
iptables -A INPUT -p tcp -s 0/0 -d 98.172.178.51/32 --dport 6665:6667 --syn -j ACCEPT
iptables -A INPUT -p tcp -s 0/0 -d 98.172.178.51/32 --dport 9000 --syn -j ACCEPT
iptables -A INPUT -p tcp -s 0/0 -d 98.172.178.51/32 --dport 6697 --syn -j ACCEPT

# Drop everything else
iptables -A INPUT -s 0/0 -d 0/0 -p udp -j DROP
iptables -A INPUT -s 0/0 -d 0/0 -p tcp --syn -j DROP
iptables -A INPUT -s 0/0 -d 0/0 -p all -j DROP

Remember that the firewall script above is somewhat 'wide open' when it comes to the majority of the ports. Basically the only thing above I'm protecting on the linux machine is the ssh port, which is 55555 and is why my ports end at 55550.

Be careful that your rules to allow don't overlap a protected port. Userspace programs generally listen above 1024 and system daemons (servers, if you will) always under 1024. Your remote desktop server most likely listens above 1024. There are port scanners available in your linux console like nmap that can show you the status of what's open versus what's not.

Having an account on somebody else's machine is sometimes a great idea as well, so you can scan your own machine from the internet and verify your port forwarding is working too.

Machines with dynamically-assigned ip addresses (DHCP normally) will require some modifications to the script since the ip address will change on eth0. Typically you could replace the ip.add.res.s/cidr with 0/0

like for the apache service:
iptables -A INPUT -p tcp -s 0/0 -d 98.172.178.51/32 --dport 80 --syn -j ACCEPT

could be written as:
iptables -A INPUT -p tcp -s 0/0 -d 0/0 --dport 80 --syn -j ACCEPT

and is now suitable for dynamic ip addressing.

Whoa. Okay. I think all of that just flew so far over my head that I'm thinking you should be able to collect a few AirMiles. heh ...the server's remote, can't do too much in the way of front-ends etc.

Thanks to a suggestion from Sing, I've installed Comodo Firewall on the Server.. which looks like it should put a end to the Server Attacks. Might be a hiccup or two while I configure the rules etc. looks like a great firewall.

Good news. New FireWall appears to be up and running nicely with alot of help from Sing and his expertise. Incredibly Comodo is very powerful and featureful.. and dare I say it: freeful!

Last night. Extern did not run because the Firewall detected a possible threat in that the xtern is a seperate EXEC, and blocked its loading. I've adjusted the rules and this shouldn't occur again. I regret not being able to be at keys for actual Extern, I've had to initate it manually.

As an aside. There are approx 8 games with aliens (one game has 5 different races). I think all these NPC's use up alot of resources for TWGS'. If Server performance continues to suffer some of these baddies will have to go (thinking SZ Edits w/o the aliens, with ship tweaks to compensate).

That's all for now. Hoping things become much more stable.

server attacks...lol

redownload twgs and start over...lol

i havent had a firewall in years and basically no security, and i have never had an attack...i went thru exactly what your describing, redownloaded twgs reinstalled games and havent had a problem since

to paranoid, and players filling your head with ummmmm BS!!!! lol

sorry to sound so insensitive, but my corp was accused of these "attacks" rofl, new sysop gets new twgs and goes in messes with settings and things get messed up...or low and behold....download of twgs was bad? download farted and corrupted a couple files???

if you're looking for a cheap hardware firewall, find and old pc, 100mhz will do, throw in an extra nic and you can have a really great m0n0wall. thats what i run. solid as a rock.

Or just a NAT router, hehe. That's what I use, filters all non-local requests for RDC, allowing only access to the VPN server (which I can then route thru to access RDC by remote).

Problem is, in this case, it's not a home computer. It's on a hosted network, and he needs RDC access in order to do anything on that computer. This means he needed a software solution for a windows server that could block access to a range of IPs bound for a specific port or set of ports.

Basically there are 2 choices. A software firewall (the easiest) or a software firewall with a wide port ban and an openVPN server. Considering that...

I have to say that I've received alot of help from both Sing and Rider. Each invested their personal time in helping me make this Game Server possible. Sing answered all my questions and setup the FireWall, and Rider configured, secured, and a few other things I barely grasp. Server Rocks now!

Dorks...

hehe

Thanks guys and congrats bud on getting everything figured out!