How to Secure your NATS Data - Audit Time!

This Guide covers securing your NATS backend and performing an overall audit of your NATS backend security setup. Many tips found throughout this guide can be used to secure other Webmaster Programs and scripts like Wordpress too.

As with any Program Backend, Security should be your Number One priority. The email hungry and password-trading world is a relentless underground network that will never back off. (plus all the other bs they could get) These guys continually hunt all Webmaster Programs, there servers, networks, bad scripts, and anything else they can find to use as a backdoor in so they can start pawning the Program again.

You don't have to be a Server Admin or a NATS God to use this guide. However, some parts of this article do require Server Administration Skills and an advanced understanding of Webmastering Nats.

Most Hosting Companies can easily assist you adding the more advanced security additions, if needed. If you are one of those unlucky few that got stuck with a crap host or if you are just in need of a solid Hosting Company then I recommend you check out Phatservers and oc3 Networks for some reliable and secure hosting services.

Anyway, Please don't try to secure your own NATS Program and Server if you don't fully understanding what you are doing. Security setup mistakes can be the cause for some nasty problems.

Basic 101 to Securing NATS:
NATS offers a good mixture of tools to help Program Owners secure the Administration Area and the overall data stored within the system.

From within your NATS Admin click the Configuration link in the Menu. At the top of the Config page is the Admin Related IP Features. Each of the 3 fields allows you to secure different parts of NATS for different reasons.

1. ADMIN_IPS - Enter your IP address, your support, staff, remote staff, ect to this field. This protects all admin files from being viewable.
2. REMOTE_AUTH_IPS - This tool is used to verify Webmaster account details. More Details Simply put, you create a script that contacts the NATS DB and it will return if the data is correct or not. This could be used on support forums to auth your Webmasters into the forum.
3. SECURE_IPS - If you use scripts on different servers (like members machines) to access parts of NATS, add the Machines IP address to this list to authorize its access.

From here jump on over to the Resellers Admin and scroll down just past the search fields you can view your Admin Accounts. You can review account logins for Admins or Resellers by clicking the Clock Icon next to the record. This will give you a listing of all the IP's that have entered under this Username.

On the left is icon to set the admin levels for an account. This is where you should adjust what Admin accounts can and can't access. Depending on the Support issue, TMM Support can be restricted to only the needed sections. This goes for Contract Workers too, such as myself. Unless needed, I don't need to see your stats, member or webmaster data, payouts, and a great deal of other possible sensitive data.

Log every request that ANY Admin User makes while logged into NATS:
This is a new feature from TMM/NATS. Yes, you have to do a little bit of your own legwork to use it, but it's a great feature either way. You can check out this NATS KB Article for more details on what to add to your config and the needed file data to make this bad boy work.

Secure Your Data with A Digital Security Certificate:
By using a Digital Certificate on your NATS domain you electronically secure your data while it goes across the Internet. Normally a Credit Card Auth page will be secured by a Digital Security Certificate.

You can use the same technology to help secure your NATS data too. You can provide secure pages for Webmaster signup forms, all support forms, edit profile page, Webmaster and Admin Login pages and Statistics areas.

If you wish to front the money you can pickup a Company/Server Wide Digital Certificate and secure your Member Signup Forms, Member Login Pages, and every other page/domain that you own.

Once you have your Secure Domain setup, you will need to modify all links, in all NATS Templates to point to the new Secure URL's. This can be a pain, but it's well worth it.

Most hosting companies can easily assist you with getting a Digital Certificate and getting it installed onto your Machine.

Advanced Security Tips from oc3Networks:
This information was contributed in by Milan over at oc3Networks. All I can say is Thanks for the great tips guys! These tips are prefect for all those wanting to really lock down NATS and protect that precious data from prying eyes.

1. Put all apache configs in the main httpd.conf and not within the .htaccess files directly. This is especially true for any mysql authentication configs (for member areas). This is good for your NATS site specifically because during upgrades TMM has may delete your custom changes.
2. When using NATS database for member authentication create a mysql user specifically for only looking up usernames/passes. Typically you will use an .htaccess file (see #1!) with basic authentication against NATS mysql dbase. Most people will use the actual nats dbase username and password from the main config.php. Dont do this. Instead create a user with ONLY SELECT privileges on the NATS members table. Go further and only allow this mysql user the ability to SELECT only the username, password and maybe siteid fields.
3. Restrict access to NATS admin_*.php files. NATS has an option built it, but if you dont trust it then you can use an apache config to IP restrict access to it.

In the VirtualHost section for the NATS site or within the .htaccess file, you could add:

If your ISP changes your IP often (a dynamic ip address) then you can use the typical "Basic Auth" config instead of IP restricting access. Make sure you use a strong password. You can visit oc3's Generate Password Script for a great password generator.

1. Restrict access to the NATS scripts that payment processors post-back to. Restrict by IP like #3. You would need the IP's from the processors so you know which IP's to allow. Please Note: Biller IP's often change, so doing this could result in lost reports if you don't properly stay on top of it.
2. Use php's openbase_dir option to restrict the VirtualHost that NATS is on to only be able to open files in its own directories. I'll also mention using safe_mode. These are NOT perfect, but they are useful.
3. Ensure there aren't any files or directories in the NATS install that are writable by the web server. I say "web server" here because it's different for each. For apache it's typically the user "www-data". The NATS Software writes files as www-data, like logs, backup directories, crons and so on. Don't screw with server files unless you know exactly what those files are for.
4. If you give TMM admin access to your NATS install then be sure to change the password or disable the account as soon as they are done. Since this last breach was because they kept your admin passes on their network, this is a good idea.
5. Use /etc/hosts.deny and /etc/hosts.allow to restrict SSH access to your server in general. Add TMM's IP's to the hosts.allow file. Reset there ssh password on each use.
6. You can make their ssh username expire after a period of time by typeing: usermod -e 2008-01-10 username (Linux) This will disable the "username" ssh account on Jan 10th, 2008.

How to Disable the Debug Console in Smarty:
Debug is a tool build into the template engine Smarty. When you add debug to your Smarty Templates a helper window will open. This window tells you a great deal of information, like each Smarty Variable that can be called within the Template. It also displays some other dirty information, like your MySQL login details.

So to protect your program if any of your Admin Users are ever breached you should disable the debug consol. But rather that disabling it, since it is a handy tool, we want to rename it and make the old debug call no longer available.

Open your FTP or SSH to your NATS Machine. The path could be different for your server but mine is: /nats/Smarty-2.6.18/libs/plugins/ Depending your smarty version, your Smarty folder name may be different.

Locate the function.debug.php file and download it. (Make a backup now) Now we need to rename part of the file name. The debug part needs to be replaced with a new word. You could use debuger, debugger, debugs, or DeBugThisShitPlease, anything really. Ie: function.DeBugThisShitPlease.php

Once you have renamed the file, open it. Around line 24 is: function smarty_function_debug($params, &$smarty)

All you need to do is change the word debug, to the new word you put into the file. Such as: function smarty_function_ DeBugThisShitPlease($params, &$smarty)

If you want to call the debug menu within your Smarty Templates with the above example, you would put DeBugThisShitPlease within the template and the consol will now pop.

Now, save your new file and upload it. We aren't done yet though! Now that we have created our new debug function, we now need to disable the old debug call. To do this download the function.debug.php file again and open it.

In the same area as above, but just below the function line is the bracket { and at the very bottom, just above the close of PHP is the closing bracket }. Everything between the brackets gets deleted, make sure you leave the brackets.

Once you have removed the guts of the file, save it and upload it over the original function.debug.php file.

Now when debug is called nothing will happen. Problem solved.

NATS Audit on Templates and Server Files:
Doing an audit of your NATS Program should become a standard. Even more so if your program was ever breached or if you ever feel that something could be wrong. You can continually audit your program as you normally work on it, keeping a watchful eye can pay greatly pay off.

Tip when setting up new Skins: If you start a new skin it's better to rebuild fresh from those templates rather than move or copy over old templates. Besides getting possible exploits, NATS often updates and changes templates features and by using the freshest templates you are always sure to have the most recent features.

Some things to look for within Templates:

• Unknown Iframes or include statements. NATS doesn't support PHP Includes or includes from the Smarty Direcotry but through Smarty Plugins.
• JavaScript lines that link to unknown js files or other URL's. Javascript or a .js file can easily be dropped into templates.

Log into your NATS Admin > Open the Skins & Template Admin > Edit the templates of your Active Skin.

• Starting with the first template, the access template and including all the admin_ templates, you will be looking for every template that has been edited. Meaning the pencil could be clicked. Most admin templates haven't been modified but you should check always check the access template.

Other Main Templates to check:

1. Check the outside templates: index, header, footer, access, contactus (all forms and thanks pages)
2. Webmaster signup templates: signup_adv0 (9+ possible templates)
3. Webmaster edit details: members_edit_adv templates (9+ possible templates)
4. members_header and members_footer and members (and any other member_ header / footer files you may have)
5. Check the other templates as you update or publish new pages.

Check Your Website & Billing Templates:
Now jump on over to the Site Admin and click the Paper Icon to Edit that Websites Templates. Often these templates may have been viewed but not actually used. Such as, if you use Approval URL's vs Approval Templates, if the URL is used the Template is ignored.

You need to check every template you use and don't use. If you have created multiple join forms, examples, or templates for expanded features then each of those should be checked too.

The cascade, approval, denial, and join templates should be double checked for problems.

Give Your Program a Once Over:
Just check everything over, this is good for a lot more than exploits or hacks, it can greatly help spot problems and differences/errors between Website sites, programs, payouts, and much more.

1. Check each Website, Starting with all of the top forms to make sure the proper data is used.
2. Make sure the Site Partner data is correct.
3. Check all the join options and make sure all the billing amounts and codes appear proper.
4. If you use Xsales, then click the xsale options for each billing option and make sure the proper data is used.
5. If Special Billing Options are used make sure they are correct.
6. Make sure the Website is in the proper Programs.
7. Jump over to the Programs Admin and double check each program. Edit each program and make sure the Default Payouts haven't been adjusted for any unauthorized accounts.
8. Ad Tools: You may have many Websites with a great deal of Promo Content but it only takes a short time to scan through it and make sure no wanted Ads/URLs have been mixed in the Tools.
9. Biller Admin: Check all your Biller Data Account Info Settings, make sure the data is correct. Then quickly give your Cascades a quick look to make sure they are properly setup, weighted and GEOIP options correctly set.
10. Popup/Exit Admin: View each chain and make sure the URL is correct.
11. Commissions and Rewards: Give everything a look over to make sure it's correct.
12. Cross Sells Admin: Make sure no unwanted Xsales have been added.
13. Mailing Admin: Wouldn't that suck.
14. Configuration: The Config Admin has 7 different Admins to go through. You should check, read and learn each of these options. Many can greatly benefit your Program.
15. Do it once, do it twice, check everything! Don't forget to check all the things you don't think are important.

Checking the NATS Files on the Server:
Looking over your Server Files for NATS isn't ever a fun job, but it is one that should periodically be done. The trick is doing the often enough that you memorize what files and file dates you see.

The first thing to check is the last time and each time your NATS Install was updated. To do this visit the /nats/upgrade_log/ folder, opening shows a listing of .log files, named and dated for each of your updates. My most recent update is Nov 19 2007 or the 20071119.log. Don't forget to make a note of the other log file dates.

Now that you know when things were updated, we can get things started. Open your /nats/www directory. This is the Web directory for your NATS Program. It should contain your Admin and Member PHP files for NATS and the /signup/ folder.

Checking the directories: /nats/www and /nats/www/signup

1. In the www and signup directories, almost all files should be dated the same as your most recent upgrade log. However, some files could have newer dates because of Support Updates from NATS.
2. Most NATS files are encoded, other than a few helper type files.
3. The encoded NATS files contain two styles of headers. Study the header styles and you will more easily be able to identify unknown files.
4. People who add files to a system often name them close to other file names. You could have a file called access_log but they call it log_access.
5. Look at the file and folder permissions. No files or folders should be open to the world. Chmod 777 or -rwxrwxrwx is bad. Ask your host to adjust this.

Some files are old and may appear to not have been updated for some time. Don't delete these files. If any files are in question, post a ticket and ask NATS.

Other Directories to Check: /nats/includes/ and /nats/Smarty-2.6.18/libs/plugins/
The backend of NATS has a couple areas we should check out too. These files and folders often contain the master working files or control the functionality of NATS.

Starting in the /nats/includes/ directory. Most of these files should be dated the same as your last update. Older dated files are often backups or logs.

From here jump over to your Smarty Install directory, the version number of the folder is probably the same but it could be different.

Open: /nats/Smarty-2.6.18/libs/plugins/

These files either are dated the same because your install is fresh or the dates are all out of whack because you have gone through several NATS versions, like myself. I don't have a real system for telling you how to check the plugins. Most are Smarty created plugins for the system, some NATS clients create their own plugins, and if anyone really wanted to screw with your NATS, this is where they could do it best.

Don't panic though, chances aren't very good that the Plugin directory was exploited. First the person would need server access and a few times a year when Smarty Updates, we all get fresh files and plugins during this update NATS moves over any plugins we created for ourselves.

Quick Tip: Create a text file called _my-plugins.txt within the Plugins directory. List each of your own created Smarty Plugins in the text file. I do this on my own Program and each of my Clients. Now when NATS is doing an update and asks which Smarty Plugins were created by me, I can quickly give them an answer and make sure all of my Plugins get moved over during the upgrade.

Security Reminders from PhatServers:
The PhatServers Team was nice enough to provide us was some great insight on security tips to keep you and your data safe.

1. First and foremost, no security system/setup is 100% secure. Hacking goes beyond bits and bytes, social engineering can be a large part of it and especially in this industry where we're all bro's, and trust shouldn't be handed out as easily as terms of endearment.
2. Don't leave your Wifi network open. In this industry a number of people telecommute from home. So make sure your home and office network(s) are secure. Your Wifi should be protected by some form of key based and/or MAC based authentication.
3. Make sure your PC has all the latest updates as well. A decent virus/spyware/rootkit application is also a must. Use them regularly EVEN if you think you're a PC security expert. (If you really are a PC security expert you can do whatever you want)
4. Keep Your Passwords to Yourself! Having passwords stored on your PC is another place to get them stolen. Handing them out login details to coders, webmasters, updaters, and so on can be dangerous.
5. If you have a coder/script guy who needs SSH access, first ask what they need it for then ask your host if they can take care of it for you. Any decent host will want to keep as many people out of SSH as possible. If your host won't do it, then grant access if you _absolutely must_, but change your password before and after.
6. If you have root to your machines, NEVER give the root password to anyone. If your host gave you root and you don't know what root is, you should change hosts.
7. Don't skimp out on your host, a server isn't a toy. A 10/100MBit/s (Or even 1000MBit/s, fucking fear those overages when some script kiddies backdoors your 10mbit burstable server with a gigabit pipe and you or your host don't notice for a few days) warez/irc bot/DOS bot/scan bot/etc just waiting to happen. It's not something to take lightly and can be an invite for big trouble.
8. Only run essential system services on your server. Disable remote access to applications that don't need to listen remotely. This goes for applications like MySQL (skip-networking in /etc/my.cnf) if your MySQL doesn't receive remote connections. If it does need to accept remote connections, firewall the port to only those machines that need to connect. If your server doesn't need to receive mail, the MTA can either be turned off entirely, or made to listen locally only.
9. Disable FTP and use SFTP. Works pretty much the same and it's part of SSH. Free software like FileZilla support SFTP connections as well as regular connections. Firewall SSH/SFTP if possible, if not, you can use the "AllowUsers" directive to specify which users may connect. A combination of both is ideal.
10. Use mod_auth as often as you can. Password protect your admin interfaces for all of your web applications, restrict them to specific IPs if possible.
11. mod_security can prevent (un)known application exploits from being used but can be a resource hog depending on the type of site it's running on. From NATS: NATS and CARMA don't work correctly with mod_security. It causes a number of problems, including issues with saving some pages. Every once in a while clients run into random forbidden errors in their admin, particularly when editing templates, and it's because they have mod_security.

Don't assume anything. Sometimes things do get missed by your host/server admins, we're not perfect, try to do some of your own research, and....

Be Paranoid About Your Security.

Other Security Tips:
These handy security tips will help you in other related areas of NATS. Like PHP, FTP, Logins, ect.

1. Disable error reporting in php.ini, this will prevent displaying of file locations in the filesystem in the event of an error.
2. disable magic_quotes_gpc in php.ini, and manually do all escaping of user submitted variables. (NATS Does This Now) For single variables, use mysql_real_escape_string (http://www.php.net/mysql_real_escape_string). For arrays, use the following function

1. In the event that user input is to be published on a web page, use a function such as strip_tags (http://www.php.net/strip_tags) to prevent cross site scripting (xss). An example for this would be a comment system. A user could post malicious javascript code, or a redirect to another page if this is not used.
2. When doing user authentication using PHP, never store the users password as plain-text. Always use md5 or a similar encryption method, and authenticate using mysql's built in md5 function. An example would be: Example: SELECT * FROM `users` WHERE username = '$username' AND password = MD5('$password');
3. Disable functions such as system, passthru, exec, shell_exec, and anything else that can be used to execute malicious code via shell through php. If these must be used, pass the command through EscapeShellArg() first to avoid shell injection vulnerabilities.
4. Disable allow_url_fopen in php.ini unless required for script to function. NATS requires allow_url_fopen
5. Insure open_basedir is properly setup in php.ini. Open_basedir restricts file inclusion to the defined directories. This will prevent someone from doing something such as "include('/etc/passwd');"
6. Create a new username and password in mysql for every new project. Give that username ONLY access to the database the script needs to access, and limit it to SELECT, UPDATE, INSERT, and DELETE unless otherwise necessary.
7. Be very careful when using functions such as eval(), as they are a potential security issue.
8. Upgrade to the latest version of PHP. There is no reason to be using PHP4 anymore. Check with script vendors for updated versions of their scripts if they do not support php5, or hire someone to do the code modifications.
9. Have your host setup SFTP rather than FTP access to your servers. It's much more secure. Telnet should be off, with SSH replacing it.

Keep Your sFTP / SSH & Login Data Secure:
All to often Webmaster Programs will hesitate to give you access to a program but have no problem shooting you FTP/SSH or PHPmyAdmin details over ICQ or Email, with little to no care of how secure that is or the receiving persons computer.

If you must send Login Details and Password data to a Client/Webmaster then be smart about it. ICQ, Email and even storing the data on your PC is not a good idea.

1. Email the person the Host and User details and ICQ or Phone them the Password.
2. Setup a Temp Jailed SFTP account for the person and SSH add the details to a text file in that directory.
3. Don't write don't passwords with host/user detail.
4. Change / Remove the Password once the person is done using it. Don't leave extra-open SFTP/SSH accounts for no reason.
5. Never give out your NATS Admin Account Details. Have the Person create an account on your Program, then set the Admin Levels for that User.

Webmasters and Affiliates: If you are doing business on your Social Security Number or some other Personal Id Number then I suggest you stop. Setting up an LLC is quick, cheap and easy and can save you from Identity Theft. The Internet is a hellhole of security issues at every level. Keep Your Private Information To Yourself!

Owners-Directors-Shareholders: Programs, commerce sites, social sites, any other Website that collects and stores any private data is solely responsible to make sure the data is secure. We can point fingers when we fail this duty but at the end of the day we provide the privacy policies, it's our terms and conditions, our databases and servers, our money made from that data and our ass if someone sues because we were irresponsible with that private data.

This article is made possible because of some great Webmasters and Companies who were willing to take some time and lend a hand to the Adult Industry. Please be sure to publicly thank these people on forums, in my comments, or at the up coming show when you see them.

Thanks To:

• Oc3 Networks for being the first host to respond back and adding some kick ass tips on extra IP blocking for admin scripts and PostBack URL's.
• PhatServers because they do a damn good job as my host! And for taking the time to provide us with some great security tips on keeping your data and servers secure.
• SmokeyTheBear - Cause
• Borked - Because he is a Smarty.
• Konrad, the Kandian Koder for contributing the PHP security tips.
• And finally TMM/NATS for making all this possible!

If you have any questions, additions, found a mistake, or just want to make a comment, then please do so below. ~ TheDoc

(Please Rate This Article)