| ||||||||
Line: 23 to 23 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Changed: | ||||||||
< < |
As a policy, we strictly avoid sudo'ing to a shell (e..g., "=sudo -i=", "=sudo /bin/sh="). This is entirely for traceability -- commands done within a sudo shell are not logged. If it must be done, wrap your session in an invocation of script(1) to log the entire shell session. | |||||||
> > |
As a policy, we strictly avoid sudo'ing to a shell (e..g., "sudo -i", "sudo /bin/sh"). This is entirely for traceability -- commands done within a sudo shell are not logged. If it must be done, wrap your session in an invocation of script(1) to log the entire shell session. | |||||||
With this environment of multiple admins from diverse backgrounds who have never worked together before, this is mostly done for record-keeping purposes. Our use of sudo is more about keeping honest people honest then protecting from arbitrary attacks. |
| ||||||||
Line: 14 to 14 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Changed: | ||||||||
< < |
sudo | |||||||
> > |
In placesudo | |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
Firewall
SSH | |||||||
Changed: | ||||||||
< < |
sudo to shell | |||||||
> > |
| |||||||
Changed: | ||||||||
< < |
It is proposed that we strictly avoid sudo'ing to a shell (e..g., "sudo /bin/sh"), or wrap such things in an automatic invocation of script(1) to log the entire shell session. Traceability again. -- BruceDawson and BenScott | |||||||
> > |
logwatchThis automatically distills the logs, highlighting unusual events. It mails a report every night, and I (BenScott?) usually read it on a daily basis.Ideas and discussionauto-start script on sudo to shellIt was suggested that it would be nice ifscript(1) could be auto-started if a sudo-to-shell was performed. Implementation failed to materialize.
| |||||||
I much prefer autostarting script if 'sudo shell' is run - flexible and easy. Creating time/original user named logfile in standard location would be ideal. (e.g. 2006_02_10_11_53_billm.log) -- DrewVanZandt - 10 Feb 2006 Some things that require shell redirection don't work without this [the ability to sudo to a shell] - however those can be put into a script and run 'sudo script'. But then the script is fungable after the run, so what's been gained is worth debating. -- BillMcGonigle - 08 Feb 2006 | ||||||||
Changed: | ||||||||
< < |
I agree with Bruce that we need to be very diligent in keeping track of what we do and keeping strict access and audit controls in place. With the planned environment of multiple admins from diverse backgrounds who have never worked together before, this will be critical. So I favor the idea of capturing any root shell sessions in log files. Flat out disabling sudo to a shell is less appealing. It certainly doesn't get us any security (aside from Bill's obvervation on changing files, sudo can generally be used to disable itself, unless you lock everyone down to the point where we wouldn't be able to admin the box with it anymore). So our use of sudo will be more about keeping honest people honest then protecting from arbitrary attacks. -- BenScott - 16 Feb 2006 | |||||||
> > |
I agree with Bruce that we need to be very diligent in keeping track of what we do and keeping strict access and audit controls in place. . So I favor the idea of capturing any root shell sessions in log files. Flat out disabling sudo to a shell is less appealing. It certainly doesn't get us any security (aside from Bill's observation on changing files, sudo can generally be used to defeat itself, unless you lock everyone down to the point where we wouldn't be able to admin the box with it anymore). So our use of sudo will be more about keeping honest people honest then protecting from arbitrary attacks. -- BenScott - 16 Feb 2006 | |||||||
OTP for sudo | ||||||||
Line: 43 to 80 | ||||||||
The only thing OTP for sudo would save us from in this case is attacks to extract passwords typed during ssh sessions. Given the decisions we've made regarding that, there's no point in pursuing OTP for sudo any further. -- MikeLedoux - 27 Feb 2006 | ||||||||
Changed: | ||||||||
< < |
Firewall
Remote Access (SSH) | |||||||
> > |
SSH | |||||||
Changed: | ||||||||
< < |
Public keys | |||||||
> > |
Public keys | |||||||
It has been suggested by several that we require public key authentication and disallow password authentication entirely. | ||||||||
Line: 72 to 94 | ||||||||
I'm not convinced that OTP for SSH is more secure than SSH keys, provided a) you use a strong passphrase for your SSH key, and b) you only use your SSH key and passphrase directly on a trusted host under your immediate control. Since your passphrase is never sent over the wire to the remote sshd, I'm not sure how a trojaned sshd would ever get that passphrase. Perhaps I am missing something obvious here. -- MikeLedoux - 27 Feb 2006 | ||||||||
Changed: | ||||||||
< < |
Access list | |||||||
> > |
Access list | |||||||
Require entries in AllowedUsers in sshd_config. Inconvenient for adding new accounts, but the number of accounts will be very low and we don't have time to deal with getting cracked. -- BillMcGonigle - 11 Feb 2006 | ||||||||
Line: 82 to 104 | ||||||||
Addendum: root login via SSH allowed by public key with "forced-commands-only_ to enable backups via SSH. -- BenScott - 16 Nov 2006 | ||||||||
Changed: | ||||||||
< < |
Port number | |||||||
> > |
Port number | |||||||
It has been suggested by several that we use a non-standard port number for SSH (instead of IANA's assignment of 22). | ||||||||
Line: 90 to 112 | ||||||||
While this won't stop any serious attack, it does stop a lot of the stupid ones, and that counts for something. It also cuts down on log noise, if nothing else. ![]() | ||||||||
Changed: | ||||||||
< < |
IP address restrictions | |||||||
> > |
IP address restrictions | |||||||
It has been suggested that we restrict SSH to a small set of known IP addresses. | ||||||||
Line: 100 to 122 | ||||||||
Likewise, my personal 'net connection has a dynamic IP, so this would severly impair my ability to contribute. -- MikeLedoux - 27 Feb 2006 | ||||||||
Changed: | ||||||||
< < |
Other tools | |||||||
> > |
Other tools | |||||||
| ||||||||
Line: 56 to 56 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Remote Access (SSH) | ||||||||
Line: 80 to 80 | ||||||||
Also, no root logins via SSH (public key or otherwise). sudo only. See above. -- BenScott - 16 Feb 2006 | ||||||||
Added: | ||||||||
> > |
Addendum: root login via SSH allowed by public key with "forced-commands-only_ to enable backups via SSH. -- BenScott - 16 Nov 2006 | |||||||
Port numberIt has been suggested by several that we use a non-standard port number for SSH (instead of IANA's assignment of 22). |
| ||||||||
Line: 41 to 41 | ||||||||
---|---|---|---|---|---|---|---|---|
I think OTP for sudo would be a royal p.i.t.a. I use OTP a lot at work and home, and while it's very secure, and not too painful for basic ssh authentication, it could become seriously cumbersome for sudo access. Additionally, the risk OTP is engineered to protect against might actually be subverted if people were to accidently generate the OTPs on the remote server. -- PaulLussier - 24 Feb 2006 | ||||||||
Added: | ||||||||
> > |
The only thing OTP for sudo would save us from in this case is attacks to extract passwords typed during ssh sessions. Given the decisions we've made regarding that, there's no point in pursuing OTP for sudo any further. -- MikeLedoux - 27 Feb 2006 | |||||||
Firewall
| ||||||||
Line: 68 to 70 | ||||||||
Another thing which has not been discussed is the use of OTP for ssh access. This would be significantly more secure than the use of SSH keys. Consider the possibility of a trojaned sshd getting installed on the system. This sshd now has access to the secret passphrase to your key should you ssh from the remote system elsewhere. Using agent-based authentication forwarding and OTP, this risk is mitigated. Any OTP you type is instantly obsolete upon it's successful use. I would find this use of OTP far more palatable than for sudo. -- PaulLussier - 24 Feb 2006 | ||||||||
Added: | ||||||||
> > |
I'm not convinced that OTP for SSH is more secure than SSH keys, provided a) you use a strong passphrase for your SSH key, and b) you only use your SSH key and passphrase directly on a trusted host under your immediate control. Since your passphrase is never sent over the wire to the remote sshd, I'm not sure how a trojaned sshd would ever get that passphrase. Perhaps I am missing something obvious here. -- MikeLedoux - 27 Feb 2006 | |||||||
Access listRequire entries in AllowedUsers in sshd_config. Inconvenient for adding new accounts, but the number of accounts will be very low and we don't have time to deal with getting cracked. -- BillMcGonigle - 11 Feb 2006 | ||||||||
Line: 92 to 96 | ||||||||
Unfortunately, I do not have a personal static IP address, so this would mean I would not be able to help much (or at all). Active discussion of this issue is presently on the -sysadmin list. -- BenScott - 16 Feb 2006 | ||||||||
Added: | ||||||||
> > |
Likewise, my personal 'net connection has a dynamic IP, so this would severly impair my ability to contribute. -- MikeLedoux - 27 Feb 2006 | |||||||
Other tools
|
| ||||||||
Line: 96 to 96 | ||||||||
---|---|---|---|---|---|---|---|---|
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Line: 100 to 100 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Line: 100 to 100 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Changed: | ||||||||
< < |
I can only vouch for tripwire, it works, and it works well. But it require maintenance and produces rather verbose reports which need to be monitored and dealt with. urceforge.net/sourceforge/pyflag/pyflag-0.80.1.tar.gz | |||||||
> > |
| |||||||
| ||||||||
Line: 39 to 39 | ||||||||
---|---|---|---|---|---|---|---|---|
I'm a little unsure about how this fits into the risk management equation. What threat are we defending against here? Compromised SSH keys? Won't the overhead of OTP (I assume that's One Time Password; I've never used OPIE or S/Key before) be a large burden for us? -- BenScott - 16 Feb 2006 | ||||||||
Added: | ||||||||
> > |
I think OTP for sudo would be a royal p.i.t.a. I use OTP a lot at work and home, and while it's very secure, and not too painful for basic ssh authentication, it could become seriously cumbersome for sudo access. Additionally, the risk OTP is engineered to protect against might actually be subverted if people were to accidently generate the OTPs on the remote server. -- PaulLussier - 24 Feb 2006 | |||||||
Firewall
| ||||||||
Line: 64 to 66 | ||||||||
While I agree that vulnerabilities present a bigger danger, password cracking is a threat. Further, blind, automatic, SSH password guessing attacks are currently active on the Internet. At work we were getting probed not infrequently. Changing the default port foils most of them, but it's still there. At the time time, public keys are pretty easy, generally considered very strong, and actually make things easier if you use ssh-agent. -- BenScott - 16 Feb 2006 | ||||||||
Added: | ||||||||
> > |
Another thing which has not been discussed is the use of OTP for ssh access. This would be significantly more secure than the use of SSH keys. Consider the possibility of a trojaned sshd getting installed on the system. This sshd now has access to the secret passphrase to your key should you ssh from the remote system elsewhere. Using agent-based authentication forwarding and OTP, this risk is mitigated. Any OTP you type is instantly obsolete upon it's successful use. I would find this use of OTP far more palatable than for sudo. -- PaulLussier - 24 Feb 2006 | |||||||
Access listRequire entries in AllowedUsers in sshd_config. Inconvenient for adding new accounts, but the number of accounts will be very low and we don't have time to deal with getting cracked. -- BillMcGonigle - 11 Feb 2006 | ||||||||
Line: 92 to 96 | ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
Don't forget to sign your comments! TOC: No TOC in "Organizational.ServerSecurity" | |||||||
Goals
| ||||||||
Line: 10 to 14 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Changed: | ||||||||
< < |
Account Restrictions | |||||||
> > |
sudo | |||||||
sudo to shell | ||||||||
Changed: | ||||||||
< < |
It is proposed that we strictly avoid sudo'ing to a shell (e..g., "sudo /bin/sh"), or wrap such things in an automatic invocation of script(1) to log the entire shell session. Traceability again. | |||||||
> > |
It is proposed that we strictly avoid sudo'ing to a shell (e..g., "sudo /bin/sh"), or wrap such things in an automatic invocation of script(1) to log the entire shell session. Traceability again. -- BruceDawson and BenScott | |||||||
Changed: | ||||||||
< < |
Yes, this make things more difficult, but traceability is needed when there are multiple admins. Note: I could be coaxed off this requirement if sudo would fire up a capture program (like script) when 'sudo <shell>' is used. | |||||||
> > |
I much prefer autostarting script if 'sudo shell' is run - flexible and easy. Creating time/original user named logfile in standard location would be ideal. (e.g. 2006_02_10_11_53_billm.log) -- DrewVanZandt - 10 Feb 2006 | |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
Some things that require shell redirection don't work without this [the ability to sudo to a shell] - however those can be put into a script and run 'sudo script'. But then the script is fungable after the run, so what's been gained is worth debating. -- BillMcGonigle - 08 Feb 2006 | |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
I agree with Bruce that we need to be very diligent in keeping track of what we do and keeping strict access and audit controls in place. With the planned environment of multiple admins from diverse backgrounds who have never worked together before, this will be critical. So I favor the idea of capturing any root shell sessions in log files. Flat out disabling sudo to a shell is less appealing. It certainly doesn't get us any security (aside from Bill's obvervation on changing files, sudo can generally be used to disable itself, unless you lock everyone down to the point where we wouldn't be able to admin the box with it anymore). So our use of sudo will be more about keeping honest people honest then protecting from arbitrary attacks. -- BenScott - 16 Feb 2006 | |||||||
OTP for sudo | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
OTP (OPIE or some other S/Key) for sudo access. -- MikeLedoux - 13 Feb 2006 Are there any links for those who aren't familar with these? -- BruceDawson - 13 Feb 2006 Both implement your standard challenge/response one time password, and plug in to sudo fairly easily. A quick search didn't find any information that doesn't presume familiarity, I'll see if I can come up with something better tonight. -- MikeLedoux - 13 Feb 2006 I'm a little unsure about how this fits into the risk management equation. What threat are we defending against here? Compromised SSH keys? Won't the overhead of OTP (I assume that's One Time Password; I've never used OPIE or S/Key before) be a large burden for us? -- BenScott - 16 Feb 2006 | |||||||
Firewall | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
Remote Access (SSH)Public keysIt has been suggested by several that we require public key authentication and disallow password authentication entirely. Opinion - I am aware this could cause flames, sorry. Cracking will probably not be from password guessing etc. (especially if on nonstandard port, and we stick to decent passwords e.g. gpw or whatever) - it will be a vulnerability in a service we run. Minimal exposure to the outside world would be good.![]() Access listRequire entries in AllowedUsers in sshd_config. Inconvenient for adding new accounts, but the number of accounts will be very low and we don't have time to deal with getting cracked. -- BillMcGonigle - 11 Feb 2006 Or we could use a Unix group (e.g., "sshusers"). -- BenScott - 16 Feb 2006 Also, no root logins via SSH (public key or otherwise). sudo only. See above. -- BenScott - 16 Feb 2006Port numberIt has been suggested by several that we use a non-standard port number for SSH (instead of IANA's assignment of 22). I've been port-scanned for ssh running on non-standard ports. -- BillMcGonigle - 11 Feb 2006 While this won't stop any serious attack, it does stop a lot of the stupid ones, and that counts for something. It also cuts down on log noise, if nothing else.![]() IP address restrictionsIt has been suggested that we restrict SSH to a small set of known IP addresses. I postulate that restricting ssh access to a small set of IP's is more secure than having it open to the world. It avoids all the script-kiddie issues, for instance. So, there should be arguments here for why we'd want to accept a less-secure method in the face of known attacks. -- BillMcGonigle - 11 Feb 2006 Unfortunately, I do not have a personal static IP address, so this would mean I would not be able to help much (or at all). Active discussion of this issue is presently on the -sysadmin list. -- BenScott - 16 Feb 2006 | |||||||
Changed: | ||||||||
< < |
Remote Access | |||||||
> > |
Other tools | |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
||||||||
| ||||||||
Added: | ||||||||
> > |
Goals
| |||||||
Account Restrictions | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
sudo to shellIt is proposed that we strictly avoid sudo'ing to a shell (e..g., "sudo /bin/sh"), or wrap such things in an automatic invocation of script(1) to log the entire shell session. Traceability again. Yes, this make things more difficult, but traceability is needed when there are multiple admins. Note: I could be coaxed off this requirement if sudo would fire up a capture program (like script) when 'sudo <shell>' is used. | |||||||
| ||||||||
Added: | ||||||||
> > |
||||||||
| ||||||||
Added: | ||||||||
> > |
OTP for sudo | |||||||
Firewall |
| ||||||||
Line: 9 to 9 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Firewall |
| ||||||||
Line: 9 to 9 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Firewall |
| ||||||||
Line: 6 to 6 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
Firewall |
| ||||||||
Line: 7 to 7 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Line: 23 to 23 | ||||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
Remote Access | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
|
| ||||||||
Line: 7 to 7 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Changed: | ||||||||
< < |
traceability is needed when there are multiple admins. Note: I could be coaxed off this requirement if sudo would fire up a capture program (like script) when 'sudo | |||||||
> > |
| |||||||
| ||||||||
Line: 24 to 24 | ||||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
Remote Access
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Line: 23 to 23 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Added: | ||||||||
> > |
| |||||||
|
| ||||||||
Line: 8 to 8 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Added: | ||||||||
> > |
| |||||||
Firewall |
| ||||||||
Line: 28 to 28 | ||||||||
---|---|---|---|---|---|---|---|---|
Remote Access
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Line: 21 to 21 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Added: | ||||||||
> > |
| |||||||
|
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Added: | ||||||||
> > |
Account Restrictions
Firewall
Remote Access
|