亚洲第一色欲AV|丰满无码人妻热妇无码喷水区|日韩成人一区二区|情五月亚洲天堂网

安全資訊

等保測評:CentOS登錄失敗參數(shù)說明和雙因素認證

本文上半部和等保聯(lián)絡不是很密切,還是說一了些linux里細節(jié)一些的東西,所以有可能會糟蹋你生命中的好幾分鐘,一起我運用的是centos6。

一、登錄失利處理功用參數(shù)詳解

等保測評主機安全:CentOS暗碼修正周期與登錄失利處理,登錄失利處理功用的上半段內容在這篇文章的下半部分,本篇文章主要說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內的登錄是無效的,輸入啥都不會讓你登進去的。

另外當你到達了第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內的句子,也便是添加失利計數(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銜接服務器,有些單位的內網(wǎng)直接能夠用wifi連上,防火墻那也沒對拜訪服務器長途端口的ip做出約束,只需連上wifi就能連服務器,那這種vpn的雙要素認證就不能認為是服務器的雙要素認證。

或許假如對拜訪長途端口的ip沒有做出約束,可是沒有內網(wǎng)wifi,要連內網(wǎng)就得拿網(wǎng)線跑去機房銜接的話,感覺也算是做了約束。

第二點

那天然便是登錄vpn要強制運用雙要素認證啦。

2.3. pam插件

另外一種比較雙要素認證的方法,關于centos等linux體系,便是經(jīng)過運用pam組件。

關于pam,請看等保測評主機安全:CentOS暗碼修正周期與登錄失利處理中的登錄失利處理功用部分,里邊對pam做了一個比較明晰的介紹。

不過這兒不妨能夠再說下,pam全名是可插拔認證模塊,比方登錄linux體系時,驗證用戶名暗碼其實便是經(jīng)過調用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進行長途銜接,用戶名本來就需要輸入,私鑰也要供給,私鑰的暗碼也要供給。

服務熱線

138-6598-3726

產(chǎn)品和特性

價格和優(yōu)惠

安徽靈狐網(wǎng)絡公眾號

微信公眾號