I implemented a ssh conection from the outside to my intranet. This ssh requires a username and a password.
In terms of security what is more secure: require authentication (username and password) or having the public key of each user that connects to our intranet in the
authorized public key lists (in this case there is no need for username and password)?
In the second case there is no need of authentication and only the users wich have the public keys in the list are allowed to enter in my intranet.
This second solution is a good solution or that brings other security problems ?
"Keep your friends close, but your enemies closer."
"Do or do not. There is no try" - Yoda
I feel erroneusly (?) secure after .host.denyed in.telnetd and
in.sshd from everywhere except one pc, which is denying all exept
keyboard. I belive that if i can keep hosts.deny and hosts.allow files
safe, and from time to time patch most actual security holes i`ll be
conditionaly safe. Em i wrong? Probably I do.
I just cant imaginate how system can be cracked in lower stage, so
that is my problem. I heard that inetd is very insecure, and some
peoples using tcpd (or soundlike).
I run harden_suse, but was forced to answer 8/10 to no, as my server
should provide a lot of public services, and have world writible
directories as well. And thats right - this script was developed not
for systems like mine one. However i`ll run SuSE-firewall-3.0 script,
to make my system even stronger. But thats all. I dont know what can i
do else. I should keep folowing services open:
httpd; smptd; pop3d; ftpd; snmpd; named; inetd; sshd; nscd.
So if you know how to keep them at minimal risk, or know some holes at
those, i would be very gratefull for any info and/or tips.
I dont ask to do work for me - link to good manual would be nice too.
By the way i have SuSE 6.3 (2.2.13).
Thanks in advice.
Gediminas Grigas mailto:firstname.lastname@example.org
Hi. I thought I would notify you of my findings on a possible security
problem within suse 6.3. Below is an excerpt about /dev/fd permissions
that I wrote a few days ago. I'm not sure if this has been noticed
before. If not, I hope the information does you some good. I'd appreciate
any responses on the matter that you can give, thanks :).
Out of the box, SuSE 6.3 allows global rw access on the primary and
secondary floppy drive (/dev/fd0 and /dev/fd1). Because devices can be
written to directly, just like anything else, the floppy drives do not
need to be mounted for any user to write data to a disk that has been
left in the drive. Depending on the systems setup, this can be a very
malicious tool. If the system boots SuSE directly from a floppy disk,
chances are the disk is left in the drive while the system is up. If a
user were to log on, and decide to use 'dd' (amongst a variety of other
tools, or even just a 'cat FILE > /dev/fd0') the boot floppy would be
ruined. A lazy sysadmin who didn't check the logs would not see that the
bootdisk had been ruined, and upon reboot, may find himself with a dead
box until the disk can be replaced. This is just one scenario where the
weak perms on the devices can be dangerous.
I just recently noticed this after installing SuSE 6.3 on one of my
systems over a month ago. The permissions on /dev/fd have been
checked on several SuSE 6.3 systems and all check out as o+rw. If you
are running SuSE 6.3 and have users other than yourself logging in, your
best bet is to 'chmod o-rw /dev/fd0'. I cannot think of one good reason
why SuSE would have set permissions on /dev/fd so weak. If you can
give any suggestions or feedback, an e-mail would be appreciated.
-- Bryan Hughes
dear suse security team,
on my standard suse 6.3 internet server, i have to do
"/sbin/init.d/syslog reload" after any log rotation.
if i don't restart it, syslog will not write to the new
this is a security issue, as i cannot track security
problems without log entries.
i already sent this as a bug report to suse a long time
ago but never got any response. what can i do?
b&b computersysteme * kämperheide 10 * 58285 gevelsberg * germany
fon +49 2333 913924 * fax +49 2333 913925 * http://www.bbcomp.de
on SuSE 5.3 /dev/psaux (PS2-mouse) was read and write for all users, now
(with SuSE >= 6.2) it's read only (perms = 664). Is there any risk, to
enable write permissions again on this device? (quake needs it! ;)
Peter Münster **** Brittany **** France
the box of a friend was hacked: /bin/ps /bin/login /bin/ls were
replaced / trojaned. The original files were placed in /bin/bincp
(which is not shown by ls, but cd into that dir works fine)
Luckyly I found some source within a log of
another machine. Comments show that there is an
unsigned char shellcode =
with some rows of "\x ...\x" numbers. I assume that there is the
coding of a shell command. Unfortunately I do not know how to "read"
the command. Translating the hex numbers into decimal and using an
ASCII table does not give a usefull result. Any idea?
Tips who to detect which root kit was used are welcome, too.
I have a problem concerning password aging on SuSE 6.3. If a password
expires the user is prompted for the new password at the login time. The
problem is that he/she can enter an empty one just by hitting Enter twice.
No checks for minimum password lenght, no cracklib checks - and these are
enabled in etc/login.defs. Changing the password from the prompt works
normally with all the checks in effect.
So, is there a way to enable atleast the minimum password lenght
check? Any comments and/or suggestions would be appreciated.
-----BEGIN PGP SIGNED MESSAGE-----
SuSE Security Announcement
Package: ircii < 4.4M
Date: Thu, 23 Mar 2000 11:04:19 GMT
Affected SuSE versions: all
Vulnerability Type: remote user compromise
SuSE default package: no
Other affected systems: all unix systems using ircii < 4.4M
A security hole was discovered in the package mentioned above.
Please update as soon as possible or disable the service if you are using
this software on your SuSE Linux installation(s).
Other Linux distributions or operating systems might be affected as
well, please contact your vendor for information about this issue.
Please note that we provide this information on an "as-is" basis only.
There is no warranty whatsoever and no liability for any direct, indirect or
incidental damage arising from this information or the installation of
the update package.
1. Problem Description
The package ircii is an irc client which is used to connect to irc
servers and chat with other users.
A buffer overflow in the dcc chat feature was found which is exploitable
by remote users.
Remote users may execute commands as the user running ircii.
Update the package from our FTP server.
Please verify these md5 checksums of the updates before installing:
(For SuSE 6.0, please use the 6.1 updates)
You can find updates on our ftp-Server:
ftp://ftp.suse.com/pub/suse/i386/update for Intel processors
ftp://ftp.suse.com/pub/suse/axp/update for Alpha processors
or try the following web pages for a list of mirrors:
Our webpage for patches:
Our webpage for security announcements:
If you want to report vulnerabilities, please contact
SuSE has got two free security mailing list services to which any
interested party may subscribe:
suse-security(a)suse.com - moderated and for general/linux/SuSE
security discussions. All SuSE security
announcements are sent to this list.
suse-security-announce(a)suse.com - SuSE's announce-only mailing list.
Only SuSE's security annoucements are sent
to this list.
To subscribe to the list, send a message to:
To remove your address from the list, send a message to:
Send mail to the following for info and FAQ for this list:
This information is provided freely to everyone interested and may
be redistributed provided that it is not altered in any way.
Type Bits/KeyID Date User ID
pub 2048/3D25D3D9 1999/03/06 SuSE Security Team <security(a)suse.de>
- ------BEGIN PGP PUBLIC KEY BLOCK-----
- ------END PGP PUBLIC KEY BLOCK-----
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----