Author: Brett Haines

Update on VENOM (CVE-2015-3456) QEMU Vulnerability

Brett Haines May 13, 2015 by under Announcements 0 Comments

Earlier today, a security vulnerability, CVE-2015-3456 (VENOM), was publicly announced. This vulnerability affects the widely used KVM/QEMU virtualization hypervisor platform that we use to power our SSD cloud hosting servers.

We are rolling out the necessary security patches to address this vulnerability to all applicable infrastructure. In order to ensure that the patches are effective at resolving the vulnerability, you may see a very brief interruption in service (a few seconds) while your Cloud Server is switched to run on the updated version of our infrastructure.

A very small percentage of Cloud Servers may require a reboot to complete this process. If this is necessary for one of your cloud hosting servers, you will be contacted by our support team so this can be done with as little inconvenience as possible.

We will keep you posted on progress.

 

UPDATE 05/14/15: Atlantic.Net has successfully mitigated the VENOM vulnerability in our USA-West-1 (San Francisco), USA-Central-1 (Dallas), USA-East-2 (New York) and Canada-East-1 (Toronto) Cloud locations.  USA-East-1 (Orlando) is almost complete, however, there is a small percentage of Cloud Servers that will need to be manually rebooted.  If you are one of the few affected, an email will be sent to you shortly with further instructions.

UPDATE 05/14/15: Atlantic.Net sent notification to the small percentage of cloud server hosting that needed to be manually rebooted in USA-East-1 (Orlando).  Those that were notified have until 11:59 pm ET on May 15, 2015 to power cycle their Cloud Servers per the instructions provided in the email. If they have not done so by the previously mentioned time, we will shutdown their Cloud Servers and power them back on.

UPDATE 05/16/15: Atlantic.Net has now successfully mitigated the VENOM vulnerability in USA-East-1 (Orlando), and as previously noted, all other Cloud locations.

You can read more about VENOM here.

If you have any further questions, please contact our Support team.


How to : Linux or FreeBSD Basic Shell Commands – man, echo, cat, ls, cp, rm, mkdir, cd, clear, reset and exit

Brett Haines May 8, 2015 by under Cloud Hosting 0 Comments

Introduction

This quick tutorial is for developers or system administrators new to Linux or FreeBSD. This is a quick run through of basic commands that you will need to know to get going setting up and administrating a Linux or FreeBSD server. We will review 9 of the most frequently used commands in the shell: ls, cp, mkdir, rm, cd, cat, echo, exit, and man. This tutorial is for beginners and someone who has never used a shell before.

Prerequisites:

You will need a server with Linux or FreeBSD installed. If you don’t have one, you can get an affordable cloud server from Atlantic.Net. In addition, you will need to be logged into the server and at the shell prompt. Typically, this involves using a ssh client to connect and login to the server. We will start assuming you are logged into the server. We will be using Ubuntu Linux for this demonstration, but any Linux variant will do.

Read More


How to: Linux General – IPTables in General

Brett Haines February 5, 2015 by under Cloud Hosting 0 Comments
Verified and Tested 02/16/2015

Introduction

IPTables is a firewall that is either installed already or can be installed onto any of our Linux Distributions for our Cloud service. IPTables is used to configure packet filter rule chains and enforce the built-in or user-defined rule chains for your server. IPTables has main components to it involving Tables, Targets, and Options.

 

Tables

Tables in IPTables are used to separate packets into their matching category. The table sorting depends on modules that your system has loaded and where the packet matches. Right now, there are five distinct tables for use. They are filter, nat, mangle, raw, and security. For the most part, basic IPTables use will just involve the filter table. If you are doing internal routing or more complicated networking, you will focus on using the other tables as well. This page will be going over only filter type rules.

filter – This is the basic table as was mentioned and is typically the defaulted table. This table consists of the rule chains ACCEPT, FORWARD, OUTPUT.

nat – This table is used for packets that will be creating new connections. Like routing a public IP to a private IP. It consists of the rule chains PREROUTING, POSTROUTING, and OUTPUT.

mangle – This table is used for altering the way packets are handled. It consists of the rule chains INPUT, FORWARD, OUTPUT, PREROUTING, and POSTROUTING.

raw – This table is used for configuring exemptions from connection tracking with the NOTRACK target. It consists of PREROUTING and OUTPUT.

security – This table is for MAC (Mandatory Access Control) rules. It consists of INPUT, FORWARD, and OUTPUT

 

Targets

Targets are defined as the value to the rule chain you are creating. They can contain the values ACCEPT, DROP, QUEUE, or RETURN. These values tell the rule how to proceed with a packet that matches the rule.

ACCEPT – This is pretty straightforward and means to allow the packet through to your server.

DROP – Also pretty straightforward in that it means to deny the packet through to your server.

QUEUE – This target means to pass the packet into userspace so a user may define what to do with it.

RETURN – This target stops the processing of the current chain and tells it to resume processing at the previous chain’s next rule.

 

Options

There is a ton of options available for IPTables use. We will list some of the more common ones you will see.

-A, –append – Appends your rule to a chain.

-L, –list [chain] – This will list all the rules in the chain that you specify. If you don’t supply a chain, it will list all the rules.

-F, –flush [chain] – This will remove any chains and rules in the given chain. If you don’t provide a chain, it will remove all rules and chains currently running.

-h – This provides an output of all the options that you may do.

-p, –protocol protocol – This is the packets protocol. These can be TCP, UDP, UDPlite, ICMP, ESP, AH, SCTP, all, number equivalents to these, or begin with a ! to invert the protocol check.

-s, –source address[/mask][,…] – A source address. Can be the IP, IP range via netmask, network name, or hostname.

-d, –destination address[/mask][,…] – A destination address. Same format as –s.

-m, –match match – An extension module that tests for a property.

–dport[s] [port#][,…] – A port you are looking for. –dports is used to specify more than one which are separated by comma. When using –dports make sure to set -m as multiport. To specify a port range, use a : such as 1000:1100 which would be ports 1000-1100.

-j, –jump target – This is the option that allows you to specify the target for your rule.

-i, –in-interface name – Specifies an interface that the packet should be received on.

-o, –out-interface name – Specifies an interface that the packet will leave on.

-v, –verbose – It makes the list command show interface names, rule options, and any masks. Also shows packet and byte counters.

 

Usage and Examples

Here we will show some basic usage and examples. A typical IPTables rule will tend to follow these formats. Make sure all your rules are done above COMMIT as this is used to end a table. Rules for another table will follow their own end COMMIT.

For allow established traffic:

-A INPUT -m match –state ESTABLISHED,RELATED -j ACCEPT

In use this would be:

-A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT

For allowing specific port[s].

-A INPUT -p protocol -m match –dport port -j ACCEPT

In use, an example would be:

-A INPUT -p tcp -m tcp –dport 80 -j ACCEPT

Or

-A INPUT -p tcp -m multiport –dports 80,443 -j ACCEPT

This would allow web traffic through on port 80 (in the second example, port 443 too.) That’s not all you can do. You can also add the following like in the below examples.

-A INPUT -s IPADDR -p tcp -m tcp –dport 22 -j ACCEPT

This allows only the IP address (IPADDR) that you specify through on your port 22 (ssh.) You can use any form of IP addresses that the -s option allows.

-A INPUT -p tcp -m tcp –dport 22 -j DROP

Following in step with the above example, this will drop any and all TCP traffic traveling to you SSH port. It is a good rule of thumb to always have any DROP rules at the very bottom of your list of ACCEPT rules in the chain. For example:

-A INPUT … -j ACCEPT

-A INPUT … -j ACCEPT

-A INPUT … -j ACCEPT

-A INPUT … -j DROP

-A FORWARD … -j ACCEPT

-A FORWARD … -j ACCEPT

-A FORWARD … -j ACCEPT

-A FORWARD … -j DROP

-A OUTPUT … -j ACCEPT

-A OUTPUT … -j ACCEPT

-A OUTPUT … -j ACCEPT

-A OUTPUT … -j DROP

You can also define the targets (like ACCEPT or DROP) up at the top of your IPTables for default behavior. When it’s a new install of IPTables, you always see the default behavior (defined at the top where it lists INPUT, FORWARD, and OUTPUT) as ACCEPT. A good rule of thumb for security is to change it to DROP and only make rules for the ports or traffic that you want to allow. Only change it though if you are sure you have made the exceptions you need.

Also at the top of a table, you can define your own targets. Let’s say you have the following at the top of your IPTables:

*filter

:INPUT DROP [0:0]

:FORWARD DROP [0:0]

:OUTPUT DROP [0:0]

COMMIT

Now, as we have blocked everything, let’s start with adding our own targets like:

*filter

:INPUT DROP [0:0]

:FORWARD DROP [0:0]

:OUTPUT DROP [0:0]

:APP – [0:0]

:MyNewTarget – [0:0]

COMMIT

Now you can create a custom type rule chain like the below.

*filter

:INPUT DROP [0:0]

:FORWARD DROP [0:0]

:OUTPUT DROP [0:0]

:APP – [0:0]

:MyNewTarget – [0:0]

 

-A APP -p tcp -m multiport –dports 30:40,50:80 -j ACCEPT

-A INPUT -s IPADDR -j MyNewTarget

 

-A MyNewTarget -j APP

COMMIT

Now what we have done in the above is create new targets, APP and MyNewTarget and assign to them options and targets. What the last rule (above COMMIT) does, is if the connection comes from your source IP and is attempting to hit ports 30-40 or 50-80, allow it through! It’s all defined in the chain above. This level of customization isn’t truly needed unless you are using multiple hosts or using ports you find yourself repeating and want more of a shorthand or “shortcut” to writing out rules. For example, any new rule you need coming from that source IP, you can now just use MyNewTarget.

All in all, IPTables provides a lot of customization of rules and allows you to handle how your server handles incoming, outgoing, and internal traffic. Some rules can be confusing and hard to follow, but there is no doubt to the helpfulness they provide to server stability.


New York, NY

100 Delawanna Ave, Suite 1

Clifton, NJ 07014

United States

Dallas, TX

2323 Bryan Street,

Dallas, Texas 75201

United States

San Francisco, CA

2820 Northwestern Pkwy,

Santa Clara, CA 95051

United States

Orlando, FL

440 W Kennedy Blvd, Suite 3

Orlando, FL 32810

United States

London, UK

14 Liverpool Road, Slough,

Berkshire SL1 4QZ

United Kingdom

Toronto, Canada

20 Pullman Ct, Scarborough,

Ontario M1X 1E4

Canada

Resources

We use cookies for advertising, social media and analytics purposes. Read about how we use cookies in our updated Privacy Policy. If you continue to use this site, you consent to our use of cookies and our Privacy Policy.