Archive

Archives pour 10/2015

How Do I Save Iptables Rules or Settings

30/10/2015 Comments off

save iptables rulesI am using GUI tool to setup firewall rules for my home computer connected to ADSL (DSL/Cable) network. However, after reboot my rules are not saved. Is there any way I can save and load all firewall rules again?

You need to use the iptables-save command, which is used to dump the contents of an IP Table in easily parseable format to screen. Using I/O-redirection provided by your shell you can save iptables firewall rules to a file.

To restore iptables rules use the iptables-restore command. It is used to restore an IP Tables from data specified from file. Use I/O redirection provided by your shell to read from a file.

Examples: Saving and Restoring Iptables Rules

In this example, save current iptables firewall rules to a file called /root/dsl.fw, enter:
# iptables-save > /root/dsl.fw

To restore iptables rules, enter:
# iptables-restore < /root/dsl.fw

To restore rules automatically upon Linux system reboot add following command to your /etc/rc.local file, enter:
# vi /etc/rc.local

Append the line:
/sbin/iptables-restore < /root/dsl.fw

Save and close the file. Please note that under Red Hat enterprise Linux (RHEL) / CentOS / Fedora Linux you can use following commands to save and restore firewall rules. To Save the rules to /etc/sysconfig/iptables file:
# /etc/init.d/iptables save

To restore the rules from /etc/sysconfig/iptables file:
# /etc/init.d/iptables start

If you are using Debian / Ubuntu Linux open /etc/network/interfaces:
# vi /etc/network/interfaces

Append the line to eth0 section:
post-up iptables-restore
Close and save the file. Reboot the system.

Source: nixCraft

Categories: Réseau, Sécurité Tags: ,

Ubuntu Linux /etc/network/interfaces networking example

30/10/2015 Comments off

Source: nixCraft

Q. Can you explain how to setup network parameters such as IP address, subnet, dhcp etc using /etc/network/interfaces file?

A. /etc/network/interfaces file contains network interface configuration information for the both Ubuntu and Debian Linux. This is where you configure how your system is connected to the network.

Defining physical interfaces such as eth0

Lines beginning with the word « auto » are used to identify the physical interfaces to be brought up when ifup is run with the -a option. (This option is used by the system boot scripts.) Physical interface names should follow the word « auto » on the same line. There can be multiple « auto » stanzas. ifup brings the named inter faces up in the order listed. For example following example setup eth0 (first network interface card) with 192.168.1.5 IP address and gateway (router) to 192.168.1.254:

iface eth0 inet static
address 192.168.1.5
netmask 255.255.255.0
gateway 192.168.1.254

Setup interface to dhcp

To setup eth0 to dhcp, enter:
auto eth0
iface eth0 inet dhcp

Lire la suite…

How to Protect Yourself from NSA Attacks on 1024-bit DH

29/10/2015 Comments off

nsa attacksWhen NSA gets you worrying

In a post on Wednesday, researchers Alex Halderman and Nadia Heninger presented compelling research suggesting that the NSA has developed the capability to decrypt a large number of HTTPS, SSH, and VPN connections using an attack on common implementations of the Diffie-Hellman key exchange algorithm with 1024-bit primes. Earlier in the year, they were part of a research group that published a study of the Logjam attack, which leveraged overlooked and outdated code to enforce « export-grade » (downgraded, 512-bit) parameters for Diffie-Hellman. By performing a cost analysis of the algorithm with stronger 1024-bit parameters and comparing that with what we know of the NSA « black budget » (and reading between the lines of several leaked documents about NSA interception capabilities) they concluded that it’s likely NSA has been breaking 1024-bit Diffie-Hellman for some time now.

The good news is, in the time since this research was originally published, the major browser vendors (IE, Chrome, and Firefox) have removed support for 512-bit Diffie-Hellman, addressing the biggest vulnerability. However, 1024-bit Diffie-Hellman remains supported for the forseeable future despite its vulnerability to NSA surveillance. In this post, we present some practical tips to protect yourself from the surveillance machine, whether you’re using a web browser, an SSH client, or VPN software.

Disclaimer: This is not a complete guide, and not all software is covered.

Web Browser

To make sure you’re using the strongest crypto, you have to look at the encryption algorithms (or cipher suites) that your browser supports. There’s an excellent tool, How’s My SSL?, that will test your browser’s cipher suite support. The relevant area of the page is the bottom, Given Cipher Suites. You want to make sure that you don’t see the text « _DHE_ » in the list of ciphersuites – although the Elliptic Curve variant of Diffie-Hellman, represented by suites with « _ECDHE_ » is okay. It is important to note that there is a trade-off here: removing your clients support for « _DHE_ » ciphers will eliminate the risk of this attack, but it may also remove Forward Secrecy support altogether for some sites. Here’s how to remove those « _DHE_ » cipher suites if you still have them:

Firefox

(tested with 40.0.3)

Open a new tab, enter « about:config » into the location bar and hit the « Enter » key. If you get a warning page, click « I’ll be careful, I promise! » This will bring you to the Firefox configuration settings. In the search bar up top, type « .dhe_ » and hit the « Enter » key. This should result in two settings being displayed: « security.ssl3.dhe_rsa_aes_128_sha » and « security.ssl3.dhe_rsa_aes_256_sha ». Double-click both of them to change the value from « true » to « false ».

ff

Now, if you refresh the How’s My SSL page, the « _DHE_ » ciphersuites should be gone!

Lire la suite…

How to log in to MySQL server without password

29/10/2015 Comments off

mysql without passwordIn order to log in to a MySQL server, you can run mysql command along with your login credentials and server’s IP address as arguments. For example:

$ mysql -u $MYSQL_ROOT -p $MYSQL_PASS -h 192.168.10.1

However, besides the inconvenience of typing extra arguments, using plain-text login credentials in a command line like above is really not a secure way to access a MySQL server. In a multi-user Linux environment, what you type in command line can easily be revealed to others who happen to run ps on the same host at the same time.

MySQL offers a way for you to log in to MySQL server without password, by using an external MySQL configuration file. In Linux, there are two different kinds of MySQL configuration files: (1) /etc/my.cnf and (2) ~/.my.conf. While any system-wide MySQL configuration is defined in /etc/my.cnf, any user-specific MySQL configuration is stored in ~/.my.cnf. You can leverage ~/.my.cnf, to define your MySQL login credential in the file.

$ vi ~/.my.cnf
[client]
user=alice
password=alice_passwd
host=192.168.10.1

Make sure to have the configuration file readable to you only.

$ chmod 0600 ~/.my.cnf

Once ~/.my.cnf is created, simply typing mysql command will let you log in to 192.168.10.1 as alice, and you no longer need to provide login password separately.

Source: Xmodulo

How To Isolate Servers Within A Private Network Using Iptables

28/10/2015 Comments off

Source: DigitalOcean – Mitchell Anicas

Introduction

In this tutorial, we will teach you how to use a Iptables with shared private networking to simulate the network traffic isolation that a true private network can provide. We will also cover why you would want to do this, and provide an example of how to implement this in your own environment. The example should explain the concept well enough that you should be able to adapt the configuration to your own needs.

DigitalOcean’s private networking option grants a second networking interface to a VPS, which is only accessible to other VPSs in the same datacenter–which includes the VPSs of other customers in the same datacenter. This is known as shared private networking. This means that data sent over a VPS’s private interface does not leave the datacenter at all, and no billable bandwidth usage will be incurred.

At the time of this writing, DigitalOcean offers the private networking option for VPSs in the following data centers:

  • Amsterdam 2
  • New York 2
  • Singapore 1

Note: This tutorial covers IPv4 security. In Linux, IPv6 security is maintained separately from IPv4. For example, iptables only maintains firewall rules for IPv4 addresses but it has an IPv6 counterpart called ip6tables, which can be used to maintain firewall rules for IPv6 network addresses.

If your VPS is configured for IPv6, please remember to secure both your IPv4 and IPv6 network interfaces with the appropriate tools. For more information about IPv6 tools, refer to this guide: How To Configure Tools to Use IPv6 on a Linux VPS

Example Scenario

For our example, we will use the environment created by the following tutorial: How To Optimize WordPress Performance With MySQL Replication On Ubuntu 14.04.

Here is a diagram of what the environment looks like:

prereq_no_private

The example environment uses five VPSs (and iptables are not configured):

  • haproxy-www: Reverse proxy load balancer
  • wordpress-1: First application server
  • wordpress-2: Second application server
  • mysql-1: Master MySQL database server
  • mysql-2: Slave MySQL database server

If your setup doesn’t look like this, you should still be able to follow along. Also, if you would like to read up on setting up a VPS with private networking or iptables basics, here are a few links that you might find to be useful (this tutorial assumes you know the basics of iptables):

If you are already familiar with the concepts, and would like to see the iptables setup, feel free to skip to the Overview of Iptables Configuration section.

Our Goal

When we are finished with this tutorial, we should have an environment that looks something like the following diagram:

goal

All of the servers in the private network area can only be communicated with by other servers within this private network (the orange box). The load balancer will be accessible via the Internet and also be linked to the private network. The enforcement of this policy will be implemented via iptables on each server.

Note: To block traffic to your public interface, you can either disable your public interface or set up firewall rules to achieve a similar effect with Iptables. We will go with the firewall option because we can configure it block unwanted network traffic, while allowing our server to access the Internet when it initiates the connection (this is useful for things like downloading updates on the server).

How To Set Up a Firewall with UFW on Ubuntu 14.04

28/10/2015 Comments off

Source: DigitalOcean – Mitchell Anicas

Introduction

UFW, or Uncomplicated Firewall, is an interface to iptables that is geared towards simplifying the process of configuring a firewall. While iptables is a solid and flexible tool, it can be difficult for beginners to learn how to use it to properly configure a firewall. If you’re looking to get started securing your network, and you’re not sure which tool to use, UFW may be the right choice for you.

This tutorial will show you how to set up a firewall with UFW on Ubuntu 14.04.

Prerequisites

Before you start using this tutorial, you should have a separate, non-root superuser account—a user with sudo privileges—set up on your Ubuntu server. You can learn how to do this by completing at least steps 1-3 in the Initial Server Setup with Ubuntu 14.04 tutorial.

UFW is installed by default on Ubuntu. If it has been uninstalled for some reason, you can install it with apt-get:

sudo apt-get install ufw

Using IPv6 with UFW

If your Ubuntu server has IPv6 enabled, ensure that UFW is configured to support IPv6 so that it will manage firewall rules for IPv6 in addition to IPv4. To do this, open the UFW configuration with your favorite editor. We’ll use nano:

sudo nano /etc/default/ufw

Then make sure the value of « IPV6 » is to equal « yes ». It should look like this:

/etc/default/ufw excerpt
...
IPV6=yes
...

Save and quit. Hit Ctrl-X to exit the file, then Y to save the changes that you made, then ENTER to confirm the file name.

When UFW is enabled, it will be configured to write both IPv4 and IPv6 firewall rules.

This tutorial is written with IPv4 in mind, but will work fine for IPv6 as long as you enable it.

Check UFW Status and Rules

At any time, you can check the status of UFW with this command:

sudo ufw status verbose

By default, UFW is disabled so you should see something like this:

Output:
Status: inactive

If UFW is active, the output will say that it’s active, and it will list any rules that are set. For example, if the firewall is set to allow SSH (port 22) connections from anywhere, the output might look something like this:

Output:
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere

As such, use the status command if you ever need to check how UFW has configured the firewall.

Before enabling UFW, we will want to ensure that your firewall is configured to allow you to connect via SSH. Let’s start with setting the default policies.

Lire la suite…

Iptables Essentials: Common Firewall Rules and Commands

28/10/2015 Comments off

Source: DigitalOcean – Mitchell Anicas

Introduction

Iptables is the software firewall that is included with most Linux distributions by default. This cheat sheet-style guide provides a quick reference to iptables commands that will create firewall rules are useful in common, everyday scenarios. This includes iptables examples of allowing and blocking various services by port, network interface, and source IP address.

How To Use This Guide

  • If you are just getting started with configuring your iptables firewall, check out our introduction to iptables
  • Most of the rules that are described here assume that your iptables is set to DROP incoming traffic, through the default input policy, and you want to selectively allow traffic in
  • Use whichever subsequent sections are applicable to what you are trying to achieve. Most sections are not predicated on any other, so you can use the examples below independently
  • Use the Contents menu on the right side of this page (at wide page widths) or your browser’s find function to locate the sections you need
  • Copy and paste the command-line examples given, substituting the values in red with your own values

Keep in mind that the order of your rules matter. All of these iptables commands use the -A option to append the new rule to the end of a chain. If you want to put it somewhere else in the chain, you can use the -I option which allows you to specify the position of the new rule (or simply place it at the beginning of the chain by not specifying a rule number).

Note: When working with firewalls, take care not to lock yourself out of your own server by blocking SSH traffic (port 22, by default). If you lose access due to your firewall settings, you may need to connect to it via the console to fix your access. Once you are connected via the console, you can change your firewall rules to allow SSH access (or allow all traffic). If your saved firewall rules allow SSH access, another method is to reboot your server.

Remember that you can check your current iptables ruleset with sudo iptables -S and sudo iptables -L.

Let’s take a look at the iptables commands!

Lire la suite…

How To Implement a Basic Firewall Template with Iptables on Ubuntu 14.04

28/10/2015 Comments off

Introduction

Implementing a firewall is an important step in securing your server. A large part of that is deciding on the individual rules and policies that will enforce traffic restrictions to your network. Firewalls like iptables also allow you to have a say about the structural framework in which your rules are applied.

In this guide, we will construct a firewall that can be the basis for more complex rule sets. This firewall will focus primarily on providing reasonable defaults and establishing a framework that encourages easy extensibility. We will be demonstrating this on an Ubuntu 14.04 server.

Prerequisites

Before you begin, you should have a basic idea of the firewall policies you wish to implement. You can follow this guide to get a better idea of some of the things you should be thinking about.

In order to follow along, you will need to have access to an Ubuntu 14.04 server. We will be using a non-root user configured with sudo privileges throughout this guide. You can learn how to configure this type of user in our Ubuntu 14.04 initial server setup guide.

When you are finished, continue below.

Installing the Persistent Firewall Service

To get started, you will need to install the iptables-persistent package if you have not done so already. This will allow us to save our rule sets and have them automatically applied at boot:

sudo apt-get update
sudo apt-get install iptables-persistent

During the installation, you’ll be asked whether you want to save your current rules. Say « yes » here. We will be editing the generated rules files momentarily.

A Note About IPv6 in this Guide

Before we get started, we should talk briefly about IPv4 vs IPv6. The iptables command only handles IPv4 traffic. For IPv6 traffic, a separate companion tool called ip6tables is used. The rules are stored in separate tables and chains. For iptables-persistent, the IPv4 rules are written to and read from /etc/iptables/rules.v4 and the IPv6 rules are kept in /etc/iptables/rules.v6.

This guide assumes that you are not actively using IPv6 on your server. If your services do not leverage IPv6, it is safer to block access entirely, as we will be doing in this article.

Implementing the Basic Firewall Policy (The Quick Way)

For the sake of getting up and running as quickly as possible, we’ll show you how to edit the rules file directly to copy and paste the finished firewall policy. Afterwards, we will explain the general strategy and show you how these rules could be implemented using the iptables command instead of modifying the file.

Lire la suite…

How To Choose an Effective Firewall Policy to Secure your Servers

28/10/2015 Comments off

Source: DigitalOcean – Justin Ellingwood

Introduction

Using a firewall is as much about making intelligent policy decisions as it is about learning the syntax. Firewalls like iptables are capable of enforcing policies by interpreting rules set by the administrator. However, as an administrator, you need to know what types of rules make sense for your infrastructure.

While other guides focus on the commands needed to get up and running, in this guide, we will discuss some of the decisions you will have to make when implementing a firewall. These choices will affect how your firewall behaves, how locked down your server is, and how it will respond to various conditions that are likely to occur from time to time. We will be using iptables as an example to discuss specifics, but most of the actual decisions will be relevant regardless of the tools used.

Deciding on a Default Policy

When constructing a firewall, one of the fundamental decisions that you must make is the default policy. This determines what happens when traffic is not matched by any other rules. By default, a firewall can either accept any traffic unmatched by previous rules, or deny that traffic.

Default Drop vs Default Accept

A default policy of « accept » means that any unmatched traffic is allowed to enter the server. This is generally not advised because it means that, effectively, you will be maintaining a black list. Black lists are difficult to manage because you must anticipate and block every type of unwanted traffic explicitly. This can lead to maintenance headaches and is generally prone to mistakes, mis-configurations, and unanticipated holes in the established policy.

The alternative is a default policy of « drop ». This means that any traffic not matched by an explicit rule will not be allowed. This is akin to a white list ACL. Each and every service must be explicitly allowed, which might seem like a significant amount of research and work at first. However, this means that your policy tends towards security and that you know exactly what is permitted to receive traffic on your server.

Basically the choice comes down to a tendency towards security by default or reachable services out-of-the-box. While it may be tempting to implement a firewall that leans towards service availability, it is almost always a better idea to block traffic unless explicitly allowed.

Default Drop Policy vs Final Drop Rule

The above choice of a default drop policy leads to another subtle decision. With iptables and other similar firewalls, the default policy can be set using the built-in policy functionality of the firewall, or implemented by adding a catch-all drop rule at the end of the list of rules.

The distinction between these two methods lies in what happens if the firewall rules are flushed.

If your firewall’s built-in policy function is set to « drop » and your firewall rules are ever flushed (reset), or if certain matching rules are removed, your services will instantly become inaccessible remotely. This is often a good idea when setting policy for non-critical services so that your server is not exposed to malicious traffic if the rules are removed.

The downside to this approach is that your services will be completely unavailable to your clients until you re-establish permissive rules. You could even potentially lock yourself out of the server if you do not have local or out-of-band access to skirt the issue (DigitalOcean servers are accessible regardless of network settings by using the « Console Access » button located in the « Access » portion of your Droplet’s page in the control panel). If your firewall flush is intentional, this can be avoided by simply switching the default policy to « accept » just prior to resetting the rules.

The alternative to setting a drop policy using the built-in policy functionality is to set your firewall’s default policy to « accept » and then implement a « drop » policy with regular rules. You can add a normal firewall rule at the end of your chain that matches and denies all remaining unmatched traffic.

In this case, if your firewall rules are flushed, your services will be accessible but unprotected. Depending on your options for local or alternative access, this might be a necessary evil in order to ensure that you can re-enter your server if the rules are flushed. If you decide to use this option, you must ensure that the catch-all rule always remains the last rule in your rule set.

Lire la suite…

How To Set Up an Iptables Firewall to Protect Traffic Between your Servers

28/10/2015 Comments off

Source DigitalOcean – Justin Ellingwood

Introduction

Deploying discrete components in your application setup onto different nodes is a common way to decrease load and begin scaling horizontally. A typical example is configuring a database on a separate server from your application. While there are a great number of advantages with this setup, connecting over a network involves a new set of security concerns.

In this guide, we’ll demonstrate how to set up a simple firewall on each of your servers in a distributed setup. We will configure our policy to allow legitimate traffic between our components while denying other traffic.

For the demonstration in this guide, we’ll be using two Ubuntu 14.04 servers. One will have a WordPress instance served with Nginx and the other will host the MySQL database for the application. Although we will be using this setup as an example, you should be able to extrapolate the techniques involved to fit your own server requirements.

Prerequisites

To get started, you will have to have two fresh Ubuntu 14.04 servers. Add a regular user account with sudo privileges on each. To learn how to do this correctly, follow our Ubuntu 14.04 initial server setup guide.

The application setup we will be securing is based on this guide. If you’d like to follow along, set up your application and database servers as indicated by that tutorial.

Setting Up a Basic Firewall

We will begin by implementing a baseline firewall configuration for each of our servers. The policy that we will be implementing takes a security-first approach. We will be locking down almost everything other than SSH traffic and then poking holes in the firewall for our specific application.

The firewall in this guide provides the basic setup that we need. Install the iptables-persistent package and paste the basic rules into the /etc/iptables/rules.v4 file:

sudo apt-get update
sudo apt-get install iptables-persistent
sudo nano /etc/iptables/rules.v4
/etc/iptables/rules.v4
*filter
# Allow all outgoing, but drop incoming and forwarding packets by default
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

# Custom per-protocol chains
:UDP - [0:0]
:TCP - [0:0]
:ICMP - [0:0]

# Acceptable UDP traffic

# Acceptable TCP traffic
-A TCP -p tcp --dport 22 -j ACCEPT

# Acceptable ICMP traffic

# Boilerplate acceptance policy
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -i lo -j ACCEPT

# Drop invalid packets
-A INPUT -m conntrack --ctstate INVALID -j DROP

# Pass traffic to protocol-specific chains
## Only allow new connections (established and related should already be handled)
## For TCP, additionally only allow new SYN packets since that is the only valid
## method for establishing a new TCP connection
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP
-A INPUT -p tcp --syn -m conntrack --ctstate NEW -j TCP
-A INPUT -p icmp -m conntrack --ctstate NEW -j ICMP

# Reject anything that's fallen through to this point
## Try to be protocol-specific w/ rejection message
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT --reject-with icmp-proto-unreachable

# Commit the changes
COMMIT

*raw
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT

*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT

*security
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT

*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT

If you are implementing this in a live environment do not reload your firewall rules yet. Loading the basic rule set outlined here will immediately drop the connection between your application and database server. We will need to adjust the rules to reflect our operational needs before reloading.

Lire la suite…