Linux 安全软件及SFTP自动化软件

飞飞鱼

原帖由 sweetheart 于 2011-8-27 21:57 发表

Problem: if an operator is able to using user A on node A to transfer files to user A's home dir on node B, he will be able to do unauthorized file transfer from any other machines. That's a very bad ...

文件传输用脚本加crontab就可以解决了，为什么要Operator手工来做？
不过我喜欢赚这样比较好赚的加班费：）
如果一定要人工手动来做，设置Operator以个人用户登录，然后sudo执行特定指令，或者sudosh到某一用户操作。
而且既然都已经人工了，就干脆把RSA加上密码来手工输入好了，并在sshd_config设置PasswordAuthentication yes

你说的这个有道理，所以我那个解决方案上应该加入下面的部分：
× 在target node配置防火墙以接受仅来自已知网段的ssh连接
e.g.
设置/etc/sysconfig/iptables (Redhat)只接收来自192.168.100.0/24 and 209.64.100.5/27, enter:
-A RH-FW-1-INPUT -s 192.168.100.0/24 -m state --state NEW -p tcp --dport 22 -j ACCEPT
-A RH-FW-1-INPUT -s 209.64.100.5/27 -m state --state NEW -p tcp --dport 22 -j ACCEPT

× 或者用个原始，但简单的方法：
需要传输的文件根据要传输到的target node，由不同的User id脚本执行，这样就可以了。

飞飞鱼

原帖由 sweetheart 于 2011-8-27 21:50 发表
I don't know when did you see after sudo to root account, all commands executed would automatically be logged. Please tell facts, not just something you believe.

不太明白你的问题？

我前面说了打开sudo log来看执行了什么指令，如果你的sudo授权是指令级别的，一定是会被log下来的啊，有疑问？
如果一定要sudo到用户，用sudosh记录所有指令。这个是我believe的，也是我经手的NAB的case。

飞飞鱼

原帖由 sweetheart 于 2011-8-27 20:26 发表

known_hosts only records hostname to host key mapping, nothing to do with user's private key!
I've be working on UNIX since 1984, of course know root can do many things, some people may say copy /dev ...

这点，我的文档是这样说的：
“
If a server host name or IP address changes, the public-private key pair configuration will break because of the cached known hosts. The old entry will need to be removed in the .ssh/known_hosts file and the SSH remote host name and/or IP address re-cached again. This will break scripts dependant on the private-public key pair.
”

我还是不认同你这个思路，你认为root是坏的，所以你弄出一个更强大的东西来看着root，这是一个安全悖论啊。

root都被人拿到了，其他的不用谈了。

飞飞鱼

原帖由 sweetheart 于 2011-8-27 22:13 发表
BTW, I found most tips about how to set up sftp only account got from google search are flawed.

这个问题你得和布老虎说，让他跟公司反映下，也许还能弄三瓜两枣奖励。

ssh我折腾的比较多，还有scp；
至于sftp，因为这个一般是应用的要求，我看DBA用rsyn来实现的比较多；因为不在系统级层面了，我木有怎么看。

BTW，我只是一个读书人，在澳洲找不到其他工作,沦为一个IT民工......

sweetheart

原帖由 飞飞鱼 于 2011-8-27 22:35 发表


文件传输用脚本加crontab就可以解决了，为什么要Operator手工来做？
不过我喜欢赚这样比较好赚的加班费：）
如果一定要人工手动来做，设置Operator以个人用户登录，然后sudo执行特定指令，或者sudosh到某一用户操作。
而且既然都 ...

It seems you still didn't understand the issue properly: with ssh_rundirect, not only you can restrict the account on server side (call it uS) to be used by secure file transfer (sftp/scp) only, but also not allowing the client user (call it uC) to take control of who is allowed to do the file transfer with uS, and also blocking the possibility for the client to alter the sftp-server's behavior for doing other things. These are not related with firewall settings.
Also please don't repeat to tell me that you can use crontab to do the file transfer without AutoSFTP: I've said very clearly using key based authentication without passphrase or password based authentication without setting a password for uS, that's not good for an environment like production environment in Banks.

sweetheart

原帖由 飞飞鱼 于 2011-8-27 23:00 发表


这点，我的文档是这样说的：
“
If a server host name or IP address changes, the public-private key pair configuration will break because of the cached known hosts. The old entry will need to be removed i ...

This is talking about host key: host key also has both private and public keys. So, again, it's not related with user's private/public keys.

sweetheart

原帖由 飞飞鱼 于 2011-8-27 22:49 发表


不太明白你的问题？

我前面说了打开sudo log来看执行了什么指令，如果你的sudo授权是指令级别的，一定是会被log下来的啊，有疑问？
如果一定要sudo到用户，用sudosh记录所有指令。这个是我believe的，也是我经手的NAB的case。

sudosh is not a command from sudo package, I have no idea what it does and how, so can't comment.
Do you know whether sudosh also uses syslog to log the messages?

sweetheart

Don't mix up prevent attack from external with the daily operation security. I'm not saying my software can prevent a hacker to do anything when that hacker has already gained root access on the system.
A few key things required by Audit department are:
1. Who is on the system and at what time period.
2. When did the bad thing happen.
3. How to determine who did that.
So, if a system is using sudo together with tripwire, and root can't directly login, must be through sudo.
How can this meet the above requirements?
Logs could show when did the user logged in to the system, when did he run sudo, but didn't show for how long, and with sudosh (as you said), it would tell what commands were run, might also tell when, and then when did the user log off. So, my question is if the user did run some commands under sudosh, and quit the sudosh, but not sudo, and then wait for 5min, did some bad things, just before quit from the sudo and after log off. So when in investigation, that user could say that when that bad thing happened, I had already quit sudo so had no privilege to do that bad thing. Remember, sudo only logs when did the user run the command, not when that command finished.

With tripwire, not only scan is very costly (that's expected, WZFileGuard full scan also has the same issue, but WZFileGuard has a scan that's only for detecting traps set by internals, which should be run every hour or even less, and is very light-weight), could contain lots of false alarms, but also it can't prevent root to change the database to hide some bad changes he made to the system config.

sweetheart

When so many Linux machines and other UNIX systems with sudo installed with default setting, you can't imagine and believe with so many system experts and security experts out there for so many years, the sudo log messages you get may not be that trust-worthy.
Just an example, on my ubuntu virtual machine,

Aug 28 07:59:34 ubuntu sudo:      gwz : TTY=pts/0 ; PWD=/home/gwz ; USER=root ; COMMAND=/bin/bash
Aug 28 08:02:35 ubuntu sudo:      gwz : TTY=pts/2 ; PWD=/home/gwz ; USER=root ; COMMAND=/bin/bash
Aug 28 08:06:22 ubuntu sudo: gwz : TTY=pts/2 ; PWD=/home/gwz ; USER=root ; COMMAND=/bin/bash
Aug 28 08:07:10 ubuntu sudo:       abc : TTY=pts/2 ; PWD=/home/gwz ; USER=root ; COMMAND=/bin/bash
Aug 28 08:08:22 ubuntu sudo: #011abc : TTY=pts/2 ; PWD=/home/gwz ; USER=root ; COMMAND=/bin/bash
Aug 28 08:12:08 ubuntu sudo:       abc : TTY=pts/2 ; PWD=/home/gwz ; USER=root ; COMMAND=rm -rf /  <<<======= Note
Aug 28 08:17:01 ubuntu CRON[1915]: pam_unix(cron:session): session opened for user root by (uid=0)
Aug 28 08:17:01 ubuntu CRON[1915]: pam_unix(cron:session): session opened for user root by (uid=0)

and now:
root@ubuntu:/var/log# date
Sun Aug 28 10:43:24 EST 2011
root@ubuntu:/var/log# ls /
bin    dev  home        lost+found  opt   s        srv  usr
boot   etc  initrd.img  media       proc  sbin     sys  var
cdrom  h    lib         mnt         root  selinux  tmp  vmlinuz
root@ubuntu:/var/log# who -a
           system boot  2011-08-28 07:56
           run-level 2  2011-08-28 07:56
LOGIN      tty4         2011-08-28 07:56               830 id=4
LOGIN      tty5         2011-08-28 07:56               834 id=5
LOGIN      tty2         2011-08-28 07:56               843 id=2
LOGIN      tty3         2011-08-28 07:56               845 id=3
LOGIN      tty6         2011-08-28 07:56               847 id=6
LOGIN      tty1         2011-08-28 07:58              1130 id=1
gwz      + tty7         2011-08-28 07:58  old         1269 (:0)
gwz      + pts/0        2011-08-28 07:59 02:44        1567 (:0.0)
gwz      + pts/1        2011-08-28 08:02 00:16        1567 (:0.0)
gwz      + pts/2        2011-08-28 08:02   .          1567 (:0.0)
root@ubuntu:/var/log#

There is no account named as "abc" on the system, and if it's true then we won't be able to see all the files and dirs under root dir.

sweetheart

原帖由 sweetheart 于 2011-8-28 10:48 发表
When so many Linux machines and other UNIX systems with sudo installed with default setting, you can't imagine and believe with so many system experts and security experts out there for so many years, ...

Remember, these false sudo messages were put in by a normal user without root privilege. And the /var/log/auth.log is only writable by syslog:
root@ubuntu:/var/log# ls -l au*
-rw-r----- 1 syslog adm  536 2011-08-28 10:55 auth.log
-rw-r----- 1 syslog adm 1749 2011-08-28 08:17 auth.log.1
-rw-r----- 1 syslog adm 1467 2011-03-04 13:11 auth.log.2.gz

sweetheart

SUDO:
1. to run a command, you need to key in your password. Good thing about this is it gives a protection for you if you have a bad habit of leaving your computer not locked while you are away from it.  Problem with it: it blocks the possibility to use it in script, can't be non-interactive, and too troublesome when only grant individual commands (this is the main reason why knowing it's not good, Banks still have no choice to allow "sudo su" or "sudo bash" kind of usage.).
2.if you want to setup an Oracle DBA account, and don't allow it to be used directly, for a normal user account to be able to execute a command using the DBA's privilege, you have to give that user the root privilege to run a script and then in that script, using su to switch to DBA account to execute the command.
3. When you have lots of scripts for Applications' and databases' start/stop and want to grant a normal user the suitable privilege to run them, besides you have to grant root privilege for him to run another set of scripts as explained in #2, but also the chances of those applications and/or databases of using some special environment variables are very high, and those applications/databases are very probably not designed with the mind that they are going to be used in a priviledge switching environment, and because of that, it's quite possible they don't have a careful check for value length overflow.  And sudo doesn't have a way for you to control that situation.
4. By default, sudo will log through syslog, and as I explained earlier, anybody on the system can log any kind of message through syslog, so the log is not trust-worthy. Also, sudo only logs when the command starts, doesn't log when it exits.

CaclMgr:
1. When you run a command using another user's privilege through CaclMgr, it won't ask for your password. Bad thing: if you leave your computer open while you are away, you can get big trouble if someone comes to use your id to do some bad thing. Good thing: Now it's more reasonable to just assign the needed commands to a user; and it enables it to be used in scripts and crontab.
2. Now you can just assign individual commands from DBA to the normal user, no need to force develop a script, and no need to get root privilege first.
3. Can directly grant those start/stop scripts from corresponding app/dba admin accounts to the needed user. And for environment variables used by the app/database which when value length overflow could cause security issue in privilege switching environment, you can just ask system admin/data security officer to put them into either badenv.lst or goodenv.lst.
4. will log to file (writable only by root) directly, and will log both command start and exit times.

黑山老妖

I think you are better off selling your software to a security company than trying to sell it yourself.
You just don't have the marketing power, contact and reputation to sell them as effectively as say symantec or some other big companies.
You could also license it to those big companies and take a cut of every sell they make.

sweetheart

It's still easy to send the log files over to another machine through syslog if configured so, or run a cron job using a special normal user account and CaclMgr plus AutoSFTP to send the files over to another machine.

sweetheart

原帖由 黑山老妖 于 2011-8-29 11:42 发表
I think you are better off selling your software to a security company than trying to sell it yourself.
You just don't have the marketing power, contact and reputation to sell them as effectively as s ...

Thanks for the recommendation.

nali

原帖由 飞飞鱼 于 2011-8-27 20:22 发表
2.对于脚本无法控制，有一些应用必须sudo到某一个用户来运行脚本，这个时候就可以在脚本里动很多手脚了，这个我还真没有想出解决方法。只能检查脚本后修改权限，让人无法把dodgy的东西加进去。 ...

飞飞雨非常专业啊， 以后有类似的问题要来多多指教。

我们公司对2的处理方法是，所有的sudo 脚本必须owner by root. 这样的话，任何改动必须申请批准一个 change才可以修改。

有root 权限的人，只支持系统级的，不直接支持应用。 做应用支持的，没有root 权限。也就是分成两个独立的组。

飞飞鱼

原帖由 nali 于 2011-8-29 21:09 发表


飞飞雨非常专业啊， 以后有类似的问题要来多多指教。

我们公司对2的处理方法是，所有的sudo 脚本必须owner by root. 这样的话，任何改动必须申请批准一个 change才可以修改。

有root 权限的人，只支持系统级的，不直接支持应用。 做应用支持的，没有root 权限。也就是分成两个独立的组。

哈，你们有没有业务外包啊，小单在下私活就做了，一流标准，山寨收费啊，呵呵。

这个讨论不错，很多没注意的地方都重新看了下。
关于把key拷贝到别的机器上去的事情，我试验了下，在目标机器上，authorized_keys的RSA和DSA的格式都如下：
ssh-rsa AAB********BIwAAAI×××××××× = UserID@hostname
怎么拿到这个key不论，即使拿到了也不是简单的拷贝到某个机器上就可以用的问题；网络通不通也不论了；但这个userID和hostname你也要fake出来；当然在拿到root的情况下怎么都可以实现；

绕了一圈，你这个软件的前提是假设被人拿到了root，然后在这样的的情况下来如何安全手工传输以及记录对方的行为.........

bulaohu

请保持技术讨论，杜绝人身攻击。

sweetheart

When I said a key without passphrase protection can be copied to another account and even to another machine, I didn't say you will need to have the same UserID and hostname or IP to use it. And if that would be the case, I wouldn't even mention key coping stuff.
You should do more researches and post your comments based on facts and not imagination.

飞飞鱼

算了，好像有火药味道，我打住不跟了。

没有别的意思，不是踢场子，只是技术讨论，如有冒犯，见谅见谅。

技术的东西，尺有所短，寸有所长，和气生财，和气生财，呵呵。
大家买软件的话找楼主；有私活的可以联系我啊。

[ 本帖最后由 飞飞鱼 于 2012-3-21 19:55 编辑 ]

回头望

关于ssh key，如果能拿到private key，确实可以在任意机器上面ssh到server上去。比如client A生成的ssh key，copy到client B之后，到ssh server也是工作的。

know_hosts 只是存在于ssh client端的cache文件，在ssh server上面都可以没有，确实和能否ssh关系不大。

不过如果能拿到root，什么软件都没什么意义，因为root什么都可以改。

[ 本帖最后由 回头望 于 2011-8-31 19:19 编辑 ]

sweetheart

原帖由 回头望 于 2011-8-31 19:17 发表
关于ssh key，如果能拿到private key，确实可以在任意机器上面ssh到server上去。比如client A生成的ssh key，copy到client B之后，到ssh server也是工作的。

know_hosts 只是存在于ssh client端的cache文件，在ssh server上面 ...

WZFileGuard's file contents certificates are password protected, even when a hacker gained root access, if he tries to change system config or install a new SetUID program, WZFileGuard full scan will detect such change. Note: WZFileGuard software together with its data files can be burned to a CD, and run from CD directly, that way, even when the user knows the password for the security protection, he still can't hide his changes from being detected.
For the AutoSFTP and AutoSSH, the passwords encrypted can't be used by different accounts or servers, so even root can't just copy it to another machine to use it. This is one of the reasons why using AutoSFTP and AutoSSH is more secure than manually use sftp or ssh.

[ 本帖最后由 sweetheart 于 2011-9-9 10:40 编辑 ]