Archive

Articles taggués ‘CentOS’

How to configure a syslog server with rsyslog on Linux

04/03/2016 Comments off

rsyslog linuxA syslog server represents a central log monitoring point on a network, to which all kinds of devices including Linux or Windows servers, routers, switches or any other hosts can send their logs over network. By setting up a syslog server, you can filter and consolidate logs from different hosts and devices into a single location, so that you can view and archive important log messages more easily.

On most Linux distributions, rsyslog is the standard syslog daemon that comes pre-installed. Configured in a client/server architecture, rsyslog can play both roles; as a syslog server rsyslog can gather logs from other devices, and as a syslog client, rsyslog can transmit its internal logs to a remote syslog server.

In this tutorial, we cover how to configure a centralized syslog server using rsyslog on Linux. Before we go into the details, it is instructive to go over syslog standard first.

Basic of Syslog Standard

When logs are collected with syslog mechanism, three important things must be taken into consideration:

  • Facility level: what type of processes to monitor
  • Severity (priority) level: what type of log messages to collect
  • Destination: where to send or record log messages

Let’s take a look at how the configuration is defined in more detail.

The facility levels define a way to categorize internal system processes. Some of the common standard facilities in Linux are:

  • auth: messages related to authentication (login)
  • cron: messages related to scheduled processes or applications
  • daemon: messages related to daemons (internal servers)
  • kernel: messages related to the kernel
  • mail: messages related to internal mail servers
  • syslog: messages related to the syslog daemon itself
  • lpr: messages related to print servers
  • local0 – local7: messages defined by user (local7 is usually used by Cisco and Windows servers)

The severity (priority) levels are standardized, and defined by using standard abbreviation and an assigned number with number 7 being the highest level of all. These levels are:

  • emerg: Emergency – 0
  • alert: Alerts – 1
  • crit: Critical – 2
  • err: Errors – 3
  • warn: Warnings – 4
  • notice: Notification – 5
  • info: Information – 6
  • debug: Debugging – 7

Finally, the destination statement enforces a syslog client to perform one of three following tasks: (1) save log messages on a local file, (2) route them to a remote syslog server over TCP/UDP, or (3) send them to stdout such as a console.

In rsyslog, syslog configuration is structured based on the following schema.

[facility-level].[severity-level]  [destination]

Lire la suite…

Debian / Ubuntu / CentOs – Block DDOS attacks with No More DDOS (formerly : DDoS Deflate)

22/01/2016 Comments off

If you arrive on this page, is that you have already received a DDoS attack on your server or you want to protect it before this attack happens on your server.
In this tutorial, we will install « No More DDoS » (replacing DDoS Deflate that is no longer maintained by its author) that lets you easily protect you against small DDoS attacks.

This script is available in 2 versions :

  1. the Debian version, compatible with : Debian 6/7/8, Ubuntu Server 13.10, Ubuntu Server 14.04, Linux Mint 17 and distributions based on Debian.
  2. the CentOs version, compatible with : CentOs 6/7, RHEL 6/7 (à venir dans la version 2.0), Fedora 20 (coming in version 2.0), and distributions based on CentOs.
  1. Install No More DDoS
  2. Configure No More DDoS
  3. No More DDoS GUI
  4. Update No More DDoS
  5. Uninstall No More DDoS

1. Install No More DDoS

To install « No More DDoS for Debian« , use the following command :

wget -O- https://raw.githubusercontent.com/stylersnico/nmd/master/debian/install.sh | sh

To install »No More DDoS for CentOS 7 » use the following command :

wget -O- https://raw.githubusercontent.com/stylersnico/nmd/master/centos/install.sh | sh

2. Configurer No More DDoS

To configure No More DDoS, edit the « /usr/local/nmd/conf.d/agent.conf » file :

vim  /usr/local/nmd/conf.d/agent.conf

In this file, you can edit the following information :

  • FREQ : Interval time between 2 launches of the script. By default, this script is run once per minute.
  • NO_OF_CONNECTIONS : Corresponds to the maximum number of established connections to an IP address. If an IP address has more than 500 connections established on your server, this IP will be banned.
  • APF_BAN : By default, the script blocks IP addresses in the firewall with iptables (APF_BAN=0). To use « APF », specify 1 (APF_BAN=1).
  • EMAIL_TO : If you wish to be notified when blocking a DDoS attack, enter your email address at this line. If you leave this empty, then, no e-mail will be sent.
  • BAN_PERIOD : Period during an IP address is blocked. Default : 3600 seconds = 1 hour.

Lire la suite…

Securing your server with iptables

23/12/2015 Comments off

Securing your server with iptables

securing your server linuxIn the Getting Started guide, you learned how to deploy a Linux distribution, boot your Linode and perform some basic administrative tasks. Now it’s time to harden your Linode to protect it from unauthorized access.

Update Your System–Frequently

Keeping your software up to date is the single biggest security precaution you can take for any operating system–be it desktop, mobile or server. Software updates frequently contain patches ranging from critical vulnerabilities to minor bug fixes, and many software vulnerabilities are actually patched by the time they become public.

Automatic Security Updates

There are opposing arguments for and against automatic updates on servers. Nonetheless, CentOS, Debian, Fedora and Ubuntu can be automatically updated to various extents. Fedora’s Wiki has a good breakdown of the pros and cons, but if you limit updates to those for security issues, the risk of using automatic updates will be minimal.

The practicality of automatic updates must be something which you judge for yourself because it comes down to what you do with your Linode. Bear in mind that automatic updates apply only to packages sourced from repositories, not self-compiled applications. You may find it worthwhile to have a test environment which replicates your production server. Updates can be applied there and reviewed for issues before being applied to the live environment.

Add a Limited User Account

Up to this point, you have accessing your Linode as the root user. The concern here is that roothas unlimited privileges and can execute any command–even one that could accidentally break your server. For this reason and others, we recommend creating a limited user account and using that at all times. Administrative tasks will be done using sudo to temporarily elevate your limited user’s privileges so you can administer your server without logging in as root.

To add a new user, log in to your Linode via SSH.

CentOS / Fedora

  1. Create the user, replacing example_user with your desired username, and assign a password:
    useradd example_user && passwd example_user
  2. Add the user to the wheel group for sudo privileges:
    usermod -aG wheel example_user

Debian / Ubuntu

  1. Create the user, replacing example_user with your desired username. You’ll then be asked to assign the user a password.
    adduser example_user
  2. Add the user to the sudo group so you’ll have administrative privileges:
    adduser example_user sudo

With your new user assigned, disconnect from your Linode as root:

exit

Log back in to your Linode as your new user. Replace example_user with your username, and the example IP address with your Linode’s IP address:

ssh example_user@203.0.113.0

Now you can administer your Linode from your new user account instead of root. Superuser commands can now be prefaced with sudo; for example, sudo iptables -L. Nearly all superuser commands can be executed with sudo, and those commands will be logged to /var/log/auth.log.

Lire la suite…