Re: PPTP and encryption / RC4 weaknesses
On Mon, Mar 04, 2002 at 03:20:44PM +0100, Christoph Moench-Tegeder wrote: thanks, this confirm me that i really have to avoid it ;) cheers, JeF > ## Jean-Francois Dive ([EMAIL PROTECTED]): > > > I was wondering: PPTP use RC4 up to 128 bit keys as an encryption > > mechanism. I'd like > > to have the impressions from people of the list about the cryptographic > > strenght of > > such algorithm, especially now that wireless WEP RC4 based encryption have > > been broken. > > PPTP can easily be broken if MS-CHAPv2 is used: > http://mopo.informatik.uni-freiburg.de/pptp_mschapv2/ > > Regards, > cmt > > -- > Spare Space > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- -> Jean-Francois Dive --> [EMAIL PROTECTED]
Fw: CERT Advisory CA-2002-06 Radius Vulnerabilities
Hi All, Just checking our radius servers, I noticed that Cistron radius in potato is still version 1.6.1, and I cannot see any notes of security updates for the package in the changelog.Debian.gz file. Andrew Tait System Administrator Country NetLink Pty, Ltd E-Mail: [EMAIL PROTECTED] WWW: http://www.cnl.com.au 30 Bank St Cobram, VIC 3644, Australia Ph: +61 (03) 58 711 000 Fax: +61 (03) 58 711 874 "It's the smell! If there is such a thing." Agent Smith - The Matrix - Original Message - From: "CERT Advisory" To: Sent: Tuesday, March 05, 2002 6:43 AM Subject: CERT Advisory CA-2002-06 Vulnerabilities in Various Implementations of the > > > -BEGIN PGP SIGNED MESSAGE- > > CERT Advisory CA-2002-06 Vulnerabilities in Various Implementations of the > RADIUS Protocol > >Original release date: March 4, 2002 >Last revised: -- >Source: CERT/CC > >A complete revision history can be found at the end of this file. > > Systems Affected > >Systems running any of the following RADIUS implementations: > > * Ascend RADIUS versions 1.16 and prior > * Cistron RADIUS versions 1.6.5 and prior > * FreeRADIUS versions 0.3 and prior > * GnuRADIUS versions 0.95 and prior > * ICRADIUS versions 0.18.1 and prior > * Livingston RADIUS versions 2.1 and earlier > * RADIUS (previously known as Lucent RADIUS) versions 2.1 and prior > * RADIUSClient versions 0.3.1 and prior > * XTRADIUS 1.1-pre1 and prior > * YARD RADIUS 1.0.19 and prior > > Overview > >Remote Authentication Dial In User Service (RADIUS) servers are used >for authentication, authorization and accounting for terminals that >speak the RADIUS protocol. Multiple vulnerabilities have been >discovered in several implementations of the RADIUS protocol. > > I. Description > >Two vulnerabilities in various implementations of RADIUS clients and >servers have been reported to several vendors and the CERT/CC. They >are remotely exploitable, and on most systems result in a denial of >service. VU#589523 may allow the execution of code if the attacker has >knowledge of the shared secret. > >VU#589523 - Multiple implementations of the RADIUS protocol contain a >digest calculation buffer overflow > > Multiple implementations of the RADIUS protocol contain a buffer > overflow in the function that calculates message digests. > > During the message digest calculation, a string containing the > shared secret is concatenated with a packet received without > checking the size of the target buffer. This makes it possible to > overflow the buffer with shared secret data. This can lead to a > denial of service against the server. If the shared secret is known > by the attacker, then it may be possible to use this information to > execute arbitrary code with the privileges of the victim RADIUS > server or client, usually root. It should be noted that gaining > knowledge of the shared secret is not a trivial task. > > Systems Affected by VU#589523 > > * Ascend RADIUS versions 1.16 and prior > * Cistron RADIUS versions 1.6.4 and prior > * FreeRADIUS versions 0.3 and prior > * GnuRADIUS versions 0.95 and prior > * ICRADIUS versions 0.18.1 and prior > * Livingston RADIUS versions 2.1 and earlier > * RADIUS (commonly known as Lucent RADIUS) versions 2.1 and prior > * RADIUSClient versions 0.3.1 and prior > * YARD RADIUS 1.0.19 and prior > * XTRADIUS 1.1-pre1 and prior > >VU#936683 - Multiple implementations of the RADIUS protocol do not >adequately validate the vendor-length of vendor-specific attributes. > > Various RADIUS servers and clients permit the passing of > vendor-specific and user-specificattributes.Several > implementations of RADIUS fail to check the vendor-length of > vendor-specific attributes. It is possible to cause a denial of > service against RADIUS servers with a malformed vendor-specific > attribute. > > RADIUS servers and clients fail to validate the vendor-length > inside vendor-specific attributes. The vendor-length shouldn't be > less than 2. If vendor-length is less than 2, the RADIUS server (or > client) calculates the attribute length as a negative number. The > attribute length is then used in various functions. In most RADIUS > servers the function that performs this calculation is rad_recv() > or radrecv(). Some applications may use the same logic to validate > user-specific attributes and be vulnerable via the same method. > > Systems Affected by VU#936683 > > * Cistron RADIUS versions 1.6.5 and prior > * FreeRADIUS versions 0.3 and prior > * ICRADIUS versions 0.18.1 and prior > * Livingston RADI
Re: iptables vs DHCP
Osvaldo Mundim Junior <[EMAIL PROTECTED]> writes: > Does anybody use iptables in a DHCP network? I want to know how > would be some rule in this case... There were some messages flying around debian-firewall concerning DHCP and iptables. They don't seem to be in the archive yet, though. -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH
Re: PPTP and encryption / RC4 weaknesses
On Mon, Mar 04, 2002 at 03:20:44PM +0100, Christoph Moench-Tegeder wrote: thanks, this confirm me that i really have to avoid it ;) cheers, JeF > ## Jean-Francois Dive ([EMAIL PROTECTED]): > > > I was wondering: PPTP use RC4 up to 128 bit keys as an encryption mechanism. I'd >like > > to have the impressions from people of the list about the cryptographic strenght of > > such algorithm, especially now that wireless WEP RC4 based encryption have been >broken. > > PPTP can easily be broken if MS-CHAPv2 is used: > http://mopo.informatik.uni-freiburg.de/pptp_mschapv2/ > > Regards, > cmt > > -- > Spare Space > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- -> Jean-Francois Dive --> [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Fw: CERT Advisory CA-2002-06 Radius Vulnerabilities
Hi All, Just checking our radius servers, I noticed that Cistron radius in potato is still version 1.6.1, and I cannot see any notes of security updates for the package in the changelog.Debian.gz file. Andrew Tait System Administrator Country NetLink Pty, Ltd E-Mail: [EMAIL PROTECTED] WWW: http://www.cnl.com.au 30 Bank St Cobram, VIC 3644, Australia Ph: +61 (03) 58 711 000 Fax: +61 (03) 58 711 874 "It's the smell! If there is such a thing." Agent Smith - The Matrix - Original Message - From: "CERT Advisory" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, March 05, 2002 6:43 AM Subject: CERT Advisory CA-2002-06 Vulnerabilities in Various Implementations of the > > > -BEGIN PGP SIGNED MESSAGE- > > CERT Advisory CA-2002-06 Vulnerabilities in Various Implementations of the > RADIUS Protocol > >Original release date: March 4, 2002 >Last revised: -- >Source: CERT/CC > >A complete revision history can be found at the end of this file. > > Systems Affected > >Systems running any of the following RADIUS implementations: > > * Ascend RADIUS versions 1.16 and prior > * Cistron RADIUS versions 1.6.5 and prior > * FreeRADIUS versions 0.3 and prior > * GnuRADIUS versions 0.95 and prior > * ICRADIUS versions 0.18.1 and prior > * Livingston RADIUS versions 2.1 and earlier > * RADIUS (previously known as Lucent RADIUS) versions 2.1 and prior > * RADIUSClient versions 0.3.1 and prior > * XTRADIUS 1.1-pre1 and prior > * YARD RADIUS 1.0.19 and prior > > Overview > >Remote Authentication Dial In User Service (RADIUS) servers are used >for authentication, authorization and accounting for terminals that >speak the RADIUS protocol. Multiple vulnerabilities have been >discovered in several implementations of the RADIUS protocol. > > I. Description > >Two vulnerabilities in various implementations of RADIUS clients and >servers have been reported to several vendors and the CERT/CC. They >are remotely exploitable, and on most systems result in a denial of >service. VU#589523 may allow the execution of code if the attacker has >knowledge of the shared secret. > >VU#589523 - Multiple implementations of the RADIUS protocol contain a >digest calculation buffer overflow > > Multiple implementations of the RADIUS protocol contain a buffer > overflow in the function that calculates message digests. > > During the message digest calculation, a string containing the > shared secret is concatenated with a packet received without > checking the size of the target buffer. This makes it possible to > overflow the buffer with shared secret data. This can lead to a > denial of service against the server. If the shared secret is known > by the attacker, then it may be possible to use this information to > execute arbitrary code with the privileges of the victim RADIUS > server or client, usually root. It should be noted that gaining > knowledge of the shared secret is not a trivial task. > > Systems Affected by VU#589523 > > * Ascend RADIUS versions 1.16 and prior > * Cistron RADIUS versions 1.6.4 and prior > * FreeRADIUS versions 0.3 and prior > * GnuRADIUS versions 0.95 and prior > * ICRADIUS versions 0.18.1 and prior > * Livingston RADIUS versions 2.1 and earlier > * RADIUS (commonly known as Lucent RADIUS) versions 2.1 and prior > * RADIUSClient versions 0.3.1 and prior > * YARD RADIUS 1.0.19 and prior > * XTRADIUS 1.1-pre1 and prior > >VU#936683 - Multiple implementations of the RADIUS protocol do not >adequately validate the vendor-length of vendor-specific attributes. > > Various RADIUS servers and clients permit the passing of > vendor-specific and user-specificattributes.Several > implementations of RADIUS fail to check the vendor-length of > vendor-specific attributes. It is possible to cause a denial of > service against RADIUS servers with a malformed vendor-specific > attribute. > > RADIUS servers and clients fail to validate the vendor-length > inside vendor-specific attributes. The vendor-length shouldn't be > less than 2. If vendor-length is less than 2, the RADIUS server (or > client) calculates the attribute length as a negative number. The > attribute length is then used in various functions. In most RADIUS > servers the function that performs this calculation is rad_recv() > or radrecv(). Some applications may use the same logic to validate > user-specific attributes and be vulnerable via the same method. > > Systems Affected by VU#936683 > > * Cistron RADIUS versions 1.6.5 and prior > * FreeRADIUS versions 0.3 and prior > * ICRADIUS versions 0.
Re: iptables vs DHCP
Osvaldo Mundim Junior <[EMAIL PROTECTED]> writes: > Does anybody use iptables in a DHCP network? I want to know how > would be some rule in this case... There were some messages flying around debian-firewall concerning DHCP and iptables. They don't seem to be in the archive yet, though. -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hosts.{allow,deny} vs iptables.
On Mon, Mar 04, 2002 at 11:52:21AM -0500, Moses Moore wrote:
> Joao Luis Meloni Assirati wrote:
> > I want to know if my point of view is right, or if there is any
> > functionality that hosts.{allow,deny} scheme provides which iptables
> > can't.
>
> - You have daemon-by-daemon settings instead of port-by-port or
> protocol-by-protocol.
> - the aforementioned 'extra layer of security incase your iptables get
> cleared'.
> - the 'PARANOID' host definition, which matches any host that has
> doesn't have sane DNS-to-reverse-DNS settings.
>
> Bastille does something nice (apt-get install bastille) I didn't know
> about tcpwrappers. I found this in my /etc/hosts.allow after running
> Bastille's automated setup tool:
>
> ALL : ALL : spawn (/usr/sbin/safe_finger -l @%h | /bin/mail -s "Port
> Denial noted %d-%h" root) & : DENY
ALL:ALL with a fingering booby trap may not be such a good idea if you
have anything tcpwrappered that's listening on the finger port. From the
hosts_access(5) manpage (emphasis mine):
The next example permits tftp requests from hosts in the
local domain (notice the leading dot). Requests from any
other hosts are denied. Instead of the requested file, a
finger probe is sent to the offending host. The result is
mailed to the superuser.
/etc/hosts.allow:
in.tftpd: LOCAL, .my.domain
/etc/hosts.deny:
in.tftpd: ALL: (/some/where/safe_finger -l @%h | \
/usr/ucb/mail -s %d-%h root) &
The safe_finger command comes with the tcpd wrapper and
should be installed in a suitable place. It limits possi
ble damage from data sent by the remote finger server. It
gives better protection than the standard finger command.
The expansion of the %h (client host) and %d (service
name) sequences is described in the section on shell com
mands.
Warning: do not booby-trap your finger daemon, unless you
are prepared for infinite finger loops.
^^
On network firewall systems this trick can be carried even
further. The typical network firewall only provides a
limited set of services to the outer world. All other ser
vices can be "bugged" just like the above tftp example.
The result is an excellent early-warning system.
If someone on another host with a finger daemon also installed and
similarly wrappered tries to connect to anything wrappered on your
host, your computers will happily finger each other forever. This
will also fill up your mailbox.
For similar reasons, it's bad to booby-trap tcp/113, the ident port,
with anything that fingers or does ident lookups.
(Of course, if nothing using tcpwrappers is listening on tcp/79, ALL:ALL
is okay, just as long as you remember to fix it should you ever install
a finger daemon.)
--
William Aoki [EMAIL PROTECTED] /"\ ASCII Ribbon Campaign
3B0A 6800 8A1A 78A7 9A26 BB92 \ / No HTML in mail or news!
9A26 BB92 6329 2D3E 199D 8C7B X
/ \
Re: hosts.{allow,deny} vs iptables.
Joao Luis Meloni Assirati wrote:
> I want to know if my point of view is right, or if there is any
> functionality that hosts.{allow,deny} scheme provides which iptables
> can't.
- You have daemon-by-daemon settings instead of port-by-port or
protocol-by-protocol.
- the aforementioned 'extra layer of security incase your iptables get
cleared'.
- the 'PARANOID' host definition, which matches any host that has
doesn't have sane DNS-to-reverse-DNS settings.
Bastille does something nice (apt-get install bastille) I didn't know
about tcpwrappers. I found this in my /etc/hosts.allow after running
Bastille's automated setup tool:
ALL : ALL : spawn (/usr/sbin/safe_finger -l @%h | /bin/mail -s "Port
Denial noted %d-%h" root) & : DENY
Re: hosts.{allow,deny} vs iptables.
On Mon, Mar 04, 2002 at 11:52:21AM -0500, Moses Moore wrote:
> Joao Luis Meloni Assirati wrote:
> > I want to know if my point of view is right, or if there is any
> > functionality that hosts.{allow,deny} scheme provides which iptables
> > can't.
>
> - You have daemon-by-daemon settings instead of port-by-port or
> protocol-by-protocol.
> - the aforementioned 'extra layer of security incase your iptables get
> cleared'.
> - the 'PARANOID' host definition, which matches any host that has
> doesn't have sane DNS-to-reverse-DNS settings.
>
> Bastille does something nice (apt-get install bastille) I didn't know
> about tcpwrappers. I found this in my /etc/hosts.allow after running
> Bastille's automated setup tool:
>
> ALL : ALL : spawn (/usr/sbin/safe_finger -l @%h | /bin/mail -s "Port
> Denial noted %d-%h" root) & : DENY
ALL:ALL with a fingering booby trap may not be such a good idea if you
have anything tcpwrappered that's listening on the finger port. From the
hosts_access(5) manpage (emphasis mine):
The next example permits tftp requests from hosts in the
local domain (notice the leading dot). Requests from any
other hosts are denied. Instead of the requested file, a
finger probe is sent to the offending host. The result is
mailed to the superuser.
/etc/hosts.allow:
in.tftpd: LOCAL, .my.domain
/etc/hosts.deny:
in.tftpd: ALL: (/some/where/safe_finger -l @%h | \
/usr/ucb/mail -s %d-%h root) &
The safe_finger command comes with the tcpd wrapper and
should be installed in a suitable place. It limits possi
ble damage from data sent by the remote finger server. It
gives better protection than the standard finger command.
The expansion of the %h (client host) and %d (service
name) sequences is described in the section on shell com
mands.
Warning: do not booby-trap your finger daemon, unless you
are prepared for infinite finger loops.
^^
On network firewall systems this trick can be carried even
further. The typical network firewall only provides a
limited set of services to the outer world. All other ser
vices can be "bugged" just like the above tftp example.
The result is an excellent early-warning system.
If someone on another host with a finger daemon also installed and
similarly wrappered tries to connect to anything wrappered on your
host, your computers will happily finger each other forever. This
will also fill up your mailbox.
For similar reasons, it's bad to booby-trap tcp/113, the ident port,
with anything that fingers or does ident lookups.
(Of course, if nothing using tcpwrappers is listening on tcp/79, ALL:ALL
is okay, just as long as you remember to fix it should you ever install
a finger daemon.)
--
William Aoki [EMAIL PROTECTED] /"\ ASCII Ribbon Campaign
3B0A 6800 8A1A 78A7 9A26 BB92 \ / No HTML in mail or news!
9A26 BB92 6329 2D3E 199D 8C7B X
/ \
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hosts.{allow,deny} vs iptables.
Joao Luis Meloni Assirati wrote:
> I want to know if my point of view is right, or if there is any
> functionality that hosts.{allow,deny} scheme provides which iptables
> can't.
- You have daemon-by-daemon settings instead of port-by-port or
protocol-by-protocol.
- the aforementioned 'extra layer of security incase your iptables get
cleared'.
- the 'PARANOID' host definition, which matches any host that has
doesn't have sane DNS-to-reverse-DNS settings.
Bastille does something nice (apt-get install bastille) I didn't know
about tcpwrappers. I found this in my /etc/hosts.allow after running
Bastille's automated setup tool:
ALL : ALL : spawn (/usr/sbin/safe_finger -l @%h | /bin/mail -s "Port
Denial noted %d-%h" root) & : DENY
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PPTP and encryption / RC4 weaknesses
## Jean-Francois Dive ([EMAIL PROTECTED]): > I was wondering: PPTP use RC4 up to 128 bit keys as an encryption mechanism. > I'd like > to have the impressions from people of the list about the cryptographic > strenght of > such algorithm, especially now that wireless WEP RC4 based encryption have > been broken. PPTP can easily be broken if MS-CHAPv2 is used: http://mopo.informatik.uni-freiburg.de/pptp_mschapv2/ Regards, cmt -- Spare Space
Re: iptables vs DHCP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Said Osvaldo Mundim Junior on Mon, Mar 04, 2002 at 09:57:28AM -0300: > Does anybody use iptables in a DHCP network? I want to know how would > be some rule in this case... Have a look at 'firestarter' as well, a GNOME frontend to building firewall rules that can adapt for DHCP. - -- [!] Justin R. Miller <[EMAIL PROTECTED]> PGP 0xC9C40C31 -=- http://codesorcery.net http://www.aclu.org/action/id107.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8g3Tr94d6K8nEDDERAl/TAJ9plxxZTYSKOkb6Pd25rckIZuQvyACdEGMY 3sXhPd46dKcv4Hw1NX4aikk= =Z21c -END PGP SIGNATURE-
Re: iptables vs DHCP
Monday, March 04, 2002, 1:57:28 PM, Osvaldo Mundim Junior wrote: > Does anybody use iptables in a DHCP network? I want to know how would be some > rule in this case... Check the rules from the monmotha-iptables-script which can be downloaded from http://monmotha.mplug.org. In my network these DHCP-rules work at least for me. :-) Regards, Marcus -- Fickle minds, pretentious attitudes and ugly make-up on ugly faces... The Goth Goose Of The Week: http://www.gothgoose.net
iptables vs DHCP
Hi all, Does anybody use iptables in a DHCP network? I want to know how would be some rule in this case... tks in advance... Osvaldo
Re: PPTP and encryption / RC4 weaknesses
## Jean-Francois Dive ([EMAIL PROTECTED]): > I was wondering: PPTP use RC4 up to 128 bit keys as an encryption mechanism. I'd like > to have the impressions from people of the list about the cryptographic strenght of > such algorithm, especially now that wireless WEP RC4 based encryption have been >broken. PPTP can easily be broken if MS-CHAPv2 is used: http://mopo.informatik.uni-freiburg.de/pptp_mschapv2/ Regards, cmt -- Spare Space -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
PPTP and encryption / RC4 weaknesses
hi all, I was wondering: PPTP use RC4 up to 128 bit keys as an encryption mechanism. I'd like to have the impressions from people of the list about the cryptographic strenght of such algorithm, especially now that wireless WEP RC4 based encryption have been broken. I understand that the problem in WEP is the key extrapolation which is the problem, but i'd like to know if RC4 in PPTP can be considered as secure, purely on encryption side. Thanks for any pointer on this.( except the 'read the applied cryptography book ;) JeF -- -> Jean-Francois Dive --> [EMAIL PROTECTED]
Re: iptables vs DHCP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Said Osvaldo Mundim Junior on Mon, Mar 04, 2002 at 09:57:28AM -0300: > Does anybody use iptables in a DHCP network? I want to know how would > be some rule in this case... Have a look at 'firestarter' as well, a GNOME frontend to building firewall rules that can adapt for DHCP. - -- [!] Justin R. Miller <[EMAIL PROTECTED]> PGP 0xC9C40C31 -=- http://codesorcery.net http://www.aclu.org/action/id107.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8g3Tr94d6K8nEDDERAl/TAJ9plxxZTYSKOkb6Pd25rckIZuQvyACdEGMY 3sXhPd46dKcv4Hw1NX4aikk= =Z21c -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: iptables vs DHCP
Monday, March 04, 2002, 1:57:28 PM, Osvaldo Mundim Junior wrote: > Does anybody use iptables in a DHCP network? I want to know how would be some > rule in this case... Check the rules from the monmotha-iptables-script which can be downloaded from http://monmotha.mplug.org.; In my network these DHCP-rules work at least for me. :-) Regards, Marcus -- Fickle minds, pretentious attitudes and ugly make-up on ugly faces... The Goth Goose Of The Week: http://www.gothgoose.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
iptables vs DHCP
Hi all, Does anybody use iptables in a DHCP network? I want to know how would be some rule in this case... tks in advance... Osvaldo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
unsubsribe
PPTP and encryption / RC4 weaknesses
hi all, I was wondering: PPTP use RC4 up to 128 bit keys as an encryption mechanism. I'd like to have the impressions from people of the list about the cryptographic strenght of such algorithm, especially now that wireless WEP RC4 based encryption have been broken. I understand that the problem in WEP is the key extrapolation which is the problem, but i'd like to know if RC4 in PPTP can be considered as secure, purely on encryption side. Thanks for any pointer on this.( except the 'read the applied cryptography book ;) JeF -- -> Jean-Francois Dive --> [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
unsubsribe
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hosts.{allow,deny} vs iptables.
hello,
tcpd offer offer another layer of security in your application ACL
scheme which is always a good thing. Another point is that you can
have more control on whow do what from where, you can match on usernames
which is something that iptables cant do as it acts at an underlying
level. Security is a matter of choice and most of the time depends
on the equation way to protect / power of the attacker. I'd recommend
to use both as it is better to have more than not enough security
checks.
hope that help,
JeF
On Mon, Mar 04, 2002 at 09:14:27AM +0900, Olaf Meeuwissen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Joao Luis Meloni Assirati <[EMAIL PROTECTED]> writes:
>
> > Recently I learned how to use linux2.4 netfilter. Since it is a fairly
> > complete ip tool (tcp, udp, icmp), capable of a wide set of matchings
> > (source IP, dest port, ...) and also able to LOG, it seemed to me that all
> > hosts.{allow,deny} control through tcpd could be done by a convenient set
> > of host based (i.e. not in a firewall gateway) iptables rules. More than
> > this, speed seems to be improved by eliminating inetd - tcpd latency.
> >
> > I want to know if my point of view is right, or if there is any
> > functionality that hosts.{allow,deny} scheme provides which iptables
> > can't.
>
> Yes, you can achieve the same control with netfilter as you can with
> hosts.{allow,deny}. However, that doesn't mean you should throw out
> tcp wrappers (even if that improves throughput).
>
> # Rather easily done by putting ALL: ALL in your hosts.allow.
>
> It is usually desirable to have more than one line of defense. Just
> for the sake of argument, suppose you happened to
>
> ~# /etc/init.d/iptables clear
>
> and as a result tear down your whole firewall. You'd be very happy to
> a hosts.deny lying around that says ALL: ALL. This example is perhaps
> very unlikely to occur, but what if you happened to make a mistake in
> your firewall rules or, eek!, a bug in the kernel code implementing
> netfilter?
> - --
> Olaf MeeuwissenEpson Kowa Corporation, CID
> GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90
> LPIC-2 -- I hack, therefore I am -- BOFH
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: Processed by Mailcrypt 3.5.6
