Re: Security/Hacked System - Now what?!!
On Sat, 21 Dec 2013 19:36:26 -0500, bruce wrote: For sake of discussion, assume a fresh base desktop install of the OS (Fed/RHEL/Centos). After doing the install from the iso(s), you install : -rkhunter -chkconfig Did you mean chkrootkit? If so, it's only for experienced users (who know how to determine false positives and how to take a closer look), and it's really useless these days, since it hasn't been updated in many years. It should be removed from the distribution. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Security/Hacked System - Now what?!!
bruce badoug...@gmail.com writes: And regarding the ssh/remote access, you specify public/private keys, and you have the key process run from the key file. This allows a user to be able to ssh into the box without having to use the ssh passwd, but only from the corresponding box that has the associated public (master/client) passwd/key setup to permit the login access. You should set up the RSA or ECDHE private keys with a password. ssh-keygen prompts you for a password when it cranks out the key for you. But in this situation, if a user hacks into the 1st system, then they have access to the 2nd system, assuming they know the 2nd system's username. This would happen as the private/public key access file has been setup! Without the decryption password for the RSA or ECDHE keys, they are going nowhere. On the other hand, you want *all* of your systems up to snuff with all forms of unix password logins turned off. Seems like you are implying that some systems are easier to break into than others. That's not good. /etc/ssh/sshd_config: Protocol 2 # reset the host keys to only rsa or ecdsa HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_ecdsa_key # rekey every hour or default data (1G - 4G depending on cipher) RekeyLimit default 1h SyslogFacility AUTHPRIV # We use RSA/ECDSA. If it hasn't completed in 10 seconds, there is a # big problem. LoginGraceTime 10 # Unlike what this looks like, it says that root may not use the unix # password for authentication. Root *must* use public-key. -wsr PermitRootLogin without-password AuthorizedKeysFile .ssh/authorized_keys # no unix passwords any more. RSA or ECDSA only. PasswordAuthentication no ChallengeResponseAuthentication no KerberosAuthentication no GSSAPIAuthentication no UsePAM no X11Forwarding yes UsePrivilegeSeparation sandbox # Default for new installations. # Set the keep-alive for a heartbeat every 60 seconds and a connection # close after 30 minutes. -wsr 2003/11/26 ClientAliveInterval 60 ClientAliveCountMax 30 # Accept locale-related environment variables AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE AcceptEnv XMODIFIERS # Cut down on the number of user accounts that can ssh in just in case # some bug allows .ssh/authorized_keys files to be written. AllowUsers root user1 user2 usern # --- end -wolfgang -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Security/Hacked System - Now what?!!
Wolfgang, Right in what you wrote. And what you wrote allows for ssh commands to be used where you specify the keyFile. However you can also mod the ssh_config (i believe) to have it auto use the keyFile with the pub/private key to negotiate the user/passwd process for the ssh cmd. This is useful when remotely/programatically accessing the ssh cmdline process for running remote apps, xferring files, etc. But, and in my case, once all of this is setup, and working. If hacker guy gets in Sys1, (where Sys1/Sys2 have been setup to do pub/private key, and the underlying Sys1/Sys2 keyfiles have been created) then hacker guy can easily get into/access Sys2, provided they know the username. And this is where I'm trying to determine if there's any kind of approach/process to allow for the programmatic use via ssh, but at the same time be secure if the initial system is hacked. Thanks -bruce On Sun, Dec 22, 2013 at 8:31 AM, Wolfgang S. Rupprecht wolfgang.ruppre...@gmail.com wrote: bruce badoug...@gmail.com writes: And regarding the ssh/remote access, you specify public/private keys, and you have the key process run from the key file. This allows a user to be able to ssh into the box without having to use the ssh passwd, but only from the corresponding box that has the associated public (master/client) passwd/key setup to permit the login access. You should set up the RSA or ECDHE private keys with a password. ssh-keygen prompts you for a password when it cranks out the key for you. But in this situation, if a user hacks into the 1st system, then they have access to the 2nd system, assuming they know the 2nd system's username. This would happen as the private/public key access file has been setup! Without the decryption password for the RSA or ECDHE keys, they are going nowhere. On the other hand, you want *all* of your systems up to snuff with all forms of unix password logins turned off. Seems like you are implying that some systems are easier to break into than others. That's not good. /etc/ssh/sshd_config: Protocol 2 # reset the host keys to only rsa or ecdsa HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_ecdsa_key # rekey every hour or default data (1G - 4G depending on cipher) RekeyLimit default 1h SyslogFacility AUTHPRIV # We use RSA/ECDSA. If it hasn't completed in 10 seconds, there is a # big problem. LoginGraceTime 10 # Unlike what this looks like, it says that root may not use the unix # password for authentication. Root *must* use public-key. -wsr PermitRootLogin without-password AuthorizedKeysFile .ssh/authorized_keys # no unix passwords any more. RSA or ECDSA only. PasswordAuthentication no ChallengeResponseAuthentication no KerberosAuthentication no GSSAPIAuthentication no UsePAM no X11Forwarding yes UsePrivilegeSeparation sandbox # Default for new installations. # Set the keep-alive for a heartbeat every 60 seconds and a connection # close after 30 minutes. -wsr 2003/11/26 ClientAliveInterval 60 ClientAliveCountMax 30 # Accept locale-related environment variables AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE AcceptEnv XMODIFIERS # Cut down on the number of user accounts that can ssh in just in case # some bug allows .ssh/authorized_keys files to be written. AllowUsers root user1 user2 usern # --- end -wolfgang -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Security/Hacked System - Now what?!!
bruce badoug...@gmail.com writes: However you can also mod the ssh_config (i believe) to have it auto use the keyFile with the pub/private key to negotiate the user/passwd process for the ssh cmd. This is useful when remotely/programatically accessing the ssh cmdline process for running remote apps, xferring files, etc. Programatic password-less access can be done if you carefully limit the user to be powerless and the commands that that user is allowed to execute are limited to the one command you want to run over ssh. Search for 'command=command' in the sshd man page. But, and in my case, once all of this is setup, and working. If hacker guy gets in Sys1, (where Sys1/Sys2 have been setup to do pub/private key, and the underlying Sys1/Sys2 keyfiles have been created) then hacker guy can easily get into/access Sys2, provided they know the username. That is why you generally don't want the remote systems to have access to the main server. More secure would be if you push information from the main server to the remote systems. -wolfgang -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Security/Hacked System - Now what?!!
bruce badouglas@gma il.com writes: You then mod SSH as required to disable root login OK, what else should you do? Root login isn't a bad idea in and of itself. More important is to not allow anything but public key logins (eg. ECDSA, RSA). For people logging in with root credentials, give everyone a different public key and keep a secure copy of /var/log/secure on a secure system for backtracking breakins. Each login (including root) will show which key was used to log in. You can easily see who lost control of their key. I'm a firm believer in never allowing passwords logins over the net. Users will hardly ever use random-letter-upper-lower-number passwords. They always think they are oh so clever with easily guessed strung together words, with or without a punctuation char. -wolfgang -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Security/Hacked System - Now what?!!
Hi Wolfgang, Ok, say you have a box that you want to remotely access. Never a need to access the box via the gui/login. And regarding the ssh/remote access, you specify public/private keys, and you have the key process run from the key file. This allows a user to be able to ssh into the box without having to use the ssh passwd, but only from the corresponding box that has the associated public (master/client) passwd/key setup to permit the login access. But in this situation, if a user hacks into the 1st system, then they have access to the 2nd system, assuming they know the 2nd system's username. This would happen as the private/public key access file has been setup! Any way around this, or am I missing something... I'm thinking that you could setup the user(s) on the client machine, to restrict access/perms, but it still doesn't do anything about the fact that once a user hacks into the parent machine, they then would have access into the 2nd machine... feedback welcome.. On Sat, Dec 21, 2013 at 9:06 PM, Wolfgang S. Rupprecht wolfgang.ruppre...@gmail.com wrote: bruce badouglas@gma il.com writes: You then mod SSH as required to disable root login OK, what else should you do? Root login isn't a bad idea in and of itself. More important is to not allow anything but public key logins (eg. ECDSA, RSA). For people logging in with root credentials, give everyone a different public key and keep a secure copy of /var/log/secure on a secure system for backtracking breakins. Each login (including root) will show which key was used to log in. You can easily see who lost control of their key. I'm a firm believer in never allowing passwords logins over the net. Users will hardly ever use random-letter-upper-lower-number passwords. They always think they are oh so clever with easily guessed strung together words, with or without a punctuation char. -wolfgang -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
