Posted on

Threat Modeling: STRIDE & Data Flow diagrams

I’ve learned some very easy and useful techniques for performing threat modeling in order to evaluate and improve a system’s security. This stuff is a mandatory, documented step in developing for the DoD.

I used to be intimidated by trying to analyze the security of a system. No more.

Now that I have a clue about it, and see how relatively approachable the whole subject is, I consider this a vital step of any design process. Right up there with guessing the resources you’ll need, choosing a
platform, programming language, etc. Really – this is super easy. It’s kinda like basic class diagrams, only for security.

Of course, security goes much deeper than these simple tools, just like object oriented design goes deeper than class diagrams. But in each case, the simple tool gets you a heck of a long way.

Just trust me – this is good reading. RREEAAADDD, my geek friends. At least enough to get a solid feel for this. Maybe this is old hat for some of you.

STRIDE / Data Flow Diagram based analysis:

Threat Trees:


This article was posted to The List by Richard and has been reproduced here for general consumption.

Posted on

Language string failed to load: tls

We recently ran into this error while trying to get a mail service working from within PHP.   Our email service provider requires TLS security to validate our account before we are allowed to send mail through their system.  This is a good practice as it keeps rogue email traffic from flooding the outbound network queue.   However even after installing Mail and Net_SMTP from pear we still could not add mail to the outbound mail queue.

The solution was easy once we located the issue.  It turns out the new PHP installation on a development box was compiled without OpenSSL libraries.   The fix was to re-compile the source after configuring the build with openSSL enabled:

# ./configure <other-options-here> –with-openssl

We then restarted our Apache server to pick up  the new PHP executable & the pear Mail libs worked perfectly with the SSL auth keys enabled.

Posted on

cPanel Brute Force Protection – regaining access

cPanel comes with a great feature called brute force protection.  The problem is, if you mis-type your password 5x in a row or if you have multiple people in the office, like we do, that try to get into various services and they combine to have 5 missed passwords in a row (ssh, mail, and whm logins all quality) then you will lock yourself out of your system.   Here are some tips & tricks that will help you regain access.

Gaining Initial Access

The easiest and quite possibly ONLY way to get back into your system is by logging in from a different IP address.  Sometimes you can do this by re-initializing your modem/router if you are on a DHCP assigned address from your ISP.  This is usually the case for residential service from DSL companies like AT&T (no other choices, huh?  we feel sorry for your), Comcast, or Roadrunner.   If you are on a business class like and have static IP addresses assigned then your public-facing IP won’t change.   You can try to do a One-To-One NAT to give yourself a different static IP, but that assumes you have more than one and you have one that is not being used.   You can try tethering your phone, assuming you have a smart phone.  You can also try to hop on a neighbors open wifi network if you have wireless.   You can also drag your laptop to the local Starbucks and try from there.  If you are wired you have a lot less choices, either call your IPP (hosting company) and ask them to reset brute force protection OR call your ISP and have them assign you a new static IP (if you have only one, chances are you don’t have servers mapped).

To summarize : get on a different network!

  • Try resetting your modem/router if you are on a DHCP address from your ISP.
  • Assign your PC a different static IP if you have a static IP group.
  • Tether your phone.
  • Jump on the neighbor’s network. (ask first)
  • Bring your laptop to a public WiFi hot spot.
  • Call your ISP for a new IP.
  • Call your IPP and ask them to reset cPanel brute force.

Cleaning Out Specific Blocked Entries

If you can gain SSH access you can clean out the errant entries in the cphulkd database that drives brute force protection, entering your IP address in the where clause to find and remove your blocked IP:

# mysql
mysql> use cphulkd;
mysql> select * from brutes where ip LIKE '%<your-ip-or-start-of-ip-address>%';
check the returned list to make sure what you think is your blocked IP is actually on the list.
mysql> delete from brutes where ip LIKE '%<your-ip-or-start-of-ip-address>%';
mysql> quit

Restarting cpHulkd

After making any changes make sure you restart cpHulkd:

# /usr/local/cpanel/etc/init/stopcphulkd
# /usr/local/cpanel/etc/init/startcphulkd

Cleaning Out ALL Blocked Entries

This will reset the “good guys” and the “bad guys”, but if you need a quick fix, don’t want to disable brute force protection, and aren’t comfortable with MySQL command line then go to the  brute force protection interface in cPanel and click the “flush db” button.

Make Sure You Don’t Get Blocked Again

Login to cPanel and go to the brute force protection interface.  Look for the trusted IP list link.  Add your IPs to that list.

Also Running APF?

You will need to stop the apf process from running:

# service apf stop

Then add your good IPs to the whitelist:

# vi /etc/apf/allow_hosts.rules
Posted on

Cyber Sprocket IP Blacklist

The following IP addresses have been blacklisted on our servers due to excessive break-in attempts. If your internet service provider (ISP) or internet presence provider/web host (IPP) is on this list your servers (or desktop computer) will not be able to access any of the Cyber Sprocket servers or the servers we manage for our clients.

If your IP address is on this list and you wish to be removed send us a request via the Contact Us form requesting access to our servers, the reason for your access request, and the specific IP address that you want to use to talk to our servers. Each whitelist request will be considered on a case-by-case basis.

We also recommend that you contact your ISP/IPP and ask them to deal with the hackers that reside on their network. Many ISP/IPPs take a passive approach to these problems, even after we’ve sent them specific log reports showing detailed timestamps, dates, and IP addresses of the systems on their network that are responsible for the attack. Attacks originating from your ISP/IPP not only slow down your network but hamper open & productive communication for everyone on the Internet.

Banned ISP/IPPs

These are companies in North America that have been put on our blacklist for failure to address logged complaints. If you see your hosting or ISP company on this list, send them an email and ask them why they allow hackers to remain on their network after being notified of a coordinated or brute force attack.

Rackforce Hosting, Inc.

OrgName:    RackForce Hosting Inc.
OrgID:      RACKF
Address:    Suite 210
Address:    1628 Dickson Avenue
City:       Kelowna
StateProv:  BC
PostalCode: V1Y-9X1
Country:    CA

ReferralServer: rwhois://

NetRange: -
NetName:    RACKFORCE-3
NetHandle:  NET-64-46-32-0-1
Parent:     NET-64-0-0-0-0
NetType:    Direct Allocation
Comment: port 4321
RegDate:    2006-02-10
Updated:    2006-12-13

OrgTechHandle: RNO3-ARIN
OrgTechName:   Network Operations Center
OrgTechPhone:  +1-250-717-2340

Banned Countries

These are countries that have posted thousands of hacking attempts per month. While we’ve tried contacting nearly every ISP/IPP on this part of the list, we’ve never received a response. Many of the ISP/IPP agencies here are government sponsored agencies that do not police their network traffic or do not respond to private corporation requests to address hackers on their systems.

# China  (59.151.* - 59.151.127.*)
# China (61.172.* - 61.173.*)
# Amsterdam
# Amsterdam
# Italy
# Netherlands
# Turkey
# Germany
# Amsterdam
# Australia
# Australia
# Australia
# Australia
# Columbia
# Ecuador
# Uruguay
# India (202.140.32.* - 202.140.63.*)
# ???
# ???
# Turkey
# Spain
# PanAmSat Corp (USA GA)
# China (222.32.* - 222.63.*)
# China (222.64.* - 222.79.*)
# China
# China
# China
# China
# China
Posted on

Upgrading Logwatch on CentOS 5


I finally got tired at looking at the thousand-plus line daily reports coming to my inbox from Logwatch every evening.  Don’t get me wrong, I love logwatch.  It helps me keep an eye on my servers without having to scrutinize every log file.  If you aren’t using logwatch on your Linux boxes I strongly suggest you look into it and turn on this very valuable service.  Most Linux distros come with this pre-installed.

The problem is that on CentOS the version of logwatch that comes with the system was last updated in 2006.   The logwatch project itself, however, was updated just a few months ago.  As of this writing the version running on CentOS 5 is 7.3 (released 03/24/06) and the version on the logwatch SourceForge site is 7.3.6 (updated March 2010).   In this latest version there are a log of nice updates to the scripts that monitor your log files for you.

The one I’m after, consolidating brute force hacking attempt reports, is a BIG thing.  We see thousands of entries in our daily log files from China hackers trying to get into our servers.   This is typical of most servers these days, however in many cases ignorance is bliss.  Many site owners and IPPs don’t have logging turned on because they get sick of all the reports of hacking attempts.  Luckily we block these attempts on our server, but our Fireant labs project is configured to have iptables tell us whenever an attempt is blocked at the kernel level (we like to monitor what our labs scripts are doing while they are still in alpha testing).   This creates THOUSANDS of lines of output in our daily email.   Logwatch 7.3.6 helps mitigate this.

Logwatch 7.3.6 has a lot of new reports that default to “summary mode”.  You see a single line entry for each notable event, v. a line for each time the event occured.  For instance we see a report more like this for IMAPD..

 [IMAPd] Logout stats:
 User | Logouts | Downloaded |  Mbox Size
 --------------------------------------- | ------- | ---------- | ----------
 cpanel@localhost |     287 |          0 |          0 |       4 |          0 |          0
 291 |          0 |          0

Versus the older output like this:

--------------------- IMAP Begin ------------------------
 **Unmatched Entries**
LOGIN, user=cpanel@localhost, ip=[::ffff:], port=[32811], protocol=IMAP: 1 Time(s)
LOGIN, user=cpanel@localhost, ip=[::ffff:], port=[32826], protocol=IMAP: 1 Time(s)
LOGIN, user=cpanel@localhost, ip=[::ffff:], port=[32981], protocol=IMAP: 1 Time(s)

LOGIN, user=cpanel@localhost, ip=[::ffff:], port=[32988], protocol=IMAP: 1 Time(s)

LOGIN, user=cpanel@localhost, ip=[::ffff:], port=[33040], protocol=IMAP: 1 Time(s)

LOGIN, user=cpanel@localhost, ip=[::ffff:], port=[33245], protocol=IMAP: 1 Time(s)

LOGIN, user=cpanel@localhost, ip=[::ffff:], port=[33294], protocol=IMAP: 1 Time(s)

LOGIN, user=cpanel@localhost, ip=[::ffff:], port=[33310], protocol=IMAP: 1 Time(s)
 repeat 280 more times...

So as you can imagine, with 10 sections to our logwatch report, the new summary reports make our email a LOT easier to scan for potential problems in our log files.

Upgrading Logwatch

In order to get these cool new features you need to spend 10 minutes, 5 if you’re good with command line Linux, and install the latest version of logwatch. In essence you are downloading a tarzip that is full of new shell and Perl script files.  The install does not compile anything, it simply copies scripts files to the proper directory on your server.

Our example here are all based on the default CentOS 5 paths.

  • Go to a temp install or source directory on your server.
    # cd /usr/local/src
  • Get the source for logwatch
    # wget
  • Extract the files
    # tar xvfz logwatch-7.3.6.tar.gz
  • Make the install script executable
    # cd logwatch-7.3.6
    # chmod a+x
  • Run the script & enter the correct paths for logwatch:
    # ./
    ...Logwatch Basedir [/usr/share/logwatch]  : /etc/log.d
    ...Logwatch ConfigDir [/etc/logwatch] : /etc/log.d
    ...temp files [/var/cache/logwatch] : <enter>
    ...perl [/usr/bin/perl] : <enter>
    ...manpage [/usr/share/man] : <enter>


That’s it.  You should now be on the latest version of logwatch.

You can tweak a lot of the settings by editing the files in /etc/log.d/default.conf/services/<service-name>, for example we ask logwatch to only tell us when someones attempt to connect to our server has been dropped more than 10 times by our Fireant scripts (we do this via the iptables service setting).

Hope you find this latest update useful.   We certainly did!

Posted on

SFTP Tips & Tricks

Using Keyfiles To Access SFTP Services

You can use the private key .pem files to allow you to connect via SFTP on a server that only allows key access.

The trick is to get the .pem file that Amazon gives you onto the sever that you will be using to connect to the EC2 instance.   When you store the .pem file on the local box, you will need to ensure the security level is set to 500 (r-x——).

Here is an example:

# sftp -o IdentityFile=my-amazon-given-key.pem root@domU-11-22-33-00-CC-11

We often use this trick to talk to our Amazon EC2 instances as they do not allow password based authentication by default.   This is a good security mechanism as only people with an authorized key file can gain access.   It also gives you a quick an easy way to shut down all access keys by disabling a single key file, essentially shutting down access from an entire group should there be a breach.

Create SFTP Logins Using Private Keyfiles

This is an example based on creating 3rd party access to SFTP on an Amazon EC2 instance.  The article is written for system administrators that wish to grant SFTP access to their server using a private key file they distribute to their users.  There can be multiple key files per username/directory.

  1. Logon to the EC2 instance with a privileged (root?) account.
  2. Create a keypair and save it to your PC.
  3. Start puttygen on your PC.
    1. Conversion/Import – load the key file you saved in step 2.
    2. Save as a private key (I like to add the -priv.ppk extension).
    3. Copy the Key data from the top private key info box (Public key for pasting into OpenSSH authorized_keys file:).
  4. Login to the server where you want the SFTP user to retrieve their files from.
  5. Change to the home directory of the user you want to grant SFTP access to.
  6. Create a .ssh directory.
    1. chmod 700 on that directory (rwx——)
    2. chmod 750 on that directory (rwxr-x—) to open access to other people in the same user group.
  7. Create an authorized_keys file within the .ssh directory.
    1. Create a SINGLE LINE that has the fingerprint you copied from puttygen above.
    2. Save the file.
    3. Chmod 600 on that file (rw——-)
      1. Use mode 640 (rw-r—–) to open access to other people in the same user group.

Now that you have the private key file from step 2.2 above, you can use that to login via PuTTY or SFTP from any system.  The only thing you need is local access to that key file.

Using Private Keys with Filezilla and EC2

After completing the creation of the key file & server-side tweaks to accept that key, you can now use desktop clients such as Filezilla to access your FTP content.   This assumes the system administrator of the server you are connecting to has given you a key file and they have installed the handshake privelages in the authorized_keys file on the remote end.

Pageant Method

  • Start by running pageant on your local system.
  • Add key
  • Find the key you generated with puttygen in step 3.2 above.
  • Start filezilla
  • In site manager enter the host name.  This will be the same server you logged into on step 4 above.
  • Servertype should be set to SFTP
  • Logontype Normal
  • User will be the name of the user that was given SFTP access (you created a .ssh/authorized_keys file in their home directory on the server)

Filezilla Specified Key Method

  • Start Filezilla
  • File/Site Manager – New Site
  • Enter the host name.  This will be the same server you logged into on step 4 from  Create SFTP Logins Using Private Keyfiles
  • Servertype should be set to SFTP
  • Logontype Normal
  • User will be the name of the user that was given SFTP access (you created a .ssh/authorized_keys file in their home directory on the server)
  • Click OK (NOT CONNECT)
  • Edit/Settings
    • Connection/SFTP
    • Add keyfile… and select the private keyfile you generated with puttygen above.
Filezilla - Edit Settings
Filezilla – Edit Settings
Filezilla Site Manager
Filezilla Site Manager

Now connect to that site.   Filezilla will read through the keys and find the right key for the user/server pair that you are connecting to.

Posted on

IP Based Firewall with cPanel

CPanel/WHM Based Systems

If you are using a web server from a web hosting company, chances are the CPanel/WHM is the system admin interface you use to manage your server.

The current revision of CPanel/WHM (Mar 5th, 2008) appears to rely on the host access file as a method of preventing access to the system. Access to iptables or ipchains rules is not readily apparent, however it is possible that we have overlooked these options.

Blocking An IP Range

The steps below will help you research who is connecting to your box and how to block them from gaining access to your system through software based IP blocking.

Real World Example

This implementation is based on our experiences after turning on the Logwatch utility on our web server. The logwatch report for PAM shows sshd authentication failures. From our most recent report:

--------------------- pam_unix Begin ------------------------
  Authentication Failures:
     unknown ( 45 Time(s)
     root ( 10 Time(s)
     unknown ( 9 Time(s)
     ftp ( 4 Time(s)
     mail ( 4 Time(s)
     root ( 2 Time(s)
     apache ( 1 Time(s)
     ftp ( 1 Time(s)
     mysql ( 1 Time(s)
     named ( 1 Time(s)
     postgres ( 1 Time(s)
  Invalid Users:
     Unknown Account: 54 Time(s)
---------------------- pam_unix End -------------------------

The first entry concerns us since there were 45 attempts to access our system that failed. We check the IP range doing a whois lookup (we use DNS Stuff to do our homework) to determine whether or not a general IP block makes sense. We then use CPanel/WHM utilities to shut down access from the offending IP.

Note: This procedure can prevent ANYONE from accessing your server, including yourself, if not done correctly. If you are not confident in your abilities do not even attempt this. Or as the boys like to say “Don’t attempt anything we’re about to do at home. EVER!”

WHM Host Access Control


WHM Host Access Control

  1. Run a DNSStuff whois lookup:
  2. Connect to our CPanel/WHM service via the web connection that our hosting company gave us (http://host.<domain>.com:2086).
  3. Click on the security icon
  4. Click on security center
  5. Click on host access control
  6. In the four entry boxes that are presented, type:
    • daemon : ALL (do not let them connect to ANYTHING on this box, even the web ports)
    • access list: (block anyone connecting from 210.205.231.*)
      • Based on our whois lookup we know that all ip addresses under the 210.205.231.* range are from a specific ISP in Korea. While all the users under that range may not be bad guys, we know from experience that the hackers may get a different IP next week as they tend to be assigned their IP address dynamically. We prefer to block a few of the good guys to shut down the one nuisance user. Your beliefs in the goodness of humanity may dictate a different strategy.
    • action: deny (versus allow which would always let them in regardless of other rules)
    • comment: Korea (you can enter whatever you’d like)
  7. Click Save Host Access List on the bottom of the screen

Go back into security center and click Host Access List. Verify your latest entry appears and that the data is correct. If it is entered incorrectly you may block legitimate users from accessing your system.

Turning On Logwatch

Logwatch notifications may not be enabled on your CPanel/WHM system. Logwatch tends to be running in the background but the notifications go to Never-Never Land by default. You will need to look in system notifications and enter an email address to actually see your messages.


Software Based IP Blocking

Software based IP blocking is a method for preventing access to your system by using a program running on the target computer (the computer people are trying to hack) that intercepts the connection by hooking into the TCP/IP process flow.

Software based IP blocking will consume CPU resources and memory on the target box. It can also be susceptible to hacking, although this is unusual, because it is nothing more than another program that runs on the server. For these reasons, many people consider a separate hardware firewall appliance as the better solution.

However, many web hosting services do not offer external firewall appliances. Those that do may charge more than you are willing to spend on security. In these cases you can still protect yourself via a software based IP blocking program. The most common options on Linux boxes are to use a software based firewall (ipchains or iptables) or preventing connections via host access directives.

Implementation of these concepts is discussed elsewhere on this page.

Posted on

Creating and Installing SSL Certs via SSH

Certificate Signing Request (CSR)

Apache + Open SSL

Login as root
cd /usr/bin/ (/your path to openssl/)
openssl genrsa -des3 -out <name_of_your_certificate>.key 1024

You will need to enter a passphrase for your key here, and then enter it again in the next step.

openssl req -new -key <name_of_your_certificate>.key -out <name_of_your_certificate>.csr

At this point you’ll have to enter information about the site/owner of the SSL cert. Keep in mind that the common name (CM) is actually the address of the site (without http://, etc), and that each cert is only for one host. IE: is not the same as Some certs can be created with multiple/alternative common names.

You’ll need the contents of the csr file to create the cert on godaddy or whichever cert site you’re using. Either download it or VI, and copy and paste the contents.

Installing SSL Certificate and the Intermediate Certificate

Once you’ve gotten the actual certs from the cert site (CRT files), you’ll need to upload them onto the server. You can put them wherever you want, but try to keep things organized because you’ll need to reference them later.

Next you’ll need to edit your conf files. In Apache 1.x this will be httpd.conf, Apache2 will most likely be ssl.conf (or some variation thereof), if the server is using virtual hosts there will be either separate conf files for each host, or seperate entries for each host within the ssl.conf or httpd.conf.
Either add, or uncomment these lines:

SSLCertificateFile /path/to/your/certificate/file

this is the CRT file provided by the cert site

SSLCertificateKeyFile /path/to/your/key/file

this is the KEY file you created previously

SSLCertificateChainFile /path/to/intermediate/bundle/file

an intermediate CRT file also provided by the cert site, this file is only required by certain cert providers

Server Restart

Next you’ll need to restart the web server, this can be done in numerous ways, but if you need to restart via SSH use the command:

apachectl -k graceful

This will restart the server and also allow any connections currently in place to finish. You may need to perform the restart twice, and enter the passphrase that you created your original key file with.