SYN Flooding using SCAPY and Prevention using iptables

DoS (Denial of Service) attacks against Web services make them unavailable for legitimate users, affecting the website owner’s potential business. These involve intentional consumption of network, CPU and memory resources. In this article, I will demonstrate how to do a SYN flood using the SCAPY framework, along with other preventive measures.

Over time, DoS attacks have become more complicated, concealing malicious client requests as legitimate ones. Also, a distributed approach, the DDoS (Distributed Denial of Service) is now being adopted, which involves generating multiple requests to create a flood scenario. One type of DDoS flood attack is the TCP SYN queue flood.
A SYN queue flood attack takes advantage of the TCP protocol’s “three-way handshake”. A client sends a TCP SYN (S flag) packet to begin a connection to the server. The target server replies with a TCP SYN-ACK (SA flag) packet, but the client does not respond to the SYN-ACK, leaving the TCP connection “half-open”. In normal operation, the client should send an ACK (a flag) packet followed by the data to be transferred, or an RST reply to reset the connection. On the target server, the connection is kept open, in a “SYN_RECV” state, as the ACK packet may have been lost due to network problems.

How to Fix Nf_conntrack Table Full Dropping Packet

Issue

Packet drops on this system for connections using ip_conntrack or nf_conntrack. Following messages seen in /var/log/kern on the centos nodes when one of the instances drops packets:

$ tail -f /var/log/kern
Jul  4 03:47:16 centos kernel: : nf_conntrack: table full, dropping packet
Jul  4 03:47:16 centos kernel: : nf_conntrack: table full, dropping packet

This can happen when you are being attacked, or is also very likely to happen on a busy server even if there is no malicious activity.

NOTE: By default, CentOS will set this maximum to 65,536 connections. This is enough for lightly loaded servers, but can easily be exhausted on heavy traffic servers.

How to Fix

Nginx: 24: Too Many Open Files Error And Solution

How do I fix this problem under CentOS / RHEL / Fedora Linux or UNIX like operating systems?

Linux / UNIX sets soft and hard limit for the number of file handles and open files. You can use ulimit command to view those limitations:
su - nginx
To see the hard and soft values, issue the command as follows:
ulimit -Hn
ulimit -Sn

Increase Open FD Limit at Linux OS Level

Your operating system set limits on how many files can be opened by nginx server. You can easily fix this problem by setting or increasing system open file limits under Linux. Edit file /etc/sysctl.conf, enter:
# vi /etc/sysctl.conf
Append / modify the following line:
fs.file-max = 70000
Save and close the file. Edit /etc/security/limits.conf, enter:
# vi /etc/security/limits.conf
Set soft and hard limit for all users or nginx user as follows:

nginx       soft    nofile   10000
nginx       hard    nofile  30000

Save and close the file. Finally, reload the changes with sysctl command:
# sysctl -p

yum, rpm and duplicate versions

Apparently, when doing "yum update", and it fails miserably, you can end up with duplicate versions of packages in the RPM database. This seems harmless, but is annoying. yum provides a tool to check for this, but I was not able to find anything that would automatically repair it. So here's a little tip:

$ yum check duplicates | awk '/is a duplicate/ {print $6}' > /tmp/DUPES
$ yum remove `cat /tmp/DUPES`

 Of course, before you remove the dupes, make sure to examine the tmp file (/tmp/DUPES) and make sure it looks ok.
Update:
There seems to be a command to do this, package-cleanup has an option for it. E.g.

$ package-cleanup --cleandupes

However, testing this command on a second box having the same problem gave bad results, it seems to have uninstalled the "real" packages too.

Hệ điều hành Centos 7 – Có gì mới và khác so với Centos 6 – Phần 2 – Systemd

Có thể nói đây là sự thay đổi lớn trong  Centos 7. Trước tiên ta tìm hiểu các kỹ thuật cũ về hệ thống khởi động trên các phiên bản trước của Centos:

+ init – là process đầu tiên được load và sẽ nằm ở đó cho đến khi hệ thống (họ nhà Red Hat, Centos ) shutdown. Múc đích của nó là sử dụng các run levels để quyết định daemons nào được start và tương tác để điều khiển chúng. Tuy nhiên điểm cố hữu ” chết người” của init là ở chỗ nó khởi động các process theo thứ tự lần lượt, các tác vụ chỉ được khởi động khi tác vụ trước đó đã hoàn thành. Vì thế sẽ mất nhiều thời gian hơn và nếu một tác vụ bị failed, quá trình khởi động sẽ dừng lại ở đó cho đến khi nó tìm được cách xử lý.
+ Upstart – là sự thay thế cho init, chủ yếu sử dụng trên Ubuntu và dành cho mục đích khởi động các process không đồng thời, điều này làm tăng tốc độ boot và mức ổn định của hệ thống.

Hệ điều hành Centos 7 – Có gì mới và khác so với Centos 6 – Phần 1

Centos 7 đã ra đời được gần 1 năm nay nhưng  chưa phổ biến. Có lẽ vì người làm webhosting, máy chủ, hay system admin vẫn đang quen với Centos 6 và cũng là để thời gian cho Centos 7 được ổn định và hoàn thiện dần, tương thích với các ứng dụng phổ biến ngày nay như Cloud linux, các phần mềm quản trị webhosting, system như Cpanel hay Direct Admin.

Có thể nói, Centos 7 đã tạo ra một kiến trúc xử lý tương đối mới và khác lạ so với những thay đổi từ Centos 5 lên Centos 6. mô tả những điểm mới khác biệt trong Centos 7 để người dùng cùng nhìn nhận đó là:

1. Hệ thống khởi động mới systemd thay thế initd.

2. firewalld mới vẫn trên nền netfilter như iptables nhưng thêm nhiều tính năng tương tác để xử lý module firewall trong kernel.

3. Boot loader mới GRUB2 hỗ trợ nhiều scripts cũng như nhiều tùy chọn phần cứng trên các mainboard đời mới.

4. Hệ thống filesystem mới XFS hỗ trợ cho lưu trữ lớn, thời gian format siêu nhanh, tích hợp snapshot và cho phép dump trực tiếp mà ko cần umont như EXT.

5. Giao diện desktop GNOME 3

Understanding Hadoop Clusters and the Network

This article is Part 1 in series that will take a closer look at the architecture and methods of a Hadoop cluster, and how it relates to the network and server infrastructure. The content presented here is largely based on academic work and conversations I’ve had with customers running real production clusters. If you run production Hadoop clusters in your data center, I’m hoping you’ll provide your valuable insight in the comments below. Subsequent articles to this will cover the server and network architecture options in closer detail. Before we do that though, lets start by learning some of the basics about how a Hadoop cluster works. OK, let’s get started!

The three major categories of machine roles in a Hadoop deployment are Client machines, Masters nodes, and Slave nodes. The Master nodes oversee the two key functional pieces that make up Hadoop: storing lots of data (HDFS), and running parallel computations on all that data (Map Reduce). The Name Node oversees and coordinates the data storage function (HDFS), while the Job Tracker oversees and coordinates the parallel processing of data using Map Reduce. Slave Nodes make up the vast majority of machines and do all the dirty work of storing the data and running the computations. Each slave runs both a Data Node and Task Tracker daemon that communicate with and receive instructions from their master nodes. The Task Tracker daemon is a slave to the Job Tracker, the Data Node daemon a slave to the Name Node.
Client machines have Hadoop installed with all the cluster settings, but are neither a Master or a Slave. Instead, the role of the Client machine is to load data into the cluster, submit Map Reduce jobs describing how that data should be processed, and then retrieve or view the results of the job when its finished. In smaller clusters (~40 nodes) you may have a single physical server playing multiple roles, such as both Job Tracker and Name Node. With medium to large clusters you will often have each role operating on a single server machine.
In real production clusters there is no server virtualization, no hypervisor layer. That would only amount to unnecessary overhead impeding performance. Hadoop runs best on Linux machines, working directly with the underlying hardware. That said, Hadoop does work in a virtual machine. That’s a great way to learn and get Hadoop up and running fast and cheap. I have a 6-node cluster up and running in VMware Workstation on my Windows 7 laptop.

---