與
Linux中斷息息相關(guān)的一個重要概念是Linux中斷分為兩個半部：上半部（tophalf）和下半部(bottom half)。上半部的功能是"登記中斷"，當(dāng)一個中斷發(fā)生時，它進(jìn)行相應(yīng)地硬件讀寫后就把中斷例程的下半部掛到該設(shè)備的下半部執(zhí)行隊列中去。因此，上半部 執(zhí)行的速度就會很快，可以服務(wù)更多的中斷請求。但是，僅有"登記中斷"是遠(yuǎn)遠(yuǎn)不夠的，因為中斷的事件可能很復(fù)雜。因此，Linux引入了一個下半部，來完 成中斷事件的絕大多數(shù)使命。下半部和上半部最大的不同是下半部是可中斷的，而上半部是不可中斷的，下半部幾乎做了中斷處理程序所有的事情，而且可以被新的 中斷打斷！下半部則相對來說并不是非常緊急的，通常還是比較耗時的，因此由系統(tǒng)自行安排運(yùn)行時機(jī)，不在中斷服務(wù)上下文中執(zhí)行。
Linux實現(xiàn)下半部的機(jī)制主要有tasklet和工作隊列。 Tasklet基于Linux softirq，其使用相當(dāng)簡單，我們只需要定義tasklet及其處理函數(shù)并將二者關(guān)聯(lián)：
void my_tasklet_func(unsigned long); //定義一個處理函數(shù)：
DECLARE_TASKLET(my_tasklet,my_tasklet_func,data); //定義一個tasklet結(jié)構(gòu)my_tasklet，與
my_tasklet_func(data)函數(shù)相關(guān)聯(lián)
然后，在需要調(diào)度tasklet的時候引用一個簡單的API就能使系統(tǒng)在適當(dāng)?shù)臅r候進(jìn)行調(diào)度運(yùn)行：
tasklet_schedule(&my_tasklet);
此外，Linux還提供了另外一些其它的控制tasklet調(diào)度與運(yùn)行的API：
DECLARE_TASKLET_DISABLED(name,function,data); //與DECLARE_TASKLET類似，但等待tasklet被使能
tasklet_enable(struct tasklet_struct *); //使能tasklet
tasklet_disble(struct tasklet_struct *); //禁用tasklet
tasklet_init(struct tasklet_struct *,void (*func)(unsigned long),unsigned long); //類似
DECLARE_TASKLET()
tasklet_kill(struct tasklet_struct *); // 清除指定tasklet的可調(diào)度位，即不允許調(diào)度該tasklet
我們先來看一個tasklet的運(yùn)行實例，這個實例沒有任何實際意義，僅僅為了演示。它的功能是：在globalvar被寫入一次后，就調(diào)度一個tasklet，函數(shù)中輸出"tasklet is executing"：
#include … //定義與綁定tasklet函數(shù) void test_tasklet_action(unsigned long t); DECLARE_TASKLET(test_tasklet, test_tasklet_action, 0); void test_tasklet_action(unsigned long t) { printk("tasklet is executing\n"); } … ssize_t globalvar_write(struct file *filp, const char *buf, size_t len, loff_t *off) { … if (copy_from_user(&global_var, buf, sizeof(int))) { return - EFAULT; } //調(diào)度tasklet執(zhí)行 tasklet_schedule(&test_tasklet); return sizeof(int); } |
下半部分的任務(wù)就是執(zhí)行與中斷處理密切相關(guān)但中斷處理程序本身不執(zhí)行的工作。在Linux2.6的內(nèi)核中存在三種不同形式的下半部實現(xiàn)機(jī)制：軟中斷，tasklet和工作隊列。
下面將比較三種機(jī)制的差別與聯(lián)系。
軟中斷： 1、軟中斷是在編譯期間靜態(tài)分配的。
2、最多可以有32個軟中斷。
3、軟中斷不會搶占另外一個軟中斷，唯一可以搶占軟中斷的是中斷處理程序。
4、可以并發(fā)運(yùn)行在多個CPU上（即使同一類型的也可以）。所以軟中斷必須設(shè)計為可重入的函數(shù)（允許多個CPU同時操作），
因此也需要使用自旋鎖來保護(hù)其數(shù)據(jù)結(jié)構(gòu)。
5、目前只有兩個子系直接使用軟中斷：網(wǎng)絡(luò)和SCSI。
6、執(zhí)行時間有：從硬件中斷代碼返回時、在ksoftirqd內(nèi)核線程中和某些顯示檢查并執(zhí)行軟中斷的代碼中。
tasklet： 1、tasklet是使用兩類軟中斷實現(xiàn)的：HI_SOFTIRQ和TASKLET_SOFTIRQ。
2、可以動態(tài)增加減少，沒有數(shù)量限制。
3、同一類tasklet不能并發(fā)執(zhí)行。
4、不同類型可以并發(fā)執(zhí)行。
5、大部分情況使用tasklet。
工作隊列： 1、由內(nèi)核線程去執(zhí)行，換句話說總在進(jìn)程上下文執(zhí)行。
2、可以睡眠，阻塞。
碰巧用到Proto,算是筆記吧算是筆記吧，
windows :
1,兩個文件：proto.exe, protobuf-java-2.4.1.jar
2,建立一個工程TestPb，在下面建立一個proto文件件，用來存放【。proto】文件
3，將proto,exe放在工程下，
4，建立一個msg.proto文件：
option java_package = "com.protobuftest.protobuf"; option java_outer_classname = "PersonProbuf"; message Person { required string name = 1; required int32 id = 2; optional string email = 3; enum PhoneType { MOBILE = 0; HOME = 1; WORK = 2; } message PhoneNumber { required string number = 1; optional PhoneType type = 2 [default = HOME]; } repeated PhoneNumber phone = 4; message CountryInfo { required string name = 1; required string code = 2; optional int32 number = 3; } } message AddressBook { repeated Person person = 1; } |
5，生成
java文件：在proto.exe目錄下：protoc --java_out=./src ./proto/msg.proto
6,copy個測試示例了
新建一個文件TestPb.java
*********************************************************** package com.protobuftest.protobuf; import java.util.List; import com.google.protobuf.InvalidProtocolBufferException; import com.protobuftest.protobuf.PersonProbuf; import com.protobuftest.protobuf.PersonProbuf.Person; import com.protobuftest.protobuf.PersonProbuf.Person.PhoneNumber; public class TestPb { /** * @param args */ public static void main(String[] args) { // TODO Auto-generated method stub PersonProbuf.Person.Builder builder = PersonProbuf.Person.newBuilder(); builder.setEmail("kkk@email.com"); builder.setId(1); builder.setName("TestName"); builder.addPhone(PersonProbuf.Person.PhoneNumber.newBuilder().setNumber("131111111").setType(PersonProbuf.Person.PhoneType.MOBILE)); builder.addPhone(PersonProbuf.Person.PhoneNumber.newBuilder().setNumber("011111").setType(PersonProbuf.Person.PhoneType.HOME)); Person person = builder.build(); byte[] buf = person.toByteArray(); try { Person person2 = PersonProbuf.Person.parseFrom(buf); System.out.println(person2.getName() + ", " + person2.getEmail()); List<PhoneNumber> lstPhones = person2.getPhoneList(); for (PhoneNumber phoneNumber : lstPhones) { System.out.println(phoneNumber.getNumber()); } } catch (InvalidProtocolBufferException e) { // TODO Auto-generated catch block e.printStackTrace(); } System.out.println(buf); } } |
***********************************************
*******************************
生成java文件:PersonProbuf.java
*******************************
工程文件結(jié)構(gòu)：
很多
測試人員很有興趣, 管理高層是怎么看待測試團(tuán)隊? 作者問了一群有資深的測試人員和測試經(jīng)理, 得到以下的答案:
What is the point?
Necessary evil
Ad hoc
Why so much time?
Too slow
Overstaffed
Too many excuses
Testing should find everything
Quality gatekeeper
Find bugs too late
Testing less value than other disciplines
作者認(rèn)為由這些答案, 可以知道可能很多高階主管是不太了解測試到底在做什么.
測試人員必須要對自己的
工作成果, 設(shè)定較高的期待. 因為使用者和資深管理者, 會期望測試人員需要找到所有的bugs. 這種期待是不可能, 也不切實際的.
如果有太多的bugs被產(chǎn)生在系統(tǒng)中, 其中一種解決的方法, 就是藉由大量的測試和修復(fù)bugs, 來維持質(zhì)量. 但是, 可能較好的方法, 是想辦法去了解客戶要什么, 產(chǎn)生較好的requirement, 或者一開始便產(chǎn)生較有質(zhì)量的程序代碼.
測試并是不要做質(zhì)量的把關(guān)者, 測試的目的不應(yīng)該只是去保證受測系統(tǒng)的質(zhì)量, 而是要去衡量其質(zhì)量
最后作者和大家分享這兩句話, 很值得大家思考一下:
1. The purpose of testing is not to ensure the quality of the software, but rather to measure its quality
2. Testing is just one facet of the quality solution. Responsibility for the quality of the product must reside in the entire team
最新做的一個項目，被
測試組猛烈攻擊，暴露了不少問題。其中一個問題印象深刻！
測試使用了WebInspect這個掃描工具，掃描了整個網(wǎng)站，包括后臺。結(jié)果我們的
數(shù)據(jù)庫里被灌入大量的垃圾數(shù)據(jù)，并修改了原有的數(shù)據(jù)。總之，慘不忍睹！
后來，我們發(fā)現(xiàn)我們后臺的一個簡單的檢查是否登錄的方法有問題:在判定未登錄時，使用php header()跳轉(zhuǎn)頁面，沒有在這個方法執(zhí)行后退出執(zhí)行。這樣的話，頁面跳轉(zhuǎn)，但在header()下面的代碼依然會執(zhí)行。
現(xiàn)總結(jié)下php header()使用時注意的問題：
1、location和“:”號間不能有空格，否則會出錯。
2、在用header前不能有任何的輸出。
3、header后的PHP代碼還會被執(zhí)行。記得加exit() 或者die 退出。
另外，后臺登錄地址注意安全，不讓他人輕易猜到！
一、 如何讓初/中級測試人員甚至開發(fā)人員進(jìn)行正規(guī)化的移動白盒測試？ 據(jù)悉，
黑盒測試方法是現(xiàn)今
移動測試最多的測試方式。這意味著手動測試將貫穿整個軟件發(fā)布周期的前前后后。但是手動測試還存在問題，理由有幾點：它大大減慢了開發(fā)過程，給錯誤的發(fā)生留下很多余地，最終會降低團(tuán)隊在短時間內(nèi)發(fā)布高質(zhì)量軟件的信心。
ThreadingTest（下面簡稱TT）是一款國產(chǎn)化的
白盒測試工具，100%Java語法支持，最高支持Java1.7版本（小型有安卓
游戲測試、大型如liferay網(wǎng)站的測試），TT都能通過簡單的插裝，自動建立
測試用例與程序源代碼之間的邏輯關(guān)系，又通過自動化的生成 CallGraph、ControlFlow 等視圖，讓以往的移動黑盒測試轉(zhuǎn)變成透明化的白盒測試。
TT率先將引入的測試示波器概念，在實際測試的過程中，可以實時的看到從程序中各種邏輯體執(zhí)行的速率、頻率等信息，測試人員可以從傳統(tǒng)的對被測應(yīng)用的黑盒子測試（僅能看到功能的反饋無法看到程序內(nèi)部的反饋）進(jìn)而轉(zhuǎn)換成為類似于對于硬件測試的示波器一樣，能夠?qū)φ麄€測試過程的關(guān)鍵測試數(shù)據(jù)進(jìn)行實時的分析和查看。
二、 如何打破測試和開發(fā)之間的對立關(guān)系，提倡需求變更？
據(jù)悉，以往軟件需求變更會給項目帶來巨大的風(fēng)險，會導(dǎo)致項目的成本費(fèi)用增加、開發(fā)周期延長、產(chǎn)品質(zhì)量下降及團(tuán)隊
工作效率下降等不良后果，因而需求變更在
軟件開發(fā)項目中應(yīng)該盡量避免，但是在現(xiàn)今IT行業(yè)高速發(fā)展的情況下，為了達(dá)到市場的需求，頻繁的需求變更是迫在眉睫的，這也是開發(fā)和測試對立的主要焦點。
TT采用正向追溯和反向追溯的功能，自動化的展示連接代碼和被測功能模塊的關(guān)系，來引導(dǎo)開發(fā)與測試合作完成100%覆蓋率測試。
1. 正向追溯：在TT中開發(fā)工程師可以通過雙向追溯界面，觀看到測試工程師執(zhí)行用例經(jīng)過的代碼細(xì)節(jié)、運(yùn)行的次數(shù)、模塊的覆蓋率等，這樣能高效的進(jìn)行開發(fā)工程師和測試工程師之間的互動，當(dāng)覆蓋率不全或出現(xiàn)BUG時，也為開發(fā)快速定位和修復(fù)缺陷提供依據(jù)。
2. 反向追溯：在TT中測試工程師可以通過雙向追溯界面，觀看到某一些代碼到底和哪些功能點有關(guān)，當(dāng)進(jìn)行需求變更時，測試人員能快速的定位到那些被修改的代碼
所對應(yīng)影響的功能，而不是盲目的進(jìn)行整個工程的反復(fù)測試，這為縮短測試時間和提高產(chǎn)品質(zhì)量提供了便捷的路徑，并為測試人員自身的理解提供了一個便捷的平臺。
三、 是否有一款移動測試工具支持多語言、多平臺、多應(yīng)用，并且支持移動模擬器和真機(jī)的雙重測試？
據(jù)悉，現(xiàn)今市場上的測試工具多數(shù)以國外軟件為主，在使用和享受服務(wù)過程中，會產(chǎn)生功能繁瑣、平臺不同、售后服務(wù)等問題。
1． TT采用傻瓜式的操作方式，引導(dǎo)測試工程師逐步的提升測試質(zhì)量。
2． TT程序具有跨平臺技術(shù)特性，已經(jīng)推出windows版本，可以輕松的擴(kuò)展到linux，mac os等環(huán)境下運(yùn)行。
3． TT 支持移動模擬器和真機(jī)的雙重測試，讓測試人員在真機(jī)上也能進(jìn)行正規(guī)化的白盒測試。
Informatica
測試數(shù)據(jù)管理解決方案可幫助 IT 組織創(chuàng)建功能完整、安全的
數(shù)據(jù)庫應(yīng)用程序測試數(shù)據(jù)子集。 支持?jǐn)?shù)據(jù)庫應(yīng)用程序的 IT 組織常常會制作生產(chǎn)環(huán)境的多個副本來用于開發(fā)、測試和培訓(xùn)。 然而，隨著生產(chǎn)數(shù)據(jù)庫的增大，制作這些副本將會用掉成本高昂的存儲空間和系統(tǒng)資源，同時會讓公司陷入因數(shù)據(jù)泄露而導(dǎo)致財務(wù)損失的風(fēng)險。 借助 Informatica 測試數(shù)據(jù)管理解決方案，公司可以避免：
過高的數(shù)據(jù)管理成本
未能有效遵守隱私法規(guī)
由數(shù)據(jù)泄露而導(dǎo)致的聲譽(yù)、客戶和收入損失
借助測試數(shù)據(jù)管理降低成本和風(fēng)險
Informatica 測試數(shù)據(jù)管理解決方案無需使用生產(chǎn)數(shù)據(jù)的完整集合，因此可以讓貴公司：
縮短開發(fā)周期：使用較小的測試數(shù)據(jù)集合，通過測試數(shù)據(jù)管理縮短開發(fā)周期
降低 IT 成本：實施測試數(shù)據(jù)管理時使用較小的數(shù)據(jù)集合，這樣所需的存儲和系統(tǒng)資源也較少
支持合規(guī)性：屏蔽的數(shù)據(jù)符合所需的測試質(zhì)量級別，這是成功測試數(shù)據(jù)管理的關(guān)鍵，同時確保數(shù)據(jù)隱私
快速部署：通過使用預(yù)打包或自定義的子集化和屏蔽政策進(jìn)行測試數(shù)據(jù)管理，可以快速創(chuàng)建安全的數(shù)據(jù)子集，同時保持參考完整性
借助測試數(shù)據(jù)管理提高質(zhì)量和安全性
Informatica 測試數(shù)據(jù)管理解決方案創(chuàng)建安全的測試數(shù)據(jù)管理子集，同時將成本、風(fēng)險和開發(fā)時間降到最少。 通過實現(xiàn)測試數(shù)據(jù)管理子集和屏蔽操作的自動化，該解決方案允許您的 IT 團(tuán)隊專注于其它開發(fā)活動。 測試數(shù)據(jù)管理甚至于可縮小您測試和開發(fā)環(huán)境的規(guī)模，這樣您便可以將回收的存儲空間重新分配于其它方面。
借助測試數(shù)據(jù)管理提高生產(chǎn)率和靈活性
Informatica 測試數(shù)據(jù)管理解決方案還可以重復(fù)地復(fù)制生產(chǎn)數(shù)據(jù)，以為測試數(shù)據(jù)管理創(chuàng)建安全、最新的非生產(chǎn)環(huán)境。 測試數(shù)據(jù)管理的子集政策可以包括任何規(guī)則組合，例如數(shù)據(jù)的使用年限、部門或國家、數(shù)據(jù)范圍或值。 適用于
Oracle Applications 或 SAP 等應(yīng)用程序的預(yù)打包測試數(shù)據(jù)管理政策進(jìn)一步簡化了開發(fā)和測試。
1、創(chuàng)建qunit.html 文件添加由官方提供的cdn 加載
測試框架
<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>QUnit Example</title> <link rel="stylesheet" > </head> <body> <div id="qunit"></div> <div id="qunit-fixture"></div> <script src="http://code.jquery.com/qunit/qunit-1.15.0.js"></script> <script src="project.js"></script> <script src="tests.js"></script> </body> </html> |
最后面引入的 project.js 就是待測試的文件
最后面引入的 tests.js 就是
測試用例的文件
2、測試用例的編寫
先寫一個待測試?yán)樱@是一個判斷是否是偶數(shù)的方法
//project.js function isEven(val) { return val % 2 === 0; } |
3、編寫測試
//tests.js<br>test('isEven()', function() { ok(isEven(0), 'Zero is an even number'); ok(isEven(2), 'So is two'); ok(isEven(-4), 'So is negative four'); ok(!isEven(1), 'One is not an even number'); ok(!isEven(-7), 'Neither is negative seven'); }) |
IT行業(yè)發(fā)展到現(xiàn)在，安全問題已經(jīng)變得至關(guān)重要，從最近的“棱鏡門”事件中，折射出了很多安全問題，信息安全問題已變得刻不容緩，而做為運(yùn)維人員，就必須了解一些安全運(yùn)維準(zhǔn)則，同時，要保護(hù)自己所負(fù)責(zé)的業(yè)務(wù)，首先要站在攻擊者的角度思考問題，修補(bǔ)任何潛在的威脅和漏洞。
下面通過一個案例介紹下當(dāng)一個服務(wù)器被rootkit入侵后的處理思路和處理過程，rootkit
攻擊是Linux系統(tǒng)下最常見的攻擊手段和攻擊方式。
1、受攻擊現(xiàn)象
這是一臺客戶的門戶網(wǎng)站服務(wù)器，托管在電信機(jī)房，客戶接到電信的通知：由于此服務(wù)器持續(xù)對外發(fā)送數(shù)據(jù)包，導(dǎo)致100M帶寬耗盡，于是電信就切斷了此服務(wù)器的網(wǎng)絡(luò)。此服務(wù)器是Centos5.5版本，對外開放了80、22端口。
從客戶那里了解到，網(wǎng)站的訪問量并不大，所以帶寬占用也不會太高，而耗盡100M的帶寬是絕對不可能的，那么極有可能是服務(wù)器遭受了流量攻擊，于是登錄服務(wù)器做詳細(xì)的檢測。
2、初步分析
在電信人員的配合下通過交換機(jī)對該服務(wù)器的網(wǎng)絡(luò)流量進(jìn)行了檢測，發(fā)現(xiàn)該主機(jī)確實存在對外80端口的掃描流量，于是登錄系統(tǒng)通過“netstat –an”命令對系統(tǒng)開啟的端口進(jìn)行檢查，可奇怪的是，沒有發(fā)現(xiàn)任何與80端口相關(guān)的網(wǎng)絡(luò)連接。接著使用“ps –ef”、“top”等命令也沒有發(fā)現(xiàn)任何可疑的進(jìn)程。于是懷疑系統(tǒng)是否被植入了rootkit。
為了證明系統(tǒng)是否被植入了rootkit，我們將網(wǎng)站服務(wù)器下的ps、top等命令與之前備份的同版本可信
操作系統(tǒng)命令做了md5sum校驗，結(jié)果發(fā)現(xiàn)網(wǎng)站服務(wù)器下的這兩個命令確實被修改過，由此斷定，此服務(wù)器已經(jīng)被入侵并且安裝了rootkit級別的后門程序。
3、斷網(wǎng)分析系統(tǒng)
由于服務(wù)器不停向外發(fā)包，因此，首先要做的就是將此服務(wù)器斷開網(wǎng)絡(luò)，然后分析系統(tǒng)日志，尋找攻擊源。但是系統(tǒng)命令已經(jīng)被替換掉了，如果繼續(xù)在該系統(tǒng)上執(zhí)行操作將變得不可信，這里可以通過兩種方法來避免這種情況，第一種方法是將此服務(wù)器的硬盤取下來掛載到另外一臺安全的主機(jī)上進(jìn)行分析，另一種方式就是從一個同版本可信操作系統(tǒng)下拷貝所有命令到這個入侵服務(wù)器下某個路徑，然后在執(zhí)行命令的時候指定此命令的完整路徑即可，這里采用第二種方法。
我們首先查看了系統(tǒng)的登錄日志，查看是否有可疑登錄信息，執(zhí)行如下命令：
more /var/log/secure |grep Accepted
通過對命令輸出的查看，有一條日志引起了我們的懷疑：
Oct 3 03:10:25 webserver sshd[20701]: Accepted password for mail from 62.17.163.186 port 53349 ssh2
這條日志顯示在10月3號的凌晨3點10分，有個mail帳號從62.17.163.186這個IP成功登錄了系統(tǒng)，mail是系統(tǒng)的內(nèi)置帳號，默認(rèn)情況下是無法執(zhí)行登錄操作的，而62.17.163.186這個IP，經(jīng)過查證，是來自愛爾蘭的一個地址。從mail帳號登錄的時間來看，早于此網(wǎng)站服務(wù)器遭受攻擊的時間。
接著查看一下系統(tǒng)密碼文件/etc/shadow，又發(fā)現(xiàn)可疑信息：
mail:$1$kCEd3yD6$W1evaY5BMPQIqfTwTVJiX1:15400:0:99999:7:::
很明顯，mail帳號已經(jīng)被設(shè)置了密碼，并且被修改為可遠(yuǎn)程登錄，之所以使用mail帳號，猜想可能是因為入侵者想留下一個隱蔽的帳號，以方便日后再次登錄系統(tǒng)。
然后繼續(xù)查看其他系統(tǒng)日志，如/var/log/messages、/var/log/wtmp均為空文件，可見，入侵者已經(jīng)清理了系統(tǒng)日志文件，至于為何沒有清空/var/log/secure文件，就不得而知了。
4、尋找攻擊源
到目前為止，我們所知道的情況是，有個mail帳號曾經(jīng)登錄過系統(tǒng)，但是為何會導(dǎo)致此網(wǎng)站服務(wù)器持續(xù)對外發(fā)送數(shù)據(jù)包呢？必須要找到對應(yīng)的攻擊源，通過替換到此服務(wù)器上的ps命令查看系統(tǒng)目前運(yùn)行的進(jìn)程，又發(fā)現(xiàn)了新的可疑：
nobody 22765 1 6 Sep29 ? 4-00:11:58 .t
這個.t程序是什么呢，繼續(xù)執(zhí)行top命令，結(jié)果如下：
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22765 nobody 15 0 1740m 1362m 1228 S 98.3 91.5 2892:19 .t
從輸出可知，這個t程序已經(jīng)運(yùn)行了4天左右，運(yùn)行這個程序的是nobody用戶，并且這個t程序消耗了大量的內(nèi)存和cpu，這也是之前客戶反映的網(wǎng)站服務(wù)器異常緩慢的原因，從這個輸出，我們得到了t程序的進(jìn)程PID為22765，接下來根據(jù)PID查找下執(zhí)行程序的路徑在哪里：
進(jìn)入內(nèi)存目錄，查看對應(yīng)PID目錄下exe文件的信息：
[root@webserver ~]# /mnt/bin/ls -al /proc/22765/exe
lrwxrwxrwx 1 root root 0 Sep 29 22:09 /proc/22765/exe -> /var/tmp/…/apa/t
這樣就找到了進(jìn)程對應(yīng)的完整程序執(zhí)行路徑，這個路徑很隱蔽，由于/var/tmp目錄默認(rèn)情況下任何用戶可讀性，而入侵者就是利用這個漏洞在/var/tmp目錄下創(chuàng)建了一個“…”的目錄，而在這個目錄下隱藏著攻擊的程序源，進(jìn)入/var/tmp/…/目錄，發(fā)現(xiàn)了一些列入侵者放置的rootkit文件，列表如下：
[root@webserver ...]#/mnt/bin/ls -al drwxr-xr-x 2 nobody nobody 4096 Sep 29 22:09 apa -rw-r--r-- 1 nobody nobody 0 Sep 29 22:09 apa.tgz drwxr-xr-x 2 nobody nobody 4096 Sep 29 22:09 caca drwxr-xr-x 2 nobody nobody 4096 Sep 29 22:09 haha -rw-r--r-- 1 nobody nobody 0Sep 29 22:10 kk.tar.gz -rwxr-xr-x 1 nobody nobody 0 Sep 29 22:10 login -rw-r--r-- 1 nobody nobody 0 Sep 29 22:10 login.tgz -rwxr-xr-x 1 nobody nobody 0 Sep 29 22:10 z |
通過對這些文件的分析，基本判斷這就是我們要找的程序攻擊源，其中：
1）、z程序是用來清除系統(tǒng)日志等相關(guān)信息的，例如執(zhí)行：
./z 62.17.163.186
這條命令執(zhí)行后，系統(tǒng)中所有與62.17.163.186有關(guān)的日志將全部被清除掉。
2）、在apa目錄下有個后門程序t，這個就是之前在系統(tǒng)中看到的，運(yùn)行此程序后，此程序會自動去讀apa目錄下的ip這個文件，而ip這個文件記錄了各種ip地址信息，猜想這個t程序應(yīng)該是去掃描ip文件中記錄的所有ip信息，進(jìn)而獲取遠(yuǎn)程主機(jī)的權(quán)限，可見這個網(wǎng)站服務(wù)器已經(jīng)是入侵者的一個肉雞了。
3）、haha目錄里面放置的就是用來替換系統(tǒng)相關(guān)命令的程序，也就是這個目錄下的程序使我們無法看到操作系統(tǒng)的異常情況。
4）、login程序就是用來替換系統(tǒng)登錄程序的木馬程序，此程序還可以記錄登錄帳號和密碼。
5、查找攻擊原因
到這里為止，服務(wù)器上遭受的攻擊已經(jīng)基本清晰了，但是入侵者是如何侵入這臺服務(wù)器的呢？這個問題很重要，一定要找到入侵的根源，才能從根本上封堵漏洞。
為了弄清楚入侵者是如何進(jìn)入服務(wù)器的，需要了解下此服務(wù)器的軟件環(huán)境，這臺服務(wù)器是一個基于java的web服務(wù)器，安裝的軟件有apache2.0.63、tomcat5.5，apache和tomcat之間通過mod_jk模塊進(jìn)行集成，apache對外開放80端口，由于tomcat沒有對外開放端口，所以將問題集中到apache上面。
通過查看apache的配置發(fā)現(xiàn)，apache僅僅處理些靜態(tài)資源請求，而網(wǎng)頁也以靜態(tài)頁面居多，所以通過網(wǎng)頁方式入侵系統(tǒng)可能性不大，既然漏洞可能來自于apache，那么嘗試查看apache日志，也許能發(fā)現(xiàn)一些可疑的訪問痕跡，通過查看access.log文件，發(fā)現(xiàn)了如下信息：
62.17.163.186 - - [29/Sep/2013:22:17:06 +0800] "GET http://www.xxx.com/cgi-bin/awstats.pl?configdir=|echo;echo;ps+-aux%00 HTTP/1.0" 200 12333 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1) Gecko/20121010 Firefox/2.0"
62.17.163.186 - - [29/Sep/213:22:17:35 +0800] "GET http://www.xxx.com/cgi-bin/awstats.pl?configdir=|echo;echo;cd+/var/tmp/.../haha;ls+-a%00 HTTP/1.0" 200 1626 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1) Gecko/20121010 Firefox/2.0"
至此，發(fā)現(xiàn)了漏洞的根源，原來是awstats.pl腳本中configdir的一個漏洞，通過了解此服務(wù)器的應(yīng)用，客戶確實是通過一個Awstats的開源插件來做網(wǎng)頁訪問統(tǒng)計，通過這個漏洞，攻擊者可以直接在瀏覽器上操作服務(wù)器，例如查看進(jìn)程、創(chuàng)建目錄等。通過上面第二條日志可以看出，攻擊者正常瀏覽器執(zhí)行切換到/var/tmp/.../haha目錄的操作。
這個腳本漏洞挺可怕的，不過在Awstats官網(wǎng)也早已給出了修補(bǔ)的方法，對于這個漏洞，修復(fù)方法很簡單，打開awstats.pl文件，找到如下信息：
if ($QueryString =~ /configdir=([^&]+)/i)
{
$DirConfig=&DecodeEncodedString("$1");
}
修改為如下即可：
if ($QueryString =~ /configdir=([^&]+)/i)
{
$DirConfig=&DecodeEncodedString("$1");
$DirConfig=~tr/a-z0-9_\-\/\./a-z0-9_\-\/\./cd;
}
6、揭開謎團(tuán)
通過上面逐步分析和介紹，此服務(wù)遭受入侵的原因和過程已經(jīng)非常清楚了，大致過程如下：
（1）攻擊者通過Awstats腳本awstats.pl文件的漏洞進(jìn)入了系統(tǒng)，在/var/tmp目錄下創(chuàng)建了隱藏目錄，然后將rootkit后門文件傳到這個路徑下。
（2）攻擊者通過植入后門程序，獲取了系統(tǒng)超級用戶權(quán)限，進(jìn)而控制了這臺服務(wù)器，通過這臺服務(wù)器向外發(fā)包。
（3）攻擊者的IP地址62.17.163.186可能是通過代理過來的，也可能是攻擊者控制的其他肉雞服務(wù)器。
（4）攻擊者為了永久控制這臺機(jī)器，修改了系統(tǒng)默認(rèn)帳號mail的信息，將mail帳號變?yōu)榭傻卿洠⑶以O(shè)置了mail帳號的密碼。
（5）攻擊者在完成攻擊后，通過后門程序自動清理了系統(tǒng)訪問日志，毀滅了證據(jù)。
通過對這個入侵過程的分析，發(fā)現(xiàn)入侵者的手段還是非常簡單和普遍的，雖然入侵者刪除了系統(tǒng)的一些日志，但是還是留下了很多可查的蹤跡，其實還可以查看用戶下的.bash_history文件，這個文件是用戶操作命令的歷史記錄。
7、如何恢復(fù)網(wǎng)站
由于系統(tǒng)已經(jīng)文件被更改和替換，此系統(tǒng)已經(jīng)變得完全不可信，因此建議備份網(wǎng)站數(shù)據(jù)，重新安裝系統(tǒng)，基本步驟如下：
（1）安裝穩(wěn)定版本的操作系統(tǒng)，刪除系統(tǒng)默認(rèn)的并且不需要的用戶。
（2）系統(tǒng)登錄方式改為公鑰認(rèn)證方式，避開密碼認(rèn)證的缺陷。
（3）安裝更高版本的apache和最新穩(wěn)定版本的Awstats程序。
（4）使用Linux下的Tcp_Wrappers防火墻，限制ssh登錄的源地址。
集算器支持包括
數(shù)據(jù)庫在內(nèi)的多種異構(gòu)數(shù)據(jù)源。這里，我們通過例子來看一下集算器訪問數(shù)據(jù)庫的方法。
集算器可以連接數(shù)據(jù)庫的jdbc驅(qū)動，也可以通過jdbc-odbc橋連接數(shù)據(jù)庫。由于版權(quán)的原因，使用集算器的程序員需要自行準(zhǔn)備數(shù)據(jù)庫的jdbc或者odbc驅(qū)動。Jdbc驅(qū)動jar包準(zhǔn)備好之后，需要放入集算器IDE安裝目錄的/common/jdbc中，例如：C:\Program Files (x86)\MicroInsight\common\jdbc目錄中。
集算器集成開發(fā)環(huán)境的ODBC配置界面如下：
集算器的集成開發(fā)環(huán)境提供了多種數(shù)據(jù)庫的jdbc配置提示，包括：SQLserver、
Oracle、DB2、Sybase、Access、mysql、hsql、teradata、postgres等。如果需要連接的數(shù)據(jù)庫不在這個范圍內(nèi)，可以使用other類型來添加。配置界面如下：
驅(qū)動jar包放好，配置完成之后，在IDE中就可以很方便的連接數(shù)據(jù)庫，取出表中的數(shù)據(jù)：
上圖中A1單元格連接上了一個名為demo的hsql數(shù)據(jù)庫，A2單元使用
sql語句查詢了employee表，作為集算器的序表存入了A2單元格這個變量中，arg1是外部傳入的參數(shù)。A3單元格關(guān)閉了數(shù)據(jù)庫連接，A4單元格對外返回查詢結(jié)果。集算器的集成開發(fā)環(huán)境右下角紅框中可以顯示demo數(shù)據(jù)庫的表名、字段名，可以方便程序員書寫sql語句。
和集算器提供的其他函數(shù)一樣，query函數(shù)包含選項和參數(shù)。如果寫成query@1(“select * from employee”)，@1是表示使用了1選項，查看函數(shù)說明可知，是僅僅返回sql語句取出的第一條記錄。而括號中是參數(shù)，上圖的括號中是一條sql語句的字符串，沒有其他參數(shù)，也就是說其他所有的參數(shù)都使用了默認(rèn)值。
上圖中的集算器網(wǎng)格程序可以集成到Java應(yīng)用中，作為集算器jdbc驅(qū)動被Java程序調(diào)用，具體方法是：
1、 準(zhǔn)備dfx文件。
2、 部署集算器jar包。
將調(diào)用集算器程序所必須的jar包放入Java應(yīng)用的classpath中。如果是
web應(yīng)用，可以放在WEB-INF/lib目錄下。這些jar包都位于集算器IDE的安裝目錄\esProc\lib下，包括：
dm.jar 集算器計算引擎及JDBC驅(qū)動包
poi-3.7-20101029.jar 處理對Excel文件的讀寫
log4j_128.jar 處理日志
icu4j_3_4_5.jar 處理國際化
dom4j-1.6.1.jar 解析配置文件
3、 部署數(shù)據(jù)庫驅(qū)動jar包。
將集算器連接數(shù)據(jù)庫所需要的數(shù)據(jù)庫jdbc驅(qū)動包也放入Java應(yīng)用的classpath中。例如：demo數(shù)據(jù)庫的hsql.jar。
4、 配置dfxConfig.xml、config.xml文件。
config.xml文件中包含了集算器的基本配置信息，如注冊碼、尋址路徑、主目錄、數(shù)據(jù)源配置等，可以在集算器安裝目錄的esProc\config路徑下找到，其中存儲的信息與集算器的選項頁面中設(shè)定相同。dfxConfig.xml可以在安裝目錄esProc\classes中找到。這里介紹集算器連接數(shù)據(jù)庫的部分配置，其他配置參見集算器教程。
1）配置數(shù)據(jù)源的方式之一：直接配置數(shù)據(jù)庫數(shù)據(jù)源連接參數(shù)。
config.xml文件：
<DBList> <!-- 數(shù)據(jù)源名稱，必須與dfx文件中的數(shù)據(jù)源名稱一致 --> <DBname="demo"> <propertyname="url" value="jdbc:hsqldb:hsql://127.0.0.1/demo"/> <propertyname="driver" value="org.hsqldb.jdbcDriver"/> <propertyname="type" value="HSQL"/> <propertyname="user" value="sa"/> <propertyname="password" value=""/> <propertyname="batchSize" value="1000"/> <!-- 是否自動連接。如果設(shè)定為true，則可以直接使用db.query()函數(shù)來訪問數(shù)據(jù)庫；如果為false，則不會自動連接，使用前必須用connect(db)語句連接。 --> <propertyname="autoConnect" value="true"/> <property name="useSchema"value="false"/> <propertyname="addTilde" value="false"/> </DB> </DBList> |
2）配置數(shù)據(jù)源的方式之二：在Java應(yīng)用中配置連接池和jndi，在dfxConfig.xml文件中指定jndi名稱。
dfxConfig.xml文件：
<jndi-ds-configs> <!-- jndi前綴 --> <jndi-prefix>java:comp/env</jndi-prefix> <!-- 數(shù)據(jù)源名稱，必須與dfx文件中的數(shù)據(jù)源名稱一致 --> <jndi-ds-config> <name>demo</name> <dbType>HSQL</dbType> <dbCharset>ISO-8859-1</dbCharset> <clientCharset>ISO-8859-1</clientCharset> <needTranContent>false</needTranContent> <needTranSentence>false</needTranSentence> <!-- 是否自動連接。如果設(shè)定為true，則可以直接使用db.query()函數(shù)來訪問數(shù)據(jù)庫；如果為false，則不會自動連接，使用前必須用connect(db)語句連接。 --> <autoConnect>true</autoConnect> </jndi-ds-config> </jndi-ds-configs> |
需要說明的是：
配置文件的名稱必須為config.xml和dfxConfig.xml，不能改變。
在配置數(shù)據(jù)庫連接信息時，要注意不能循環(huán)調(diào)用，不能將集算器JDBC本身作為數(shù)據(jù)源在配置中使用。
如果兩種方式都配置了同名的數(shù)據(jù)源，就以config.xml中的為準(zhǔn)。
5、 部署dfxConfig.xml、config.xml和test.dfx文件。
將dfxConfig.xml、config.xml放入Java應(yīng)用的類路徑下（classpath），也可以直接打包到dm.jar中。
將test.dfx文件放到Java應(yīng)用的類路徑下，也可以放到dfxConfig.xml文件的<paths/>節(jié)點指定的絕對路徑中。
6、 在java程序中調(diào)用test.dfx。
如果集算器 JDBC的連接串中使用了...?config=...；即用該.xml文件中的配置，忽略config.xml中的定義；連接串中無config參數(shù)時則用默認(rèn)配置。
例如：con=DriverManager.getConnection("jdbc:esproc:local://?config=myconfig.xml");則使用myconfig.xml中的定義。
樣例代碼如下：
public voidtestDataServer(){ Connection con = null; com.esproc.jdbc.InternalCStatementst; com.esproc.jdbc.InternalCStatement st2; try{ //建立連接 Class.forName("com.esproc.jdbc.InternalDriver"); con=DriverManager.getConnection("jdbc:esproc:local://"); //調(diào)用存儲過程，其中test是dfx的文件名 st =(com.esproc.jdbc.InternalCStatement)con.prepareCall("calltest(?)"); //設(shè)置參數(shù) st.setObject(1,"3"); //下面的語句和上面的調(diào)用方法效果相同 st =(com.esproc.jdbc.InternalCStatement)con.prepareCall("calltest(3)"); //執(zhí)行存儲過程 st.execute(); //獲取結(jié)果集 ResultSet set =st.getResultSet(); } catch(Exception e){ System.out.println(e); } finally{ //關(guān)閉連接 if(con!=null) { try { con.close(); } catch(Exception e){ System.out.println(e); } } } } |
嵌入式
數(shù)據(jù)庫是輕量級的，獨立的庫，沒有服務(wù)器組件，無需管理，一個小的代碼尺寸，以及有限的資源需求。目前有幾種嵌入式數(shù)據(jù)庫，你可以在
移動應(yīng)用程序中使用。讓我們來看看這些最流行的數(shù)據(jù)庫。
數(shù)據(jù)庫
數(shù)據(jù)類型存儲
License支持平臺
BerkeleyDBrelational, objects, key-value pairs, documentsAGPL 3.0
Android, iOS
Couchbase LitedocumentsApache 2.0Android, iOS
LevelDBkey-value pairsNew BSDAndroid, iOS
SQLiterelationalPublic DomainAndroid, iOS,
Windows Phone, Blackberry
UnQLitekey-value pairs, documentsBSD 2-ClauseAndroid, iOS, Windows Phone
1. Berkeley DB
Berkeley DB 是由美國 Sleepycat Software 公司開發(fā)的一套開放源代碼的嵌入式數(shù)據(jù)庫管理系統(tǒng)（已被
Oracle 收購），它為應(yīng)用程序提供可伸縮的、高性能的、有事務(wù)保護(hù)功能的數(shù)據(jù)管理服務(wù)。
Berkeley DB（BDB）是一個高效的嵌入式數(shù)據(jù)庫編程庫，C語言、C++、Java、Perl、
Python、Tcl 以及其他很多語言都有其對應(yīng)的 API。Berkeley DB 可以保存任意類型的鍵/值對（Key/Value Pair），而且可以為一個鍵保存多個數(shù)據(jù)。Berkeley DB 支持讓數(shù)千的并發(fā)線程同時操作數(shù)據(jù)庫，支持最大 256TB 的數(shù)據(jù)，廣泛用于各種
操作系統(tǒng)，其中包括大多數(shù)類 Unix 操作系統(tǒng)、Windows 操作系統(tǒng)以及實時操作系統(tǒng)。
2. Couchbase Lite
Couchbase Lite 是一個為滿足在線和離線的移動應(yīng)用所開發(fā)的超輕量的，可靠的，并且安全的 JSON 數(shù)據(jù)庫。即使在最不確定的網(wǎng)絡(luò)條件下，亦可以給您的移動應(yīng)用提供富有成效的和可靠的信譽(yù)。除此之外，’同步門戶’功能亦可以提供協(xié)作， 社交互動或者是用戶的更新。
3. LevelDB
LevelDB 是
Google 開源出的一個 Key/Value 存儲引擎，它采用 C++ 編寫的，支持高并發(fā)訪問和寫入，特別適合對于高寫入業(yè)務(wù)環(huán)境。
對于 LevelDB 的概覽可以參考數(shù)據(jù)分析與處理之二（Leveldb 實現(xiàn)原理）對 LevelDB 的一個描述，本文的圖解更多的是 LevelDB 的一個實現(xiàn)層的糾纏，版本為 LevelDB 1.7.02。
LevelDB 存儲主要分為 SSTable 和 MemTable，前者為不可變且存儲于持久設(shè)備上，后者位于內(nèi)存上并且可變(在 LevelDB 中有兩個 MemTable，一個為當(dāng)前寫入 MemTable，另一個為等待持久化的不可變 MemTable)。首先來看 SSTable 的實現(xiàn)層分析。
4. SQLite
SQLite 是一個開源的嵌入式關(guān)系數(shù)據(jù)庫，實現(xiàn)自包容、零配置、支持事務(wù)的
SQL 數(shù)據(jù)庫引擎。 其特點是高度便攜、使用方便、結(jié)構(gòu)緊湊、高效、可靠。 與其他數(shù)據(jù)庫管理系統(tǒng)不同，SQLite 的安裝和運(yùn)行非常簡單，在大多數(shù)情況下 - 只要確保 SQLite 的二進(jìn)制文件存在即可開始創(chuàng)建、連接和使用數(shù)據(jù)庫。如果您正在尋找一個嵌入式數(shù)據(jù)庫項目或解決方案，SQLite 是絕對值得考慮。
5. UnQLite
UnQLite 是，由 Symisc Systems 公司出品的一個嵌入式C語言軟件庫，它實現(xiàn)了一個自包含、無服務(wù)器、零配置、事務(wù)化的NoSQL 數(shù)據(jù)庫引擎。UnQLite是一個文檔存儲數(shù)據(jù)庫，類似于 MongoDB、Redis、CouchDB 等。同時，也是一個標(biāo)準(zhǔn)的 Key/Value 存儲，與 BerkeleyDB 和 LevelDB 等類似。
UnQLite 是一個嵌入式NoSQL（鍵/值存儲和文檔存儲）數(shù)據(jù)庫引擎。不同于其他絕大多數(shù) NoSQL 數(shù)據(jù)庫，UnQLite 沒有一個獨立的服務(wù)器進(jìn)程。UnQLite 直接讀/寫普通的磁盤文件。包含多個數(shù)據(jù)集的一個完整的數(shù)據(jù)庫，存儲在單一的磁盤文件中。數(shù)據(jù)庫文件格式是跨平臺的，可以在32位和64位系統(tǒng)或大端和小端架構(gòu)之間，自由拷貝一個數(shù)據(jù)庫