[SECURITY] [DSA 208-1] New Perl packages correct Safe handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 208-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze December 12th, 2002 http://www.debian.org/security/faq - -- Package: perl, perl-5.004, perl-5.005 Vulnerability : broken safe compartment Problem-type : local Debian-specific: no CVE Id: CAN-2002-1323 A security hole has been discovered in Safe.pm which is used in all versions of Perl. The Safe extension module allows the creation of compartments in which perl code can be evaluated in a new namespace and the code evaluated in the compartment cannot refer to variables outside this namespace. However, when a Safe compartment has already been used, there's no guarantee that it is Safe any longer, because there's a way for code to be executed within the Safe compartment to alter its operation mask. Thus, programs that use a Safe compartment only once aren't affected by this bug. This problem has been fixed in version 5.6.1-8.2 for the current stable distribution (woody), in version 5.004.05-6.2 and 5.005.03-7.2 for the old stable distribution (potato) and in version 5.8.0-14 for the unstable distribution (sid). We recommend that you upgrade your Perl packages. wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 2.2 alias potato - - Source archives: http://security.debian.org/pool/updates/main/p/perl-5.004/perl-5.004_5.004.05-6.2.dsc Size/MD5 checksum: 675 6fd3dd1d3346fed64da5a5af67730586 http://security.debian.org/pool/updates/main/p/perl-5.004/perl-5.004_5.004.05-6.2.diff.gz Size/MD5 checksum:47924 a5b16d1599b04013a139510563206b24 http://security.debian.org/pool/updates/main/p/perl-5.004/perl-5.004_5.004.05.orig.tar.gz Size/MD5 checksum: 2856190 b92ffc4e7bea3a367af102e8db136864 http://security.debian.org/pool/updates/main/p/perl-5.005/perl-5.005_5.005.03-7.2.dsc Size/MD5 checksum: 694 7531125caf802bad131494e664c53ba2 http://security.debian.org/pool/updates/main/p/perl-5.005/perl-5.005_5.005.03-7.2.diff.gz Size/MD5 checksum:96897 fffd8c16f393c20fbac4eef683cb81b3 http://security.debian.org/pool/updates/main/p/perl-5.005/perl-5.005_5.005.03.orig.tar.gz Size/MD5 checksum: 3679040 427890d97e32430341c1fa80f55277a7 Architecture independent components: http://security.debian.org/pool/updates/main/p/perl-5.004/perl-5.004-doc_5.004.05-6.2_all.deb Size/MD5 checksum: 2296810 f96146c04692fad19a8d6372f86ed69d http://security.debian.org/pool/updates/main/p/perl-5.005/perl-5.005-doc_5.005.03-7.2_all.deb Size/MD5 checksum: 2849810 45ab33a3a00906413791b62c1c686aba Alpha architecture: http://security.debian.org/pool/updates/main/p/perl-5.004/perl-5.004_5.004.05-6.2_alpha.deb Size/MD5 checksum: 1634058 f0765237e1ac6133ce5e731a04f69c40 http://security.debian.org/pool/updates/main/p/perl-5.004/perl-5.004-base_5.004.05-6.2_alpha.deb Size/MD5 checksum: 452634 aae1fc314f90b6a1b8007a1e396db5ff http://security.debian.org/pool/updates/main/p/perl-5.004/perl-5.004-debug_5.004.05-6.2_alpha.deb Size/MD5 checksum: 1984930 b2669cce93aeb5c6b5839cd75e946bff http://security.debian.org/pool/updates/main/p/perl-5.004/perl-5.004-suid_5.004.05-6.2_alpha.deb Size/MD5 checksum: 346460 603729228532b771cd604349fe5699d6 http://security.debian.org/pool/updates/main/p/perl-5.005/perl-5.005_5.005.03-7.2_alpha.deb Size/MD5 checksum: 1978462 622b3d300bafcadf874a529efac4f4d2 http://security.debian.org/pool/updates/main/p/perl-5.005/perl-5.005-base_5.005.03-7.2_alpha.deb Size/MD5 checksum: 576628 df9878b0d71f9be6ea9a4f9f2e8a8bae http://security.debian.org/pool/updates/main/p/perl-5.005/perl-5.005-debug_5.005.03-7.2_alpha.deb Size/MD5 checksum: 2218552 497012e99b26b25e28c3f0de6d6cd879 http://security.debian.org/pool/updates/main/p/perl-5.005/perl-5.005-suid_5.005.03-7.2_alpha.deb Size/MD5 checksum: 373452 5e5c6bb092c749d580b5562263940ffa http://security.debian.org/pool/updates/main/p/perl-5.005/perl-5.005-thread_5.005.03-7.2_alpha.deb Size/MD5 checksum: 1436580 8ac1e7a3a3cd9450558425223a711931 ARM architecture: http://security.debian.org/pool/updates/main/p/perl-5.004/perl-5.004_5.004.05-6.2_arm.deb Size/MD5 checksum: 1483602
Re: VPN + Roadwarrior
also sprach Noah L. Meyerhans [EMAIL PROTECTED] [2002.12.12.1656 +0100]: On Thu, Dec 12, 2002 at 09:39:27AM -0500, Phillip Hofmeister wrote: If you implement IPSec, my experience (as of 6 months ago) with IPSec is that it works great, as long as you use the same implementation on all host. I don't really agree with that. I have used several different IPsec implementations and interoperated successfully. me too. i've had all of freeswan, native 2.5, cisco, sonicwall, nokia, check point, *BSD and win2k interoperate. it wasn't always easy (especially windoze, check point and cisco), but it works. www.freeswan.org has quite a bit of interoperability documentation. this site has very good documentation in general. but it takes time. no expert reference. Basically, the only difficulties come from the fact that the Internet Key Exchange (IKE) protocol, defined in RFC 2409, has so damn many configurable parameters that it's easy to missconfigure it. Since there isn't (and probably won't ever be) a standard set of defaults, this can get confusing. it's getting there... ISAKMP/Oakley... -- Please do not CC me! Get a proper mailer instead: www.mutt.org .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system NOTE: The public PGP keyservers are broken! Get my key here: http://people.debian.org/~madduck/gpg/330c4a75.asc msg08138/pgp0.pgp Description: PGP signature
Re: init.d startup sequence for shorewall
- Original Message - From: Matt Zimmerman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, December 12, 2002 12:55 PM Subject: Re: init.d startup sequence for shorewall On Wed, Dec 11, 2002 at 05:39:37PM -0800, Yogesh Sharma wrote: networking comes up at S35 in runlevel 0 so my internet is up and there is no firewall running so far. runlevel 0 is system shutdown and halt. The network is not brought up in this runlevel. :-) Actually that seems to be a highly secure firewall...Firewalls with no power cannot be compromised via the network:-) Jeremy -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: init.d startup sequence for shorewall
On Thu, Dec 12, 2002 at 03:55:56PM -0500, Matt Zimmerman remarked: On Wed, Dec 11, 2002 at 05:39:37PM -0800, Yogesh Sharma wrote: networking comes up at S35 in runlevel 0 so my internet is up and there is no firewall running so far. runlevel 0 is system shutdown and halt. The network is not brought up in this runlevel. :-) -- - mdz There have been several responses to Yogesh's question, but none of them provide a clear and straightforward answer. Does anyone know why Shorewall leaves the system unprotected between network startup and firewall startup, whether it is a security risk, and if so what can be done about it besides crude workarounds? Cheers, Raymond msg08141/pgp0.pgp Description: PGP signature
Re: init.d startup sequence for shorewall
On Thu, 2002-12-12 at 12:55, Matt Zimmerman wrote: On Wed, Dec 11, 2002 at 05:39:37PM -0800, Yogesh Sharma wrote: networking comes up at S35 in runlevel 0 so my internet is up and there is no firewall running so far. runlevel 0 is system shutdown and halt. The network is not brought up in this runlevel. :-) Sorry I type wrong runlevel, please read runlevel 1 -- - mdz -- Yogesh Sharma [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: init.d startup sequence for shorewall
networking comes up at S35 in runlevel 0 so my internet is up and there is no firewall running so far. runlevel 0 is system shutdown and halt. The network is not brought up in this runlevel. :-) Actually that seems to be a highly secure firewall...Firewalls with no power cannot be compromised via the network:-) http://www.samag.com/documents/s=1824/sam0201d/0201d.htm Halted firewalls? /Daniel -- File not found. Should I fake it (y/n)? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Apologies re: VPN + Roadwarrior
Sorry for the multiple sends. Some of the original addresses had typos that I corrected and resent. Bad dog! Apologies, Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VPN + Roadwarrior
From Building Linux VPNs, FreeS/WAN has some basic interoperability
with:
KAME: FreeBSD, NetBSD, OpenBSD, BSDi
PGPnet
Windows 2000
F-Secure VPN
IRE Safenet/SoftPK
SSH IPSec Express
Gauntlet GVPN
Xedia's AccessPoint QVPN
Checkpoint SecuRemote VPN-1/Firewall-2
Raptor Firewall, Raptor MobileNT T
Testing was not comprehensive and there are no guarantees of ease of
setup.
Web based testing tools at:
http://ipsec.wit.antd.nist.gov/
http://isakmp.test.ssh.fi/
http://www.vpnc.org/conformance.html
I recommend this book if you are thinking of some kind of VPN. See my
review at: http://www.ercb.com/feature/feature.0063.html
HTH,
Jeffrey
Quoting Noah L. Meyerhans [EMAIL PROTECTED]:
On Thu, Dec 12, 2002 at 09:39:27AM -0500, Phillip Hofmeister wrote:
If you implement IPSec, my experience (as of 6 months ago) with IPSec is
that it works great, as long as you use the same implementation on all
host.
I don't really agree with that. I have used several different IPsec
implementations and interoperated successfully. The latest combination
that I tried was the Linux 2.5 native IPsec communicating with
FreeS/WAN. No problem. I've documented the steps I had to go through
to get the {Free,Net}BSD IPsec implementation to interoperate with
FreeS/WAN using X.509 certs for authentication. Again, very few
problems.
www.freeswan.org has quite a bit of interoperability documentation.
Basically, the only difficulties come from the fact that the Internet
Key Exchange (IKE) protocol, defined in RFC 2409, has so damn many
configurable parameters that it's easy to missconfigure it. Since there
isn't (and probably won't ever be) a standard set of defaults, this can
get confusing.
noah
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: init.d startup sequence for shorewall
On Thu, 2002-12-12 at 15:07, Jeremy A. Puhlman wrote: - Original Message - From: Matt Zimmerman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, December 12, 2002 12:55 PM Subject: Re: init.d startup sequence for shorewall On Wed, Dec 11, 2002 at 05:39:37PM -0800, Yogesh Sharma wrote: networking comes up at S35 in runlevel 0 so my internet is up and there is no firewall running so far. runlevel 0 is system shutdown and halt. The network is not brought up in this runlevel. :-) Actually that seems to be a highly secure firewall...Firewalls with no power cannot be compromised via the network:-) Jeremy -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Well, check this article out from the Sysadmin (magazine) website: http://www.samag.com/documents/s=1824/sam0201d/0201d.htm It describes a method of using a system with a halted kernel as a firewall. Mitch Thompson, San Antonio TX Red Hat Certified Engineer (RHCE) http://home.satx.rr.com/mlthompson Key fingerprint = BBDA 3A2A 4483 BD0D 7CED B8A9 D183 C8F6 B0AF 66AE wget -O - http://home.satx.rr.com/mlthompson/pubkey.gpg | gpg --import -- America works less, when you say Union Yes!~ signature.asc Description: This is a digitally signed message part
Re: Apologies re: VPN + Roadwarrior
On Thursday, 2002-12-12 at 13:02:41 -0600, Jeffrey Taylor wrote: Sorry for the multiple sends. Some of the original addresses had typos that I corrected and resent. Bad dog! Still no cookie, bad dog :-P http://ipsec.wit.antd.nist.gov/ Host does not resolve http://isakmp.test.ssh.fi/ Host does not resolve http://www.vpnc.org/conformance.html404 Access denied, or file does not exist Can you please correct again? Thanks, Lupe Christoph -- | [EMAIL PROTECTED] | http://www.lupe-christoph.de/ | | Big Misunderstandings #6398: The Titanic was not supposed to be| | unsinkable. The designer had a speech impediment. He said: I have | | thith great unthinkable conthept ... | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to identify the superuser in C
Oohara Yuuma [EMAIL PROTECTED] writes: fakeroot (or any other dynamic linker tricks) will not work on set[ug]id programs. libc can be trusted here. Is this Linux specific? (There can be a Hurd port in the sarge release). Of course the same protection is present in GNU/Hurd. Btw: this problem (`how to find out your id[s]') is even trickier in GNU/Hurd. Let's have a look at how fakeroot is implemented in GNU/Hurd. Instead of using a libfakeroot trick, we simply use our own features for that, which can do much better. Authentication in the Hurd is based on the `auth' server. Now, in the Hurd it is possible to use other auth servers than the default system server. Glibc functions working with IDs in fact communicate with the auth server. If you use your own auth server, then getuid() returns whatever that auth server tells you (of course, faking your auth server does not raise your permissions in the system at all, since that auth server is private to you). Now, back to fakeroot. Fakeroot in GNU/Hurd consists of: * a command line program (fakeauth), which creates a new auth server and runs a program with the auth server changed accordingly. This makes getuid() and friends behave like if the program would run as root; * a filesystem server, which is used for faking filesystem accesses - this makes chmod/chown work accordingly. moritz -- [EMAIL PROTECTED] - http://duesseldorf.ccc.de/~moritz/ GPG fingerprint = 3A14 3923 15BE FD57 FC06 B501 0841 2D7B 6F98 4199
Re: VPN + Roadwarrior
On Wed, 11 Dec 2002 at 07:41:55PM -0700, Aaron Anderson wrote: I'm planning to setup a VPN to bridge 2 networks over DSL as well as have the ability to have people connect to the network from home. I wanted to get an idea of what experiences that people had had and what packages they've used. I have looked at FreeSwan but haven't set it up yet. I have setup CIPE but my problem with it is that it doesn't die gracefully and doesn't seem to have home user support. If you implement IPSec, my experience (as of 6 months ago) with IPSec is that it works great, as long as you use the same implementation on all host. IPSec isn't a hard standard yet therefore different implementations may not have compatibility, and if they do have compatibility it is kind of a hack job. I used FreeSwan. Like I said above, use the same implementation and same version on all hosts and you should be fine. Of course you will set up a CA Hierarchy so you can revolk people from the VPN... Regards, -- Phil PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.txt | gpg --import -- Excuse #229: The Token fell out of the ring. Call us when you find it.
Re: VPN + Roadwarrior
On Thu, Dec 12, 2002 at 09:39:27AM -0500, Phillip Hofmeister wrote:
If you implement IPSec, my experience (as of 6 months ago) with IPSec is
that it works great, as long as you use the same implementation on all
host.
I don't really agree with that. I have used several different IPsec
implementations and interoperated successfully. The latest combination
that I tried was the Linux 2.5 native IPsec communicating with
FreeS/WAN. No problem. I've documented the steps I had to go through
to get the {Free,Net}BSD IPsec implementation to interoperate with
FreeS/WAN using X.509 certs for authentication. Again, very few
problems.
www.freeswan.org has quite a bit of interoperability documentation.
Basically, the only difficulties come from the fact that the Internet
Key Exchange (IKE) protocol, defined in RFC 2409, has so damn many
configurable parameters that it's easy to missconfigure it. Since there
isn't (and probably won't ever be) a standard set of defaults, this can
get confusing.
noah
--
___
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html
pgpwzE6unxlbN.pgp
Description: PGP signature
Re: VPN + Roadwarrior
also sprach Noah L. Meyerhans [EMAIL PROTECTED] [2002.12.12.1656 +0100]: On Thu, Dec 12, 2002 at 09:39:27AM -0500, Phillip Hofmeister wrote: If you implement IPSec, my experience (as of 6 months ago) with IPSec is that it works great, as long as you use the same implementation on all host. I don't really agree with that. I have used several different IPsec implementations and interoperated successfully. me too. i've had all of freeswan, native 2.5, cisco, sonicwall, nokia, check point, *BSD and win2k interoperate. it wasn't always easy (especially windoze, check point and cisco), but it works. www.freeswan.org has quite a bit of interoperability documentation. this site has very good documentation in general. but it takes time. no expert reference. Basically, the only difficulties come from the fact that the Internet Key Exchange (IKE) protocol, defined in RFC 2409, has so damn many configurable parameters that it's easy to missconfigure it. Since there isn't (and probably won't ever be) a standard set of defaults, this can get confusing. it's getting there... ISAKMP/Oakley... -- Please do not CC me! Get a proper mailer instead: www.mutt.org .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system NOTE: The public PGP keyservers are broken! Get my key here: http://people.debian.org/~madduck/gpg/330c4a75.asc pgpM0P1CQqIOc.pgp Description: PGP signature
Re: VPN + Roadwarrior
From Building Linux VPNs, FreeS/WAN has some basic interoperability
with:
KAME: FreeBSD, NetBSD, OpenBSD, BSDi
PGPnet
Windows 2000
F-Secure VPN
IRE Safenet/SoftPK
SSH IPSec Express
Gauntlet GVPN
Xedia's AccessPoint QVPN
Checkpoint SecuRemote VPN-1/Firewall-2
Raptor Firewall, Raptor MobileNT T
Testing was not comprehensive and there are no guarantees of ease of
setup.
Web based testing tools at:
http://ipsec.wit.antd.nist.gov/
http://isakmp.test.ssh.fi/
http://www.vpnc.org/conformance.html
I recommend this book if you are thinking of some kind of VPN. See my
review at: http://www.ercb.com/feature/feature.0063.html
HTH,
Jeffrey
Quoting Noah L. Meyerhans [EMAIL PROTECTED]:
On Thu, Dec 12, 2002 at 09:39:27AM -0500, Phillip Hofmeister wrote:
If you implement IPSec, my experience (as of 6 months ago) with IPSec is
that it works great, as long as you use the same implementation on all
host.
I don't really agree with that. I have used several different IPsec
implementations and interoperated successfully. The latest combination
that I tried was the Linux 2.5 native IPsec communicating with
FreeS/WAN. No problem. I've documented the steps I had to go through
to get the {Free,Net}BSD IPsec implementation to interoperate with
FreeS/WAN using X.509 certs for authentication. Again, very few
problems.
www.freeswan.org has quite a bit of interoperability documentation.
Basically, the only difficulties come from the fact that the Internet
Key Exchange (IKE) protocol, defined in RFC 2409, has so damn many
configurable parameters that it's easy to missconfigure it. Since there
isn't (and probably won't ever be) a standard set of defaults, this can
get confusing.
noah
Re: VPN + Roadwarrior
From Building Linux VPNs, FreeS/WAN has some basic interoperability
with:
KAME: FreeBSD, NetBSD, OpenBSD, BSDi
PGPnet
Windows 2000
F-Secure VPN
IRE Safenet/SoftPK
SSH IPSec Express
Gauntlet GVPN
Xedia's AccessPoint QVPN
Checkpoint SecuRemote VPN-1/Firewall-2
Raptor Firewall, Raptor MobileNT T
Testing was not comprehensive and there are no guarantees of ease of
setup.
Web based testing tools at:
http://ipsec.wit.antd.nist.gov/
http://isakmp.test.ssh.fi/
http://www.vpnc.org/conformance.html
I recommend this book if you are thinking of some kind of VPN. See my
review at: http://www.ercb.com/feature/feature.0063.html
HTH,
Jeffrey
Quoting Noah L. Meyerhans [EMAIL PROTECTED]:
On Thu, Dec 12, 2002 at 09:39:27AM -0500, Phillip Hofmeister wrote:
If you implement IPSec, my experience (as of 6 months ago) with IPSec is
that it works great, as long as you use the same implementation on all
host.
I don't really agree with that. I have used several different IPsec
implementations and interoperated successfully. The latest combination
that I tried was the Linux 2.5 native IPsec communicating with
FreeS/WAN. No problem. I've documented the steps I had to go through
to get the {Free,Net}BSD IPsec implementation to interoperate with
FreeS/WAN using X.509 certs for authentication. Again, very few
problems.
www.freeswan.org has quite a bit of interoperability documentation.
Basically, the only difficulties come from the fact that the Internet
Key Exchange (IKE) protocol, defined in RFC 2409, has so damn many
configurable parameters that it's easy to missconfigure it. Since there
isn't (and probably won't ever be) a standard set of defaults, this can
get confusing.
noah
Re: VPN + Roadwarrior
From Building Linux VPNs, FreeS/WAN has some basic interoperability
with:
KAME: FreeBSD, NetBSD, OpenBSD, BSDi
PGPnet
Windows 2000
F-Secure VPN
IRE Safenet/SoftPK
SSH IPSec Express
Gauntlet GVPN
Xedia's AccessPoint QVPN
Checkpoint SecuRemote VPN-1/Firewall-2
Raptor Firewall, Raptor MobileNT T
Testing was not comprehensive and there are no guarantees of ease of
setup.
Web based testing tools at:
http://ipsec.wit.antd.nist.gov/
http://isakmp.test.ssh.fi/
http://www.vpnc.org/conformance.html
I recommend this book if you are thinking of some kind of VPN. See my
review at: http://www.ercb.com/feature/feature.0063.html
HTH,
Jeffrey
Quoting Noah L. Meyerhans [EMAIL PROTECTED]:
On Thu, Dec 12, 2002 at 09:39:27AM -0500, Phillip Hofmeister wrote:
If you implement IPSec, my experience (as of 6 months ago) with IPSec is
that it works great, as long as you use the same implementation on all
host.
I don't really agree with that. I have used several different IPsec
implementations and interoperated successfully. The latest combination
that I tried was the Linux 2.5 native IPsec communicating with
FreeS/WAN. No problem. I've documented the steps I had to go through
to get the {Free,Net}BSD IPsec implementation to interoperate with
FreeS/WAN using X.509 certs for authentication. Again, very few
problems.
www.freeswan.org has quite a bit of interoperability documentation.
Basically, the only difficulties come from the fact that the Internet
Key Exchange (IKE) protocol, defined in RFC 2409, has so damn many
configurable parameters that it's easy to missconfigure it. Since there
isn't (and probably won't ever be) a standard set of defaults, this can
get confusing.
noah
Re: VPN + Roadwarrior
also sprach Noah L. Meyerhans [EMAIL PROTECTED] [2002.12.12.1656 +0100]: On Thu, Dec 12, 2002 at 09:39:27AM -0500, Phillip Hofmeister wrote: If you implement IPSec, my experience (as of 6 months ago) with IPSec is that it works great, as long as you use the same implementation on all host. I don't really agree with that. I have used several different IPsec implementations and interoperated successfully. me too. i've had all of freeswan, native 2.5, cisco, sonicwall, nokia, check point, *BSD and win2k interoperate. it wasn't always easy (especially windoze, check point and cisco), but it works. www.freeswan.org has quite a bit of interoperability documentation. this site has very good documentation in general. but it takes time. no expert reference. Basically, the only difficulties come from the fact that the Internet Key Exchange (IKE) protocol, defined in RFC 2409, has so damn many configurable parameters that it's easy to missconfigure it. Since there isn't (and probably won't ever be) a standard set of defaults, this can get confusing. it's getting there... ISAKMP/Oakley... -- Please do not CC me! Get a proper mailer instead: www.mutt.org .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system NOTE: The public PGP keyservers are broken! Get my key here: http://people.debian.org/~madduck/gpg/330c4a75.asc pgptCGIO76yZq.pgp Description: PGP signature
Apologies re: VPN + Roadwarrior
Sorry for the multiple sends. Some of the original addresses had typos that I corrected and resent. Bad dog! Apologies, Jeff
Re: init.d startup sequence for shorewall
On Wed, Dec 11, 2002 at 05:39:37PM -0800, Yogesh Sharma wrote: networking comes up at S35 in runlevel 0 so my internet is up and there is no firewall running so far. runlevel 0 is system shutdown and halt. The network is not brought up in this runlevel. :-) -- - mdz
Re: init.d startup sequence for shorewall
- Original Message - From: Matt Zimmerman [EMAIL PROTECTED] To: debian-security@lists.debian.org Sent: Thursday, December 12, 2002 12:55 PM Subject: Re: init.d startup sequence for shorewall On Wed, Dec 11, 2002 at 05:39:37PM -0800, Yogesh Sharma wrote: networking comes up at S35 in runlevel 0 so my internet is up and there is no firewall running so far. runlevel 0 is system shutdown and halt. The network is not brought up in this runlevel. :-) Actually that seems to be a highly secure firewall...Firewalls with no power cannot be compromised via the network:-) Jeremy -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: init.d startup sequence for shorewall
On Thu, Dec 12, 2002 at 03:55:56PM -0500, Matt Zimmerman remarked: On Wed, Dec 11, 2002 at 05:39:37PM -0800, Yogesh Sharma wrote: networking comes up at S35 in runlevel 0 so my internet is up and there is no firewall running so far. runlevel 0 is system shutdown and halt. The network is not brought up in this runlevel. :-) -- - mdz There have been several responses to Yogesh's question, but none of them provide a clear and straightforward answer. Does anyone know why Shorewall leaves the system unprotected between network startup and firewall startup, whether it is a security risk, and if so what can be done about it besides crude workarounds? Cheers, Raymond pgpRDYUvDjDmr.pgp Description: PGP signature
Re: init.d startup sequence for shorewall
On Thu, 2002-12-12 at 12:55, Matt Zimmerman wrote: On Wed, Dec 11, 2002 at 05:39:37PM -0800, Yogesh Sharma wrote: networking comes up at S35 in runlevel 0 so my internet is up and there is no firewall running so far. runlevel 0 is system shutdown and halt. The network is not brought up in this runlevel. :-) Sorry I type wrong runlevel, please read runlevel 1 -- - mdz -- Yogesh Sharma [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: init.d startup sequence for shorewall
networking comes up at S35 in runlevel 0 so my internet is up and there is no firewall running so far. runlevel 0 is system shutdown and halt. The network is not brought up in this runlevel. :-) Actually that seems to be a highly secure firewall...Firewalls with no power cannot be compromised via the network:-) http://www.samag.com/documents/s=1824/sam0201d/0201d.htm Halted firewalls? /Daniel -- File not found. Should I fake it (y/n)?
Bug#172835: shorewall should use update-rc.d
Package: shorewall Severity: normal On Thu, Dec 12, 2002 at 04:18:17PM -0500, Raymond Wood wrote: On Thu, Dec 12, 2002 at 03:55:56PM -0500, Matt Zimmerman remarked: On Wed, Dec 11, 2002 at 05:39:37PM -0800, Yogesh Sharma wrote: networking comes up at S35 in runlevel 0 so my internet is up and there is no firewall running so far. runlevel 0 is system shutdown and halt. The network is not brought up in this runlevel. :-) There have been several responses to Yogesh's question, but none of them provide a clear and straightforward answer. Does anyone know why Shorewall leaves the system unprotected between network startup and firewall startup, whether it is a security risk, and if so what can be done about it besides crude workarounds? Based on the message, I could not tell whether it actually did leave the system unprotected or not. Apparently, it does, because this bug has already been reported in the BTS: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=172607 In looking at the source package, I noticed another one, which is that it does not call update-rc.d to set the symlinks. Either this is being done by an upstream script, the links are being managed by hand, or the links are not being created at all on new installations. I have not tested to see which is the case, but in any of these cases, it is a bug, and update-rc.d should be used instead in order to allow for alternate init schemes and to otherwise ensure policy-conformant behavior. http://www.debian.org/doc/debian-policy/ch-opersys.html#s10.3.3 -- - mdz
Re: init.d startup sequence for shorewall
On Thu, 2002-12-12 at 15:07, Jeremy A. Puhlman wrote: - Original Message - From: Matt Zimmerman [EMAIL PROTECTED] To: debian-security@lists.debian.org Sent: Thursday, December 12, 2002 12:55 PM Subject: Re: init.d startup sequence for shorewall On Wed, Dec 11, 2002 at 05:39:37PM -0800, Yogesh Sharma wrote: networking comes up at S35 in runlevel 0 so my internet is up and there is no firewall running so far. runlevel 0 is system shutdown and halt. The network is not brought up in this runlevel. :-) Actually that seems to be a highly secure firewall...Firewalls with no power cannot be compromised via the network:-) Jeremy -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Well, check this article out from the Sysadmin (magazine) website: http://www.samag.com/documents/s=1824/sam0201d/0201d.htm It describes a method of using a system with a halted kernel as a firewall. Mitch Thompson, San Antonio TX Red Hat Certified Engineer (RHCE) http://home.satx.rr.com/mlthompson Key fingerprint = BBDA 3A2A 4483 BD0D 7CED B8A9 D183 C8F6 B0AF 66AE wget -O - http://home.satx.rr.com/mlthompson/pubkey.gpg | gpg --import -- America works less, when you say Union Yes!~ signature.asc Description: This is a digitally signed message part
