确保登录服务器验证时安全 确保登录服务器验证时安全吗

怎么保证远程登录服务器安全

　“远程桌面”面板下方有一个“选择用户”的按钮,点击之后,在“远程桌面用户” 窗口中点击“添加”按钮键入允许的用户,或者通过“高级→立即查找”添加用户。远程的登录具有一定的风险,所以可登录的帐户一定要控制好。还可以设置为只允许特定的IP访问(例如只允许管理员网段访问)—由于限制较大,这个要根据实际情况来操作的。

创新互联公司服务项目包括南华网站建设、南华网站制作、南华网页制作以及南华网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，南华网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到南华省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！

如何保障Web服务器安全

不但企业的门户网站被篡改、资料被窃取，而且还成为了病毒与木马的传播者。有些Web管理员采取了一些措施，虽然可以保证门户网站的主页不被篡改，但是却很难避免自己的网站被当作肉鸡，来传播病毒、恶意插件、木马等等。笔者认为，这很大一部分原因是管理员在Web安全防护上太被动。他们只是被动的防御。为了彻底提高Web服务器的安全，笔者认为，Web安全要主动出击。具体的来说，需要做到如下几点。 一、在代码编写时就要进行漏洞测试 现在的企业网站做的越来越复杂、功能越来越强。不过这些都不是凭空而来的，是通过代码堆积起来的。如果这个代码只供企业内部使用，那么不会带来多大的安全隐患。但是如果放在互联网上使用的话，则这些为实现特定功能的代码就有可能成为攻击者的目标。笔者举一个简单的例子。在网页中可以嵌入SQL代码。而攻击者就可以利用这些SQL代码来发动攻击，来获取管理员的密码等等破坏性的动作。有时候访问某些网站还需要有某些特定的控件。用户在安装这些控件时，其实就有可能在安装一个木马(这可能访问者与被访问者都没有意识到)。 为此在为网站某个特定功能编写代码时，就要主动出击。从编码的设计到编写、到测试，都需要认识到是否存在着安全的漏洞。笔者在日常过程中，在这方面对于员工提出了很高的要求。各个员工必须对自己所开发的功能负责。至少现在已知的病毒、木马不能够在你所开发的插件中有机可乘。通过这层层把关，就可以提高代码编写的安全性。 二、对Web服务器进行持续的监控 冰冻三尺、非一日之寒。这就好像人生病一样，都有一个过程。病毒、木马等等在攻击Web服务器时，也需要一个过程。或者说，在攻击取得成功之前，他们会有一些试探性的动作。如对于一个采取了一定安全措施的Web服务器，从攻击开始到取得成果，至少要有半天的时间。如果Web管理员对服务器进行了全天候的监控。在发现有异常行为时，及早的采取措施，将病毒与木马阻挡在门户之外。这种主动出击的方式，就可以大大的提高Web服务器的安全性。 笔者现在维护的Web服务器有好几十个。现在专门有一个小组，来全天候的监控服务器的访问。平均每分钟都可以监测到一些试探性的攻击行为。其中99%以上的攻击行为，由于服务器已经采取了对应的安全措施，都无功而返。不过每天仍然会遇到一些攻击行为。这些攻击行为可能是针对新的漏洞，或者采取了新的攻击方式。在服务器上原先没有采取对应的安全措施。如果没有及时的发现这种行为，那么他们就很有可能最终实现他们的非法目的。相反，现在及早的发现了他们的攻击手段，那么我们就可以在他们采取进一步行动之前，就在服务器上关掉这扇门，补上这个漏洞。 笔者在这里也建议，企业用户在选择互联网Web服务器提供商的时候，除了考虑性能等因素之外，还要评估服务提供商能否提供全天候的监控机制。在Web安全上主动出击，及时发现攻击者的攻击行为。在他们采取进一步攻击措施之前，就他们消除在萌芽状态。 三、设置蜜罐，将攻击者引向错误的方向 在军队中，有时候会给军人一些伪装，让敌人分不清真伪。其实在跟病毒、木马打交道时，本身就是一场无硝烟的战争。为此对于Web服务器采取一些伪装，也能够将攻击者引向错误的方向。等到供给者发现自己的目标错误时，管理员已经锁定了攻击者，从而可以及早的采取相应的措施。笔者有时候将这种主动出击的行为叫做蜜罐效应。简单的说，就是设置两个服务器。其中一个是真正的服务器，另外一个是蜜罐。现在需要做的是，如何将真正的服务器伪装起来，而将蜜罐推向公众。让攻击者认为蜜罐服务器才是真正的服务器。要做到这一点的话，可能需要从如下几个方面出发。 一是有真有假，难以区分。如果要瞒过攻击者的眼睛，那么蜜罐服务器就不能够做的太假。笔者在做蜜罐服务器的时候，80%以上的内容都是跟真的服务器相同的。只有一些比较机密的信息没有防治在蜜罐服务器上。而且蜜罐服务器所采取的安全措施跟真的服务器事完全相同的。这不但可以提高蜜罐服务器的真实性，而且也可以用来评估真实服务器的安全性。一举两得。 二是需要有意无意的将攻击者引向蜜罐服务器。攻击者在判断一个Web服务器是否值得攻击时，会进行评估。如评估这个网站的流量是否比较高。如果网站的流量不高，那么即使被攻破了，也没有多大的实用价值。攻击者如果没有有利可图的话，不会花这么大的精力在这个网站服务器上面。如果要将攻击者引向这个蜜罐服务器的话，那么就需要提高这个蜜罐服务器的访问量。其实要做到这一点也非常的容易。现在有很多用来交互流量的团队。只要花一点比较小的投资就可以做到这一点。 三是可以故意开一些后门让攻击者来钻。作为Web服务器的管理者，不仅关心自己的服务器是否安全，还要知道自己的服务器有没有被人家盯上。或者说，有没有被攻击的价值。此时管理者就需要知道，自己的服务器一天被攻击了多少次。如果攻击的频率比较高，管理者就高兴、又忧虑。高兴的是自己的服务器价值还蛮大的，被这么多人惦记着。忧虑的是自己的服务器成为了众人攻击的目标。就应该抽取更多的力量来关注服务器的安全。 四、专人对Web服务器的安全性进行测试 俗话说，靠人不如靠自己。在Web服务器的攻防战上，这一个原则也适用。笔者建议，如果企业对于Web服务的安全比较高，如网站服务器上有电子商务交易平台，此时最好设置一个专业的团队。他们充当攻击者的角色，对服务器进行安全性的测试。这个专业团队主要执行如下几个任务。 一是测试Web管理团队对攻击行为的反应速度。如可以采用一些现在比较流行的攻击手段，对自己的Web服务器发动攻击。当然这个时间是随机的。预先Web管理团队并不知道。现在要评估的是，Web管理团队在多少时间之内能够发现这种攻击的行为。这也是考验管理团队全天候跟踪的能力。一般来说，这个时间越短越好。应该将这个时间控制在可控的范围之内。即使攻击最后没有成功，Web管理团队也应该及早的发现攻击的行为。毕竟有没有发现、与最终有没有取得成功，是两个不同的概念。 二是要测试服务器的漏洞是否有补上。毕竟大部分的攻击行为，都是针对服务器现有的漏洞所产生的。现在这个专业团队要做的就是，这些已发现的漏洞是否都已经打上了安全补丁或者采取了对应的安全措施。有时候我们都没有发现的漏洞是无能为力，但是对于这些已经存在的漏洞不能够放过。否则的话，也太便宜那些攻击者了。

如何在Linux上用一次性密码确保SSH登录安全

第一步：在Linux上安装和配置OTPW

在Debian、Ubuntu或Linux Mint上：

用apt-get安装OTPW程序包。

$ sudo apt-get install libpam-otpw otpw-bin

使用文本编辑工具，打开SSH的PAM配置文件(/etc/pam.d/sshd)，注释掉下面这行代码(以禁用密码验证)。

#@include common-auth

然后添加下面两行代码(以启用一次性密码验证)：

auth required pam_otpw.so

session optional pam_otpw.so

在Fedora或CentOS/RHEL上：

在基于红帽的系统上，没有作为预制程序包的OTPW。于是，我们通过从源代码来构建的方法，安装OTPW。

首先，安装基本组件：

$ sudo yum git gcc pam-devel

$ git clone

$ cd otpw

使用文本编辑工具打开Makefile，编辑以“PAMLIB=”开头的这一行，如下所示。

在64位系统上：

PAMLIB=/usr/lib64/security

在32位系统上：

PAMLIB=/usr/lib/security

编译后安装。请注意：安装环节会自动重启SSH服务器。所以如果你使用SSH连接，就要准备好断开。

$ make

$ sudo make install

现在你需要更新SELinux策略，因为/usr/sbin/sshd试图写入到用户的主目录，而默认的SELinux策略不允许这个操作。下面这些命令可以起到更新策略的作用。如果你不使用SELinux，跳过这一步好了。

$ sudo grep sshd /var/log/audit/audit.log | audit2allow -M mypol

$ sudo semodule -i mypol.pp

下一步，用文本编辑工具打开SSH的PAM配置文件(/etc/pam.d/sshd)，注释掉下面这行代码(以禁用密码验证)。

#auth substack password-auth

然后添加下面两行代码(以启用一次性密码验证)：

auth required pam_otpw.so

session optional pam_otpw.so

第二步：针对一次性密码配置SSH服务器

下一步是配置SSH服务器，以接受一次性密码。

用文本编辑工具打开/etc/ssh/sshd_config，设置下列三个参数。确保你没有不止一次地添加这几行，因为那会引起SSH服务器失效。

UsePrivilegeSeparation yes

ChallengeResponseAuthentication yes

UsePAM yes

你还需要禁用默认的密码验证。可以视情况，禁用公密验证，那样万一你没有一次性密码，就可以恢复到基于密钥的验证。

PubkeyAuthentication yes

PasswordAuthentication no

现在，重启SSH服务器。

在Debian、Ubuntu或Linux Mint上：

$ sudo service ssh restart

在Fedora或CentOS/RHEL 7上：

$ sudo systemctl restart sshd

第三步：用OTPW生成一次性密码

如前所述，你需要事先创建一次性密码，并将它们存储在远程SSH服务器主机上。为此，以你登录时所用的用户身份运行otpw-gen工具。

$ cd ~

$ otpw-gen temporary_password.txt

它会要求你设置一个前缀密码。你以后登录时，就需要输入这个前缀密码以及一次性密码。实际上前缀密码是另一层保护机制。即使密码表落到了不法分子手里，前缀密码也会迫使对方采用蛮力攻击。

一旦前缀密码设置完毕，命令会生成280个一次性密码，并将它们存储在输出文本文件(比如temporary_password.txt)中。每个密码(默认情况下长度是8个字符)的前面是三位数的索引号。你可以将文件打印在纸张上，随身携带。

你还会看到~/.otpw文件已创建，这些密码的密码散列就存储在其中。每一行的头三位表明了将用于SSH登录的密码的索引号。

$ more ~/.otpw

OTPW1

280 3 12 8

191ai+:ENwmMqwn

218tYRZc%PIY27a

241ve8ns%NsHFmf

055W4/YCauQJkr:

102ZnJ4VWLFrk5N

2273Xww55hteJ8Y

1509d4b5=A64jBT

168FWBXY%ztm9j%

000rWUSdBYr%8UE

037NvyryzcI+YRX

122rEwA3GXvOk=z

测试用于SSH登录的一次性密码

现在，不妨像平常那样登录到SSH服务器：

$ ssh user@remote_host

如果OTPW成功设置，你会看到略有不同的密码提示符：

Password 191:

现在打开密码表，寻找密码表中的索引号“191”。

023 kBvp tq/G 079 jKEw /HRM 135 oW/c /UeB 191 fOO+ PeiD 247 vAnZ EgUt

据上面密码表显示，编号“191”的一次性密码是“fOO+PeiD”。你需要在前面加上前缀密码。比如说，如果你的前缀密码是“000”，那么需要输入的实际的一次性密码是“000fOO+PeiD”。

一旦你成功登录，所使用的密码会自动作废。如果你查看~/.otpw，就会注意到第一行被换成了“---------------”，这意味着密码“191”已经无效。

OTPW1

280 3 12 8

---------------

218tYRZc%PIY27a

241ve8ns%NsHFmf

055W4/YCauQJkr:

102ZnJ4VWLFrk5N

2273Xww55hteJ8Y

1509d4b5=A64jBT

168FWBXY%ztm9j%

000rWUSdBYr%8UE

037NvyryzcI+YRX

122rEwA3GXvOk=z

app的登录认证与安全

粗略地分析， 登录机制主要分为登录验证、登录保持、登出三个部分。登录验证是指客户端提供用户名和密码，向服务器提出登录请求，服务器判断客户端是否可以登录并向客户端确认。 登录认保持是指客户端登录后， 服务器能够分辨出已登录的客户端，并为其持续提供登录权限的服务器。登出是指客户端主动退出登录状态。容易想到的方案是，客户端登录成功后， 服务器为其分配sessionId, 客户端随后每次请求资源时都带上sessionId。

上述简易的登录验证策略存在明显的安全漏洞,需要优化。

客户端第一次发出登录请求时， 用户密码以明文的方式传输， 一旦被截获， 后果严重。因此密码需要加密，例如可采用RSA非对称加密。具体流程如下：

再仔细核对上述登录流程， 我们发现服务器判断用户是否登录， 完全依赖于sessionId, 一旦其被截获， 黑客就能够模拟出用户的请求。于是我们需要引入token的概念： 用户登录成功后， 服务器不但为其分配了sessionId, 还分配了token， token是维持登录状态的关键秘密数据。在服务器向客户端发送的token数据，也需要加密。于是一次登录的细节再次扩展。

在最原始的方案中， 登录保持仅仅靠服务器生成的sessionId: 客户端的请求中带上sessionId, 如果服务器的redis中存在这个id，就认为请求来自相应的登录客户端。 但是只要sessionId被截获， 请求就可以为伪造， 存在安全隐患。

引入token后，上述问题便可得到解决。 服务器将token和其它的一些变量， 利用散列加密算法得到签名后，连同sessionId一并发送给服务器； 服务器取出保存于服务器端的token,利用相同的法则生成校验签名， 如果客户端签名与服务器的校验签名一致， 就认为请求来自登录的客户端。

1.3 TOKEN失效

用户登录出系统

失效原理：

在服务器端的redis中删除相应key为session的键值对。

App因为要实现自动登陆功能，所以必然要保存一些凭据，所以比较复杂。

App登陆要实现的功能：

这里判断时间，主要是防止攻击者截取到加密串后，可以长久地利用这个加密串来登陆。

不用AES加密，用RSA公钥加密也是可以的。AES速度比RSA要快，RSA只能存储有限的数据。