<<O>>  Difference Topic ServerSecurity (r1.20 - 07 Mar 2009 - BenScott)

META TOPICPARENT InternetServer
Our InternetServer will need to be protected against all the Internet nasties (which are legion).
Line: 23 to 23

  • This gives us both enhanced security and traceability (a record of what gets done).
  • Avoid "sudo to shell" if at all feasible. If you must, consider using "script" to record the session.
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.

 <<O>>  Difference Topic ServerSecurity (r1.19 - 22 Feb 2009 - BenScott)

META TOPICPARENT InternetServer
Our InternetServer will need to be protected against all the Internet nasties (which are legion).
Line: 14 to 14

  • Authenticity - Making sure admins really are who they say they are is important. Otherwise, this is a lower priority for us; most stuff is cleartext and public.
  • Privacy - Generally not a priority for us. Most of what we do is public by nature and intent. Still, some things (e.g., root password) will need to be protected.
Changed:
<
<

sudo

>
>

In place

sudo


  • All people have their own user account on the system.
Changed:
<
<
  • No direct root logins. Login to user account first, then sudo. This gives us both enhanced security and traceability.
>
>
  • No direct root logins. Login to user account first, then sudo.
  • This gives us both enhanced security and traceability (a record of what gets done).
  • Avoid "sudo to shell" if at all feasible. If you must, consider using "script" to record the 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.

Firewall

  • Using a local firewall (iptables/netfilter) to lock out most things
  • Deny inbound by default
  • Allow outbound by default
  • Allowed inbound from anywhere:
    • 25/tcp (SMTP)
    • 80/tcp (HTTP)
    • 443/tcp (
    • 53/udp
    • Safe ICMP types (ping, destination unreachable, parameter problem, time expired)
    • SSH -- for specifics, see discussion elsewhere
  • Allow 53/tcp from DNS slaves
    • Currently allowed from everywhere because we're lazy smile

SSH


Changed:
<
<

sudo to shell

>
>
  • Public keys are required; passwords disabled.
  • General root login via SSH not allowed.
    • SSH to root allowed with "=forced-commands-only=" to enable backups
  • Users must be a member of the "=sshusers=" group
  • Listens on a non-standard TCP port to foil Internet-wide bulk scanning

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
>
>

logwatch

This 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 discussion

auto-start script on sudo to shell

It was suggested that it would be nice if script(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

  • Use a local firewall (iptables/netfilter) to lock out most things
  • Deny inbound by default
  • Allow outbound by default (?)
  • Allowed inbound from anywhere:
    • 25/tcp
    • 80/tcp
    • 443/tcp
    • 53/udp
    • ICMP echo request (ping)
  • SSH -- for specifics, see discussion in "Remote Access"
  • Allow 53/tcp from DNS slaves
    • Currently allowed from everywhere because we're lazy smile

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. smile -- BenScott - 16 Feb 2006

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


  • logsentry/logwatch/etc - alert us to unusual messages (email, maybe SMS) -- BenScott - 16 Feb 2006
  • portsentry - identify probes and scans and auto-firewall the source addresses -- BenScott - 16 Feb 2006
 <<O>>  Difference Topic ServerSecurity (r1.18 - 15 Nov 2006 - BenScott)

META TOPICPARENT InternetServer
Our InternetServer will need to be protected against all the Internet nasties (which are legion).
Line: 56 to 56

    • ICMP echo request (ping)
  • SSH -- for specifics, see discussion in "Remote Access"
  • Allow 53/tcp from DNS slaves
Changed:
<
<
    • 199.125.76.10 LINUX.CODEMETA.COM
>
>
    • Currently allowed from everywhere because we're lazy smile

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 number

It has been suggested by several that we use a non-standard port number for SSH (instead of IANA's assignment of 22).

 <<O>>  Difference Topic ServerSecurity (r1.17 - 27 Feb 2006 - MikeLedoux)

META TOPICPARENT InternetServer
Our InternetServer will need to be protected against all the Internet nasties (which are legion).
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

  • Use a local firewall (iptables/netfilter) to lock out most things
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 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: 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

  • logsentry/logwatch/etc - alert us to unusual messages (email, maybe SMS) -- BenScott - 16 Feb 2006
 <<O>>  Difference Topic ServerSecurity (r1.16 - 26 Feb 2006 - ColeTuininga)

META TOPICPARENT InternetServer
Our InternetServer will need to be protected against all the Internet nasties (which are legion).
Line: 96 to 96

  • logsentry/logwatch/etc - alert us to unusual messages (email, maybe SMS) -- BenScott - 16 Feb 2006
  • portsentry - identify probes and scans and auto-firewall the source addresses -- BenScott - 16 Feb 2006
Added:
>
>
    • One note - this would require us to open up any ports we want to sentry in the firewall. Is this something we want to do? -- ColeTuininga - 26 Feb 2006

  • System file integrity verification tools:
    • bsign - Corruption & intrusion detection using embedded hashes
    • systraq - monitor your system and warn when system files change
    • tripwire - file and directory integrity checker
      • 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. -- PaulLussier - 24 Feb 2006
Added:
>
>
    • rkhunter/chkrootkit - Looks for known rootkits, and a few other things. -- ColeTuininga - 26 Feb 2006

 <<O>>  Difference Topic ServerSecurity (r1.15 - 25 Feb 2006 - BruceDawson)

META TOPICPARENT InternetServer
Our InternetServer will need to be protected against all the Internet nasties (which are legion).
Line: 100 to 100

    • bsign - Corruption & intrusion detection using embedded hashes
    • systraq - monitor your system and warn when system files change
    • tripwire - file and directory integrity checker
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.
-- PaulLussier - 24 Feb 2006
>
>
      • 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. -- PaulLussier - 24 Feb 2006

 <<O>>  Difference Topic ServerSecurity (r1.14 - 24 Feb 2006 - PaulLussier)

META TOPICPARENT InternetServer
Our InternetServer will need to be protected against all the Internet nasties (which are legion).
Line: 100 to 100

    • bsign - Corruption & intrusion detection using embedded hashes
    • systraq - monitor your system and warn when system files change
    • tripwire - file and directory integrity checker
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
>
>
      • 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.
-- PaulLussier - 24 Feb 2006

 <<O>>  Difference Topic ServerSecurity (r1.13 - 24 Feb 2006 - PaulLussier)

META TOPICPARENT InternetServer
Our InternetServer will need to be protected against all the Internet nasties (which are legion).
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

  • Use a local firewall (iptables/netfilter) to lock out most things
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 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: 92 to 96

  • logsentry/logwatch/etc - alert us to unusual messages (email, maybe SMS) -- BenScott - 16 Feb 2006
  • portsentry - identify probes and scans and auto-firewall the source addresses -- BenScott - 16 Feb 2006
Added:
>
>
  • System file integrity verification tools:
    • bsign - Corruption & intrusion detection using embedded hashes
    • systraq - monitor your system and warn when system files change
    • tripwire - file and directory integrity checker 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

 <<O>>  Difference Topic ServerSecurity (r1.12 - 15 Feb 2006 - BenScott)

META TOPICPARENT InternetServer
Our InternetServer will need to be protected against all the Internet nasties (which are legion).
Added:
>
>
Don't forget to sign your comments!

TOC: No TOC in "Organizational.ServerSecurity"


Goals

  • Availability - Keep the services up and running.
Line: 10 to 14

  • Authenticity - Making sure admins really are who they say they are is important. Otherwise, this is a lower priority for us; most stuff is cleartext and public.
  • Privacy - Generally not a priority for us. Most of what we do is public by nature and intent. Still, some things (e.g., root password) will need to be protected.
Changed:
<
<

Account Restrictions

>
>

sudo


  • All people have their own user account on the system.
  • No direct root logins. Login to user account first, then sudo. This gives us both enhanced security and traceability.

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:
<
<
  • 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:
<
<
  • Some things that require shell redirection don't work without this - 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
>
>
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
>
>
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:
<
<
  • iptables - unless there is some other level of firewalling available to us.
    • even if there is a hardware firewall, don't trust it. To expound, only allow incoming access on the minimum number of ports to get us going. We should restrict ssh access to a limited number of IP's to avoid being DDOS'ed with ssh scans. -- BillMcGonigle - 09 Feb 2006
    • Allowed Ports From Anywhere
>
>
  • Use a local firewall (iptables/netfilter) to lock out most things
  • Deny inbound by default
  • Allow outbound by default (?)
  • Allowed inbound from anywhere:

      • 25/tcp
      • 80/tcp
      • 443/tcp
      • 53/udp
Changed:
<
<
    • Allowed IP's for port 22 ssh
      • 217.160.248.65 -- BillMcGonigle - 09 Feb 2006
      • Recommend moving SSH to nonstandard port. Scripted attacks only hit 22. -- DrewVanZandt - 10 Feb 2006
        • I've been port-scanned for ssh running on non-standard ports. -- BillMcGonigle - 11 Feb 2006
      • All except non-routable IP's. But run ssh on a non-standard, non-privileged port.
        • 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
      • Suggest running SSH on a nonstandard port -- ColeTuininga - 10 Feb 2006
    • Allowed Ports for our backup DNS, currenly LINUX.CODEMETA.COM (199.125.76.10)
      • 53/tcp
>
>
    • ICMP echo request (ping)
  • SSH -- for specifics, see discussion in "Remote Access"
  • Allow 53/tcp from DNS slaves
    • 199.125.76.10 LINUX.CODEMETA.COM

Remote Access (SSH)

Public keys

It 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. smile -- DrewVanZandt - 10 Feb 2006

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

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

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 2006

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).

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. smile -- BenScott - 16 Feb 2006

IP address restrictions

It 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:
<
<
  • SSH - Require public key authentication, 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
  • 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. smile
>
>
  • logsentry/logwatch/etc - alert us to unusual messages (email, maybe SMS) -- BenScott - 16 Feb 2006
  • portsentry - identify probes and scans and auto-firewall the source addresses -- BenScott - 16 Feb 2006

 <<O>>  Difference Topic ServerSecurity (r1.11 - 15 Feb 2006 - BenScott)

META TOPICPARENT InternetServer
Our InternetServer will need to be protected against all the Internet nasties (which are legion).
Added:
>
>

Goals

  • Availability - Keep the services up and running.
  • Integrity - Prevent our Internet presence from being vandalized or subverted.
  • Traceability - Track who did what, when. Needed for change control and as a best practice.
  • Authenticity - Making sure admins really are who they say they are is important. Otherwise, this is a lower priority for us; most stuff is cleartext and public.
  • Privacy - Generally not a priority for us. Most of what we do is public by nature and intent. Still, some things (e.g., root password) will need to be protected.

Account Restrictions

Changed:
<
<
  • All admins have their own account on the system.
  • Disallow root access, except via sudo.
  • Disallow sudo <shell> access. 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. -- BenScott - 08 Feb 2006
>
>
  • All people have their own user account on the system.
  • No direct root logins. Login to user account first, then sudo. This gives us both enhanced security and traceability.

sudo to shell

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.

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
Added:
>
>

  • Some things that require shell redirection don't work without this - 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
Added:
>
>

OTP for sudo


  • 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

Firewall

 <<O>>  Difference Topic ServerSecurity (r1.10 - 13 Feb 2006 - MikeLedoux)

META TOPICPARENT InternetServer
Our InternetServer will need to be protected against all the Internet nasties (which are legion).
Line: 9 to 9

  • Disallow sudo <shell> access. 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. -- BenScott - 08 Feb 2006
  • 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 - 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:
<
<
  • 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
>
>
  • 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

Firewall

 <<O>>  Difference Topic ServerSecurity (r1.9 - 13 Feb 2006 - BruceDawson)

META TOPICPARENT InternetServer
Our InternetServer will need to be protected against all the Internet nasties (which are legion).
Line: 9 to 9

  • Disallow sudo <shell> access. 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. -- BenScott - 08 Feb 2006
  • 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 - 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:
<
<
  • OTP (OPIE or some other S/Key) for sudo access. -- MikeLedoux - 13 Feb 2006
>
>
  • 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

Firewall

 <<O>>  Difference Topic ServerSecurity (r1.8 - 12 Feb 2006 - MikeLedoux)

META TOPICPARENT InternetServer
Our InternetServer will need to be protected against all the Internet nasties (which are legion).
Line: 6 to 6

  • All admins have their own account on the system.
  • Disallow root access, except via sudo.
Changed:
<
<
  • Disallow sudo access. 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 ' is used. -- BenScott - 08 Feb 2006
>
>
  • Disallow sudo <shell> access. 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. -- BenScott - 08 Feb 2006

  • 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 - 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
Added:
>
>
  • OTP (OPIE or some other S/Key) for sudo access. -- MikeLedoux - 13 Feb 2006

Firewall

 <<O>>  Difference Topic ServerSecurity (r1.7 - 11 Feb 2006 - BillMcGonigle)

META TOPICPARENT InternetServer
Our InternetServer will need to be protected against all the Internet nasties (which are legion).
Line: 7 to 7

  • All admins have their own account on the system.
  • Disallow root access, except via sudo.
  • Disallow sudo access. Yes, this make things more difficult, but
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 ' is used. -- BillMcGonigle - 08 Feb 2006
>
>
  • 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 ' is used. -- BenScott - 08 Feb 2006

  • 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 - 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
Line: 23 to 23

    • Allowed IP's for port 22 ssh
      • 217.160.248.65 -- BillMcGonigle - 09 Feb 2006
      • Recommend moving SSH to nonstandard port. Scripted attacks only hit 22. -- DrewVanZandt - 10 Feb 2006
Added:
>
>
        • I've been port-scanned for ssh running on non-standard ports. -- BillMcGonigle - 11 Feb 2006

      • All except non-routable IP's. But run ssh on a non-standard, non-privileged port.
Added:
>
>
        • 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

      • Suggest running SSH on a nonstandard port -- ColeTuininga - 10 Feb 2006
    • Allowed Ports for our backup DNS, currenly LINUX.CODEMETA.COM (199.125.76.10)
      • 53/tcp

Remote Access

Changed:
<
<
  • SSH - Require public key authentication, 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.
>
>
  • SSH - Require public key authentication, 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

  • 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. smile
 <<O>>  Difference Topic ServerSecurity (r1.6 - 10 Feb 2006 - DrewVanZandt)

META TOPICPARENT InternetServer
Our InternetServer will need to be protected against all the Internet nasties (which are legion).
Line: 7 to 7

  • All admins have their own account on the system.
  • Disallow root access, except via sudo.
  • Disallow sudo access. Yes, this make things more difficult, but
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 ' is used.
>
>
  • 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 ' is used. -- BillMcGonigle - 08 Feb 2006

  • 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 - 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
Line: 24 to 24

      • 217.160.248.65 -- BillMcGonigle - 09 Feb 2006
      • Recommend moving SSH to nonstandard port. Scripted attacks only hit 22. -- DrewVanZandt - 10 Feb 2006
      • All except non-routable IP's. But run ssh on a non-standard, non-privileged port.
Added:
>
>
      • Suggest running SSH on a nonstandard port -- ColeTuininga - 10 Feb 2006

    • Allowed Ports for our backup DNS, currenly LINUX.CODEMETA.COM (199.125.76.10)
      • 53/tcp

Remote Access

  • SSH - Require public key authentication, 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.
Changed:
<
<
  • Suggest running SSH on a nonstandard port -- ColeTuininga - 10 Feb 2006
>
>
  • 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. smile

 <<O>>  Difference Topic ServerSecurity (r1.5 - 10 Feb 2006 - BruceDawson)

META TOPICPARENT InternetServer
Our InternetServer will need to be protected against all the Internet nasties (which are legion).
Line: 23 to 23

    • Allowed IP's for port 22 ssh
      • 217.160.248.65 -- BillMcGonigle - 09 Feb 2006
      • Recommend moving SSH to nonstandard port. Scripted attacks only hit 22. -- DrewVanZandt - 10 Feb 2006
Added:
>
>
      • All except non-routable IP's. But run ssh on a non-standard, non-privileged port.

    • Allowed Ports for our backup DNS, currenly LINUX.CODEMETA.COM (199.125.76.10)
      • 53/tcp
 <<O>>  Difference Topic ServerSecurity (r1.4 - 10 Feb 2006 - DrewVanZandt)

META TOPICPARENT InternetServer
Our InternetServer will need to be protected against all the Internet nasties (which are legion).
Line: 8 to 8

  • Disallow root access, except via sudo.
  • Disallow sudo access. 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 ' is used.
Added:
>
>
  • 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 - 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

Firewall

 <<O>>  Difference Topic ServerSecurity (r1.3 - 10 Feb 2006 - ColeTuininga)

META TOPICPARENT InternetServer
Our InternetServer will need to be protected against all the Internet nasties (which are legion).
Line: 28 to 28

Remote Access

  • SSH - Require public key authentication, 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.
Added:
>
>
  • Suggest running SSH on a nonstandard port -- ColeTuininga - 10 Feb 2006

 <<O>>  Difference Topic ServerSecurity (r1.2 - 10 Feb 2006 - DrewVanZandt)

META TOPICPARENT InternetServer
Our InternetServer will need to be protected against all the Internet nasties (which are legion).
Line: 21 to 21

      • 53/udp
    • Allowed IP's for port 22 ssh
Added:
>
>
      • Recommend moving SSH to nonstandard port. Scripted attacks only hit 22. -- DrewVanZandt - 10 Feb 2006

    • Allowed Ports for our backup DNS, currenly LINUX.CODEMETA.COM (199.125.76.10)
      • 53/tcp
 <<O>>  Difference Topic ServerSecurity (r1.1 - 09 Feb 2006 - BenScott)
Line: 1 to 1
Added:
>
>
META TOPICPARENT InternetServer
Our InternetServer will need to be protected against all the Internet nasties (which are legion).

Account Restrictions

  • All admins have their own account on the system.
  • Disallow root access, except via sudo.
  • Disallow sudo access. 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 ' is used.
    • Some things that require shell redirection don't work without this - 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

Firewall

  • iptables - unless there is some other level of firewalling available to us.
    • even if there is a hardware firewall, don't trust it. To expound, only allow incoming access on the minimum number of ports to get us going. We should restrict ssh access to a limited number of IP's to avoid being DDOS'ed with ssh scans. -- BillMcGonigle - 09 Feb 2006
    • Allowed Ports From Anywhere
      • 25/tcp
      • 80/tcp
      • 443/tcp
      • 53/udp
    • Allowed IP's for port 22 ssh
    • Allowed Ports for our backup DNS, currenly LINUX.CODEMETA.COM (199.125.76.10)
      • 53/tcp

Remote Access

  • SSH - Require public key authentication, 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.
Revision r1.1 - 09 Feb 2006 - 20:07 - BenScott
Revision r1.20 - 07 Mar 2009 - 16:39 - BenScott