AnsweredAssumed Answered

Disable Root SSH

Question asked by Sean Koniarz on Feb 3, 2014
Latest reply on Mar 14, 2014 by Jeff Marshall

Like • Show 0 Likes0
Comment • 6

Hey SA Community,

I am looking to disable root login via SSH which is easy enough but I also don't want to lose my ability to SFTP the files in /etc/netwitness/ng/envision/etc/devices.

I have already setup PAM and added the users to wheel so I can get root access if needed. The best way I thought to do this was to change group ownership to wheel then change permissions to the files to 660 so I will be able to sftp the information off with my own user account. I am just worried this might break other internal processes, any ideas?

If all else fails I will open a support case and see what they say also.

Thanks

RSA Admin

Feb 3, 2014 9:04 AM

Correct Answer

You should SFTP those files to the home directory of the user that you created to SSH to that appliance. Do not change the permissions on the directory. You went to all this trouble to deny direct root logins for SSH, so don't compromise that control by then allowing direct SFTP of files with root-like permissions to the appliance. If you want to do that just allow root logins. So, SFTP the files to the home directory of the user, then SSH to the appliance and sudo the file to the appropriate place.

See the reply in context

No one else had this question

Outcomes

RSA Admin

Feb 3, 2014 9:04 AM

Actions

Sean Koniarz @ RSA Admin on Feb 3, 2014 9:17 AM

Good point about enabling root like privileges to other users.

So if my thinking is correct, the best way to make it easy for everyone in wheel group is to have a directory that allows all wheel group members to access that has a copy of all the information in the /etc/netwitness/ng/envision/etc folder, then from there copy the data to the production directory.

Actions

RSA Admin

@ Sean Koniarz on Feb 3, 2014 9:28 AM

If you want other users to be able to put log parsers into this directory, then you put them in the sudoers list and allow them to sudo the files. You don't need to create a separate directory for staging.

then the user will SFTP to their home directory and then sudo to copy/move the directory into the appropriate place. If they aren't in the sudoers then they are allowed access to the appliance, but maybe they aren't allowed to install parsers because they have a different function.

Actions

Jeff Marshall Mar 14, 2014 2:03 PM

Let me know if you run into any issues. I was getting ready to do the same thing...

Actions

Sean Koniarz @ Jeff Marshall on Mar 14, 2014 2:12 PM

We actually decided not to fully turn off root SSH access. I did however make it more secure by only allowing a ssh key with passphrase to be used. We now keep that key in a secure are of our network. Although this is less secure then turning off ssh access it is much less of a headache to edit a simple parsing file. I also turned on sudo for people who need access to root for other things like restarting services and such.

Actions

Jeff Marshall @ Sean Koniarz on Mar 14, 2014 2:34 PM

Bummer! I'm going to turn mine off still. I don't mind people having root access password but don't want it open by default. I submitted a ticket for vulnerabilities found on the SA boxes themselves and prefer not to leave it open.

Actions

6 Replies

RSA Admin Feb 3, 2014 9:04 AM
Unmark Correct
Correct Answer
You should SFTP those files to the home directory of the user that you created to SSH to that appliance. Do not change the permissions on the directory. You went to all this trouble to deny direct root logins for SSH, so don't compromise that control by then allowing direct SFTP of files with root-like permissions to the appliance. If you want to do that just allow root logins. So, SFTP the files to the home directory of the user, then SSH to the appliance and sudo the file to the appropriate place.
Like • Show 0 Likes0
Actions
- Sean Koniarz @ RSA Admin on Feb 3, 2014 9:17 AM
  Mark Correct
  Correct Answer
  Good point about enabling root like privileges to other users.
  
  So if my thinking is correct, the best way to make it easy for everyone in wheel group is to have a directory that allows all wheel group members to access that has a copy of all the information in the /etc/netwitness/ng/envision/etc folder, then from there copy the data to the production directory.
  Like • Show 0 Likes0
  Actions
  - RSA Admin @ Sean Koniarz on Feb 3, 2014 9:28 AM
    Mark Correct
    Correct Answer
    If you want other users to be able to put log parsers into this directory, then you put them in the sudoers list and allow them to sudo the files. You don't need to create a separate directory for staging.
    
    then the user will SFTP to their home directory and then sudo to copy/move the directory into the appropriate place. If they aren't in the sudoers then they are allowed access to the appliance, but maybe they aren't allowed to install parsers because they have a different function.
    Like • Show 0 Likes0
    Actions
Jeff Marshall Mar 14, 2014 2:03 PM
Mark Correct
Correct Answer
Let me know if you run into any issues. I was getting ready to do the same thing...
Like • Show 0 Likes0
Actions
- Sean Koniarz @ Jeff Marshall on Mar 14, 2014 2:12 PM
  Mark Correct
  Correct Answer
  We actually decided not to fully turn off root SSH access. I did however make it more secure by only allowing a ssh key with passphrase to be used. We now keep that key in a secure are of our network. Although this is less secure then turning off ssh access it is much less of a headache to edit a simple parsing file. I also turned on sudo for people who need access to root for other things like restarting services and such.
  Like • Show 0 Likes0
  Actions
  - Jeff Marshall @ Sean Koniarz on Mar 14, 2014 2:34 PM
    Mark Correct
    Correct Answer
    Bummer! I'm going to turn mine off still. I don't mind people having root access password but don't want it open by default. I submitted a ticket for vulnerabilities found on the SA boxes themselves and prefer not to leave it open.
    Like • Show 0 Likes0
    Actions

Disable Root SSH

Outcomes

Related Content

Recommended Content