Hi to all again, thanks for all the ideas!
What I did at the end is a mix of some things you guys said:
1.- created a .bashrc fila with a logout on the first line for all users (Just one) 2.- Change shell to bash for all this users. 3.- chown root .bashrc 4.- chmod 555 .bashrc
And there you go!
Do you find a hole on that?
Regards.
Ben Yau wrote:
-----Original Message----- From: Sven 'Darkman' Michels [mailto:sven@darkman.de]
Ben Yau wrote:
Another thing to try is put "logout" at the beginning of ~/.bash_login. Upon ssh login it will run the .bash_login and log them out.
On sftp, it
won't run ~/.bash_login so they can still sftp
ssh user@remote.sftp.server rm .bash_login
;)
Ruin my day .. go ahead :)
I started thinking of another solution (along the lines of alias rm='logout') when I realized that a smart user could just sftp and put in
a
new ~/.bash_profile.
Provided they were clever enough to figure out how you auto logged them
out.
...
Depends on what's acceptable at your place. You could give the person (people) a home dir that is owned by root, and all files in the home dir owned by root, with perms of 555 (basically a shell home, just enough to make whatever you need work); then you could set things up that way. It seems to me there should be a more elegant way, but my point is you should be able to make the above work. That is assuming you're allowed to lock it down that tight (by management).
HTH, Kevin
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
Manuel Balderrábano wrote:
Hi to all again, thanks for all the ideas!
What I did at the end is a mix of some things you guys said:
1.- created a .bashrc fila with a logout on the first line for all users (Just one) 2.- Change shell to bash for all this users. 3.- chown root .bashrc 4.- chmod 555 .bashrc
And there you go!
Do you find a hole on that?
how about this:
ssh remote.host /bin/sash
;)
Quoting Manuel Balderrábano garibolo@wanadoo.es:
Hi to all again, thanks for all the ideas!
What I did at the end is a mix of some things you guys said:
1.- created a .bashrc fila with a logout on the first line for all users (Just one) 2.- Change shell to bash for all this users. 3.- chown root .bashrc 4.- chmod 555 .bashrc
And there you go!
Do you find a hole on that?
Why don't you just use 'scponly' or 'rssh'? The posted workarounds are kinda silly when there are two perfectly good programs written precisely for what you're looking for...
-----Original Message----- From: suse@rio.vg [mailto:suse@rio.vg] Sent: Wednesday, January 28, 2004 12:23 PM To: suse-security@suse.com Subject: Re: Fw: [suse-security] sftp with no ssh login
Why don't you just use 'scponly' or 'rssh'? The posted workarounds are kinda silly when there are two perfectly good programs written precisely for what you're looking for...
Can you use rssh with cvs? One reason we use ssh is because of cvs. We didn't want to use rsh or pserver. So we have a bunch of people cvs into our file server but do not want them to have login access.
Ben
if you check the files below, they are owned by the apache user.
My apache is linux:/tmp # rpm -q apache -> apache-1.3.27-82
Anyone know of existing security leaks for this?
Thanks Evert
Below-> listing of temp files,anyone seens this before?
drwxrwxrwt 25 root root 1640 Jan 31 12:45 . drwxr-xr-x 22 root root 512 Dec 5 14:52 .. drwxr-xr-x 8 wwwrun nogroup 640 Jan 21 10:49 ... drwxr-xr-x 2 wwwrun nogroup 48 Jan 28 15:17 .... drwxrwxrwt 2 root root 48 Mar 18 2003 .ICE-unix drwxrwxrwt 2 root root 48 Mar 18 2003 .X11-unix drwxr-xr-x 2 root root 48 Aug 10 15:16 .qt -rwxr-xr-x 1 wwwrun nogroup 838 Dec 15 12:49 .rHgmHsb drwxr-xr-x 2 root root 144 Aug 11 16:12 .webmin drwx------ 2 root root 48 Aug 10 15:53 YaST2-02912-qsgkrH drwx------ 2 root root 48 Aug 10 15:53 YaST2-02935-ouNVcO drwx------ 2 root root 48 Aug 12 01:16 YaST2-07664-ZvoZ8K drwx------ 2 root root 48 Aug 12 01:16 YaST2-07664-auzHSh drwx------ 2 root root 48 Aug 10 22:59 YaST2-07686-1dMyRl drwx------ 2 root root 48 Aug 10 22:59 YaST2-07686-srPZXX drwx------ 2 root root 48 Aug 21 09:47 YaST2.tdir -rw-r--r-- 1 wwwrun nogroup 424644 Oct 15 04:46 ary.tgz.tgz -rwxr-xr-x 1 wwwrun nogroup 19580 Jan 28 15:17 bindtty -rwxr-xr-x 1 wwwrun nogroup 15003 Aug 5 20:17 cbd -rwxr-xr-x 1 wwwrun nogroup 17897 Jan 31 08:26 cgi -rwxrwxrwx 1 wwwrun nogroup 15029 Jan 31 08:42 cgi.1 -rw-r--r-- 1 wwwrun nogroup 11805 Jan 31 08:42 dc -rw------- 1 wwwrun nogroup 8952 Jan 30 10:22 sess_2c7437c59ed72bd629dbf80821a7d18e -rw------- 1 wwwrun nogroup 22261 Jan 31 12:40 sess_3b7cea3ca7bcc2eb36e488c9246fa6e9 -rw------- 1 wwwrun nogroup 9309 Jan 30 11:21 sess_5343ef8f9fc370f32683b6fa46c97475 -rw------- 1 wwwrun nogroup 10277 Jan 30 15:48 sess_82e39dce0b040da32ef0173ec78ec061 -rw------- 1 wwwrun nogroup 17344 Jan 30 13:34 sess_97acba92f3fe53b2bdd085fcc63866d8 -rw------- 1 wwwrun nogroup 25966 Jan 30 08:31 sess_a5a39f339352ede930fc2adc46a30ca7 -rw------- 1 wwwrun nogroup 12524 Jan 30 10:42 sess_ade174aac83031f1b20e0efd08465a73 -rw------- 1 wwwrun nogroup 22138 Jan 30 09:03 sess_cae01eeb71780d8a5dd9cebc4abf6e45 -rw------- 1 wwwrun nogroup 26961 Jan 30 15:34 sess_e6d8df92da33395045842fbf19f8c8cf -rw------- 1 wwwrun nogroup 30854 Jan 31 08:59 sess_f35c03347ec657bc814b17571dc5877d -rw------- 1 wwwrun nogroup 8952 Jan 30 07:59 sess_f6fedf50059f8b64747e060905fde21d drwx------ 2 everts users 80 Aug 12 22:26 ssh-XX9Glbxm drwx------ 2 everts users 80 Sep 16 23:06 ssh-XX9kCFU2 drwx------ 2 everts users 80 Sep 28 08:47 ssh-XXDzxDkf drwx------ 2 everts users 80 Jan 31 08:47 ssh-XXJioYvk drwx------ 2 everts users 80 Sep 22 20:38 ssh-XXZFwAIi drwx------ 2 everts users 80 Aug 11 14:11 ssh-XXioCldw drwx------ 2 everts users 80 Oct 1 20:49 ssh-XXuOdNCB drwx------ 2 everts users 80 Oct 1 21:00 ssh-XXw3Tg6h drwx------ 2 everts users 80 Aug 11 14:59 ssh-XXwqFEAg drwx------ 2 everts users 80 Dec 5 13:08 ssh-XXzcFeK0 -rwxrwxrwx 1 wwwrun nogroup 170613 Dec 5 06:45 telnetd -rwxrwxrwx 1 wwwrun nogroup 16798 Jan 28 07:51 webphp
On Sat, 31 Jan 2004, Evert Smit wrote:
if you check the files below, they are owned by the apache user.
My apache is linux:/tmp # rpm -q apache -> apache-1.3.27-82
Anyone know of existing security leaks for this?
if this is a suse 8.2 the apache should be ok, but you need to check all your cgi's and php-scripts too. and you should look into you apache logs if there is something unusual.
c'ya sven
Hi,
if you check the files below, they are owned by the apache user.
My apache is linux:/tmp # rpm -q apache -> apache-1.3.27-82
Anyone know of existing security leaks for this?
apache can be patched and without security holes but what is with other apache modules or scripts?! check this also!
the entries in your directory list like "..." and "...." are not normal, chack what is in this directories! (i thik your machine was hacked and you shold disconnect it from network, backup all logs, grep for open connection and processes for research purposes and make a clean install of the system!)
chack running process and opened network connections, check for rootkits (also the services that are in LISTEN mode)
Below-> listing of temp files,anyone seens this before?
drwxrwxrwt 25 root root 1640 Jan 31 12:45 . drwxr-xr-x 22 root root 512 Dec 5 14:52 .. drwxr-xr-x 8 wwwrun nogroup 640 Jan 21 10:49 ... drwxr-xr-x 2 wwwrun nogroup 48 Jan 28 15:17 .... -rwxr-xr-x 1 wwwrun nogroup 838 Dec 15 12:49 .rHgmHsb -rw-r--r-- 1 wwwrun nogroup 424644 Oct 15 04:46 ary.tgz.tgz -rwxr-xr-x 1 wwwrun nogroup 19580 Jan 28 15:17 bindtty -rwxr-xr-x 1 wwwrun nogroup 15003 Aug 5 20:17 cbd -rwxr-xr-x 1 wwwrun nogroup 17897 Jan 31 08:26 cgi -rwxrwxrwx 1 wwwrun nogroup 15029 Jan 31 08:42 cgi.1 -rw-r--r-- 1 wwwrun nogroup 11805 Jan 31 08:42 dc -rw------- 1 wwwrun nogroup 8952 Jan 30 10:22 -rwxrwxrwx 1 wwwrun nogroup 170613 Dec 5 06:45 telnetd -rwxrwxrwx 1 wwwrun nogroup 16798 Jan 28 07:51 webphp
best regards, allen
1.- created a .bashrc fila with a logout on the first line for all users (Just one) 2.- Change shell to bash for all this users. 3.- chown root .bashrc 4.- chmod 555 .bashrc
And there you go!
Do you find a hole on that?
Yes ... user can still remove it, because he owns his home directory and has therefore delete rights. You COULD set the permissions like in /tmp (1755), but I ask myself, why you don't use scponly or rssh as shell, as I suggested? They are designed for your purpose. No clumsy scripts and permissions necessary!
Markus
-
allen＠tele-call.de -
Ben Yau -
Evert Smit -
Manuel Balderrábano -
Markus Gaugusch -
suse＠rio.vg -
Sven 'Darkman' Michels -
Sven-Haegar Koch