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