TCP
21 FTP
22 SSH
25 SMTP
26 SMTP (Alternative port, configurable via WHM)
80 HTTP
110 POP3
143 IMAP
443 HTTPS
465 SMTPS
993 IMAP4
995 POP3
2082 cPanel (NON Encrypted)
2083 cPanel (HTTPS)
2086 WHM (NON Encrypted)
2087 WHM (Encrypted)
2095 Webmail (NON Encrypted)
2096 Webmail (Encrypted)
3306 MySQL (Only if allowing Remote Connections)

–UDP
53 DNS

It should be noted that if you’re firewalling off your server, you should open up a portrange for the FTP PassivePort Rolloff. Typically these are higher up ports and a wide range, such as 30000-50000. You’ll also need to modify your FTPd configuration to use this portrange as well. If you don’t, you’ll see issues with FTP connections dropping, successful logins, but a hang, pause or delay when dong an ls or beginning a transfer that results in a dropped connection. Typically this will affect ftp clients that are behind a firewall/router doing NAT translations.

Anyway, that’s it, quick and simple. Enjoy

So I’m just going to paste a sample firewall below, notate it heavily for you, and show you how to get it enabled.

For newer FreeBSD builds, it’s enough to add firewall_enable="YES" to your /etc/rc.conf file and reboot. This will load all the necessary kernel modules, and get you in shape. You should know that by default FreeBSD defaults to a ‘default deny’ policy. This is *VERY* important to know. What it means is that by default, your server isn’t going to open up any ports. You *WILL* be locked out if you do not have a firewall in place. Don’t say I didn’t warn you!

So, with that being said, let’s get our firewall in built and in place, and then we’ll go about adding in the necessary options to ensure it comes up properly on boot. It should noted here that you can build in a “Default to accept” option into the kernel or “firewall_type=”open” to the /etc/rc.conf to start up wide open. This is the suggested practice as the chances are, you’re not close enough to your server to console it.

Let’s get our basic firewall going. We’re going to open up 22 for SSH, 80 for web traffic, 25 for SMTP and 110/143 for POP3/IMAP mail. The syntax is simple enough you should be able to customize it for your own needs, but always make sure your SSH port is accessible. Also if you run SSH on an alternative port, you should modify that here. You don’t want to lock yourself out now, do you?

So go ahead, login as root to your server, open up your text editor of choice. For the purpose of this post, I’m going to assume you’re creating the file /etc/firewall.sh. If not, modify where appropriate. You should also make sure this file is executable by root, otherwise it won’t fire off properly on reboot.


#!/bin/sh

Done!

Save your /etc/firewall.sh file, then make sure permissions are right on it…


chmod 755 /etc/firewall.sh && chown root:wheel /etc/firewall.sh


Open up your handy text editor again, and add the following lines to /etc/rc.conf at the bottom.


firewall_enable="YES"
firewal_script="/etc/firewall.sh"


Done!

Please keep in mind that if you set “firewall_type=open” above, it may overrule this firewall_script variable, so it should be removed.

Congrats, reboot and enjoy your new firewall.

If this is something you’re interested in, leave a comment and let me know how and I can write a few more articles on more complex configurations quite easily.

Fuser.

Why?

fuser is awesome. Not awesome in a “run it and it fixes everything” way, but awesome in a “What in the hell is binding to this port??” kind of way. Two classic scenarios where this is handy…

1. Apache won’t start, “Can’t bind to port ::80″ or “Can’t bind to port ::443″, etc. This typically means something else is already tied to that port, and won’t relinquish it…

2. A security scan of your machine shows something funny running on port 6667… You didn’t start this or know what it is.

What to do now? Well you can sift through netstat output, but that’s, well, boring and slightly annoying.

netstat output

[root@vps ~]# netstat -anp |grep 80
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 3266/httpd
tcp 0 0 127.0.0.1:58725 127.0.0.1:80 TIME_WAIT -
tcp 0 0 10.10.10.10:2078 192.168.1.23:63024 ESTABLISHED 18088/cpdavd - acce
unix 3 [ ] STREAM CONNECTED 49222880 11574/dovecot-auth /var/run/dovecot/login/default
unix 2 [ ] DGRAM 6804658 14078/named


Okay now we see that 3266/httpd is running on 80. Then we do this to find the process..


[root@vps ~]# ps auxwww |grep 3266
nobody 3266 0.0 0.3 65704 3516 ? S 17:05 0:00 /usr/local/apache/bin/httpd -k start -DSSL
root 21665 0.0 0.0 6024 640 pts/2 S+ 18:51 0:00 grep 3266
[root@vps ~]#


Okay there we go…

Now for hacked systems, this could (and probably) is fully forged for a lot of remote shells. Going back to my previous post at http://serveradmins.net/ssh-on-nonstandard-ports-how-to-not-do-it/ which talks about priveleged ports, you could in theory have trojaned ‘ps’, top, etc masking that real process. It may *look* like httpd, but bound to a port like 23425… So dont’t trust that too much, but a bit on that in a second.

The fuser approach…


[root@vps ~]# fuser -n tcp 80
80/tcp: 3266 3267 3268 3269 3271 16078 18274
[root@vps ~]#


Oh look at that a list of all pids bound to that port. Nice, clean, to the point and easily parsable. fuser rocks.

Now a bit more about the masked processes… To run those down, here’s a quick tip. Forget ps/top and your other normal utilities, /proc/ is your friend here…

Proc looks like this on a linux box…

[root@vps ~]# cd /proc/
[root@vps proc]# ls -al
total 1
dr-xr-xr-x 78 root root 0 Jan 26 09:58 .
drwxr-xr-x 24 chrismm chrismm 1024 Feb 4 22:06 ..
dr-xr-xr-x 4 root root 0 Feb 5 05:05 1
dr-xr-xr-x 4 root root 0 Feb 5 05:05 11573
dr-xr-xr-x 4 root root 0 Feb 5 05:05 11574
dr-xr-xr-x 4 dovecot dovecot 0 Feb 5 05:05 11575
dr-xr-xr-x 4 dovecot dovecot 0 Feb 5 05:05 11576
...
...


These directories match the pids of the running process… So if you have something advertising itself as ‘httpd’ on port 234234 and you know it’s pid 3266, you’d just do the following…


[root@vps proc]# cd /proc/3266
[root@vps 3266]# ls -al
total 0
dr-xr-xr-x 4 nobody nobody 0 Feb 5 17:08 .
dr-xr-xr-x 78 root root 0 Jan 26 09:58 ..
-r-------- 1 root root 0 Feb 5 18:56 auxv
-r--r--r-- 1 root root 0 Feb 5 17:08 cmdline
-rw-r--r-- 1 root root 0 Feb 5 18:56 coredump_filter
-r--r--r-- 1 root root 0 Feb 5 18:56 cpuset
lrwxrwxrwx 1 root root 0 Feb 5 18:54 cwd -> /
-r-------- 1 root root 0 Feb 5 18:56 environ
lrwxrwxrwx 1 root root 0 Feb 5 17:10 exe -> /usr/local/apache/bin/httpd
dr-x------ 2 root root 0 Feb 5 18:49 fd
?r--r--r-- 1 root root 0 Feb 5 18:56 io
-r-------- 1 root root 0 Feb 5 18:56 limits
-rw-r--r-- 1 root root 0 Feb 5 18:56 loginuid
-r--r--r-- 1 root root 0 Feb 5 18:54 maps
-rw------- 1 root root 0 Feb 5 18:56 mem
-r--r--r-- 1 root root 0 Feb 5 18:56 mounts
-r-------- 1 root root 0 Feb 5 18:56 mountstats
-r--r--r-- 1 root root 0 Feb 5 18:56 numa_maps
-rw-r--r-- 1 root root 0 Feb 5 18:56 oom_adj
-r--r--r-- 1 root root 0 Feb 5 18:56 oom_score
lrwxrwxrwx 1 root root 0 Feb 5 18:54 root -> /
-r--r--r-- 1 root root 0 Feb 5 18:56 schedstat
-r-------- 1 root root 0 Feb 5 18:56 smaps
-r--r--r-- 1 root root 0 Feb 5 17:08 stat
-r--r--r-- 1 root root 0 Feb 5 17:10 statm
-r--r--r-- 1 root root 0 Feb 5 17:08 status
dr-xr-xr-x 3 nobody nobody 0 Feb 5 18:56 task
-r--r--r-- 1 root root 0 Feb 5 18:56 wchan
[root@vps 3266]#


Bam, there you go. cwd and exe are the things you’re looking for It shows you the dir it was spawned from (typically a users homedirectory on a shared hosting machine) and the full path/binary actually being executed (usually lame perl/php listeners)… Also the ./fd/ folder is kind of neat as it shows you all the open file handles tied up by that pid as well.

Anyway, /proc/ examination too, is for another day, I just wanted to ramble on about one of my favorite, neat little single use utilities that no one else seems to know about. fuser. Enjoy. =)

Wow.  That’s all I can say.  T-Mobile is hacked BIGTIME and from the looks of things, I’d say they knew about it.   Typically in these sorts of situations, the hackers will contact the company they just owned and try to buy their silence.  Now, if the company refuses, then that data gets shopped around.

Now, if there’s no buyer after that, the hacker isn’t just going to walk away, especially on a large scale hack like this.  They’re either going to A: Auction your data off to the highest bidder, or B: Publicly release it for the fame/glory/etc.

I think the biggest thing that concerns me about this, being a T-Mob customer and all, is that even after being contacted by the hackers (assumed at this point), I’ve seen ZERO notice from T-Mobile about this.   Given the scale of their operations, and the control they have over your private data, this is quite concerning.

Let’s think about this for just one second, here’s a bit of info T-Mobile has on you…

• Full Name
• Home Address
• Phone Number
• Answers to private security questions (commonly reused by people from site to site)
• Social Security Number
• Birthdate
• Credit Card Number
• Credit Card Expiration Date
• Credit Card CCV Value (possibly, vendors aren’t supposed to store, but you never know)
• Billing address if it differs from your Main acct address.

Now, that’s just the billing info alone, and if they hackers do have root access on the machines in that URL above, which contains quite a few billing machines, we can assume they have this data in some form.  Let’s look at the other data they have on you…  Here’s where things start to get even freakier than simple credit card fraud and identity theft potential of the situation.

• Your Phone Number
• Your Phones IMEI (numerous repercussions from this)
• Your Call History (Inbound and Outbound)
• Radio Tag Number
• GPS Tag (Yes, your phone has a GPS/Cell location unit.   Yes it can be used to track you without your knowledge)
• Text Message History (inbound and outbound)
• Email History
• Access to your cam-phone pictures (most phones upload and store these online now)

Now, the above list is all stuff that your cell provider logs and tracks.  We know this, it’s public knowledge, etc.  Let’s go ahead and put on the SUPAR BIG tinfoil hat now…   With the advent of government pushes into call logging/tracing/information tracking, we know for a fact that several of the big telcos already record phone calls, fully log all data communications, and have active taps on all of this information.

As more or less of a mental exercise, what do you think the repercussions from this hack look like now?   How far did the intrusion go, and what is the extent of the data turnover?

Spooky, isn’t it.  The even spookier part is that I doubt we’ll ever get a public acknowledgment from T-Mobile regarding this intrusion, any turnover of customer data, nothing.

If you don’t want to end up like T-Mobile, it might be time to look into a proper security audit of your network.
serveradmins.NET