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 have just read an Bell Labs anouncement, that they are going to release
>libsafe under GNU licence, and that some major Linux distros are going to
>be using it. SuSE was not amongst them, why is that? I think that libsafe would
>be a good echnacement against buffer overflow.
>Anouncement is on:
just because something new pops up please be careful with questions like
"when will you implement it?" ;-)
There are several questions to ask:
a) is it STABLE and does it NOT affect the stability of other programs?
b) does it bring additional security problems into the system?
c) is the security protection effective?
Well, of course the SuSE Security Team already reviewed libsafe.
Here are the answers:
a) unsure. it would have to be tested very intensive. this was not done yet.
b) the code might have vulnerabilities, however the protection gained is
higher even if a vulnerability would be present
c) okay, now the tough part:
libsafe is a dynamic library which is set in the environment which checks
several dangerous functions, which can be a security problem.
Because it is a dynamic library, it is NO protection against local
attackers, just against remote attackers on network services. (if an
attacker wants to attack a local suid file, he would just reset his library
path environment). Next thing: it does not check for all known
vulnerabilites. It even doesn't protect against all buffer overflows, It
just protects against *some* overflows. those which happen because of
insecure use of strcat/strcpy etc.
I can not remember a vulnerability in a network service for the last year
which this tool would have prevented. Therefore: as long as this tool is not
enhanced to also protect open/fopen calls against symlink/hardlink/pipe
attacks, several more buffer overflow types, system/exec* function
protection etc. it is not useful to use this tool.
I would rather propose to use the secumod module which comes with SuSE Linux
since 6.3 and maybe the secure-linux kernel patch from www.openwall.com -
these two tools enhance your security. (and btw, install seccheck,
hardensuse and firewals and use them - then your security is very high)
Marc Heuse, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg
E@mail: marc(a)suse.de Function: Security Support & Auditing
"lynx -source http://www.suse.de/~marc/marc.pgp | pgp -fka"
Key fingerprint = B5 07 B6 4E 9C EF 27 EE 16 D9 70 D4 87 B5 63 6C
I must be able to telnet from a terminal (not a console) as a root without
In solaris i could do that editing /etc/default/login file,but i can't find
it on this
How can i do ?
recently at the place where i work a collegue came up with an idea to use nfs
over vpn to sync our webservers. i have not done much work with either, and i
have two questions about it. first, is this a practical solution? and second,
im a bit stumped about resources on the subject (i do have nfs documentation,
but not much of vpn resources, and nothing on how to combine the two).
sorry is this question might seem trivial/stupid, any help/opinion is
greatly appreciated : )
I feel a little bit confused on which direction I should be going, hence
I need some advice, pointers and clarification on establishing a
firewall. I am setting up a LAN of 10 PC's. The LAN will have access to
the internet via cable modem. This is what I thought of doing.
A) Setting up a 486/Pentium MMX as the firewall / router.
B) Use either of the following
1) Phoenix adaptive firewall ( I could only found it for SuSE 6.3 which
probably will not work with SuSE 7.0)
2) Sinus firewall
3) T.REx Open Source proxy firewall
1) What could be my concerns regarding security, if I am running a stock
SuSE pre compiled Kernel. What specific things I should be looking to
enable / disable ? As far as I understand, if using a pre compiled stock
SuSE kernel ,my option of using SINUS firewall is out of the choices.
Hence I thought of using T.Rex if using stock kernel.
2) I thought of recompiling the kernel with the SuSE default config
options, so I can get Sinus back into choices for proxy firewalls ( yet
by doing this most probably Suse Installation support will not be very
helping since I am not using the SUSE pre compiled kernel. Result
questionable SuSE support availability)
3) Recompiling the after patching it with openwall security patch ( The
question is SuSE kernel is pre 2.2.17 so which patch I use; 2.2.16 or
2.2.17) and then make the choice for the proxy firewall.
Could some one please kindly help me with a road to choose and if
possible pros and cons of the my choices and/or proxy firewalls I have
found (any other suggestion is more than welcomed)
Thanks in advance
100% MS FREE
Absolutely no component of Microsoft was used
in the generation or posting of this e-mail. So it is virus free
the FreeBSD has recently issued two security warnings concerning PINE
SA-00:47: pine4 port allows denial of service
SA-00:59: pine4 port contains remote vulnerability
and on the pine site they claim that they fixed these security related
bugs in 4.30.
| Bugs that have been addressed in this release include:
| * Incoming mail with an extremely long From address can cause a
| buffer overflow on the stack (security)
| * X-Keywords crash for unix formatted mailboxes
| * Pine crashes when replying to or forwarding messages with certain
| types of attachments
Can we expect an update or is SuSE's 4.21-123 not vulnerable to either
Any user can write a simple program that emulates the behavior of the console
login. Executed in a console it waits for an unsuspecting user and logs the
username/password to a file. It then shows login incorrect and exists (starting
the real login-program). Most users will assume they had a typo in the password
and will not know that their password was stolen.
This is a problem e.g. at university labs with linux-PCs and many "creative"
Is there a way to prevent a user from "emulating" a login screen (especially
for the console)?
I think in WinNT this problem is solved by pressing Ctrl-Alt-Del before logging
in and it is guarateed that that key-combination will be answered by the OS login
Is there anything similar for linux?
PGP key available on request
Anibal Vasquez wrote:
> Eduardo Carriles wrote:
> > Amusing compendium.
> What´s amusing on it? Are the URLs not to be taken seriously?
Amusing? Because it's again Kurt on his LSKB, Mark and others, all at
their best, and i love'em.
They are great and amusing also.
As i see i did not explain my self enought, and you jumped quick.
Beg your pardon for the annoyance.
And would you reply PUBLIC, please!!. =:`8)
And note that i said [Thanks Jonathan. =:`8)]
So i say you.
[-- Better a smile than a flame --]
(Long time SuSE-Linux [preferred distro] user).
[-- Se me nota mucho? -- Notices me much?]
[-- Have a lot of fun...]
> After 7 years of **IX based development, I find myself in a VERY security
> conscious environment. I am aware of the basics, but I need come up to speed
> very quickly on the details of how or why to implement various security
> features, e.g. how does ssh work. What are the specific holes to watch out for
> etc., I'm looking more for the lower level mechanics not the "don't surf the web
> as root" stuff.
> If someone could point me to the FAQ for this group and any other recommended
> reading I sure would appreciate it.
Linux Administrator's Security Guide (LASG)
Read it end to end.
Try "Linux System Security" for in depth coverage of security features &
software on Linux. Well written and goes into good detail on algorithms
(the SSH chapter is very useful if you're trying to visualize the
protocol) and recommendations.
Practical UNIX & Internet Security, 2nd Edition
Classic O'Reilly guide to security on a UNIX system
Of particular interest are the harden_suse and seccheck scripts. Once you
understand everything they do and why you'll know more about security than
News from Marc Heuse concerning the questions about SuSEfirewall 4.0.
He's on vacation - I hope he'll be back soon.
> Hi folks,
> I'm currently on a trip in england and cant access my suse account.
> Anyone who has got a problem with SuSEfirewall 4.0 - known to me is only
> the reverse masquerading bug - please send a private email to
> with the following information:
> try tcpdump and see if packets are forwarded to the internal network,
> if answer packets arrive from the internal network. Set FW_LOG_DENY_ALL
> yes and note down corresponding entries if they are logged by
> Send me all this information plus the FW_FORWARD_MASQ_* config lines.
> This is weird because it worked for the people I asked. *sigh* I hope
> few people are affected.
> Marc <marc(a)suse.de>
> SuSE Security Team
| Roman Drahtmüller <draht(a)suse.de> // "Caution: Cape does |
SuSE GmbH - Security Phone: // not enable user to fly."
| Nürnberg, Germany +49-911-740530 // (Batman Costume warning label) |