Questions tagged «security»

如果您已经关注unix.stackexchange.com一段时间了，那么您现在应该希望知道，echo $var在Bourne / POSIX shell（zsh是例外）的列表上下文中（如）在列表上下文中不加引号的变量具有非常特殊的含义，并且除非您有充分的理由，否则不应该这样做。 在此处的许多问答中对此进行了详细讨论（示例：为什么我的shell脚本为什么在空格或其他特殊字符上感到窒息？，何时需要双引号？，shell变量的扩展以及glob对其的影响和split，引用vs无引号的字符串扩展） 自从70年代末Bourne shell首次发布以来就是这种情况，但Korn shell（David Korn的最大遗憾之一（问题＃7））并没有改变它，或者bash主要是复制了Korn shell，这就是POSIX / Unix如何指定的。 现在，我们仍然在这里看到许多答案，甚至偶尔看到一些不引用变量的公开发布的shell代码。您可能以为人们现在已经学到了。 根据我的经验，主要有3种类型的人忽略了引用其变量： 初学者。可以原谅这是完全不直观的语法。这是我们在此站点上进行教育的职责。 健忘的人。 甚至在反复敲打之后仍然没有被说服的人，他们认为Bourne shell的作者肯定不打算让我们引用所有变量。 如果我们暴露与此类行为相关的风险，也许我们可以说服他们。 如果忘记引用变量，最糟糕的事情莫过于发生。真的那么糟糕吗？ 我们在这里谈论什么样的漏洞？ 在什么情况下会出现问题？

206 bash  shell  shell-script  security  quoting 

该setuid权限位告诉Linux与业主，而不是执行者的有效用户ID运行程序： > cat setuid-test.c #include <stdio.h> #include <unistd.h> int main(int argc, char** argv) { printf("%d", geteuid()); return 0; } > gcc -o setuid-test setuid-test.c > ./setuid-test 1000 > sudo chown nobody ./setuid-test; sudo chmod +s ./setuid-test > ./setuid-test 65534 但是，这仅适用于可执行文件。Shell脚本忽略setuid位： > cat setuid-test2 #!/bin/bash id -u > ./setuid-test2 1000 > …

184 shell  scripting  setuid  security 

从技术上讲，除非pam您设置为不检查您的外壳，否则pam_shells，如果您不在外壳上，则这两种方法均无法阻止您的登录。在我的系统上，它们的大小甚至不同，因此我怀疑它们实际上在做什么。那有什么区别呢？他们为什么都存在？为什么我要一个使用另一个？ -rwxr-xr-x 1 root root 21K Feb 4 17:01 /bin/false -rwxr-xr-x 1 root root 4.7K Mar 2 14:59 /sbin/nologin

169 shell  security  login 

我的Linux机器是否可能被恶意软件感染？ 我还没有听说过发生在我认识的任何人身上的情况，而且我已经听说过很多次这是不可能的。真的吗？ 如果是这样，Linux Anti-Virus（安全）软件怎么了？

142 security  malware 

有关该错误的一些上下文：CVE-2014-6271 Bash不仅支持将Shell变量导出，而且还通过过程环境将Shell函数导出到其他bash实例（间接）到子进程。当前的bash版本使用以函数名称命名的环境变量，以及在变量值中以“（）{”开头的函数定义，以在环境中传播函数定义。发生此漏洞是因为bash在处理函数定义后不会停止；它会继续按照函数定义来解析和执行shell命令。例如，环境变量设置为 VAR=() { ignored; }; /bin/id 将环境导入到bash进程时将执行/ bin / id。 资料来源：http : //seclists.org/oss-sec/2014/q3/650 该错误是什么时候引入的，什么可以完全修复该补丁？（请参阅CVE-2014-7169） 除了CVE（最初）（3. {0..2}和4. {0..3}）中提到的易受攻击的版本还有哪些？ 越野车源代码是否已在其他项目中重用？ 需要其他信息。 相关：env x ='（）{：;};是什么？命令” bash做，为什么它不安全？

122 bash  security  shellshock 

即使我的非特权用户受到威胁，我也希望安全地拥有root帐户。 在Ubuntu上，默认情况下只能出于“安全原因”使用sudo。但是，我不确定它是否比在文本模式控制台上使用登录名更安全。如果攻击者可以以我的普通用户身份运行代码，则可能会出错。例如，添加别名，向我的PATH添加内容，设置LD_PRELOAD和X11键盘记录器，仅举几例。我唯一看到的好处是超时，因此我永远不会忘记注销。 我对su也有同样的疑问，但是它甚至没有时间限制。某些操作（尤其是IO重定向）对su更为方便，但是从安全角度而言，这似乎更糟。 在文本模式控制台上登录似乎是最安全的。由于它是由init启动的，因此如果攻击者可以控制PATH或LD_PRELOAD，则他已经是root。X上运行的程序无法拦截按键事件。我不知道X上运行的程序是否可以拦截[ctrl] + [alt] + [f1]（并打开一个看起来像控制台的全屏窗口）或就像Windows上的[ctrl] + [alt] + [del]一样安全。除此之外，我看到的唯一问题是缺少超时。 那我想念什么吗？为什么Ubuntu家伙决定只允许sudo？如何提高任何一种方法的安全性？ SSH呢？传统上，root用户无法通过SSH登录。但是使用上述逻辑并不是最安全的做法： 通过SSH允许root 切换到文字模式 以root身份登录 SSH到另一台机器 以root身份登录？

120 security  sudo  login  su  privileges 

您绝对不应从Web粘贴到终端。相反，您应该粘贴到文本编辑器，检查命令，然后粘贴到终端。 可以，但是如果Vim是我的文本编辑器怎么办？能否伪造一种内容，将Vim切换到命令模式并执行恶意命令？

112 security  vim  escape-characters  clipboard  special-characters 

CVE-2014-0160（又名Heartbleed）是OpenSSL中的漏洞。看起来很吓人。 如何确定我是否受到影响？ 如果我受到影响，我该怎么办？显然，升级还不够。

93 security  openssl 

我注意到关于密码的一件奇怪的事（根据我的说法）。例如，如果我在登录时输入了错误的密码，则系统会提示我几秒钟的延迟。当我尝试sudo使用错误的密码时，我还必须等待外壳说“抱歉，再试一次”。 我想知道为什么“识别”不正确的密码需要这么长时间？在我使用的多个发行版（甚至OSX）上都可以看到这一点，所以我认为这不是发行版特定的东西。

89 security  password  authentication  pam 

多年来（自2005年以来），我在维护的多个DNS / BIND服务器上看到奇怪的随机DNS请求完成的日志。 May 7 12:13:50 1.1.1.1 named[63742]: client 1.1.1.2#24123 (verxkgiicjmcnxg): view internal: query: verxkgiicjmcnxg IN A + (1.1.1.1) May 7 12:13:50 1.1.1.1 named[63742]: client 1.1.1.2#29159 (epqoaqsayo): view internal: query: epqoaqsayo IN A + (1.1.1.1) May 7 12:13:50 1.1.1.1 named[63742]: client 1.1.1.2#27411 (qlllglwcjglu): view internal: query: qlllglwcjglu IN A + …

88 security  dns  chrome 

在Linux中，我可以使用创建SHA1密码哈希sha1pass mypassword。有没有类似的命令行工具可以让我创建sha512哈希？Bcrypt和的问题相同PBKDF2。

83 security  password  encryption  hashsum 

互联网上的每个人都建议禁用通过SSH的 root登录，因为这是一种不好的做法，并且会给系统造成安全漏洞，但是没有人解释为什么会这样做。 启用root登录（尤其是禁用密码登录）有何危险？ 从安全的角度来看，如果允许密码认证，那么X符号用户名和Y符号密码或根用户名和X + Y符号密码有什么区别？

83 ssh  security  root 

我知道它的作用，但我不知道为什么。它可以防止什么攻击？ 它与所有身份验证方法有关吗？（基于主机，密码，公钥，与键盘交互...）

78 ssh  security  dns  openssh 

在我的/etc/passwd文件中，我可以看到www-dataApache所使用的用户以及各种系统用户都具有/usr/sbin/nologin或/bin/false作为其登录外壳。例如，以下是几行： daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin sys:x:3:3:sys:/dev:/usr/sbin/nologin games:x:5:60:games:/usr/games:/usr/sbin/nologin www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin syslog:x:101:104::/home/syslog:/bin/false whoopsie:x:109:116::/nonexistent:/bin/false mark:x:1000:1000:mark,,,:/home/mark:/bin/bash 因此，如果我尝试交换这些用户中的任何一个（有时我想检查我对他们的权限的了解，并且可能还有其他至少至少一半的理智的原因），则我将失败： mark@lunchbox:~$ sudo su www-data This account is currently not available. mark@lunchbox:~$ sudo su syslog mark@lunchbox:~$ 当然，这不算什么麻烦，因为我仍然可以通过这样的方法为他们启动外壳程序： mark@lunchbox:~$ sudo -u www-data /bin/bash www-data@lunchbox:~$ 但这让我想知道拒绝这些用户的登录外壳将达到什么目的。环顾互联网进行解释，许多人声称这与安全性有关，并且每个人似乎都同意更改这些用户的登录外壳在某种程度上是个坏主意。这是引号的集合： 将Apache用户的shell设置为非交互式通常是一种很好的安全做法（实际上，所有不必交互式登录的服务用户都应将其shell设置为非交互式）。 - https://serverfault.com/a/559315/147556 用户www-data的shell设置为/ usr / sbin / nologin，这是有充分理由的。 - https://askubuntu.com/a/486661/119754 [系统帐户] 可能是安全漏洞，尤其是在启用了外壳程序的情况下： 坏 bin:x:1:1:bin:/bin:/bin/sh 好 bin:x:1:1:bin:/bin:/sbin/nologin …

76 shell  security  users  login 

我低头看着键盘并输入密码，因为我以为我已经输入了登录名。我按Enter，然后在要求输入密码时按Ctrl+ c。 我应该采取一些预防措施以确保密码不是以纯文本格式存储在某处，还是应该更改密码？ 这也是在ubuntu服务器16.04 LTS上的tty上。

75 security  login  password