This post is more than 5 years old
1 Rookie
•
20.4K Posts
0
2894
Restricted SSH and SupportIQ
I have a requirement to lock down ssh/WebUI access to Isilon to specific ip subnets (going to use primus emc14002971). My one concern is Isilon support access to my cluster using SupportIQ. Currently SupportIQ is enabled on our cluster to allow for ssh and web access, my goal is not to brake it by enabling restricted access. So the question is, what ip/mask do i need to add to my host.allow file to allow Isilon support to get into the cluster ?
OneFS 6.5.5.22
Thank you
AndrewChung
132 Posts
0
August 1st, 2013 10:00
In terms of having support able to manage the systems, support will generally start a WebEx session to connect to the cluster. So as long as you are stating that WebEx from a machine that is allowed access through a firewall we should be fine there. In terms of the direct SSH access, as long as the cluster has a means to get out to the Internet via HTTPS then you can enable the direct SSH login option and that will work as well. We tunnel the SSH session over HTTPS.
AndrewChung
132 Posts
0
August 1st, 2013 11:00
For things like logs, if you have SupportIQ on, support can gather logs without SSH. The cluster will perform a regular poll out to our support server and it can grab instructions to perform basic log gathering and auto upload without SSH. SSH is only really required if someone needs to go in and manually run commands on the cluster.
dynamox
1 Rookie
1 Rookie
•
20.4K Posts
0
August 1st, 2013 11:00
Andrew,
SupportIQ has been enabled for 2 years now with direct ssh and web access. I don't want to do webex for rudimentary things like collecting logs ..etc, Isilon needs to give 1st level support access to SupportIQ.
Good to know what you tunnel ssh over https, so i don't need to add any special subnets to hosts.allow files.
Thanks
dynamox
1 Rookie
1 Rookie
•
20.4K Posts
0
August 1st, 2013 13:00
i agree, yet every time i open a ticket first level support insists on doing webex or asks me to run isi_gather.
/rant
I don't want to do it neither do i have time to do it ..that's why we opened ssh/web access to Isilon support and provided cluster credentials. Sounds like a training opportunity for Isilon support organization. /rant
Peter_Sero
1.2K Posts
1
August 2nd, 2013 03:00
Yeah, I also wondered wether there is a policy on pushing vs. pulling isi_gather logs.
We don't do much Webex here, but tunneled ssh as Andrew has described.
Usually I ask the supporter to issue a "script -t 1" command at the start of the session.
It logs all terminal input and output to a single file ("typescript"),
buffering for at most 1 second ("-t 1").
I can then watch all activities with "tail -f typescript" in real time
and discuss issues on the phone at the same time.
Plus, the typescript can be archived for later reference.
(The logging feature of "screen" might also work.)
-- Peter
Peter_Sero
1.2K Posts
0
August 2nd, 2013 04:00
That impossible, but as you log any attempt, it should be mostly ok.
-- Peter
Peter_Sero
1.2K Posts
0
August 2nd, 2013 04:00
sudo /bin/bash
sudo /usr/bin/vi -> :sh ;-)
Actually I enable ssh access only temporarily, and while having the supporter on the phone.
-- Peter
Peter_Sero
1.2K Posts
1
August 2nd, 2013 04:00
That still allows other commands, like vi, to be sudo'ed at first,
and then escape to a shell (":sh")...
Even more obvious for "script", "screen", "xterm", ...
And one simply cannot know the details for OneFS specific commands.
Or how about "cp /bin/bash /tmp/mash; sudo /tmp/mash"?
There have been endless debates on this already... anyway, have a nice weekend.
-- Peter
dynamox
1 Rookie
1 Rookie
•
20.4K Posts
0
August 2nd, 2013 04:00
sure it's possible
Cmnd_Alias NSHELLS = /usr/bin/sh,/usr/bin/zsh,/usr/bin/bash
Cmnd_Alias NSU = /usr/bin/su,/usr/local/sbin/visudo
admin ALL=(ALL) NOPASSWD: ALL, !NSU, !NSHELLS
dynamox
1 Rookie
1 Rookie
•
20.4K Posts
0
August 2nd, 2013 04:00
no worries, i googled enough to lock those things down too
dynamox
1 Rookie
1 Rookie
•
20.4K Posts
0
August 2nd, 2013 04:00
configure your sudoers file like i provided above and try your vi/sh trick ..let me know how that works for ya.
dynamox
1 Rookie
1 Rookie
•
20.4K Posts
0
August 2nd, 2013 04:00
i don't give support root access, i setup an account with sudo privileges and restricted it so they can't su to root but can run any command they want. This way i log what's going on.
Peter_Sero
1.2K Posts
1
August 2nd, 2013 05:00
Sure it works:
isilon-1:/tmp $ id uid=...(pserocka) gid=...
isilon-1:/tmp $ sudo ex
/tmp//vi.YsAzrb1mtP: new file: line 1
:sh
[root@isilon-1 /tmp]# id
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator),20(staff),70(ifs),10(admin)
Voila!
(Using ex instead of vi to avoid clearing the screen.
And I have doublechecked=tested
that the sudo restrictions on the shells etc actually apply to the account.)
Now for your test...
-- Peter
dynamox
1 Rookie
1 Rookie
•
20.4K Posts
0
August 2nd, 2013 07:00
if i run vi without sudo i can't, if i run it with sudo i can :sh . Wonderful
ultimately if somebody really wants to do that they will, i can't even log that because to me it will look like they are simply trying to vi a legitimate file. Our site notes specifically say what account to use with sudo privileges because we want to audit what's being done. If technician is trying to circumvent documented procedure and gets caught, they will need to explain that to our security team. Thank you Peter
Peter_Sero
1.2K Posts
0
August 3rd, 2013 05:00
Glad to hear ;-)
It is indeed good practice not to work in a root shell, but to use sudo,
even for the main admins, for some logging, limiting the impact of accidental mistakes and so on.
Just don't expect to establish a "sandbox" or "jail" with sudo.
The key is that permissions or restrictions to execute certain programs
are NOT inheritable properties of a process in UNIX. Unlike memory
and other restrictions set by "ulimit", which cannot (in their "hard" form)
be escaped throughout a whole process hierarchy.
sudo simply applies its rules to the launch of the executable in question.
-- Peter