Hi My pptp VPN connection between W2K and a SuSE Linux8.0 server (with SuSEfirewall2) seems to work (username and password are verified, PC is registered and authentificated). /var/log/messages tells me for the vpn-connection: .... - SuSE-FW-UNALLOWED-TARGETIN.........prot. 47...... (after launching vpn-connection) .... - SuSE-FW-DROP-ANTI-SPOOFIN.................DPT 139.... (after hitting network item) .... - SuSE-FW-DROP-ANTI-SPOOFIN.................DPT 139.... (after Start/run "\\192.168.x.y") - SuSE-FW-DROP-ANTI-SPOOFIN.................DPT 445.... These services (protocols and ports) are accessible according to my SuSEfirewall2 definitions. I opened theme in section 9.) I guess, this is the reason, that I don't see my samba shares on linux. Can someone give me a hand on this problem? Markus
On Wed, 12 Jun 2002, Markus Dahinden wrote: Hi, Just because i often read mails like 'we are using a pptp VPN' on this list: pptp is horrible weak and should not be used to protect critical channels or to authenticate users. A paper can be found at http://stealth.7350.org/chap.pdf. I know it doesnt help in this case but I hope it helps one to decide against pptp :) regards, Sebastian
Hi My pptp VPN connection between W2K and a SuSE Linux8.0 server (with SuSEfirewall2) seems to work (username and password are verified, PC is registered and authentificated).
/var/log/messages tells me for the vpn-connection: .... - SuSE-FW-UNALLOWED-TARGETIN.........prot. 47...... (after launching vpn-connection) .... - SuSE-FW-DROP-ANTI-SPOOFIN.................DPT 139.... (after hitting network item) .... - SuSE-FW-DROP-ANTI-SPOOFIN.................DPT 139.... (after Start/run "\\192.168.x.y") - SuSE-FW-DROP-ANTI-SPOOFIN.................DPT 445....
These services (protocols and ports) are accessible according to my SuSEfirewall2 definitions. I opened theme in section 9.)
I guess, this is the reason, that I don't see my samba shares on linux.
Can someone give me a hand on this problem?
Markus
-- ~ ~ perl self.pl ~ $_='print"\$_=\47$_\47;eval"';eval ~ krahmer@suse.de - SuSE Security Team ~
So what do u recommend that people use instead of pptp ----- Original Message ----- From: "Sebastian Krahmer" <krahmer@suse.de> To: "Markus Dahinden" <mdahinden@swissonline.ch> Cc: <suse-security@suse.com> Sent: Wednesday, June 12, 2002 11:08 AM Subject: Re: [suse-security] VPN with pptp
On Wed, 12 Jun 2002, Markus Dahinden wrote:
Hi,
Just because i often read mails like 'we are using a pptp VPN' on this list: pptp is horrible weak and should not be used to protect critical channels or to authenticate users. A paper can be found at http://stealth.7350.org/chap.pdf. I know it doesnt help in this case but I hope it helps one to decide against pptp :)
regards, Sebastian
Hi My pptp VPN connection between W2K and a SuSE Linux8.0 server (with SuSEfirewall2) seems to work (username and password are verified, PC is registered and authentificated).
/var/log/messages tells me for the vpn-connection: .... - SuSE-FW-UNALLOWED-TARGETIN.........prot. 47...... (after launching vpn-connection) .... - SuSE-FW-DROP-ANTI-SPOOFIN.................DPT 139.... (after hitting network item) .... - SuSE-FW-DROP-ANTI-SPOOFIN.................DPT 139.... (after Start/run "\\192.168.x.y") - SuSE-FW-DROP-ANTI-SPOOFIN.................DPT 445....
These services (protocols and ports) are accessible according to my SuSEfirewall2 definitions. I opened theme in section 9.)
I guess, this is the reason, that I don't see my samba shares on linux.
Can someone give me a hand on this problem?
Markus
-- ~ ~ perl self.pl ~ $_='print"\$_=\47$_\47;eval"';eval ~ krahmer@suse.de - SuSE Security Team ~
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
On Thursday 13 June 2002 05:46, techplus wrote:
So what do u recommend that people use instead of pptp
Definitely IPsec ! (FreeS/Wan). It is both included in the default newer SuSE, but even if you roll your own kernel, as I do, the install script does everything for you; patch the kernel, build & install it :-) [ make menugo ] I just went through all that, these past weeks. The configuration is more of a challenge, I just printed out some 120 pages of docs and read them very patiently and extensively (Though when it comes to security- critical software you should do this anyway...!!) After some fighting with the SuSEFirewall everything works as a charm. I didn't apply the x509(?) cert patches yet though, as I was only interested in a linux<->linux static WAN link, no windows involved. That is for a later date. As is often the case, the first time can be somewhat intimidating. Afterwards it becomes routine very quickly. :-) Maarten
----- Original Message ----- From: "Sebastian Krahmer" <krahmer@suse.de> To: "Markus Dahinden" <mdahinden@swissonline.ch> Cc: <suse-security@suse.com> Sent: Wednesday, June 12, 2002 11:08 AM Subject: Re: [suse-security] VPN with pptp
On Wed, 12 Jun 2002, Markus Dahinden wrote:
Hi,
Just because i often read mails like 'we are using a pptp VPN' on this list: pptp is horrible weak and should not be used to protect critical channels or to authenticate users. A paper can be found at http://stealth.7350.org/chap.pdf. I know it doesnt help in this case but I hope it helps one to decide against pptp :)
regards, Sebastian
Hi My pptp VPN connection between W2K and a SuSE Linux8.0 server (with SuSEfirewall2) seems to work (username and password are verified, PC is registered and authentificated).
/var/log/messages tells me for the vpn-connection: .... - SuSE-FW-UNALLOWED-TARGETIN.........prot. 47...... (after launching vpn-connection) .... - SuSE-FW-DROP-ANTI-SPOOFIN.................DPT 139.... (after hitting network item) .... - SuSE-FW-DROP-ANTI-SPOOFIN.................DPT 139.... (after Start/run "\\192.168.x.y") - SuSE-FW-DROP-ANTI-SPOOFIN.................DPT 445....
These services (protocols and ports) are accessible according to my SuSEfirewall2 definitions. I opened theme in section 9.)
I guess, this is the reason, that I don't see my samba shares on linux.
Can someone give me a hand on this problem?
Markus
-- ~ ~ perl self.pl ~ $_='print"\$_=\47$_\47;eval"';eval ~ krahmer@suse.de - SuSE Security Team ~
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
-- brick (brik) n. (4) pl. Another item that can be used to crash windows. Maarten J. H. van den Berg ~~//~~ network administrator VBVB - Amsterdam - The Netherlands - http://vbvb.nl T +31204233288 F +31204233286 G +31651994273
Just because i often read mails like 'we are using a pptp VPN' on this list: pptp is horrible weak and should not be used to protect critical channels or to authenticate users. A paper can be found at http://stealth.7350.org/chap.pdf. I know it doesnt help in this case but I hope it helps one to decide against pptp :)
So what do u recommend that people use instead of pptp
Definitely IPsec! :>) That's both a matter of both taste and requirements.
the install script does everything for you; patch the kernel, build & install it :-) The less kernel patches required, the better I like it.
The configuration is more of a challenge, I just printed out some 120 pages of docs and read them very patiently and extensively (Though when it comes to security- critical software you should do this anyway...!!) The simpler it is the better I like it (both from a maintenance as well as a security point of view). Complex -> much code -> many bugs. Much configuration -> much time and many mistakes that are hard to find.
Also have a look at cipe. - It's not a standard (no co-op with Cisco and friends). - It's a module without kernel patches. - It runs on most Microsoft platforms. - It uses UDP for transport (never use TCP for serious tunnelling). - It's got one small config file (and even that causes enough problems to those who don't know - their networking basics). - It supports IPTABLES NAT and bridging. - There is some version confusion right now (I'm using a snapshot till that sorts itself out). - It's got a good security track record. - I used it for years and am very satisfied. So it fits my taste and requirements best. You should have a look around and decide for yourself. Peter
On Thursday 13 June 2002 11:55, Peter van den Heuvel wrote:
Just because i often read mails like 'we are using a pptp VPN' on this list: pptp is horrible weak and should not be used to protect critical channels or to authenticate users. A paper can be found at http://stealth.7350.org/chap.pdf. I know it doesnt help in this case but I hope it helps one to decide against pptp :)
So what do u recommend that people use instead of pptp
Definitely IPsec!
:>) That's both a matter of both taste and requirements.
Well, sure. But from what I understood IPsec implements the underlying security mechanisms that are being / will be used by IPv6. Also, it is widely adopted, not only by microsoft and cisco, but in practice by just about anyone. If you buy a DSL-router that sports VPN support, you can bet it's based on IPsec. So, standards-wise, you can't go wrong with IPsec
the install script does everything for you; patch the kernel, build & install it :-)
The less kernel patches required, the better I like it.
The suse kernel (binary) IS patched AFAIK. It's just that a new hand-installed kernel from sources doesn't have IPsec out of the box. Just like reiserFS in 2.2 days, and Raid v0.90. If you don't want to patch your kernel, fine. I however, have no problems with that. I don't run custom kernels on my desktops and workstations, but I surely do on dedicated webserver, firewalls et al. Feel free to disagree though ;-)
The configuration is more of a challenge, I just printed out some 120 pages of docs and read them very patiently and extensively (Though when it comes to security- critical software you should do this anyway...!!)
The simpler it is the better I like it (both from a maintenance as well as a security point of view). Complex -> much code -> many bugs. Much configuration -> much time and many mistakes that are hard to find.
It is not so complex, maybe I went and exaggerated. Its just a bit of twiddling with firewallscripts to get it going && keep it secure. If you really like it _simple_ you can always add some rule like ipchains -A FORWARD -j ACCEPT but I rather like it 'more complex', hence safer... ;-))
Also have a look at cipe. - It's not a standard (no co-op with Cisco and friends). - It's a module without kernel patches. - It runs on most Microsoft platforms. - It uses UDP for transport (never use TCP for serious tunnelling). - It's got one small config file (and even that causes enough problems to those who don't know - their networking basics).
same as with freeswan...
- It supports IPTABLES NAT and bridging. - There is some version confusion right now (I'm using a snapshot till that sorts itself out). - It's got a good security track record. - I used it for years and am very satisfied.
So it fits my taste and requirements best. You should have a look around and decide for yourself.
Why, of course. Many roads lead to Rome, as they say. :-) Maarten -- Maarten J. H. van den Berg ~~//~~ network administrator VBVB - Amsterdam - The Netherlands - http://vbvb.nl T +31204233288 F +31204233286 G +31651994273
* Peter van den Heuvel wrote on Thu, Jun 13, 2002 at 11:55 +0200:
the install script does everything for you; patch the kernel, build & install it :-) The less kernel patches required, the better I like it.
But the origin of the patches are more important :)
The simpler it is the better I like it (both from a maintenance as well as a security point of view).
That is an important point I think! But IPSec is straight-forward, but of course you need to read half a page about IPSec to understand it. Well, there are multiple "modes" for IPSec operation and so on, at least here is potential for misconfigurations or such.
Complex -> much code -> many bugs.
This rule is definitly wrong. The number (and kind) of bugs depend on the quality which itselfs depend on the software creation processes. And many small "hacked-in" things are horrible :)
Much configuration -> much time and many mistakes that are hard to find.
Yes, this is correct. But you cannot implement a solution which is more easy than the problem, usually ;) Well, VPN is not a trivial theme, even if M$ and all those stuff suggests. If you use simple protocols, maybe they are just so simple since they are bad by design?
Also have a look at cipe. - It's not a standard (no co-op with Cisco and friends). - It's a module without kernel patches.
Where is the difference to a kernel patch? A module runs in kernel space and has access to any resource, and a wild pointer can happily crash your system.
- It runs on most Microsoft platforms.
Well, for Win it may be ok, and insecure VPN for insecure systems :) SCNR.
- It uses UDP for transport (never use TCP for serious tunnelling).
Hum, why UDP? IPSec uses protocol 50,51 IIRC. Well, tunneling UDP Packets in a TCP tunnel would dramaticall increase the reliance :)
- It's got one small config file (and even that causes enough problems to those who don't know - their networking basics).
Without knowledge noone should start :) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
hi all to add another view to this what if you have a provider that do not route type 50 packets? you have to use cipe! I myself use it - and its ok mark Steffen Dettmer wrote:
* Peter van den Heuvel wrote on Thu, Jun 13, 2002 at 11:55 +0200:
the install script does everything for you; patch the kernel, build & install it :-)
The less kernel patches required, the better I like it.
But the origin of the patches are more important :)
The simpler it is the better I like it (both from a maintenance as well as a security point of view).
That is an important point I think! But IPSec is straight-forward, but of course you need to read half a page about IPSec to understand it. Well, there are multiple "modes" for IPSec operation and so on, at least here is potential for misconfigurations or such.
Complex -> much code -> many bugs.
This rule is definitly wrong. The number (and kind) of bugs depend on the quality which itselfs depend on the software creation processes. And many small "hacked-in" things are horrible :)
Much configuration -> much time and many mistakes that are hard to find.
Yes, this is correct. But you cannot implement a solution which is more easy than the problem, usually ;) Well, VPN is not a trivial theme, even if M$ and all those stuff suggests. If you use simple protocols, maybe they are just so simple since they are bad by design?
Also have a look at cipe. - It's not a standard (no co-op with Cisco and friends). - It's a module without kernel patches.
Where is the difference to a kernel patch? A module runs in kernel space and has access to any resource, and a wild pointer can happily crash your system.
- It runs on most Microsoft platforms.
Well, for Win it may be ok, and insecure VPN for insecure systems :) SCNR.
- It uses UDP for transport (never use TCP for serious tunnelling).
Hum, why UDP? IPSec uses protocol 50,51 IIRC. Well, tunneling UDP Packets in a TCP tunnel would dramaticall increase the reliance :)
- It's got one small config file (and even that causes enough problems to those who don't know - their networking basics).
Without knowledge noone should start :)
oki,
Steffen
On Friday 14 June 2002 11:10, Mark Wassermann wrote:
hi all
to add another view to this what if you have a provider that do not route type 50 packets?
In that case, drop the provider.
From /etc/protocols :
ipv6-crypt 50 IPv6-Crypt # Encryption Header for IPv6 ipv6-auth 51 IPv6-Auth # Authentication Header for IPv6 Any provider not routing these will presumably break(?) ipv6. My guess is, in view of the timeline to fully implement ipv6 globally, that this is not acceptable, or at the very least it won't take long before it is unacceptable. FWIW, I know of no provider that doesn't route these... Alternatively, another response could have been: what if you have a provider that do not route type 17 packets? ;-)) Maarten -- Maarten J. H. van den Berg ~~//~~ network administrator VBVB - Amsterdam - The Netherlands - http://vbvb.nl T +31204233288 F +31204233286 G +31651994273
* Mark Wassermann wrote on Fri, Jun 14, 2002 at 11:10 +0200:
to add another view to this what if you have a provider that do not route type 50 packets?
If your ISP don't routes IP today, then drop the ISP I would suggest. Today IP is *the* tranport protocol. Of course there are still other protocols like X.25 or whatever, but I think this is a completely different theme. And on X.25, you can put IP on top, but if you have an X.25 or whatever access, you usually don't need IP :)
you have to use cipe!
You mean, you found an ISP, that routes a few but not all IP protocols?! Hum, I cannot believe that someone would do so?! oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Complex -> much code -> many bugs. This rule is definitly wrong. The number (and kind) of bugs depend on the quality which itselfs depend on the software creation processes. And many small "hacked-in" things are horrible :) Well, I could write a more formally correct specification. That would get lengthy and less pointy. I sort of "hoped" that most folk on the list would understand that "simple" would mean "as simple as you can reasonably make it without neglecting the most essential requirements or common sense elements of quality". In software (and IT more generally) there's a funny tendency towards TONS of features and complexity to the extreme. Most often the argumentation for the architecture chosen is debatable at best. So what I mean is you best start with the simple. If you get a feel for the quality (you can even audit the code of smaller things more easily) and can live with it you best not go for the more complex options. Like why would you use complex public protocol negociation with public keys if your setup would be just as sound with a fixed key and a fixed protocol. The point was: look at yours requirements before you select a product.
Much configuration -> much time and many mistakes that are hard to find. Yes, this is correct. But you cannot implement a solution which is more easy than the problem, usually ;) Thanks for pointing that out.
Well, VPN is not a trivial theme, even if M$ and all those stuff suggests. If you use simple protocols, maybe they are just so simple since they are bad by design? Simplicity is an ASPECT. You realy think I meant to say that a bad architecture is better than a complex architecture?
Also have a look at cipe. - It's not a standard (no co-op with Cisco and friends). - It's a module without kernel patches. Where is the difference to a kernel patch? A module runs in kernel space and has access to any resource, and a wild pointer can happily crash your system. The difference is clarity in architecture. One aspect that is grossly missing from most infrastructures of any weight I've seen over the years. But even then, this was part of a list of cipe characteristics. There was NO attempt at comparing it favourably to IPsec WHATSOEVER.
- It runs on most Microsoft platforms. Well, for Win it may be ok, and insecure VPN for insecure systems :) SCNR. It's just a feature, not a recommendation. And please, would you care to explain why you feel cipe is not secure? And also, most insecurity issues in Microsoft shops are due to mis-management of their systems instead of the system themselves, however much I might personally prefer Linux. Try to grab any 5 year old Linux distro and throw it on the net without any serious configuration and see how long it survives.
- It uses UDP for transport (never use TCP for serious tunnelling). Hum, why UDP? IPSec uses protocol 50,51 IIRC. Well, tunneling UDP Packets in a TCP tunnel would dramaticall increase the reliance Yes, and sooo useful if the protocol being tunneled does it as well. And then both protocols get their own transmission window timeouts and try to correct. As soon as you loose packets you'll find out why you do not want to use TCP. But again, it just a cipe characteristic.
Peter
* Peter van den Heuvel wrote on Fri, Jun 14, 2002 at 11:56 +0200:
Complex -> much code -> many bugs. This rule is definitly wrong. The number (and kind) of bugs depend on the quality which itselfs depend on the software creation processes. And many small "hacked-in" things are horrible :)
Well, I could write a more formally correct specification.
:) Surely you could, but I think it's not needed here ;)
quality". In software (and IT more generally) there's a funny tendency towards TONS of features and complexity to the extreme.
Yes, I think you're right here. This ends up in software with integrated anything that can do anything - except it's job :)
keys if your setup would be just as sound with a fixed key and a fixed protocol. The point was: look at yours requirements before you select a product.
Well, don't get me wrong, I think exactly the same. But I see another tendency: choosing simple architechtures for complex problems, and mostly that stuff works, but not well.
Much configuration -> much time and many mistakes that are hard to find. Yes, this is correct. But you cannot implement a solution which is more easy than the problem, usually ;) Thanks for pointing that out.
[Hope you don't missed the smilie]
Well, VPN is not a trivial theme, even if M$ and all those stuff suggests. If you use simple protocols, maybe they are just so simple since they are bad by design? Simplicity is an ASPECT. You realy think I meant to say that a bad architecture is better than a complex architecture?
It sounded a little like that. Sorry if I misunderstood you.
Where is the difference to a kernel patch? A module runs in kernel space and has access to any resource, and a wild pointer can happily crash your system. The difference is clarity in architecture.
Ohh, you mean, that modules usually have are more clean interface? Ohh, yes, I see what you mean. You are afraid in software that patches hundered points of foreign kernel sources probably with some side effects or such things? Indeed, this may be very risky and seems to be much more complex than useing a nice interface.
- It runs on most Microsoft platforms. Well, for Win it may be ok, and insecure VPN for insecure systems :) SCNR. It's just a feature, not a recommendation. And please, would you care to explain why you feel cipe is not secure?
I don't know what I meant with this, sorry, either it was too late that I mixed up something or it was a kind of typo.
- It uses UDP for transport (never use TCP for serious tunnelling). Hum, why UDP? IPSec uses protocol 50,51 IIRC. Well, tunneling UDP Packets in a TCP tunnel would dramaticall increase the reliance Yes, and sooo useful if the protocol being tunneled does it as well. And then both protocols get their own transmission window timeouts and try to correct. As soon as you loose packets you'll find out why you do not want to use TCP.
Yes, you do not want TCP for UDP transmissions. But that doesn't means that you do want UDP for UDP transmissions, and IP proto 50 isn't TCP as well. The point is that it's not the best idea to put stream characteristics on packet based applications/sessions, but this isn't the case in IPSec AFAIK. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Hi, the paper is about normal chap. but what about chapms-v2 with mppe-128 stateless? my pptp server only accept chapms-v2, should be secure or? here is my option file: ipparam PoPToP lock mtu 1490 mru 1490 multilink auth #+chap #+chapms +chapms-v2 ipcp-accept-local ipcp-accept-remote lcp-echo-failure 30 lcp-echo-interval 5 deflate 0 mppe-128 mppe-stateless require-mppe require-mppe-stateless for markus: a good paper for setting up pptpd: http://www.shorewall.net/PPTP.htm best regards Wolfgang -----Ursprungliche Nachricht----- Von: Sebastian Krahmer [mailto:krahmer@suse.de] Gesendet: Mittwoch, 12. Juni 2002 17:08 An: Markus Dahinden Cc: suse-security@suse.com Betreff: Re: [suse-security] VPN with pptp On Wed, 12 Jun 2002, Markus Dahinden wrote: Hi, Just because i often read mails like 'we are using a pptp VPN' on this list: pptp is horrible weak and should not be used to protect critical channels or to authenticate users. A paper can be found at http://stealth.7350.org/chap.pdf. I know it doesnt help in this case but I hope it helps one to decide against pptp :) regards, Sebastian
Hi My pptp VPN connection between W2K and a SuSE Linux8.0 server (with SuSEfirewall2) seems to work (username and password are verified, PC is registered and authentificated).
/var/log/messages tells me for the vpn-connection: .... - SuSE-FW-UNALLOWED-TARGETIN.........prot. 47...... (after launching vpn-connection) .... - SuSE-FW-DROP-ANTI-SPOOFIN.................DPT 139.... (after hitting network item) .... - SuSE-FW-DROP-ANTI-SPOOFIN.................DPT 139.... (after Start/run "\\192.168.x.y") - SuSE-FW-DROP-ANTI-SPOOFIN.................DPT 445....
These services (protocols and ports) are accessible according to my SuSEfirewall2 definitions. I opened theme in section 9.)
I guess, this is the reason, that I don't see my samba shares on linux.
Can someone give me a hand on this problem?
Markus
-- ~ ~ perl self.pl ~ $_='print"\$_=\47$_\47;eval"';eval ~ krahmer@suse.de - SuSE Security Team ~ -- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
On Mon, 17 Jun 2002 webmaster@hackenschmiede.com wrote: Hi, Neither CHAP or any of its extensions (MS-CHAP,...) is secure because the same requirement 'answer auth-requests' is true for all of these. The extensions just use different hashing function and negotiate keys for further channel encryption which is weak enough to be broken. I am currently in research about the extensions but I am pretty sure VPN clients can be tricked into disabling crypto if the server either doesnt offer it or rejects such requests. This would allow one authenticated user to slip through all traffic through his account and forbidding crypto for all the other clients. There was also a paper from Bruce Schneier and Mudge about MS CHAP extensions covering other weaknesses. Sebastian
Hi,
the paper is about normal chap.
but what about chapms-v2 with mppe-128 stateless?
my pptp server only accept chapms-v2, should be secure or?
here is my option file:
ipparam PoPToP lock mtu 1490 mru 1490 multilink auth #+chap #+chapms +chapms-v2 ipcp-accept-local ipcp-accept-remote lcp-echo-failure 30 lcp-echo-interval 5 deflate 0 mppe-128 mppe-stateless require-mppe require-mppe-stateless
for markus:
a good paper for setting up pptpd:
http://www.shorewall.net/PPTP.htm
best regards Wolfgang
-----Ursprungliche Nachricht----- Von: Sebastian Krahmer [mailto:krahmer@suse.de] Gesendet: Mittwoch, 12. Juni 2002 17:08 An: Markus Dahinden Cc: suse-security@suse.com Betreff: Re: [suse-security] VPN with pptp
On Wed, 12 Jun 2002, Markus Dahinden wrote:
Hi,
Just because i often read mails like 'we are using a pptp VPN' on this list: pptp is horrible weak and should not be used to protect critical channels or to authenticate users. A paper can be found at http://stealth.7350.org/chap.pdf. I know it doesnt help in this case but I hope it helps one to decide against pptp :)
regards, Sebastian
Hi My pptp VPN connection between W2K and a SuSE Linux8.0 server (with SuSEfirewall2) seems to work (username and password are verified, PC is registered and authentificated).
/var/log/messages tells me for the vpn-connection: .... - SuSE-FW-UNALLOWED-TARGETIN.........prot. 47...... (after launching vpn-connection) .... - SuSE-FW-DROP-ANTI-SPOOFIN.................DPT 139.... (after hitting network item) .... - SuSE-FW-DROP-ANTI-SPOOFIN.................DPT 139.... (after Start/run "\\192.168.x.y") - SuSE-FW-DROP-ANTI-SPOOFIN.................DPT 445....
These services (protocols and ports) are accessible according to my SuSEfirewall2 definitions. I opened theme in section 9.)
I guess, this is the reason, that I don't see my samba shares on linux.
Can someone give me a hand on this problem?
Markus
-- ~ ~ perl self.pl ~ $_='print"\$_=\47$_\47;eval"';eval ~ krahmer@suse.de - SuSE Security Team ~
participants (8)
-
Maarten J H van den Berg -
Mark Wassermann -
Markus Dahinden -
Peter van den Heuvel -
Sebastian Krahmer -
Steffen Dettmer -
techplus -
webmaster＠hackenschmiede.com