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 would appreciate comments on some IPSec design issues.
A transportation manufacture recently requested proposals for
a Linux based system to put Internet and email services on
their vehicles. This system would let passengers plug a laptop
into the on board network. A number of protocols were specified
including IPSec. They also specified Linux kernel 2.4.x.
It seemed to me that they intended IPSec to be used from
transportation vehicle to satellite to fixed server. The VP
of Technology here has recently discussed using IPSec
on board vehicle from web server, email server and file
server to passenger seats - typically many hundreds of
The transportation manufacture specified: "The file
server will not preclude a user from initiating and completing
a supported VPN connection from their user device through
the transportation manufacturer network using the IPSec and
PPTP protocol, as a minimum. The system should allow the
user to switch between IPSec VPN and non-VPN without need
of rebooting the laptop. The system will only pass IP based
protocols between the laptop passenger interface and the file
server. Passenger laptops will be assigned default gateway
address via DHCP. The default gateway should reside in the
server. The system will by default, route user outbound packets
to a configurable gateway."
Is it feasible to support IPSec from a passenger's laptop when
implementations of IPSec vary and either ESP or AH modes might
be used? If feasible what performance hit would be involved? I have
heard estimates of 40% when encryption is used (mileage may vary I
suppose based on CPU speed and resources).
I assumed that a "default gateway at the server" implied that the
IPSec pipe started or ended there. Since the transportation
manufacturer called out other security requirements to the passenger
seat, I assumed that IPSec to the seat was not required.
Examples of requested security: "Multiple passengers will not be
connected to shared physical media. Laptop users will not be
permitted to view packets from another user's network session.
Each passenger's laptop's user interface will be isolated to its own
link layer subnetwork. The passenger laptop will not be able to access
unauthorized IP address. The system will be immune to DoS attacks.
The server will ensure that passenger laptop's can only pass packets
with that user's assigned IP address."
My main question are,
1) "Does the transportation manufacturer really want IPSec extended
directly to the passenger's laptop?"
2) "Would it even be feasible to automate re configuration of IPSec
software running on a passenger laptop to avoid compatibility issues?"
3) "What would the performance cost be of running ESP or AH IPSec
on a laptop that might also be viewing an MPEG2 movie, web browsing
or playing a game?"
I would appreciate any opinions you care to offer.
The job you save may be my own. <s>
Another newbie question. I edited my inetd.conf and commented
out ftp, telnet, shell, login, pop3, finger and swat and
rebooted. Everything seems to work ok.
nmap -sT -v my ip shows these
nmap -sU my ip shows these
Questions are these. First, is what I commented out ok?
secondly, is it safe to comment out talk, ntalk, and time in
inetd.conf as well?
Secondly...how about ssh,sunrpc,printer and X11? Is it safe and
where do I shut them down at?
If you could just give me a site that would explain this to me I
would be very grateful. As I said, I am new and just don't want
to make any mistakes configuring or to take an unsecured machine
out on the net.
Thanks in advance,
The problem with the firewall + IPsec is still not solved.
To split the setup problems I have tried to configure different test
a) Only 2 IPsec gateways
b) 2 IPsec gateways with the firewall script - no masquerading
c) 2 IPsec gateways with the firewall script with maquerading
Setup a) is working but with setup b) I have already problems:
The tunnel is established but I still cannot ping to the net on the other
side. I checked the firewall.log for denied packets but couldn't find any
Also another strange phenomenon:
If I boot the machine with the firewall script and stop afterwards the
firewall script by hand the ipsec connection doesn't work too.
What could be the problem with my setup.
Thanks for your help
> -----Ursprüngliche Nachricht-----
> Von: Tobias Gewinner [mailto:firstname.lastname@example.org]
> Gesendet: Dienstag, 19. Juni 2001 23:32
> An: suse-security(a)suse.com
> Betreff: Re: [suse-security] Ipsec + firewall
> On Tue, Jun 19, 2001 at 05:55:09PM +0200, Schulz, Wolfgang wrote:
> > Hi list!
> > As soon as we start the firewall script (Version 4.1) ipsec
> doesn't work
> > anymore.
> I remember having the same problem in the past. AFAIK the
> firewalls must
> accept incoming requests from the outside on port 500/UDP. Also the
> firewall doesn't know the net behind his partner, so any input from
> these IPs to the internal net is denied.
> I remember that I set the following ipchains rules (or something like
> that) manually on both machines:
> On firewall A this (may have) looked like
> ipchains -I forward -b -s [local net B] -d [local net A] -j ACCEPT
> ipchains -I input -b -s [local net B] -d [local net A] -j ACCEPT
> ipchains -I output -b -s [local net B] -d [local net A] -j ACCEPT
> and on firewall B you must swap the networks, of course ;-)
> After that it worked fine for me. I think you can set these rules
> in /etc/rc.config.de/firewall-custom.rc.config
> Tobias Gewinner <gewinner(a)tmt.de>
> Fachinformatiker i.A. TMT InterNETworks GmbH
> Phone: +49921560716-0 Maxstrasse 4
> Fax: +49921560716-18 D-95444 Bayreuth
> To unsubscribe, e-mail: suse-security-unsubscribe(a)suse.com
> For additional commands, e-mail: suse-security-help(a)suse.com
Helo Stefan, helo folks,
I tried that one but it`s the same thing.
Realy curious is, when the firewall script starts I get an error message
with reference to
"Bad argument squid" even I had declared in /etc/services.
The same one, when I use the port nummer."Bad argument 3128"
Thanks and regards
Hello Dirk, hello folks,
I don't know if it works but you can try this, maybe you can send me your
log and the full error listed at you monitor:
#SQUID internal lan
iptables -A INPUT -i $IF_LAN -p tcp --dport 3128 -j ACCEPT
iptables -A OUTPUT -i $IF_LAN -p tcp --sport 3128 -j ACCEPT
iptables -A INPUT -i $IF_WAN -p tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -i $IF_WAN -p tcp --sport 80 -j ACCEPT
iptables -A INPUT -i $IF_WAN -p udp --sport 1024:65535 --dport 53 -j
iptables -A OUTPUT -o $IF_WAN -p udp --dport 53 --sport 1024:65535 -j
iptables -A INPUT -i $IF_WAN -p tcp --sport 1024:65535 --dport 53 -j
iptables -A OUTPUT -o $IF_WAN -p tcp --dport 53 --sport 1024:65535 -j
just try this (use the portnumbers not names in /etc/services). if this
doesn't work, you should try to install proxy and firewall at to different
I have a standard install running SUSE 7.1 on PC hardware.
It uses a 56k modem to talk to Earthlink via ppp.
I believe it has firewall running since (1) I can see a
couple of messages about "personal-firewall"
go by during the boot sequence and (2) if I try to telnet
or ssh into the box from the internet, I see messages
in /var/log/messages about the connect being rejected.
I would like to temporarily disable enough of the protection
to allow incoming ssh, telnet, and ftp connections.
I tried modifying settings in /etc/rc.config.d/firewall.rc.config
to allow the desired services, but to no apparent effect.
I then tried to disable the firewall completely but
found that my rc.config already had the line START_FW ="no"
and yet some firewall clearly is running.
Any pointers to definitive docs on
the SUSE 7.1 firewall setup? I don't seem to be able
to figure out what I need from the printed manuals.
Haben Sie viel Spa�
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
Ok, I have added the ip_masq_h323.o module and re-started masquerading to
load the module.
SuSEfirewall is still in place as before. I can now use NetMeeting 3.01 on
a PC to connect to a hosted meeting outside the firewall.
My question now is how do I allow external NetMeeting clients connect to a
NetMeeting host on our internal/private network.
Any help much appreciated :)
Mueller To: michael.ryan(a)storm.ie
<torsten@arch cc: suse-security(a)suse.com
esoft.de> Subject: Re: [suse-security] SuSEfirewall 2.1 and NetMeeting 3.01
i use a setup with a netmeeting kernel module and
Look at the masquearding howto, there's the lnk to the
> Trying to allow external sources connect to a machine on our private
> network which is acting as a NetMeeting host.
> Gateway is a SuSE 6.4 box, ip masquerading up and running SuSE firewall
> Anyone done this before? any advice on how this can be done securely?
> tnx in advance,
> To unsubscribe, e-mail: suse-security-unsubscribe(a)suse.com
> For additional commands, e-mail: suse-security-help(a)suse.com
I just upgraded my Suse 7.0 2.2.16 kernel server to 2.2.19 kernel.
Everything seems to be working fine except an NFS quirk. When I
try to mount the nfs shares on this machine from my Sun Solaris 7
server with the automounter, I am getting a "Permission denied"
error and fail. Looking at the log on the Sun server I see:
automountd: poseidon server not responding: RPC: Pro
on the Linux log:
Jun 28 09:54:33 poseidon mountd: export request from x.x.x.x
When I use the mount command like "mount poseidon:/ /mnt/tmp"
then it works. But, I see in the Linux servers log:
Jun 28 09:58:14 poseidon kernel: svc: unknown program 100227 (me 100003)
I am using knfsd.
Anybody know any fix?
-----BEGIN PGP SIGNED MESSAGE-----
SuSE Security Announcement
Date: Friday, June 29th 2001, 13:26:55 CEST
Affected SuSE versions: (6.0, 6.1, 6.2), 6.3, 6.4, 7.0, 7.1, 7.2
Vulnerability Type: remote code execution
Severity (1-10): 7
SuSE default package: yes
Other affected systems: All systems using xinetd
Content of this advisory:
1) security vulnerability resolved: xinetd buffer-overflows
problem description, discussion, solution and upgrade information
2) pending vulnerabilities, solutions, workarounds
3) standard appendix (further information)
1) problem description, brief discussion, solution, upgrade information
Zen-parse has reported a bug to Bugtraq which allows remote attackers
to overflow a buffer in the logging routine of xinetd. During investigation
we found that more problems exist within xinetd. Xinetd provides its own
string-handling (snprintf()-like functions) routines and fails to handle
length arguments of 0 properly. Instead of an immediate return it assumes
'no limit' for writing characters to the target-buffer. This can lead
to overflows and arbitrary remote code-execution. Additionally xinetd
now sets the correct umask before starting other deamons.
Please update the packages immediately, kill the old deamon and start
the new xinetd deamon with the
command again if you need it running.
Regardless of the bugs in xinetd, please make sure you only run as many
services as needed.
i386 Intel Platform:
AXP Alpha Platform:
PPC Power PC Platform:
2) Pending vulnerabilities in SuSE Distributions and Workarounds:
The rxvt program contains a buffer-overflow which allows an attacker
to locally execute arbitrary code under a different group-id. Please
update to the newest rxvt packages.
The dsh-program, shipped with the dqs package contains a buffer-overflow
which allows local attackers to execute arbitrary code as root.
Please update to the newest packages.
A /tmp - race has been found in the pcp package which allows
a local attacker to escalate his priviledges.
Affected versions: 7.1, 7.2.
We thank Mark Goodwin and Keith Owens from SGI who quickly responded
to SuSE in this issue and who released a fixed version of the SGI
Performance Co-Pilot in response to the security problem. Future SuSE
Linux releases will include the most recent version of the package.
Workaround: chmod a-s `rpm -ql pcp` /nosuchfile
update-package does the same.
3) standard appendix: authenticity verification, additional information
- Package authenticity verification:
SuSE update packages are available on many mirror ftp servers all over
the world. While this service is being considered valuable and important
to the free and open source software community, many users wish to be
sure about the origin of the package and its content before installing
the package. There are two verification methods that can be used
independently from each other to prove the authenticity of a downloaded
file or rpm package:
1) md5sums as provided in the (cryptographically signed) announcement.
2) using the internal gpg signatures of the rpm package.
1) execute the command
after you downloaded the file from a SuSE ftp server or its mirrors.
Then, compare the resulting md5sum with the one that is listed in the
announcement. Since the announcement containing the checksums is
cryptographically signed (usually using the key security(a)suse.de),
the checksums show proof of the authenticity of the package.
We disrecommend to subscribe to security lists which cause the
email message containing the announcement to be modified so that
the signature does not match after transport through the mailing
Downsides: You must be able to verify the authenticity of the
announcement in the first place. If RPM packages are being rebuilt
and a new version of a package is published on the ftp server, all
md5 sums for the files are useless.
2) rpm package signatures provide an easy way to verify the authenticity
of an rpm package. Use the command
rpm -v --checksig <file.rpm>
to verify the signature of the package, where <file.rpm> is the
filename of the rpm package that you have downloaded. Of course,
package authenticity verification can only target an uninstalled rpm
a) gpg is installed
b) The package is signed using a certain key. The public part of this
key must be installed by the gpg program in the directory
~/.gnupg/ under the user's home directory who performs the
signature verification (usually root). You can import the key
that is used by SuSE in rpm packages for SuSE Linux by saving
this announcement to a file ("announcement.txt") and
running the command (do "su -" to be root):
gpg --batch; gpg < announcement.txt | gpg --import
SuSE Linux distributions version 7.1 and thereafter install the
key "build(a)suse.de" upon installation or upgrade, provided that
the package gpg is installed. The file containing the public key
is placed at the toplevel directory of the first CD (pubring.gpg)
and at ftp://ftp.suse.com/pub/suse/pubring.gpg-build.suse.de .
- SuSE runs two security mailing lists to which any interested party may
- general/linux/SuSE security discussion.
All SuSE security announcements are sent to this list.
To subscribe, send an email to
- SuSE's announce-only mailing list.
Only SuSE's security annoucements are sent to this list.
To subscribe, send an email to
For general information or the frequently asked questions (faq)
send mail to:
SuSE's security contact is <security(a)suse.com>.
The <security(a)suse.com> public key is listed below.
The information in this advisory may be distributed or reproduced,
provided that the advisory is not modified in any way. In particular,
it is desired that the cleartext signature shows proof of the
authenticity of the text.
SuSE GmbH makes no warranties of any kind whatsoever with respect
to the information contained in this security advisory.
Type Bits/KeyID Date User ID
pub 2048R/3D25D3D9 1999-03-06 SuSE Security Team <security(a)suse.de>
pub 1024D/9C800ACA 2000-10-19 SuSE Package Signing Key <build(a)suse.de>
- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
- -----END PGP PUBLIC KEY BLOCK-----
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
~ perl self.pl
~ krahmer(a)suse.de - SuSE Security Team