等保測評：CentOS登錄失敗參數說(shuō)明和雙因素認證
本文上半部和等保聯(lián)絡(luò )不是很密切，還是說(shuō)一了些linux里細節一些的東西，所以有可能會(huì )糟蹋你生命中的好幾分鐘，一起我運用的是centos6。
一、登錄失利處理功用參數詳解
等保測評主機安全：CentOS暗碼修正周期與登錄失利處理，登錄失利處理功用的上半段內容在這篇文章的下半部分，本篇文章主要說(shuō)pam_tally2的參數所代表的的意思。
在測評時(shí)，設計登錄失利處理功用，就少不了要運用pam_tally2（centos6和之后的版別），那么就有必要理解這個(gè)模塊各個(gè)參數（選項）的含義。
而網(wǎng)上關(guān)于pam_tally2參數材料，不能說(shuō)不對，可是總覺(jué)得不夠詳細和全面，所以寫(xiě)了這篇文章闡明闡明。
首要，先貼上常用的參數解說(shuō)，保證來(lái)源部分不會(huì )出錯，一起給出中文解說(shuō)，我們能夠對照著(zhù)看：
1.1. deny
這個(gè)就不用多說(shuō)了，登錄失利次數一旦大于等于該數值，所登錄的賬號就會(huì )被確定。
1.2. lock_time
這個(gè)比較不常見(jiàn)，如同一般都不怎么說(shuō)這個(gè)參數，這個(gè)參數的意思便是你每一次登錄失利后，在尚未到達deny所設置的次數時(shí)，會(huì )約束你登錄的時(shí)刻。
舉個(gè)例子，假如你設置deny是3，lock_time為10。那么你第1次和第2次登錄失利時(shí)，在10s內的登錄是無(wú)效的，輸入啥都不會(huì )讓你登進(jìn)去的。
另外當你到達了第3次登錄失利后，該參數失效，由unlock_time來(lái)接收。
1.3. unlock_time
這個(gè)就很常見(jiàn)了，意思便是當你登錄失利的次數大于等于deny所設置的數值時(shí)，賬號確定的時(shí)刻，就不必多解說(shuō)了吧？
1.4. magic_root
這個(gè)的意思也很簡(jiǎn)略，假如不包括這個(gè)參數，則哪怕是root也會(huì )添加失利計數，但留意，添加失利計數不代表root就會(huì )被確定，這是兩碼事。
在tally2的源代碼中表示如下（c言語(yǔ)）：
if (!(opts->ctrl & OPT_MAGIC_ROOT) || getuid) { /* magic_root doesn't change tally */ tally.fail_cnt += inc; if (tally.fail_cnt == TALLY_HI) { /* Overflow *and* underflow. */ tally.fail_cnt -= inc; pam_syslog(pamh, LOG_ALERT, "Tally %sflowed for user %s", (inc<0)?"under":"over",user); } }
if (!(opts->ctrl & OPT_MAGIC_ROOT) || getuid)很好解說(shuō)，便是當你傳入的參數中有magic_root選項且為root用戶(hù)時(shí)，整個(gè)表達式的值才為false，才不會(huì )去履行if內的句子，也便是添加失利計數：tally.fail_cnt += inc。
傳入的參數中有magic_root選項，則!(opts->ctrl & OPT_MAGIC_ROOT)部分的bool值為false是root用戶(hù)，而getuid的返回值是當時(shí)用戶(hù)的uid，所以該部分為0，轉為bool類(lèi)型則為false，則此時(shí)||運算符兩邊皆為false，所以不會(huì )履行。
而在源代碼的另外一處，tally_check函數中，有這樣的代碼：
if ((opts->ctrl & OPT_MAGIC_ROOT) && getuid == 0) { return PAM_SUCCESS; } /* magic_root skips tally check */
這個(gè)就更好解說(shuō)了，假如存在magic_root參數，且是root賬號，就不經(jīng)過(guò)履行下面的代碼，直接返回成功了。
那么假如是root賬號，但沒(méi)有設置magic_root參數呢？其實(shí)也不一定會(huì )對root賬號進(jìn)行確定設置，請看下一個(gè)參數。
1.5. even_deny_root
意思便是說(shuō)，有這個(gè)參數，只需到達了deny設定的值，root賬號照樣也會(huì )被確定。
在tally_check函數中，假如是root賬號，但沒(méi)有設置magic_root參數，則代碼會(huì )往下履行，其中有一個(gè)if判斷如下：
if (opts->deny != 0 && /* deny==0 means no deny */ tally->fail_cnt > opts->deny && /* tally>deny means exceeded */ ((opts->ctrl & OPT_DENY_ROOT) || uid)) { /* even_deny stops uid check */
留意看((opts->ctrl & OPT_DENY_ROOT) || uid))，意思假如沒(méi)有設置even_deny_root選項，且uid為0也便是root賬號的情況下，if句子塊的代碼就不會(huì )履行。
同樣反過(guò)來(lái)，只需設置even_deny_root選項，不管啥賬號，都會(huì )履行if句子塊的代碼。 或許沒(méi)有設置even_deny_root選項，但不是root賬號，也會(huì )履行if句子塊的代碼。
插一句，在tally2源代碼中，對傳入選項的解析階段，有這么一段：
else if ( ! strcmp( *argv, "even_deny_root_account" ) || ! strcmp( *argv, "even_deny_root" ) ) { log_phase_no_auth(pamh, phase, *argv); opts->ctrl |= OPT_DENY_ROOT; }
也便是說(shuō)傳入even_deny_root_account如同也是能夠的，可能是為了兼容曾經(jīng)的版別什么的？
1.6. root_unlock_time
這個(gè)便是和even_deny_root合作運用的，假如root賬號被確定，則它所確定的時(shí)刻。
這兒就有一個(gè)問(wèn)題，假如只有even_deny_root選項，沒(méi)有設置root_unlock_time選項，root賬號會(huì )被確定多久？
解說(shuō)中如同沒(méi)說(shuō)，直接看tally2解析傳入選項的源代碼的倒數第二句：
if (opts->root_unlock_time == -1) opts->root_unlock_time = opts->unlock_time;
root_unlock_time的默認值是-1，所以假如發(fā)現你沒(méi)有給它進(jìn)行設置，在最終，它就會(huì )等于unlock_time。
反過(guò)來(lái)，假如只有root_unlock_time而沒(méi)有even_deny_root，又會(huì )怎么樣？
能夠看tally2解析傳入選項的源代碼：
else if ( ! strncmp( *argv, "root_unlock_time=", 17 ) ) { log_phase_no_auth(pamh, phase, *argv); if ( sscanf((*argv)+17,"%ld",&opts->root_unlock_time) != 1 ) { pam_syslog(pamh, LOG_ERR, "bad number supplied: %s", *argv); return PAM_AUTH_ERR; } opts->ctrl |= OPT_DENY_ROOT; /* even_deny_root implied */ }
如同是假如傳入了root_unlock_time且能夠轉化為數字的話(huà)，就相當于傳入了even_deny_root參數。
啰嗦了這么多，應該把常用參數解說(shuō)清楚了。
關(guān)于這些參數，假如光看網(wǎng)上搜的材料，發(fā)現有不清楚的地方，就應該直接去看man里邊的解說(shuō)。 假如解說(shuō)里邊寫(xiě)得也不夠理解，那么就直接看代碼。
不管怎么說(shuō)，代碼總是功用的直接表現，是不會(huì )產(chǎn)生困惑的。
二、雙要素認證
這一部分沒(méi)有特別明確的標準，所以?xún)H為個(gè)人經(jīng)歷，而我又沒(méi)多少經(jīng)歷，所以假如有過(guò)錯請見(jiàn)諒。
2.1. 堡壘機
其實(shí)常用的的做法便是，經(jīng)過(guò)堡壘機來(lái)管理服務(wù)器。 一起，堡壘機運用雙要素認證，從而直接的到達了服務(wù)器的雙要素認證。
可是首要，這種方法如同不能被認為是認證：
不過(guò)假如就算被認為是雙要素認證，也有兩點(diǎn)值得留意。
第一點(diǎn)
堡壘機有必要強制運用雙要素認證方法，而不是任選一種方法進(jìn)行登錄。
第二點(diǎn)
堡壘機所管理的服務(wù)器，有必要對銜接方法進(jìn)行約束，經(jīng)過(guò)防火墻或許網(wǎng)絡(luò )設備什么的，保證只能經(jīng)過(guò)堡壘機進(jìn)行銜接。否則，就算堡壘機強制運用雙要素認證，但服務(wù)器還是能經(jīng)過(guò)長(cháng)途桌面或許ssh連上去，那堡壘機的雙要素認證就含義不大了。
2.2. VPN
VPN方法和堡壘機有點(diǎn)像，vpn本身也能夠運用雙要素進(jìn)行身份鑒別，比方SANGFOR SSL VPN，就能夠在控制臺中進(jìn)行設置（功用如同挺多的，能夠做很多設置）：
但要害的還是要看配置有沒(méi)有做全面：
第一點(diǎn)
只能經(jīng)過(guò)vpn銜接服務(wù)器，有些單位的內網(wǎng)直接能夠用wifi連上，防火墻那也沒(méi)對拜訪(fǎng)服務(wù)器長(cháng)途端口的ip做出約束，只需連上wifi就能連服務(wù)器，那這種vpn的雙要素認證就不能認為是服務(wù)器的雙要素認證。
或許假如對拜訪(fǎng)長(cháng)途端口的ip沒(méi)有做出約束，可是沒(méi)有內網(wǎng)wifi，要連內網(wǎng)就得拿網(wǎng)線(xiàn)跑去機房銜接的話(huà)，感覺(jué)也算是做了約束。
第二點(diǎn)
那天然便是登錄vpn要強制運用雙要素認證啦。
2.3. pam插件
另外一種比較雙要素認證的方法，關(guān)于centos等linux體系，便是經(jīng)過(guò)運用pam組件。
關(guān)于pam，請看等保測評主機安全：CentOS暗碼修正周期與登錄失利處理中的登錄失利處理功用部分，里邊對pam做了一個(gè)比較明晰的介紹。
不過(guò)這兒不妨能夠再說(shuō)下，pam全名是可插拔認證模塊，比方登錄linux體系時(shí)，驗證用戶(hù)名暗碼其實(shí)便是經(jīng)過(guò)調用pam的一個(gè)驗證模塊——pam_unix。
而這個(gè)模塊干的事情，也便是提示你輸入用戶(hù)名和暗碼，然后應該是別離和passwd以及shadow文件進(jìn)行比照，最終返回成功或失利。
所以，想實(shí)現雙要素認證，比方“用戶(hù)名/口令”+“手機短信”的認證方法，完全能夠直接修正pam_unix模塊（c言語(yǔ)），添加“手機短信”驗證功用。
又或許添加一個(gè)自定義驗證模塊，里邊運用手機短信驗證，然后經(jīng)過(guò)配置文件中的控制符號，讓這個(gè)自定義的模塊和pam_unix模塊都成功才驗證成功，也能實(shí)現作用。
至于詳細有沒(méi)有這樣的模塊?我們百度查找centos 雙要素認證即可，詳細就不說(shuō)了，網(wǎng)上的材料介紹得還是很明晰的。
2.4. ssh密鑰方法登錄
這個(gè)我也不知道是不是啊，可是我感覺(jué)如同能夠算是？
簡(jiǎn)略來(lái)說(shuō)便是關(guān)于centos等linux體系，在ssh的配置文件中，禁掉用戶(hù)名、暗碼登錄方法，運用密鑰（公鑰/私鑰）+私鑰暗碼的方法進(jìn)行登錄。
網(wǎng)上材料如下：
[root@host ~]$ ssh-keygen <== 樹(shù)立密鑰對 Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): <== 按 Enter Created directory '/root/.ssh'. Enter passphrase (empty for no passphrase): <== 輸入密鑰鎖碼，或直接按 Enter 留空 Enter same passphrase again: <== 再輸入一遍密鑰鎖碼 Your identification has been saved in /root/.ssh/id_rsa. <== 私鑰 Your public key has been saved in /root/.ssh/id_rsa.pub. <== 公鑰 The key fingerprint is: 0f:d3:e7:1a:1c:bd:5c:03:f1:19:f1:22:df:9b:cc:08 root@host
留意，在樹(shù)立密鑰對的時(shí)分是能夠設置私鑰的暗碼的。
這樣，你進(jìn)行登錄的時(shí)分，比方運用xshell進(jìn)行長(cháng)途銜接，用戶(hù)名本來(lái)就需要輸入，私鑰也要供給，私鑰的暗碼也要供給。
一、登錄失利處理功用參數詳解
等保測評主機安全：CentOS暗碼修正周期與登錄失利處理，登錄失利處理功用的上半段內容在這篇文章的下半部分，本篇文章主要說(shuō)pam_tally2的參數所代表的的意思。
在測評時(shí)，設計登錄失利處理功用，就少不了要運用pam_tally2（centos6和之后的版別），那么就有必要理解這個(gè)模塊各個(gè)參數（選項）的含義。
而網(wǎng)上關(guān)于pam_tally2參數材料，不能說(shuō)不對，可是總覺(jué)得不夠詳細和全面，所以寫(xiě)了這篇文章闡明闡明。
首要，先貼上常用的參數解說(shuō)，保證來(lái)源部分不會(huì )出錯，一起給出中文解說(shuō)，我們能夠對照著(zhù)看：
1.1. deny
這個(gè)就不用多說(shuō)了，登錄失利次數一旦大于等于該數值，所登錄的賬號就會(huì )被確定。
1.2. lock_time
這個(gè)比較不常見(jiàn)，如同一般都不怎么說(shuō)這個(gè)參數，這個(gè)參數的意思便是你每一次登錄失利后，在尚未到達deny所設置的次數時(shí)，會(huì )約束你登錄的時(shí)刻。
舉個(gè)例子，假如你設置deny是3，lock_time為10。那么你第1次和第2次登錄失利時(shí)，在10s內的登錄是無(wú)效的，輸入啥都不會(huì )讓你登進(jìn)去的。
另外當你到達了第3次登錄失利后，該參數失效，由unlock_time來(lái)接收。
1.3. unlock_time
這個(gè)就很常見(jiàn)了，意思便是當你登錄失利的次數大于等于deny所設置的數值時(shí)，賬號確定的時(shí)刻，就不必多解說(shuō)了吧？
1.4. magic_root
這個(gè)的意思也很簡(jiǎn)略，假如不包括這個(gè)參數，則哪怕是root也會(huì )添加失利計數，但留意，添加失利計數不代表root就會(huì )被確定，這是兩碼事。
在tally2的源代碼中表示如下（c言語(yǔ)）：
if (!(opts->ctrl & OPT_MAGIC_ROOT) || getuid) { /* magic_root doesn't change tally */ tally.fail_cnt += inc; if (tally.fail_cnt == TALLY_HI) { /* Overflow *and* underflow. */ tally.fail_cnt -= inc; pam_syslog(pamh, LOG_ALERT, "Tally %sflowed for user %s", (inc<0)?"under":"over",user); } }
if (!(opts->ctrl & OPT_MAGIC_ROOT) || getuid)很好解說(shuō)，便是當你傳入的參數中有magic_root選項且為root用戶(hù)時(shí)，整個(gè)表達式的值才為false，才不會(huì )去履行if內的句子，也便是添加失利計數：tally.fail_cnt += inc。
傳入的參數中有magic_root選項，則!(opts->ctrl & OPT_MAGIC_ROOT)部分的bool值為false是root用戶(hù)，而getuid的返回值是當時(shí)用戶(hù)的uid，所以該部分為0，轉為bool類(lèi)型則為false，則此時(shí)||運算符兩邊皆為false，所以不會(huì )履行。
而在源代碼的另外一處，tally_check函數中，有這樣的代碼：
if ((opts->ctrl & OPT_MAGIC_ROOT) && getuid == 0) { return PAM_SUCCESS; } /* magic_root skips tally check */
這個(gè)就更好解說(shuō)了，假如存在magic_root參數，且是root賬號，就不經(jīng)過(guò)履行下面的代碼，直接返回成功了。
那么假如是root賬號，但沒(méi)有設置magic_root參數呢？其實(shí)也不一定會(huì )對root賬號進(jìn)行確定設置，請看下一個(gè)參數。
1.5. even_deny_root
意思便是說(shuō)，有這個(gè)參數，只需到達了deny設定的值，root賬號照樣也會(huì )被確定。
在tally_check函數中，假如是root賬號，但沒(méi)有設置magic_root參數，則代碼會(huì )往下履行，其中有一個(gè)if判斷如下：
if (opts->deny != 0 && /* deny==0 means no deny */ tally->fail_cnt > opts->deny && /* tally>deny means exceeded */ ((opts->ctrl & OPT_DENY_ROOT) || uid)) { /* even_deny stops uid check */
留意看((opts->ctrl & OPT_DENY_ROOT) || uid))，意思假如沒(méi)有設置even_deny_root選項，且uid為0也便是root賬號的情況下，if句子塊的代碼就不會(huì )履行。
同樣反過(guò)來(lái)，只需設置even_deny_root選項，不管啥賬號，都會(huì )履行if句子塊的代碼。 或許沒(méi)有設置even_deny_root選項，但不是root賬號，也會(huì )履行if句子塊的代碼。
插一句，在tally2源代碼中，對傳入選項的解析階段，有這么一段：
else if ( ! strcmp( *argv, "even_deny_root_account" ) || ! strcmp( *argv, "even_deny_root" ) ) { log_phase_no_auth(pamh, phase, *argv); opts->ctrl |= OPT_DENY_ROOT; }
也便是說(shuō)傳入even_deny_root_account如同也是能夠的，可能是為了兼容曾經(jīng)的版別什么的？
1.6. root_unlock_time
這個(gè)便是和even_deny_root合作運用的，假如root賬號被確定，則它所確定的時(shí)刻。
這兒就有一個(gè)問(wèn)題，假如只有even_deny_root選項，沒(méi)有設置root_unlock_time選項，root賬號會(huì )被確定多久？
解說(shuō)中如同沒(méi)說(shuō)，直接看tally2解析傳入選項的源代碼的倒數第二句：
if (opts->root_unlock_time == -1) opts->root_unlock_time = opts->unlock_time;
root_unlock_time的默認值是-1，所以假如發(fā)現你沒(méi)有給它進(jìn)行設置，在最終，它就會(huì )等于unlock_time。
反過(guò)來(lái)，假如只有root_unlock_time而沒(méi)有even_deny_root，又會(huì )怎么樣？
能夠看tally2解析傳入選項的源代碼：
else if ( ! strncmp( *argv, "root_unlock_time=", 17 ) ) { log_phase_no_auth(pamh, phase, *argv); if ( sscanf((*argv)+17,"%ld",&opts->root_unlock_time) != 1 ) { pam_syslog(pamh, LOG_ERR, "bad number supplied: %s", *argv); return PAM_AUTH_ERR; } opts->ctrl |= OPT_DENY_ROOT; /* even_deny_root implied */ }
如同是假如傳入了root_unlock_time且能夠轉化為數字的話(huà)，就相當于傳入了even_deny_root參數。
啰嗦了這么多，應該把常用參數解說(shuō)清楚了。
關(guān)于這些參數，假如光看網(wǎng)上搜的材料，發(fā)現有不清楚的地方，就應該直接去看man里邊的解說(shuō)。 假如解說(shuō)里邊寫(xiě)得也不夠理解，那么就直接看代碼。
不管怎么說(shuō)，代碼總是功用的直接表現，是不會(huì )產(chǎn)生困惑的。
二、雙要素認證
這一部分沒(méi)有特別明確的標準，所以?xún)H為個(gè)人經(jīng)歷，而我又沒(méi)多少經(jīng)歷，所以假如有過(guò)錯請見(jiàn)諒。
2.1. 堡壘機
其實(shí)常用的的做法便是，經(jīng)過(guò)堡壘機來(lái)管理服務(wù)器。 一起，堡壘機運用雙要素認證，從而直接的到達了服務(wù)器的雙要素認證。
可是首要，這種方法如同不能被認為是認證：
不過(guò)假如就算被認為是雙要素認證，也有兩點(diǎn)值得留意。
第一點(diǎn)
堡壘機有必要強制運用雙要素認證方法，而不是任選一種方法進(jìn)行登錄。
第二點(diǎn)
堡壘機所管理的服務(wù)器，有必要對銜接方法進(jìn)行約束，經(jīng)過(guò)防火墻或許網(wǎng)絡(luò )設備什么的，保證只能經(jīng)過(guò)堡壘機進(jìn)行銜接。否則，就算堡壘機強制運用雙要素認證，但服務(wù)器還是能經(jīng)過(guò)長(cháng)途桌面或許ssh連上去，那堡壘機的雙要素認證就含義不大了。
2.2. VPN
VPN方法和堡壘機有點(diǎn)像，vpn本身也能夠運用雙要素進(jìn)行身份鑒別，比方SANGFOR SSL VPN，就能夠在控制臺中進(jìn)行設置（功用如同挺多的，能夠做很多設置）：
但要害的還是要看配置有沒(méi)有做全面：
第一點(diǎn)
只能經(jīng)過(guò)vpn銜接服務(wù)器，有些單位的內網(wǎng)直接能夠用wifi連上，防火墻那也沒(méi)對拜訪(fǎng)服務(wù)器長(cháng)途端口的ip做出約束，只需連上wifi就能連服務(wù)器，那這種vpn的雙要素認證就不能認為是服務(wù)器的雙要素認證。
或許假如對拜訪(fǎng)長(cháng)途端口的ip沒(méi)有做出約束，可是沒(méi)有內網(wǎng)wifi，要連內網(wǎng)就得拿網(wǎng)線(xiàn)跑去機房銜接的話(huà)，感覺(jué)也算是做了約束。
第二點(diǎn)
那天然便是登錄vpn要強制運用雙要素認證啦。
2.3. pam插件
另外一種比較雙要素認證的方法，關(guān)于centos等linux體系，便是經(jīng)過(guò)運用pam組件。
關(guān)于pam，請看等保測評主機安全：CentOS暗碼修正周期與登錄失利處理中的登錄失利處理功用部分，里邊對pam做了一個(gè)比較明晰的介紹。
不過(guò)這兒不妨能夠再說(shuō)下，pam全名是可插拔認證模塊，比方登錄linux體系時(shí)，驗證用戶(hù)名暗碼其實(shí)便是經(jīng)過(guò)調用pam的一個(gè)驗證模塊——pam_unix。
而這個(gè)模塊干的事情，也便是提示你輸入用戶(hù)名和暗碼，然后應該是別離和passwd以及shadow文件進(jìn)行比照，最終返回成功或失利。
所以，想實(shí)現雙要素認證，比方“用戶(hù)名/口令”+“手機短信”的認證方法，完全能夠直接修正pam_unix模塊（c言語(yǔ)），添加“手機短信”驗證功用。
又或許添加一個(gè)自定義驗證模塊，里邊運用手機短信驗證，然后經(jīng)過(guò)配置文件中的控制符號，讓這個(gè)自定義的模塊和pam_unix模塊都成功才驗證成功，也能實(shí)現作用。
至于詳細有沒(méi)有這樣的模塊?我們百度查找centos 雙要素認證即可，詳細就不說(shuō)了，網(wǎng)上的材料介紹得還是很明晰的。
2.4. ssh密鑰方法登錄
這個(gè)我也不知道是不是啊，可是我感覺(jué)如同能夠算是？
簡(jiǎn)略來(lái)說(shuō)便是關(guān)于centos等linux體系，在ssh的配置文件中，禁掉用戶(hù)名、暗碼登錄方法，運用密鑰（公鑰/私鑰）+私鑰暗碼的方法進(jìn)行登錄。
網(wǎng)上材料如下：
[root@host ~]$ ssh-keygen <== 樹(shù)立密鑰對 Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): <== 按 Enter Created directory '/root/.ssh'. Enter passphrase (empty for no passphrase): <== 輸入密鑰鎖碼，或直接按 Enter 留空 Enter same passphrase again: <== 再輸入一遍密鑰鎖碼 Your identification has been saved in /root/.ssh/id_rsa. <== 私鑰 Your public key has been saved in /root/.ssh/id_rsa.pub. <== 公鑰 The key fingerprint is: 0f:d3:e7:1a:1c:bd:5c:03:f1:19:f1:22:df:9b:cc:08 root@host
留意，在樹(shù)立密鑰對的時(shí)分是能夠設置私鑰的暗碼的。
這樣，你進(jìn)行登錄的時(shí)分，比方運用xshell進(jìn)行長(cháng)途銜接，用戶(hù)名本來(lái)就需要輸入，私鑰也要供給，私鑰的暗碼也要供給。
