2015年11月25日 星期三

MPTCP

From: http://www.cnblogs.com/lxgeek/category/671444.html

MPTCP

背景
     隨著技術的發展許多設備具有了多個網絡接口,而TCP依然是一個單線路的協議,在TCP的通信過程中發端和收端都
不能隨意變換地址。我們可以利用多個網絡接口的這一特性來改善性能和有效冗餘。例如:你的手機同時連接
WIFI信號和3G信號的時候,如果WIFI關掉,使用WIFI進行的TCP連接就會斷開,而不能有效利用3G網絡繼續收發數據。
而Multipath TCP可以在一條TCP鏈接中包含多條路徑,避免上述問題出現。
 
MPTCP簡介
     MPTCP允許在一條TCP鏈路中建立多個子通道。當一條通道按照三次握手的方式建立起來後,可以按照三次握手的
方式建立其他的子通道,這些通道以三次握手建立連接和四次握手解除連接。這些通道都會綁定於MPTCP session,
發送端的數據可以選擇其中一條通道進行傳輸。
 
MPTCP的設計遵守以下兩個原則:
1.應用程序的兼容性,應用程序只要可以運行在TCP環境下,就可以在沒有任何修改的情況下,運行於MPTCP環境。
2.網絡的兼容性,MPTCP兼容其他協議。
 
MPTCP在協議棧中的位置如下所示:
 
 
 
建立連接過程 
 
  如上圖所示:MPTCP的第一個子通道的建立遵守TCP的三次握手,唯一的區別是每次發送的
報文段需要添加MP_CAPABLE的的TCP選項和一個安全用途的key。而下圖是建立其他的子通道:
 
  如上圖所示:第二條子通道的建立依然遵守TCP的三次握手,而TCP選項換成了MP_JOIN。
而token是基於key的一個hash值,rand為一個隨機數,而HMAC是基於rand的一個hash值。
 
數據的發送和接收
     MPTCP可以選擇多條子通道中任意一條來發送數據。MPTCP如果使用傳統的TCP的方式
來發送數據,將會出現一部分包在一條子通道,而另一部分包在另外一條子通道。這樣的話,防火牆等
中間設備將會收到TCP的序號跳躍的包,因此將會發生丟包等異常情況。為了解決這個問題,MPTCP通過
增加DSN(data sequence number)來管理包的發送,DSN統計總的報文段序號,而每個子通道中的
序號始終是連續。
     MPTCP的接收包過程分為兩個階段:第一、每個子通道依據自身序號來重組報文段;第二、MPTCP
的控制模塊依據DSN對所有子通道的報文段進行重組。
 
擁塞控制 
     MPTCP中擁塞控制的設計需遵守以下兩個原則:
第一:MPTCP和傳統TCP應該擁有相同的吞吐量,而不是MPTCP中每一條子通道和傳統TCP具有相同的吞吐量。
第二:MPTCP在選擇子通道的時候應該選擇擁塞情況更好的子通道。
 
MPTCP的實現
MPTCP的實現主要分為三部分:
  1. master subsocket 
  2. Multi-path control bock(mpcb)
  3. slave subsocket
 
master subsock是一個標準的sock結構體用於TCP通信。mpcb提供開啟或關閉子通道、
選擇發送數據的子通道以及重組報文段的功能。slave subsocket對應用程序並不可見,他們
都是被mpcb管理並用於發送數據。 
 
應用:
MPTCP的作用除了體現在移動設備領域,還可以用於數據中心。
比如EC2就會讓兩個終端間冗餘有多條路徑,論文《An overview of Multipath TCP》中對此進行了
實驗,作者租借40台機器安裝MPTCP的內核然後實驗,其效果如下:
 

參考文獻:
An overview of Multipath TCP  -  O. Bonaventure , M. Handley and C. Raiciu. USENIX login; , October 2012.
MultiPath TCP: From Theory to Practice  -  S. Barré ,  C. Paasch  and  O. Bonaventure . IFIP Networking, 2011

2015年8月28日 星期五

Block SSH Brute Force Attacks with IPTables

From : http://www.rackaid.com/blog/how-to-block-ssh-brute-force-attacks/

Detecting a SSH Brute Force Attack
If you are under a SSH brute force attack, you will likely see something like this in your logs.
1
2
3
4
5
6
7
8
9
10
Jan 26 03:46:02 host sshd[22731]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=125.39.22.154
Jan 26 03:46:02 host sshd[22731]: pam_succeed_if(sshd:auth): error retrieving information about user seymour
Jan 26 03:46:02 host sshd[22734]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=61.147.103.185 user=root
Jan 26 03:46:02 host sshd[22722]: Failed password for root from 61.147.103.185 port 16563 ssh2
Jan 26 03:46:02 host sshd[22723]: Received disconnect from 61.147.103.185: 11: Normal Shutdown, Thank you for playing
Jan 26 03:46:03 host sshd[22705]: Received disconnect from 61.147.103.185: 11: Normal Shutdown, Thank you for playing
Jan 26 03:46:03 host sshd[22726]: Failed password for invalid user madonna from 125.39.22.154 port 51706 ssh2
Jan 26 03:46:03 host sshd[22917]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=61.147.103.185 user=root
Jan 26 03:46:03 host sshd[22727]: Failed password for root from 61.147.103.185 port 16723 ssh2
Jan 26 03:46:03 host sshd[22729]: Failed password for invalid user florin from 125.39.22.154 port 54958 ssh2

This is a bot scanning your server trying to guess passwords.

 Methods to Stop SSH Brute Force Attacks

There are basically four approaches to dealing with SSH brute force attacks:
  • Restrict SSH access by IP address
  • Change SSH to another Port
  • Use intrusion prevention tools to dynamically block access
  • Rates limit SSH sessions using IPTables
All of these approaches have theirs benefits and drawbacks.
While restricting SSH access by IP address is the most secure method, such restrictions are often not possible when dealing with web hosting services as you have multiple users with constantly changing IP addresses.
Changing the SSH port may defeat bot scans but does little against targeted attacks.  Also, this usually just frustrates your users.
Intrusion prevention tools like fail2ban and denyhosts have their place but they are subject to log based attacks.  These tools essential analyze logs using regular expressions.  Hackers have found ways around both of these tools in the past.
Lastly, you have a great tool to block ssh brute force attacks right on your server: IPtables.

Using IPtables to Stop SSH Brute Force Attacks

I like to think of this approach similar to flow rates with pipes.  Bigger pipes allow more water to flow.  Smaller pipes can handle less water.
control ssh access with iptables
To block a SSH brute force attack, we just need to slow down the flow of requests. We can do this by rate-limiting requests to SSH with iptables.
Essentially, we create a smaller pipe for new SSH sessions.  This slows brute force attacks to a point where they become ineffective.
The iptables rules are relatively simple.
1
2
/usr/sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
/usr/sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent  --update --seconds 60 --hitcount 4 -j DROP
This rule will block an IP if it attempts more than 3 connections per minute to SSH. Notice that the state is set to NEW. This means only new connections not established ones are impacted. Established connections are the result of a successful SSHauthentication, so users who authenticate properly will not be blocked.
If you need to see what’s being done, you may want to log these drops. You can do so by setting up a log rule and then using these rules instead.
1
2
3
4
5
/sbin/iptables -N LOGDROP
/sbin/iptables -A LOGDROP -j LOG
/sbin/iptables -A LOGDROP -j DROP
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent  --update --seconds 60 --hitcount 4 -j LOGDROP
Notice that I’ve changed the rule from DROP to LOGDROP. This way your drops will get logged and you can see the results in your logs:
1
2
3
4
Jan 27 08:22:29 server kernel: IN=eth1 OUT= MAC=00:30:48:94:fb:21:00:1b:00:00:00:00:00:00 SRC=118.103.140.3 DST=208.43.148.64 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=16406 DF PROTO=TCP SPT=31003 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0
Jan 27 08:22:29 server kernel: IN=eth1 OUT= MAC=00:30:48:94:fb:21:00:1b:00:00:00:00:00:00 SRC=118.103.140.3 DST=192.168.1.1 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=5076 DF PROTO=TCP SPT=45354 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0
Jan 27 08:22:35 server kernel: IN=eth1 OUT= MAC=00:30:48:94:fb:21:00:1b:00:00:00:00:00:00 SRC=118.103.140.3 DST=208.43.148.66 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=37295 DF PROTO=TCP SPT=21077 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0
Jan 27 08:22:35 server kernel: IN=eth1 OUT= MAC=00:30:48:94:fb:21:00:1b:00:00:00:00:00:00 SRC=118.103.140.3 DST=208.43.148.64 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=16408 DF PROTO=TCP SPT=31003 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0

Effectively Stopping SSH Brute Force Attacks

I always try to get a sense of effectiveness of any tool or configuration we deploy. I find many “security” tools that are popular among the web hosting crowd provide little to no value. In many cases, appropriate configuration of your server or web application could achieve similar results without the hassle of maintaining a third party product.
Are the IPTables rules effective? In short yes.
During a recent attack on a server, the SSH service remained fully accessible with no service interruption.
Previously such aggressive attack would have caused service interruptions. So on the service side, this approach works. When I dug into the logs, I found three failed user attempts against SSH prior to the rate-limiting kicked in. The attack then sent 67 more attempts before it gave up.

Benefits of Using IPtables to Block SSH Attacks

The benefit of this approach is you don’t need any added software. IPtables is likely sitting on your server already, so you can easily and quickly deploy this solution.
Also, there are no “ban lists” to maintain.  People forget passwords or incorrectly setup their SSH/SFTP programs.   As a result, they trigger a block and get locked out.  You then have to manually edit some ban list to remove them or whitelist IPs.   Over time or with multiple servers, this is a time-consuming server management tasks.  By using iptables, there’s no list to maintain — leaving you time to work on more important things.
One of the drawbacks is that this approach does not lock accounts. A slow, distributed attack could fall under the radar. If it was a directed attack against a specific user account, the attacker could churn away for days or weeks without detection. For that, you would need something that can lock user accounts after failures. PAM includes a module called pam_tally that does just this. If you fail too many times, an account is locked.

DNSSEC安全技術簡介 作者:游子興 / 臺灣大學計算機及資訊網路中心網路組約聘幹事 DNS 是一套已經廣泛使用的Internet 服務,但因先天的技術限制導致容易成為駭客攻擊的目標。本文主要在介紹DNSSEC 之緣起與技術背景,及其使用的加解密技術如何確保資料的完整...