We manage ports, and hence differing types of network traffic, primarily with a firewall. That allows or denies data packets depending on the port to which they navigate.

If you've not already, read Overall Risk to a Site or Server, paying particular attention to the Access & Authentication Server Issues section. This topic may then make more sense.

FTP packets, for example, navigate to the server's port 21. The web service queues up for port 80. Secure web traffic – https rather than http – heads for port 443. And so on. Regardless of whether or not, say, an FTP server is installed, if port 21 is closed then traffic is denied.

So here's the problem …

Say you allow an FTP service that has a known vulnerability. Along comes a hacker, exploits the weakness and gains server access. Similarly, every service listening on every port is a potential shoo-in for a hacker. In most cases, we simply deny access by disabling the service and closing its port. Many of us, after all, only ever need web and administration ports.

So, to recap: any server port, including those for direct server access or via a GUI like cPanel, but equally using the web port 80 and secure web port 443, could potentially be used to gain malicious entry if the corresponding service can be exploited or if a hacker can glean your credentials.

This highly prevalent kind of memory attack – where system RAM is used to try to force an opening – is assisted by poorly written software and utilizes a scrap of code that's often introduced through a web form field, in that case using port 80 or 443 for a ‘secure' page, or via a port-listening service, such as that dodgy FTP daemon mentioned previously, which sits on port 21.

Take a simplistic example …

You've got a slug of RAM in the box and, on submitting data to a form, that queues up in a memory space – a buffer – where it awaits processing. Now, imagine someone submits malicious code that's longer, containing more characters, than the programmer allowed for. Again, the data queues in its buffer but, being too long, it overflows, overwriting the form's expected command and having itself executed instead.

… As with oh-so-many attacks, this manipulation is possible because the code's programmer hasn't ensured proper user input validation. The result could be anything from a crashed box to the hacker gaining a foothold into the machine.

As we'll find in wpCop's Hacking section, these attacks are kiddie-play for known exploits. Using a couple of choice tools, for example, a hacker would scan to find a buggy service and, having Googled an attack that fits, delivers a compromising payload. Supposing there is some vulnerability, really, the attack's a piece of cake. Balls!

So what can we do?

General security good practice and discipline will protect us against known exploits.

So far as those dreaded zero days are concerned though, frankly, we can only hope that the kind of multi-layered defense in depth that wpCop chats up will keep us safe.

… And this should explain why we should aspire to total security but, really, we can never achieve it.

Many in the blogging community will be aware of the Digg of death, a nice problem to have where a post's popularity, duly Digged, leads to a sudden rush of traffic that, if the web host doesn't intervene and suspend the site, can overwhelm server resources and even crash the box. What's happened here is an unintentional denial of service, this time via the web service on port 80.

As with most attacks, DoS attacks come in many forms but the malicious purpose, often concentrated at big sites or networks and sometimes to gain a commercial or political advantage, is generally to flood services and, ultimately, to disable HTTP. As wpCop touched on in Who Are the Hackers?, the distributed variety are most powerful. They synchronize the combined processing power of a zombie network – basically a bunch of machines, often called a botnet – against the target.

So hold on, is this an access issue?

Well, yes, because a server port is being used to assist an attack.

At first it's not easy wrapping your head around this stuff but, forget the jargon for a minute, the principle is simple enough …

… Hacking WordPress could be direct, some loopy kid trying to inject nefarious code by using the web browser's address bar (and port 80 or 443), for example, or it could be indirect, as here, with the underlying server pummeled with useless traffic, choking the box and crashing your sites.

Brute force attacks, on the other hand, run through alphanumeric and special character combinations against a login function, such as for a control panel or the WordPress Dashboard, until the password is cracked. They're helped immensely when the username is known, so there's a hint not to use that regular old WordPress chestnut, the admin user.

Brute forcing can be time-consuming, but can also be coordinated between multiple zombies, warp-speeding the process with the combined processing power. Dictionary attacks, meanwhile, throw A-Z word lists against the password and hybrid attacks morph brute force and dictionary techniques to crack naïve keys such as pa55worD.

Oops, hidden content alert!

This is not the same as XSS, but there are similarities, the main one being that, again, a blameless if poorly built site is crossed with malicious code to cause an effect. A user logs into your site and, in the regular way, is granted a session cookie. The user surfs some pages, one of them having been decorated with some imaginative code from an attacker which the user's browser correctly downloads. Because that script said to do something to your site and because the unfortunate user hadn't logged out of your site, relinquishing the cookie, the action is authorized by the user's browser.

What may happen to your site, for example, depends on the user's privileges so could vary from a password change or data theft to a nice new theme effect called digital soup.

Wrapping up on access issues

You may have noticed, this concern on this page – and for that matter across all of wpCop – boils down to one thing:-

Access.

And more broadly, to restricting access.

OK, so unsecured access is a prime risk factor so let's re-spin the key concerns from this section:

wpCop, vpsBible & Guvnr

wpCop is brought to you by Olly Connelly who also helps Linux noobs set up web servers at vpsBible.com. Olly’s blog, Guvnr.com, doubles as the news vehicle for wpCop & vpsBible. The forums offer friendly support.