如何讓主機的防火牆csf不會誤擋到ftp

最近公司的客戶,用ftp連線時,一直被主機的防火牆誤判為攻擊。這個問題是這樣子產生的:公司的防火牆是用csf firewall這個套件,而這個套件如果沒有特別設定的話,對於ftp,很容易誤擋。

根據csf的文件,linux的iptables如果ip_conntrack和ip_conntrack_ftp沒有正常的運作時,FTP的被動模式就無法順利地運作。在這種條件下,我們必須設定ftp的被動通訊埠在防火牆上是被視為可連接的。

以pure-ftp為例子:
(1) 必須修改/etc/pure-ftpd.conf,取消
PassivePortRange 30000 35000
這一行的註解 (注意:此處的port range要和之後步驟,設定CSF的port range相符合)
(2) 重新啟動pure-ftp
(3) 修改csf的config檔 /etc/csf/csf.conf
在 TCP_IN中,加上30000:35000,例如:
# Allow incoming TCP ports
TCP_IN = “20,21,22,25,53,80,110,143,443,465,587,993,995,2077,2078,2082,2083,2086,2087,2095,2096,1891,30000:35000″
(4) 重新啟動csf

這樣子設定之後,防火牆才能和ftp完美的合作。

參考資料:http://www.configserver.com/free/csf/readme.txt

延伸閱讀:如何查看linux server連線port是否異常?

13. A note about FTP Connection Issues
######################################

It is important when using an SPI firewall to ensure FTP client applications
are configured to use Passive (PASV) mode connections to the server.

On servers running Monolithic kernels (e.g. VPS Virtuozzo/OpenVZ and custom
built kernels) ip_conntrack and ip_conntrack_ftp iptables kernel modules may
not be available or fully functional. If this happens, FTP passive mode (PASV)
won't work. In such circumstances you will have to open a hole in your firewall
and configure the FTP server to use that same hole.

For example, with pure-ftpd you could add the port range 30000:35000 to TCP_IN
and add the following line to /etc/pure-ftpd.conf and then restart pure-ftpd:
PassivePortRange	30000 35000

For example, with proftpd you could add the port range 30000:35000 to TCP_IN
and add the following line to /etc/proftpd.conf and then restart proftpd:
PassivePorts	30000 35000

FTP over SSL/TLS will usually fail when using an SPI firewall. This is because
of the way the FTP protocol established a connection between client and server.
iptables fails to establish a related connection when using FTP over SSL
because the FTP control connection is encrypted and so cannot track the
relationship between the connection and the allocation of an ephemeral port.

If you need to use FTP over SSL, you will have to open up a passive port block
in both csf and your FTP server configuration (see above).

Perversely, this makes your firewall less secure, while trying to make FTP
connections more secure.



Search engine friendly URL

大約今年三月時,我把整個官網整合了whmcs系統。http://unethost.com/

這個whmcs有個功能叫做 Search engine friendly URL support,簡稱為SEF,這個是什麼意思呢?

如果不勾選這個選項的話,在knowledge base新增的文章,它的URL就會長成這個德性:
http://support.unethost.com/knowledgebase.php?action=displayarticle&id=18

很明顯可以知道這個連結是一個動態產生的頁面。然而各家的搜尋引擎google, yahoo對於分數的計算,都是比較喜歡靜態的頁面。所以,我就把這個選項勾了,然後,上頭那個連結就自動轉換成:
http://support.unethost.com/knowledgebase/18/web-template.html

到這裡為止,世界是和平的^^。然而,不和平的在後面。很快地,我就發現了很討人厭的問題,如果我新增的文章的title,全部是中文時,就會長出下方這種會爛掉的link,會爛掉的原因,似乎是因為會造成mod rewrite的loop。
http://support.unethost.com/knowledgebase/23/.html

這是為什麼呢?因為,whmcs的php在生成內部連結時,大概是長成這樣子的語法:
{if $seofriendlyurls}
announcements/{$id}/{$urlfriendlytitle}.html
{else}
announcements.php?id={$id}

其中,這個$urlfriendlytitle,被whmcs的設計者(這些死老美!!) 設計成,不考慮多語言的case,如果你的title本來是全部用中文寫的,它就真的給你丟出空字串。然後你的連結就會爛了。所以我對上述的code作了修改:


$urlfriendlytitle}.html
改成了
$urlfriendlytitle}-seo.html

這實在是個很暴力/很醜的改法。不過,先湊合著用就好~。(SEO做到1000分,服務不好還是不會有客戶)  這樣子,就不會生成.html的這種,之後會造成loop問題的連結。而是會形成:http://support.unethost.com/knowledgebase/23/-seo.html
我只要求.html之前,至少有一些字串就好了~ 不要求太多。

接下來,我就要開始動手術了:一次修改大量的.php檔,一口氣解決問題。來一個指令吧:

find . -name *.tpl  -exec grep -l urlfriendlytitle {} \;

把所有疑似有罪的檔案全部都抓出來修改。就這樣子,我讓官網的一些動態頁面,全數變成了SEF(Search Engine Friendly) url

備份主機– 使用rsyncd

有時候,會有一種需求,就是兩台獨立主機之間,常常需要做快速的遠端備分。這種時候,rsyncd的server mode就派上用場了。

server 端:
(1) 透過WHM ,去開啟873這個port的firewall

(2) mkdir /home/bk_server1
mkdir /home/bk_server2

(3) 寫好 /etc/rsyncd.conf
<pre>
pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
log file = /var/log/rsyncd.log #

[server1]
path = /home/bk_server1
auth users = bk_user
uid = root
gid = root
secrets file = /etc/rsyncd.secrets
read only = no

[server2]
path = /home/bk_server2
auth users = bk_user
uid = root
gid = root
secrets file = /etc/rsyncd.secrets
read only = no
</pre>
(4) 寫server side的密碼檔
vi /etc/rsyncd.secrets
<pre>
bk_user:XXXXXXXXXXXXXXX
</pre>

密碼檔設置完後,
chown root:root /etc/rsyncd.secrets
chmod 600 /etc/rsyncd.secrets

(5) 修改 /etc/xinetd.d/rsync
將 disable = yes 改成 disable = no

(6) service xinetd restart

(7) 確認 xinetd 有沒有去聽 rsync的 873 port
netstat -ntlp |grep 873
( 必須出現才是合理的。)

client 端:
(1) vi /root/rsyncd.secrets
注意,內容的格式和 server端的不同,只有密碼,而沒有user name
XXXXXXXXXXXXX

(2) chmod 600 /root/rsyncd.secrets

(3) 用下列的command就可以sync了。
例如,將client side的 /root,備分到 server 端的 /home/bk_server1
<pre>
rsync -avHz –password-file=/root/rsyncd.secrets /root bk_user@yourhost.com::server1
</pre>
(4) 在crontab 中,加入上述的command

用linux的top指令來抓出主機的效能瓶頸

我在Cloudlinux的網站看到的教學文。對於常常在抓linux的效能瓶頸的我,相當有幫助。linux的top指令,是常用的好東西,只是它給的資訊很多,沒有經驗的人很難立刻理解。從範例中來理解是最好的。

(*) example 1:
top – 01:49:59 up 49 min, 5 users, load average: 18.02, 32.55, 34.91
Tasks: 269 total, 1 running, 268 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.4%us, 0.6%sy, 0.0%ni, 16.7%id, 82.2%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 8028612k total, 2268460k used, 5760152k free, 88348k buffers
Swap: 4192924k total, 731688k used, 3461236k free, 309828k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
8842 mysql 11 -10 1274m 178m 4076 S 0.0 2.3 0:46.40 mysqld

機器跑得很不順 ( 因為load已經上來了,居然有到18 )
發現 Cpu 82.2%wa —> I/O wait
—-> 因為io busy的process通常也是cpu busy,所以直接看第一行。
—-> 八成是第一行的process把cpu cycle 吃太多了
—-> 第一行就是 mysqld
喔,這個很正常,mysqld只要config不對,就容易有這種問題。
到mysql去找問題吧。
(*) example 2:
01:15:52 up 15 min, 4 users, load average: 28.37, 20.02, 10.44
Tasks: 762 total, 1 running, 760 sleeping, 0 stopped, 1 zombie
Cpu(s): 0.5%us, 1.8%sy, 0.0%ni, 0.0%id, 97.3%wa, 0.0%hi, 0.4%si, 0.0%st
Mem: 8028612k total, 7981536k used, 47076k free, 34512k buffers
Swap: 4192924k total, 2894460k used, 1298464k free, 272708k cached

機器跑得很不順 ( 因為load已經上來了,居然有到28 )
發現 Cpu 97.3%wa —> I/O wait
此外,還發現一件事: swap 被用掉了3G,mem幾乎被用光了
—-> 八成是有一隻process把ram吃光光了,是誰呢?
—-> 按shift +m
—-> 第一行就是吃最多ram的process

(*) example 3:
top – 01:27:59 up 31 days, 22:31, 3 users, load average: 2.36, 2.33, 4.96
Tasks: 697 total, 1 running, 692 sleeping, 0 stopped, 4 zombie
Cpu(s): 2.1%us, 1.2%sy, 0.0%ni, 50.9%id, 45.5%wa, 0.1%hi, 0.1%si, 0.0%st
Mem: 4023964k total, 3917884k used, 106080k free, 298548k buffers
Swap: 8385920k total, 504136k used, 7881784k free, 1557260k cached

機器的load沒有衝高,然而,io wait 還是不低 45.5% 。swap雖然有被用到了,但是還小於0.5G,小事啦…,mem也還剩不少 ( 不是ram的問題 )

雖然cpu busy的process 通常也是io busy,但是,目前這種情況無法直接確定
所以top的第一行,cpu用最多的process,就一定是io用最多的。

所以這種時候,會需要另一隻程式 iotop,直接殺向io bound的process,找出效能瓶頸。

CPanel developer’s note

想不到最近還是有寫程式的機會,XD
目標是:修改httpd.conf , 根據cpanel的user package,來設置cband的quota limit
algorithms:
(1) 由cpanel的api—listaccts
去抓出package ( 看是A, B, C .. )
(2) 對於每一個user
建立資料夾 mkdir -p /usr/local/apache/conf/userdata/std/2/$user
(3) 由每一個user 的package, A —> a.conf
B —> b.conf
將對應的 $package.conf 拷貝到
/usr/local/apache/conf/userdata/std/2/$user/$package.conf
(4) 重新generate /usr/local/apache/conf/httpd.conf
下command /usr/local/cpanel/bin/build_apache_conf

透過rsend.sh來搬移檔案

要用rsync來傳檔,非常的方便,但是,壞處就是rsync這個command的語法太複雜了。有時候,我在幫客戶搬上百G的資料時,都是一邊查rsync的語法,一邊用。然而,自從有了rsend.sh這個scripts之後,rsync就簡單多了。
用法是如下,假設,要把sender 端 X資料夾的東西,移到 receiver 的Y 資料夾
Sender 機器 ( 來源資料端 )
(1) 關閉firewall
(2)  cd X    # 切換路徑
(3)  wget   http://acelnmp.googlecode.com/files/rsend.sh  #取得rsend這個script
(4)  mv rsend rsend.sh
       chmod +x ./rsend.sh
      ./rsend.sh
       #  這時候,螢幕上會出現三行指令,選第一行來copy ,然後貼到另一個ssh視窗
receiver 機器  (接收資料端)
(1)   關閉firewall
(2)   cd Y
(3)   rsync -aHvz rsync://example.xxxsystem.com:14845/. .
( 注意,上頭這個複雜的指令,會由rsend.sh在執行的時候,幫你算出來。 所以完全不需要動大腦。XD  )
 完成後,分別在兩台機器上,重新啟動firewall
其他問題:
最後需要注意的是,如果是不同帳號的空間,可能會有帳號權限問題,靠rsend.sh並無法解決,詳情請看: 如何複製不同虛擬主機帳號的檔案?

(本篇教學由unethost.com客服撰寫)

延伸閱讀:如何備份Cpanel後台安裝的套裝程式?

操作上述的軟體,我們提供虛擬主機試用,七天滿意保證,
功能完整使用不受限制,歡迎點我申請。