The power of the Internet resides in its ability to transcend borders. Application developers in Indonesia or Vietnam can happily find a virtual home selling into markets in North America without leaving the comfort of their sofas. Economic activity has been westward facing, serving the growing markets in developed nations with near universality of broadband access. Most consumers in developed countries have access to wireline broadband access (DSL, fiber, cable, etc.), while developing nations have suffered from under investment on this front. Much of this access has been driven by an economic imperative: Households in these markets demand fast connections, and they have the disposable income to pay for those connections. Conditions have not been the same in developing nations, but the world is changing.

According to the ITU, there were 4,000 broadband Internet users in Indonesia in 2000. In 2011, there are 2.7 million. The picture starts to get interesting when you consider smartphone penetration. An adsmobi report shows that Indonesia had an estimated 30.7-million smartphone users at the end of 2012, and that number is expected to nearly triple to 81.5 million by 2015. In the eleven-year span between 2000 to 2011, the number of smartphone users in Turkey went from zero to over 7 million. A year later in 2012, that number more than doubled to around 15 million — nearly 20% population penetration. This trend is playing itself out globally, the digital divide is getting smaller and the opportunity to provide service in these markets is getting larger.

What does that mean for you and your business online? You want to capitalize on these burgeoning markets and build your service or application to easily reach a global audience and scale to meet that audience’s demand, but that’s a pretty daunting task. You need to deliver a seamless experience to millions of users who live thousands of miles away and who may be accessing a completely different Internet than your users down the street.

The idea that large groups of users are accessing a “completely different Internet” may seem like an overly dramatic way to talk about their unique preferences and cultural/language differences, but I use that phrase very literally. As the global allocation of IPv4 addresses dwindles, Internet Service Providers will bring new users online via IPv6 addresses, and those users will only be able to access sites and applications that have IPv6 addresses. IPv6 addresses can run dual-stack with IPv4 addresses — the same content can be delivered via either protocol from the same server — but many legacy hosting providers haven’t made the necessary upgrades to make every piece of network hardware IPv6-compatible.

As you consider the challenge of preparing for a global boom in users, keep these suggestions in mind:

• Leverage a global infrastructure. You might not have the capital to build infrastructure around the world, so look for an IaaS partner that can provide resources in your targeted geographic markets. You need to be able to easily spin up IT resources where and when you need them to meet regional demand.
• Get close to your end users. Proximity to customers and new markets is vital. You might not be able to host a server next door to every one of your users, but if you can get those users on your network quickly, they’ll have the same kind of high-speed access to the content in your closest data center.
• Don’t pay too much. A simple pay-as-you-go service model helps the process of planning and growing strategically. You’re able to focus on what you do best while avoiding the pitfalls of managing IT hardware.
• Prepare for the future. Overarching technology concerns like the one I mentioned about IPv6 might not be very high on your list of priorities because they’re just theoretical … until they’re not. By preparing for those future challenges, you’ll save yourself a lot of grief when those “future” challenges eventually become “present” challenges.

SoftLayer has 13 data centers strategically located around the world, and we offer the same on-demand provisioning and month-to-month contracts in all of our facilities. We’re continuing to build our network infrastructure to bring users onto our network via one of our network Points of Presence (PoPs) within 40 milliseconds from anywhere in the world. Our platform is IPv6-capable, and we have a team of people focused on finding and addressing future technological concerns before they impact our customers.

To find out more about how your business can go global with SoftLayer, check out our network overview and learn more about what differentiates SoftLayer’s data centers from the competition’s.

-@quigleymar

When you’re driving in a car, traffic is controlled by “standards” such as lanes, stoplights, yield signs and laws that set expectations around how you should drive. When you take a road trip to a different state, the stoplights might be hung horizontally instead of vertically or you’ll see subtle variations in signage, but because you’re familiar with the rules of the road, you’re comfortable with the mechanics of driving in this new place. Coding standards help control development traffic and provide the consistency programmers need to work comfortably with a team across projects. The problem with allowing developers to apply their own unique coding styles to a project is the same as allowing drivers to drive as they wish … Confusion about lane usage, safe passage through intersections and speed would result in collisions and bottlenecks.

Coding standards often seem restrictive or laborious when a development team starts considering their adoption, but they don’t have to be … They can be implemented methodically to improve the team’s efficiency and consistency over time, and they can be as simple as establishing that all instantiations of an object must be referenced with a variable name that begins with a capital letter:

$User = new User();

While that example may seem overly simplistic, it actually makes life a lot easier for all of the developers on a given project. Regardless of who created that variable, every other developer can see the difference between a variable that holds data and one that are instantiates an object. Think about the shapes of signs you encounter while driving … You know what a stop sign looks like without reading the word “STOP” on it, so when you see a red octagon (in the United States, at least), you know what to do when you approach it in your car. Seeing a capitalized variable name would tell us about its function.

The example I gave of capitalizing instantiated objects is just an example. When it comes to coding standards, the most effective rules your team can incorporate are the ones that make the most sense to you. While there are a few best practices in terms of formatting and commenting in code, the most important characteristics of coding standards for a given team is consistency and clarity.

So how do you go about creating a coding standard? Most developers dislike doing unnecessary work, so the easiest way to create a coding standard is to use an already-existing one. Take a look at any libraries or frameworks you are using in your current project. Do they use any coding standards? Are those coding standards something you can live with or use as a starting point? You are free to make any changes to it you wish in order to best facilitate your team’s needs, and you can even set how strict specific coding standards must be adhered to. Take for example left-hand comparisons:

if ( $a == 12 ) { … } // right-hand comparison
if ( 12 == $a ) { … } // left-hand comparison

Both of these statements are valid but one may be preferred over the other. Consider the following statements:

if ( $a = 12 ) { … } // supposed to be a right-hand comparison but is now an assignment
if ( 12 = $a ) { … } // supposed to be a left-hand comparison but is now an assignment

The first statement will now evaluate to true due to $a being assigned the value of 12 which will then cause the code within the if-statement to execute (which is not the desired result). The second statement will cause an error, therefore making it obvious a mistake in the code has occurred. Because our team couldn’t come to a consensus, we decided to allow both of these standards … Either of these two formats are acceptable and they’ll both pass code review, but they are the only two acceptable variants. Code that deviates from those two formats would fail code review and would not be allowed in the code base.

Coding standards play an important role in efficient development of a project when you have several programmers working on the same code. By adopting coding standards and following them, you’ll avoid a free-for-all in your code base, and you’ll be able to look at every line of code and know more about what that line is telling you than what the literal code is telling you … just like seeing a red octagon posted on the side of the road at an intersection.

-@SoftLayerDevs

SoftLayer is able to offer the entrepreneurial community so much more than cloud computing instances and powerful servers. As a startup ourselves not so long ago, our team knows all about the difficulties of being an entrepreneur, and now that we’re able to give back to the startup community, we want to share battle stories and lessons learned. Mentorship is one of the most valuable commodities for entrepreneurs and business founders, and SoftLayer’s mentors are in a unique position to provide feedback about everything from infrastructure planning to hiring your first employees to engaging with your board of advisors to negotiating better terms on a round of funding.

The Catalyst team engages in these kinds discussions with our clients every day, and we’ve had some pretty remarkable success. When we better understand a client’s business, we can provide better feedback and insight into the infrastructure that will help that business succeed. In other words, we build meaningful relationships with our Catalyst clients, and as a result, those clients are able to more efficiently leverage the hosting credits we provide them.

The distinction between Catalyst and other startup programs in the hosting industry has never been so apparent than after South by Southwest (SXSW) in Austin this year. I had the opportunity to meet with entrepreneurs, investors, and industry experts who have been thirsting for a program like Catalyst for years, and when they hear about what we’re doing, they know they’ve found their oasis. I had a chance to sit down with Paul Ford in the Catalyst Startup Lounge at SXSW to talk about the program and some of the insights and feedback we’d gotten at the show:

Paul was quick to point out that being a leader in the startup community has more impact when you provide the best technology and pair that with a team that can deliver for startups what they need: meaningful support.

Later, I had an impromptu coffee with one of the world’s largest, most prestigious Silicon Valley-based venture capital firms — probably THE most respected venture capital firm in the world, actually. As we chatted about the firm’s seed-funding practices, the investment partner told me, “There is no better insurance policy for an infrastructure company than what SoftLayer is doing to ensure success for its startup clients.” And I thought that was a pretty telling insight.

That simple sentence drove home the point that success in a program like Catalyst is not guaranteed by a particular technology, no matter how innovative or industry-leading that technology may be. Success comes from creating value BEYOND that technology, and when I sat down with George Karidis, he shared a few insights how the Catalyst vision came to be along with how the program has evolved to what it is today:

Catalyst is special. The relationships we build with entrepreneurs are meaningful. We’ve made commitments to have the talented brainpower within our own walls to be accessible to the community already. After SXSW, I knew I didn’t have to compare what we were doing from what other programs are doing because that would be like comparing apples and some other fruit that doesn’t do nearly as much for you as apples do.

I was told once on the campaign trail for President Clinton in ’96 that so long as you have a rock-solid strategy, you cannot be beaten if you continue to execute on that strategy. Execute, Execute, Execute. If you waiver and react to the competition, you’re dead in the water. With that in mind, we’re going to keep executing on our strategy of being available to our Catalyst clients and actively helping them solve their problems. The only question that remains is this:

How can we help you?

-@JoshuaKrammes

By merging our two iOS applications into a single, universal app, we can provide better feature parity, maintain coherent architecture and increase code reuse and maintainability because we’re only working with a single feature-rich binary app that provides a consistent user experience on the iPhone and the iPad at the same. Obviously, this meant we had to retool much of the legacy iPhone-specific SoftLayer Mobile app in order to provide the same device-specific functionality we had for the iPad in SoftLayer Mobile HD, but I was surprised at how straightforward that process ended up being. I thought I’d share a few of the resources iOS includes that simplify the process of creating a universal iOS application.

iOS supports development of universal applications via device-specific resource loading and device-specific runtime checks, and we leveraged those tools based on particular situations in our code base.

Device-specific resource loading allows iOS to choose the appropriate resource for the device being used. For example, if we have two different versions of an image called SoftLayerOnBlack.png to fit either an iPhone or an iPad, we simply call one SoftLayerOnBlack~iphone.png and call the other one SoftLayerOnBlack~ipad.png. With those two images in our application bundle, we let the system choose which image to use with a simple line of code:

UIImage* image = [UIImage imageNamed: @"SoftLayerOnBlack.png"];

In addition to device-specific resource loading, iOS also included device-specific runtime checks. With these runtime checks, we’re able to create conditional code paths depending on the underlying device type:

if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad) {
    // The device is an iPad running iOS 3.2 or later.
} else {
    // The device is an iPhone or iPod touch.
}

These building blocks allow for a great deal of flexibility when it comes to creating a universal iOS application. Both techniques enable simple support based on what device is running the application, but they’re used in subtly different ways. With those device-specific tools, developers are able to approach their universal applications in a couple of distinct ways:

Device-Dependent View Controller:
If we want users on the iPhone and iPad applications to have the same functionality but have the presentation tailored to their specific devices, we would create separate iPhone and iPad view controllers. For example, let’s look at how our Object Storage browser appears on the iPhone and the iPad in SoftLayer Mobile:

We want to take advantage of the additional real estate the iPad provides, so at runtime, the appropriate view controller is be selected based on the devices’ UI context. The technique would look a little like this:

@implementation SLMenuController
...
 
- (void) navigateToStorageModule: (id) sender {
	UIViewController<SLApplicationModule> *storageModule = nil;
    if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad) {
        storageModule = [SLStorageModule_iPad storageModule];
    } else {
        storageModule = [SLStorageModule storageModule];
    }
    [self navigateToModule: storageModule];
}	
...
@end

“Universal” View Controller
In other situations, we didn’t need for the viewing experience to differ between the iPhone and the iPad, so we used a single view controller for all devices. We don’t compromise the user experience or presentation of data because the view controller either re-scales or reconfigures the layout at runtime based on screen size. Take a look at the “About” module on the iPhone and iPad:

The code for the universal view controller of the “About” module looks something like this:

@implementation SLAboutModuleNavigationViewController
…
 
- (id) init {
    self = [super init];
    if (self) {
      _navigationHidden = YES;
		_navigationWidth = [[UIScreen mainScreen] bounds].size.width * 0.5;
    }
    return self;
}
…
@end

There are plenty of other iOS features and tricks in the universal SoftLayer Mobile app. If you’ve got a SoftLayer account and an iOS devices, download the app to try it out and let us know what you think. If you were a SoftLayer Mobile HD user, do you notice any significant changes in the new app from the legacy app?

-Pawel

P.S. If you’re not on iOS but you still want some SoftLayer love on your mobile device, check out the other SoftLayer Mobile Apps on Android and Windows Phone.

Lesson 1: The founders must be committed to the success of their venture.
Joining an accelerator or incubator comes with some strings attached — startups give up between 6 to 10 percent of their equity in exchange for some cash and structured program that usually lasts around three months. Obviously, this kind of commitment should not be taken lightly.

Too often, startups join accelerator programs before they are ready or mature enough as a team. Sometimes, a company’s idea isn’t fully baked, so they end up spending as much time “creating” their business as they do “accelerating” it. As a result, that company isn’t able to leverage an accelerator’s resources efficiently throughout the entire program … The founders need to establish a vision for the business, begin laying the groundwork for the company’s products and services, and be 100% committed to the accelerator program before joining. If you can’t say with confidence that your startup meets all three of those requirements, don’t do it. Take care of those three points and proceed to the next lesson.

Lesson 2: Be prepared to leverage what you are given.
Many startups join accelerator and incubator programs with unrealistic expectations. Participation in these programs — even the most exclusive and well-known ones — by no means guarantees that you’ll raise additional money or have a successful exit. These programs provide startups with office space, free cloud services, and access to mentors, investors, recruiters and media … Those outstanding services provide participating startups with a distinct competitive advantage, but they don’t serve up success on a silver platter. If you aren’t ready work tirelessly to leverage the benefits of a startup program, don’t bother.

Lesson 3: Take advice and criticism well; mentors are trying to help.
“Mentorship” is very tough to qualify, and criticism is difficult to take … Especially if you’re 100% committed to your business and you don’t want to be told that you’ve done something wrong. Mentors in these startup programs have “been there and done that,” and they wouldn’t be in a mentorship position if they weren’t looking out for your best interest and the ultimate success of your company.

Look programs that take mentorship seriously and can provide a broad range of expertise from strategy to marketing and business development to software architecture to building and scaling IT infrastructure. Then be intentional about listening to the people around you.

Lesson 4: Do your research and make an informed decision.
With the proliferation of startups globally, we’re also seeing an evolution in the accelerator ecosystem. There are a number accelerators being positioned to help support founders with ideas on a global, regional and local basis, but it’s important to evaluate a program’s vision with its execution of that vision. Not all startup programs are created equal, and some might not offer the right set of resources and opportunities for your team. When you’re giving up equity in your company, you should have complete confidence that the accelerator or incubator you join will deliver on its side of the deal.

Lesson 5: Leverage the network and community you will meet.
When you’ve done your homework, applied and been accepted to the perfect startup program, meet everyone you can and learn from them. One of the most tangible benefits of joining an accelerator is the way you can fast track a business idea while boosting network contacts. Much in the way someone chooses a prestigious college or joins a fraternity, some of the most valuable resources you’ll come across in these programs are the people you meet. In this way, accelerators and incubators are becoming a proxy for undergrad and graduate school … The appeal for promising entrepreneurs is simple: Why wait to make a dent in the universe? Today, more people are going to college and fewer are landing well-paying jobs after graduation, so some of the world’s best and brightest are turning to these communities and foregoing the more structured “higher education” process.

Even if your startup is plugging along smoothly, a startup accelerator or incubator program might be worth a look. Venture capitalists often trust programs like TechStars and 500 Startups to filter or vet early stage companies. If your business has the stamp of approval from one of these organizations, it’s decidedly less risky than a business idea pitched by a random entrepreneur.

If you understand each of these lessons and you take advantage of the resources and opportunities provided by startup accelerators and incubators, the sky is the limit for your business. Now get to work.

Class dismissed.

-@gkdog

To get the ball rolling, we need to download CSF and install it on our server. In this post, we’re working with a CentOS 6.0 32-bit server, so our (root) terminal commands would look like this to download and install CSF:

$ wget http://www.configserver.com/free/csf.tgz #Download CSF using wget.
$ tar zxvf csf.tgz #Unpack it.
$ yum install perl-libwww-perl #Make sure perl modules are installed ...
$ yum install perl-Time-HiRes  #Otherwise it will generate an error.
$ cd csf
$ ./install.sh #Install CSF.
 
#MAKE SURE YOU HAVE YOUR BAND-AID READY
 
$ /etc/init.d/csf start #Start CSF. (Note: You can also use '$ service csf start')

Once you start CSF, you can see a list of the default rules that load at startup. CSF defaults to a DROP policy:

$ iptables -nL | grep policy
Chain INPUT (policy DROP)
Chain FORWARD (policy DROP)
Chain OUTPUT (policy DROP)

Don’t ever run “iptables -F” unless you want to lock yourself out. In fact, you might want to add “This server is running CSF – do not run ‘iptables -F’” to your /etc/motd, just as a reminder/warning to others.

CSF loads on startup by default. This means that if you get locked out, a simple reboot probably won’t fix the problem. Runlevels 2, 3, 4, and 5 are all on:

$ chkconfig --list | grep csf
csf             0:off   1:off   2:on    3:on    4:on    5:on    6:off

Some features of CSF will not work unless you have certain iptables modules installed. I believe they are installed by default in CentOS, but if you custom-built your iptables, they might not all be installed. Run this script to see if all modules are installed:

$ /etc/csf/csftest.pl
Testing ip_tables/iptable_filter...OK
Testing ipt_LOG...OK
Testing ipt_multiport/xt_multiport...OK
Testing ipt_REJECT...OK
Testing ipt_state/xt_state...OK
Testing ipt_limit/xt_limit...OK
Testing ipt_recent...OK
Testing xt_connlimit...OK
Testing ipt_owner/xt_owner...OK
Testing iptable_nat/ipt_REDIRECT...OK
Testing iptable_nat/ipt_DNAT...OK
 
RESULT: csf should function on this server

As I mentioned, this is the default iptables installation on a minimal CentOS 6.0 image, so chances are good that these modules are already installed on your system. It never hurts to check, though.

The CSF Configuration File

The primary CSF configuration is stored in the well-documented /etc/csf/csf.conf file. CSF is extremely configurable, so there are a lot of options to read over. Let’s take a look over some of the more important features:

Testing

TESTING = "1"
TESTING_INTERVAL = "5"

This TESTING cron job runs every “5″ minutes so you don’t lock yourself out when you’re testing your rules. When you are satisfied with your rules (and confident that you won’t lock yourself out), you can set TESTING to “0″.

Globally Allowed Ports

# Allow incoming TCP ports
TCP_IN = "20,21,22,25,53,80,110,143,443,465,587,993,995"
 
# Allow outgoing TCP ports
TCP_OUT = "20,21,22,25,53,80,110,113,443"
 
# Allow incoming UDP ports
UDP_IN = "20,21,53"
 
# Allow outgoing UDP ports
# To allow outgoing traceroute add 33434:33523 to this list
UDP_OUT = "20,21,53,113,123"

Incoming Ping Requests

# Allow incoming PING
ICMP_IN = "1"

Allowing ping is usually a good option for diagnostic purposes, so I don’t recommend turning it off. Disallowing ping is an example of “security through obscurity,” and it will not typically dissuade your attackers.

Ethernet Device

ETH_DEVICE = ""
ETH6_DEVICE = ""

Here, you can configure iptables to ONLY use one Ethernet adapter. You might want to only guard your public network adapter in some situations.

IP Limit in Permanent “Deny” File

DENY_IP_LIMIT = "200"

A higher number here will obviously screen out more IP addresses in csf.deny, but higher numbers also may cause slowdowns.

IP Limit in Temporary “Deny” File

DENY_TEMP_IP_LIMIT = "100"

Similar to DENY_IP_LIMIT, the DENY_TEMP_IP_LIMIT represents the maximum number of IPs that can be stored in the temporary ban list.

SMTP Blocking

SMTP_BLOCK = "0"

When set to “1″, SMTP_BLOCK does not completely block outbound SMTP, but it does block it for most users. This will prevent malicious scripts and compromised users from making outbound connections from unauthorized mail clients on the server. SMTP_BLOCK doesn’t stop those scripts from running, but it does stop them from functioning. Mail sent through the proper channels will still be delivered normally.

Allowing SMTP on localhost

SMTP_ALLOWLOCAL = "1"

Custom Mail Port Designation

SMTP_PORTS = "25,465,587"

Allowing SMTP Access to Users/Groups

SMTP_ALLOWUSER = ""
SMTP_ALLOWGROUP = "mail,mailman"

SYN Flood Protection

SYNFLOOD = "0"
SYNFLOOD_RATE = "100/s"
SYNFLOOD_BURST = "150"

Per the documentation, you should only enable SYN flood protection (SYNFLOOD= “1″) if you are currently under a SYN flood attack.

Concurrent Connections Limit

CONNLIMIT = "22;5,80;20"
PORTFLOOD = "22;tcp;5;300,80;tcp;20;5

These options allow you to add customized DoS protection. CONNLIMIT handles the number of concurrent connections, and in this example, we’re limiting port 22 to 5 connections and port 80 to 20 connections.

PORTFLOOD on deals with connections per second. In this example, we’re limiting the TCP connection on port 22 to 5 connections/second with a quiet period of 300 seconds before the connection is unblocked. Additonally, we’re limiting the TCP connection on port 80 to 20 connections/second with a quiet period of 5 seconds before the connection is unblocked.

Check the readme.txt file for more information about the syntax.

Logging to Syslog

SYSLOG = "0"

When enabled, this option logs lfd (Login Failure Daemon) messages to syslog as well as to /var/log/lfd.log.

Dropping v. Rejecting Packets

DROP = "DROP"

This configuration allows you to either DROP or REJECT packets. REJECT tells the sender that the packet has been blocked by the firewall. DROP just drops the packet and does not send a response. I like DROP better for regular use, but REJECT might be more helpful if you need to diagnose a connectivity issue.

Logging Dropped Connections

DROP_LOGGING = "1"

This option logs dropped connections to syslog. I don’t see any reason to turn this off unless your hard drive is getting full.

Port Exceptions When Logging Dropped Connections

DROP_NOLOG = "67,68,111,113,135:139,445,500,513,520"

These ports are specifically blocked from being logged either to conserve hard drive space or make the log file easier to read.

“Watch Mode”

WATCH_MODE = "0"

If you are ever stuck trying to troubleshoot a large ruleset, you might consider turning this option on. You can use it to track the actions to watched IP addresses to see where they are getting blocked or accepted.

Login Failure Daemon Alert

LF_ALERT_TO = ""
LF_ALERT_FROM = ""
LF_ALERT_SMTP = ""

You can specify an email address to report errors from the Login Failure Daemon, which tracks and automatically blocks brute force login attempts.

Permanent Blocks and NetBlocks

LF_PERMBLOCK = "1"
LF_PERMBLOCK_INTERVAL = "86400"
LF_PERMBLOCK_COUNT = "4"
LF_PERMBLOCK_ALERT = "1"
LF_NETBLOCK = "0"
LF_NETBLOCK_INTERVAL = "86400"
LF_NETBLOCK_COUNT = "4"
LF_NETBLOCK_CLASS = "C"
LF_NETBLOCK_ALERT = "1"

These settings control the permanent block and netblock blocking. You probably don’t need to touch these settings, but you might want some additional security or less security depending on your company needs. If something gets permablocked, it will require your intervention to clear it, which might create downtime for your clients. Likewise, if a legitimate IP address happens to be part of a netblock which has an attacking IP address on it, it will get blocked if you have that feature turned on. A class C network encompasses 256 IP addresses. You can set this to class B or A, but that could block thousands or millions of IP addresses, respectively. Unless you find yourself under constant attack, I would advise you to leave that LF_NETBLOCK off.

Additional Protection During Updates

# Safe Chain Update. If enabled, all dynamic update chains (GALLOW*, GDENY*,
# SPAMHAUS, DSHIELD, BOGON, CC_ALLOW, CC_DENY, ALLOWDYN*) will create a new
# chain when updating, and insert it into the relevant LOCALINPUT/LOCALOUTPUT
# chain, then flush and delete the old dynamic chain and rename the new chain.
#
# This prevents a small window of opportunity opening when an update occurs and
# the dynamic chain is flushed for the new rules.
SAFECHAINUPDATE = "0"

Activating this option will increase your system resource usage and will require more rules to be running at one time, but it provides an additional layer of protection during updates. Without this option turned on, your rules will be flushed for a short amount of time, leaving your server vulnerable.

Multi-Server Deployment Options

LF_GLOBAL = "0"
GLOBAL_ALLOW = ""
GLOBAL_DENY = ""
GLOBAL_IGNORE = ""

Like APF, you can configure global lists for multiple server deployments. You’ll need to specify a URL of the text file with the IP addresses for the global lists.

SPAMHAUSE Blocklist

LF_SPAMHAUS = "0"

This option enables the SPAMHAUS blocklist. Specify the number of seconds between refreshes. Recommended setting is 86400 (1 day).

Blocking TOR Exit IP Addresses

LF_TOR = "0"

Enabling this option will block TOR exit IP addresses. If you are not familiar with TOR, it is a completely anonymous proxy network. This could block some legitimate users who are trying to protect their anonymity, so I would recommend only turning this on if you are already under attack from a TOR exit address.

Blocking Bogon Addresses

LF_BOGON = "0"
LF_BOGON_URL = "http://www.cymru.com/Documents/bogon-bn-agg.txt"
LF_BOGON_SKIP = ""

Blocking bogon addresses (addresses that should not be possible) is usually a good decision. To enable, set the number of seconds between refreshes. I recommend enabling this option and setting the refresh at 86400 (1 day). If you do so, be sure to add your private network adapters to the skip list.

Country-Specific Access to Your Server

CC_DENY = ""
CC_ALLOW = ""

With these options, you can block or allow entire countries from accessing your server. To do so, enter the country codes in a comma separated list. Even though this generates a lot of additional rules, it’s valuable to some sysadmins.

CC_ALLOW_FILTER = ""

Alternatively, you can set your server to exclusively accept traffic from a list of country codes. All other countries not listed will have their traffic dropped. There are many other settings related to these options that I don’t have time to cover in this blog.

Blocking Login Failures

LF_TRIGGER = "0"

This enables blocking of login failures (per service). There are a lot of great customization options in this section.

Scanning Directories for Malicious Files

LF_DIRWATCH = "300"

This feature scans /tmp and /dev/shm for potentially malicious files and alerts you to their presence based on the interval you designate. You can also have CSF automatically quarantine malicious files with this option:

LF_DIRWATCH_DISABLE = "0"

Distributed Attack Protection

LF_DISTATTACK = "0"

By enabling this option, you activate additional protection against distributed attacks.

Blocking Based on Abusive Email Usage

LT_POP3D = "0"
LT_IMAPD = "0"

If a user checks email too many times per hour (more than the non-zero value specified), the user’s IP address is blocked.

Email Alert Following Block

LT_EMAIL_ALERT = "1"

This will send you email when something is blocked. I’d recommend leaving it on.

Blocking IP Addresses Based on Number of Connections

CT_LIMIT = "0"

This feature tracks connections and blocks the IP if the number of connections is too high. Use caution because if you enable this option and set this value too low, it will block legitimate traffic.

Application-Level Protection

PT_LIMIT = "60"

This feature provides application level protection against malicious scripts that take a long time to execute.

Blocking Port Scanners

PS_INTERVAL = "300"
PS_LIMIT = "10"

Enabling HTML User Interface for CSF

UI = "0"

CSF has a built-in HTML user interface. You can enable this by setting UI = “1″. There are a list of prerequisites for this option in the readme.txt.

Notifying Blocked IP Addresses

MESSENGER = "0"

This option will notify blocked IP addresses when they have been blocked by the firewall.

Port Knocking

PORTKNOCKING = ""

CSF supports port knocking, which is a technique that provides an additional layer of security. See http://www.portknocking.org/ for details.

Allow and Deny Lists

As we walked through the CSF configuration file, you saw that I referenced the csf.deny file, so it should come as no surprise that CSF also includes csf.allow to customize “allow” rules as well. If you are familiar with APF, these files have a very similar syntax … Each entry is made up of the same four components: protocol|flow|port|IP. The only real difference being that APF uses the colon as a delimiter while CSF uses the pipe:

#APF Version
tcp:in:d=48000_48020:s=10.0.0.0/8
 
#CSF Version
tcp|in|d=48000_48020|s=10.0.0.0/8

Fortunately, replacing your colon with a pipe is a minimally invasive procedure that can be automated with a tool like vi.

CSF Command Line Tool

The command line tool for CSF is much more robust than the one for APF:

$ csf --help
csf: v5.79 (cPanel)
 
ConfigServer Security & Firewall
(c)2006-2013, Way to the Web Limited (http://www.configserver.com)
 
Usage: /usr/sbin/csf [option] [value]
 
Option              Meaning
-h, --help          Show this message
-l, --status        List/Show iptables configuration
-l6, --status6      List/Show ip6tables configuration
-s, --start         Start firewall rules
-f, --stop          Flush/Stop firewall rules (Note: lfd may restart csf)
-r, --restart       Restart firewall rules
-q, --startq        Quick restart (csf restarted by lfd)
-sf, --startf       Force CLI restart regardless of LF_QUICKSTART setting
-a, --add ip        Allow an IP and add to /etc/csf.allow
-ar, --addrm ip     Remove an IP from /etc/csf.allow and delete rule
-d, --deny ip       Deny an IP and add to /etc/csf.deny
-dr, --denyrm ip    Unblock an IP and remove from /etc/csf.deny
-df, --denyf        Remove and unblock all entries in /etc/csf.deny
-g, --grep ip       Search the iptables rules for an IP match (incl. CIDR)
-t, --temp          Displays the current list of temp IP entries and their TTL
-tr, --temprm ip    Remove an IPs from the temp IP ban and allow list
-td, --tempdeny ip ttl [-p port] [-d direction]
                    Add an IP to the temp IP ban list. ttl is how long to
                    blocks for (default:seconds, can use one suffix of h/m/d).
                    Optional port. Optional direction of block can be one of:
                    in, out or inout (default:in)
-ta, --tempallow ip ttl [-p port] [-d direction]
                    Add an IP to the temp IP allow list (default:inout)
-tf, --tempf        Flush all IPs from the temp IP entries
-cp, --cping        PING all members in an lfd Cluster
-cd, --cdeny ip     Deny an IP in a Cluster and add to /etc/csf.deny
-ca, --callow ip    Allow an IP in a Cluster and add to /etc/csf.allow
-cr, --crm ip       Unblock an IP in a Cluster and remove from /etc/csf.deny
-cc, --cconfig [name] [value]
                    Change configuration option [name] to [value] in a Cluster
-cf, --cfile [file] Send [file] in a Cluster to /etc/csf/
-crs, --crestart    Cluster restart csf and lfd
-w, --watch ip      Log SYN packets for an IP across iptables chains
-m, --mail [addr]   Display Server Check in HTML or email to [addr] if present
-lr, --logrun       Initiate Log Scanner report via lfd
-c, --check         Check for updates to csf but do not upgrade
-u, --update        Check for updates to csf and upgrade if available
-uf                 Force an update of csf
-x, --disable       Disable csf and lfd
-e, --enable        Enable csf and lfd if previously disabled
-v, --version       Show csf version

The command line tool will also tell you if the testing mode is enabled (which is a very useful feature). If TESTING were enabled, we’d see this line at the bottom of the output:

*WARNING* TESTING mode is enabled - do not forget to disable it in the configuration

Did you make it all the way through?! Great! I know it’s a lot to take in, but it’s not terribly complicated when we break it down and understand how each piece works. Next time, I’ll be back with some tips on integrating CSF into cPanel.

-Mark

Anyone who’s organized events knows that it often involves a financial risk because it’s hard to know whether the event will be well-enough attended to cover the costs of putting on the event. With Kickback Tickets, an event is listed an funded ahead of time, and when it reaches its “Tipping Point” goal of tickets ordered, it’s completely funded, the early supporters are charged, and the ticket sales continue.

The process is simple:

Event updates, guest registrations and QR-coded tickets are provided to attendees to make check-in seamless, so the hosts of each event don’t have hassle with those details. Kickback’s revenue comes from a small fee on each ticket for each successfully funded event, and they’ve got a ton of momentum. After signing on with Catalyst in March 2012, Kickback went live with an open beta in November 2012, and they launched their out-of-beta site in February 2013. They’ve successfully funded more than 20 events, and new events are added daily.

When I met the Kickback founders Jonathan Perkins and Julian Balderas, I was attending SF Beta (my first official event as a SLayer). At the time, Jonathan and Julian were a couple of bankers with an innovative idea to help organizations alleviate the financial risk of planning and putting on events by enlisting community support. I told them about my experience as the COO of a small non-profit startup up called Slavery Footprint (also a Catalyst partner), and I guess they could relate to the challenges SoftLayer helped us overcome because they were excited to join.

In their own words, Jonathan and Julian explain that their partnership with Softlayer and the Catalyst program has been extremely valuable:

SoftLayer provides a rock-solid technical foundation and allows us to focus more resources on business development. On the technical side, what Softlayer offers is impressive — super fast speeds and an intricate level of control over the hardware. On the personal side, the mentorship and networking benefits of the program have been very helpful. We’ve always found the Catalyst team to be available to chat about any questions we had, ranging from development to biz dev to fundraising.

As they continue to expand their platform, it’s going to be exciting to watch Kickback become a true force in the events space. Organize your next event with Kickback and make sure it’s a success.

Oh, and if you want to speak to Jonathan and Julian, just reach out to me and I’ll happily make the introduction.

-@JoshuaKrammes

For the fifth annual Global Game Jam, more than 16,000 participants committed a weekend to learning from and collaborating with their peers in a worldwide game development hackathon. I was lucky enough to get to sit in on the action in Vancouver, and I thought I’d give you a glimpse into how participants make game development magic happen in such a short period of time.

Day 1 (Friday Night): The Brainstorm
More than 260 participants poured into an open study area of the Life Sciences building at the Univerity of British Columbia to build the next best distraction … er, video game. The event kicked off with a keynote from Brian Proviciano, a game development prodigy, who shared his history and offered sage advice for those interested in the industry. Following a comical 20-second idea pitch session, the caffeine began to flow and the brainstorm commenced.

Inspiration could come from anywhere, and a perfect example is the “Poseidon” game I mentioned above: GGJVancouver organizer Kimberly Voll had sprinklers rain on her office a few days prior to the event, so someone decided to make a game out of that situation. This year, the Global Game Jam introduced an interesting twist that they called “diversifiers.” Diversifiers are side-challenges for extra credit, and two of my favorites were “Atari Age” — the game has to be smaller than 4kb — and “May the (Web) Force be With You” — the game has to run in a browser.

Fast-forward two hours, and as you look around, you see storyboards and scripts being written, characters being born, and a few intrepid developers starting to experiment with APIs, game engines , and external controllers to find some additional flair for their final products. You wouldn’t expect a game made in 48 hours to incorporate an iOS Eye Tracking API or the Leap Motion gesture controller, but these developers are ambitious!

As the concepts are finalized, team members rotate in and out for sleep, and some even go home to get some rest — a good idea on the first night since everyone usually pulls an all-nighter on Saturday.

Day 2 (Saturday): Laying the Foundation
It was cool to walk the aisles and peer over peoples’ shoulders as musical scores, wrangled code and character models were coming together. However, the scene wasn’t all smiles and hugs; a few groups were wrestling quirky bugs and integration issues, and in some cases, they ended up having to completely reboot their approach. Day 2 set the course for all of the teams. A few teams disbanded due to disagreements or unfixable bugs, and some developers peeled off from their teams to follow an untamed passion. In the Global Game Jam, there are no rules … only games.

Day 3 (Sunday): Sleep, What’s That?
By Day 3, the building starts feeling like a college dorm during finals week when everyone is staying up all night to study or finish their comp-sci assignments (I know it wasn’t just me…). Running on various vehicles of caffeine, teams worked heads-down all day to meet their 3pm deadline. Sighs of relief and high fives were exchanged when the games were submitted, and the event concluded with a pizza party and demo session where everyone could see and share the fruits of their labor.

As I left the conference, teams were given the opportunity to showcase their games on the big screen to a chorus of laughter and applause. It was an awesome experience, and I’m glad SoftLayer sponsored it so that I could attend, take it all in and meet a ton of outstanding up-and-coming game developers. If you’re into making games (or you’ve thought about it), check out the Global Game Jam one of these years.

Just don’t forget to bring deodorant … for your neighbor’s sake.

-@andy_mui

Photo Credit Shout-Outs: Alex Larente, Ligia Brosch, Naz Madani. Great shots!

Let’s start with the jQuery code block we created in Part 1:

(function($) {
    $.fn.slPlugin = function(options) {
            var defaults = {
                myVar: "This is", // this will be the default value of this var
                anotherVar: "our awesome",
                coolVar: "plugin!",
            };
            var options = $.extend(defaults, options);
            this.each(function() {
                ourString = myVar + " " + anotherVar + " " + coolVar;
            });
            return ourString;
    };
}) (jQuery);

We want our plugin to do a little more than return, “This is our awesome plugin!” so let’s come up with some functionality to build. For this exercise, let’s create a simple plugin that allows truncates a blob of text to a specified length while providing the user an option show/hide the rest of the text. Since the most common character length limitation on the Internet these days is Twitter’s 140 characters, we’ll use that mark in our example.

Taking what we know about the basic jQuery plugin structure, let’s create the foundation for our new plugin — slPlugin2:

(function($) {
    $.fn.slPlugin2 = function(options) {
 
        var defaults = {
            length: 140,
            moreLink: "read more",
            lessLink: "collapse",
            trailingText: "..."
        };
 
        var options = $.extend(defaults, options);
    };
})(jQuery);

As you can see, we’ve established four default variables:

• length: The length of the paragraph we want before we truncate the rest.
• moreLength: What we append to the paragraph when it is truncated. This will be the link the user clicks to expand the rest of the text.
• lessLink: What we append to the paragraph when it is expanded. This will be the link the user clicks to collapse the rest of the text.
• trailingText: The typical ellipses to append to the truncation.

In our jQuery plugin example from Part 1, we started our function with this.each(function() {, and for this example, we’re going to add a return for this to maintain chainability. By doing so, we’re able to manipulate the segment with methods. For example, if we started our function with this.each(function() {, we’d call it with this line:

$('#ourParagraph').slPlugin2();

If we start the function with return this.each(function() {, we have the freedom to add further manipulation:

$('#ourParagraph').slPlugin2().bind();

With such a simple change, we’re able to add method calls to make one massive dynamic function.

Let’s flesh out the actual function a little more. We’ll add a substantial bit of code in this step, but you should be able to follow along with the changes via the comments:

(function($) {
    $.fn.slPlugin2 = function(options) {
 
        var defaults = {
            length: 140, 
            moreLink: "read more",
            lessLink: "collapse",
            trailingText: "..."
        };
 
        var options = $.extend(defaults, options);
 
        // return this keyword for chainability
        return this.each(function() {
            var ourText = $(this);  // the element we want to manipulate
            var ourHtml = ourText.html(); //get the contents of ourText!
            // let's check if the contents are longer than we want
            if (ourHtml.length > options.length) {
                var truncSpot = ourHtml.indexOf(' ', options.length); // the location of the first space (so we don't truncate mid-word) where we will end our truncation.
 
   // make sure to ignore the first space IF the text starts with a space
   if (truncSpot != -1){
       // the part of the text that will not be truncated, starting from the beginning
       var firstText = ourHtml.substring(0, truncSpot);
 
       // the part of the text that will be truncated, minus the trailing space
       var secondText = ourHtml.substring(truncSpot, ourHtml.legnth -1);
                }
            }
        })
    };
})(jQuery);

Are you still with us? I know it seems like a lot to take in, but each piece is very straightforward. The firstText is the chunk of text that will be shown: The first 140 characters (or whatever length you define). The secondText is what will be truncated. We have two blobs of text, and now we need to make them work together:

(function($) {
    $.fn.slPlugin2 = function(options) {
 
        var defaults = {
            length: 140, 
            moreLink: "read more",
            lessLink: "read less",
            trailingText: "..."
        };
 
        var options = $.extend(defaults, options);
 
        // return this keyword for chainability
        return this.each(function() {
            var ourText = $(this);  // the element we want to manipulate
            var ourHtml = ourText.html(); //get the contents of ourText!
            // let's check if the contents are longer than we want
            if (ourHtml.length > options.length) {
                var truncSpot = ourHtml.indexOf(' ', options.length); // the location of the first space (so we don't truncate mid-word) where we will end our truncation.
 
   // make sure to ignore the first space IF the text starts with a space
   if (truncSpot != -1){
       // the part of the text that will not be truncated, starting from the beginning
       var firstText = ourHtml.substring(0, truncSpot);
 
       // the part of the text that will be truncated, minus the trailing space
       var secondText = ourHtml.substring(truncSpot, ourHtml.legnth -1);
 
       // perform our truncation on our container ourText, which is technically more of a "rewrite" of our paragraph, to our liking so we can modify how we please. It's basically saying: display the first blob then add our trailing text, then add our truncated part wrapped in span tags (to further modify)
       ourText.html(firstText + options.trailingText + '<span class="slPlugin2">' + secondText + '</span>');
 
       // but wait! The secondText isn't supposed to show until the user clicks "read more", right? Right! Hide it using the span tags we wrapped it in above.
       ourText.find('.slPlugin2').css("display", "none");
                }
            }
        })
    };
})(jQuery);

Our function now truncates text to the specified length, and we can call it from our page simply:

<script src="jquery.min.js"></script>
<script src="jquery.slPlugin2.js"></script>
<script type="text/javascript">
$(document).ready(function() {  
    $('#slText').slPlugin2();  
});
</script>

Out of all the ways to truncate text via jQuery, this has to be my favorite. It’s feature-rich while still being fairly easy to understand. As you might have noticed, we haven’t touched on the “read more” and “read less” links or the expanding/collapsing animations yet, but we’ll be covering those in Part 3 of this series. Between now and when Part 3 is published, I challenge you to think up how you’d add those features to this plugin as homework.

-Cassandra

With SoftLayer Object Storage Python Client set up and the SoftLayer Object Storage Backup script — slbackup.py — in hand, I had the tools I needed to build a solid backup infrastructure easily. On Linux.org, I contributed an article about how to perform MySQL backups with those resources, so the database piece is handled, but I also need to back up my web files, so I whipped up another quick bash script to run:

#!/bin/bash
 
# The path the backups will be dumped to
DUMP_DIR="/home/backups/"
 
# Path to the web files to be backed up
BACKUP_PATH="/var/www/sites /"
 
# Back up folder name (mmddyyyy)
BACKUP_DIR="`date +%m%d%Y`"
 
# Backup File Name
DUMP_FILE="`date +%m_%d_%Y_%H_%M_%S`_site_files"
 
# SL container name
CONTAINER="site_backups"
 
# Create backup dir if doesn't exist
if [ ! -d $DUMP_DIR$BACKUP_DIR ]; then
        mkdir -p $DUMP_DIR$BACKUP_DIR
fi
 
tar -zcvpf $DUMP_DIR$BACKUP_DIR/$DUMP_FILE.tar.gz $BACKUP_PATH
 
# Make sure the archive exists
if [ -f $DUMP_DIR$BACKUP_DIR/$DUMP_FILE.tar.gz ]; then
        /root/slbackup.py -s $DUMP_DIR$BACKUP_DIR/ -o "$CONTAINER" -r 30
 
        # Remove the backup stored locally
        rm -rf $DUMP_DIR$BACKUP_DIR
 
        # Success
        exit 0
else
        echo "$DUMP_DIR$BACKUP_DIR/$DUMP_FILE.tar.gz does not exist."
        exit 1
fi

It’s not the prettiest bash script, but it gets the job done. By tweaking a few variables, you can easily generate backups for any important directory of files and push them to your SoftLayer Object Storage account. If you want to change the retention time of your backups to be longer or shorter, you can change the 30 after the –r in the line below to the number of days you want to keep each backup:

/root/slbackup.py -s $DUMP_DIR$BACKUP_DIR/ -o "$CONTAINER" -r 30

I created a script for each website on my server, and I set a CRON (crontab –e) entry to run each one on Sundays staggered by 5 minutes:

5 1 * * 0  /root/bin/cron/CRON-site1.com_web_files > /dev/null
10 1 * * 0  /root/bin/cron/CRON-site2.com_web_files > /dev/null
15 1 * * 0  /root/bin/cron/CRON-site3.com_web_files > /dev/null

If you’re looking for an easy way to automate and solidify your backups, this little bit of code could make life easier on you. Had I taken the few minutes to put this script together prior to the attack I experienced at my previous host, I wouldn’t have lost any of my data. It’s easy to get lulled into “backup apathy” when you don’t need your backups, but just because nothing *has* happened to your data doesn’t mean nothing *can* happen to your data.

Take it from me … Be over-prepared and save yourself a lot of trouble.

-Ronald