Re: A more secure form of .htaccess?
also sprach Dan Faerch <[EMAIL PROTECTED]> [2002.04.27.2120 +0200]: > > you know their algorithm against MAC table overflow? > No i dont.. I would be very interrested in reading about it, if you know of > a link.. Im sure that it would be possible to enforce some level of > security.. it's quite simple. i don't have a link. but these switches clear out their MAC tables LRU style at a rate indirectly proportional to the space left. so if you manage to half the space left by MAC flooding, they'll clean out the tables twice as fast. if you manage to half the remaining space, they'll clean out four times as fast. there's very little chance that a you can fill those tables and make it enter hub mode. > It is correct that you can get switches that, one way or another, will try > to enforce the switching mode and thus, not reentering hub-mode.. Also the > locking mechanism some switches use, that locks the MAC/IP pair to a single > port is quite good, but rather annoying to work with in most office > enviroments (because of laptops and so forth).. aside from the fact that you can still change you MAC address at will... but yes, these are good for static environments only, but they aren't a security measure. `ifconfig eth0 hw ether 00:11:22:33:44:55` is all i have to say... switches are *not* a security measure, period. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] "one should never trust a woman who tells her real age. if she tells that, she'll tell anything." -- oscar wilde pgpWiS72NUL0V.pgp Description: PGP signature
Re: A more secure form of .htaccess?
also sprach Dan Faerch <[EMAIL PROTECTED]> [2002.04.27.2120 +0200]: > > you know their algorithm against MAC table overflow? > No i dont.. I would be very interrested in reading about it, if you know of > a link.. Im sure that it would be possible to enforce some level of > security.. it's quite simple. i don't have a link. but these switches clear out their MAC tables LRU style at a rate indirectly proportional to the space left. so if you manage to half the space left by MAC flooding, they'll clean out the tables twice as fast. if you manage to half the remaining space, they'll clean out four times as fast. there's very little chance that a you can fill those tables and make it enter hub mode. > It is correct that you can get switches that, one way or another, will try > to enforce the switching mode and thus, not reentering hub-mode.. Also the > locking mechanism some switches use, that locks the MAC/IP pair to a single > port is quite good, but rather annoying to work with in most office > enviroments (because of laptops and so forth).. aside from the fact that you can still change you MAC address at will... but yes, these are good for static environments only, but they aren't a security measure. `ifconfig eth0 hw ether 00:11:22:33:44:55` is all i have to say... switches are *not* a security measure, period. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; net@madduck "one should never trust a woman who tells her real age. if she tells that, she'll tell anything." -- oscar wilde msg06516/pgp0.pgp Description: PGP signature
Re: A more secure form of .htaccess?
Gareth Bowker wrote: >If someone's already logged in, and they visit a webpage on the same domain >which asks for a username and password for the same realm as the one used to >log in, the browser will send the username/password pair without asking the >user for any confirmation. >At least I assume that's what Dan meant above and I assume that that would >happen (I haven't tried it myself). Yep... Thats what i meant... The browser will retransmit the username and password with every request while youre roaming the same realm.. All you'd have to do is make a page identify itself with the same realm-name and then log the username and password. Martin wrote (on the subject of switches): > you know their algorithm against MAC table overflow? No i dont.. I would be very interrested in reading about it, if you know of a link.. Im sure that it would be possible to enforce some level of security.. It is correct that you can get switches that, one way or another, will try to enforce the switching mode and thus, not reentering hub-mode.. Also the locking mechanism some switches use, that locks the MAC/IP pair to a single port is quite good, but rather annoying to work with in most office enviroments (because of laptops and so forth).. And most systemadministrators doesnt know how theese are enabled or simply never knew they existed. Theese security measures are therefore often not enabled or manually disabled for convenience. And then there is the matter of the price ;) - Dan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A more secure form of .htaccess?
Gareth Bowker wrote: >If someone's already logged in, and they visit a webpage on the same domain >which asks for a username and password for the same realm as the one used to >log in, the browser will send the username/password pair without asking the >user for any confirmation. >At least I assume that's what Dan meant above and I assume that that would >happen (I haven't tried it myself). Yep... Thats what i meant... The browser will retransmit the username and password with every request while youre roaming the same realm.. All you'd have to do is make a page identify itself with the same realm-name and then log the username and password. Martin wrote (on the subject of switches): > you know their algorithm against MAC table overflow? No i dont.. I would be very interrested in reading about it, if you know of a link.. Im sure that it would be possible to enforce some level of security.. It is correct that you can get switches that, one way or another, will try to enforce the switching mode and thus, not reentering hub-mode.. Also the locking mechanism some switches use, that locks the MAC/IP pair to a single port is quite good, but rather annoying to work with in most office enviroments (because of laptops and so forth).. And most systemadministrators doesnt know how theese are enabled or simply never knew they existed. Theese security measures are therefore often not enabled or manually disabled for convenience. And then there is the matter of the price ;) - Dan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: IPtables and Connection Tracking
also sprach vdongen <[EMAIL PROTECTED]> [2002.04.27.1812 +0200]: > > Does the connection tracking hold the connections even if the > > firewall > > was flushed? > > > > If it is so, is it a bug or a feature? > did you by chance forget to flush all tables and just flushed by doing > iptables -F ??? i have noticed behaviour like this before. on a machine doing PAT (masquerading), an /etc/init.d/iptables clear would not disrupt existing connections. that was kind of astonishing to see... can't say whether it's a bug or a feature, but it doesn't look very harmful... -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] scintillation is not always identification for an auric substance. pgpt4kKdKpRLO.pgp Description: PGP signature
Re: IPtables and Connection Tracking
> Does the connection tracking hold the connections even if the > firewall > was flushed? > > If it is so, is it a bug or a feature? did you by chance forget to flush all tables and just flushed by doing iptables -F ??? Gr, Ivo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: IPtables and Connection Tracking
also sprach vdongen <[EMAIL PROTECTED]> [2002.04.27.1812 +0200]: > > Does the connection tracking hold the connections even if the > > firewall > > was flushed? > > > > If it is so, is it a bug or a feature? > did you by chance forget to flush all tables and just flushed by doing > iptables -F ??? i have noticed behaviour like this before. on a machine doing PAT (masquerading), an /etc/init.d/iptables clear would not disrupt existing connections. that was kind of astonishing to see... can't say whether it's a bug or a feature, but it doesn't look very harmful... -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; net@madduck scintillation is not always identification for an auric substance. msg06514/pgp0.pgp Description: PGP signature
Re: IPtables and Connection Tracking
> Does the connection tracking hold the connections even if the > firewall > was flushed? > > If it is so, is it a bug or a feature? did you by chance forget to flush all tables and just flushed by doing iptables -F ??? Gr, Ivo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: connection refuse by tcp_wrapper - error message
hi ya On Thu, 25 Apr 2002, Marcin Bednarz wrote: > > but when i try to connect from 192.168.1.10 and 11 my server is allways > > give a message : > > ssh_exchange_identification: Connection closed by remote host i just ran into that same silly exact message turns out in our case... that the ip# listed in /etc/hosts.allow was wrong ... fixing the iP# allowed us to ssh in as usual c ya alvin > I think that it is SSH problem. > You probably have option > (If I correctly remember:) > StrictHostKeyChecking yes > > Then your ssh client want to have public key of host in directory > ~/.ssh/known_hosts or known_hosts2 (or sth like that) > > But if you haven't it it reply to you : > ssh_exchange_identification: Connection closed by remote host > ^^^ ^^^ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: connection refuse by tcp_wrapper - error message
hi ya On Thu, 25 Apr 2002, Marcin Bednarz wrote: > > but when i try to connect from 192.168.1.10 and 11 my server is allways > > give a message : > > ssh_exchange_identification: Connection closed by remote host i just ran into that same silly exact message turns out in our case... that the ip# listed in /etc/hosts.allow was wrong ... fixing the iP# allowed us to ssh in as usual c ya alvin > I think that it is SSH problem. > You probably have option > (If I correctly remember:) > StrictHostKeyChecking yes > > Then your ssh client want to have public key of host in directory > ~/.ssh/known_hosts or known_hosts2 (or sth like that) > > But if you haven't it it reply to you : > ssh_exchange_identification: Connection closed by remote host > ^^^ ^^^ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A more secure form of .htaccess?
Steve Mickeler wrote: > > Trust not in switches. > > They too can be easily manipulated unless you have locked them down at a > mac address and port level. > > 'apt-get install dsniff' ; 'man arpspoof' Of course, which is one of the things I had in mind when I said: > > topology. Switches tend not to allow other nodes on a network to see and: > > sniffed off the network. That is, of course, if the network was designed > > with that in mind. Dan Faerch wrote: > The subject on switches.. It is a general misunderstanding that switches > provide security.. There are several easy tricks to make a switch spill its > guts.. They were designed for performance and no one ever promised security > :) Cisco, in fact does promise security when using thier switches. Well, most of thier switches. But I do agree that they are designed with security as an other-than-primary goal. However, they can provide a layer of abstraction, to help prevent sniffing. wheee. -Will Wesley, CCNA "Cheer up! Things are getting worse at a slower rate." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A more secure form of .htaccess?
On Sat, Apr 27, 2002 at 03:32:45AM +0200, martin f krafft wrote: > also sprach Dan Faerch <[EMAIL PROTECTED]> [2002.04.26.1955 +0200]: > > Second more, if your users are allowed to have pages on the same > > address as the login system, the browser can, without much effort, > > be tricked into giving away your systems username and password to > > a personal user page... > > how? Take a look at http://www.php.net/manual/ro/features.http-auth.php If someone's already logged in, and they visit a webpage on the same domain which asks for a username and password for the same realm as the one used to log in, the browser will send the username/password pair without asking the user for any confirmation. At least I assume that's what Dan meant above and I assume that that would happen (I haven't tried it myself). Gareth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A more secure form of .htaccess?
Steve Mickeler wrote: > > Trust not in switches. > > They too can be easily manipulated unless you have locked them down at a > mac address and port level. > > 'apt-get install dsniff' ; 'man arpspoof' Of course, which is one of the things I had in mind when I said: > > topology. Switches tend not to allow other nodes on a network to see and: > > sniffed off the network. That is, of course, if the network was designed > > with that in mind. Dan Faerch wrote: > The subject on switches.. It is a general misunderstanding that switches > provide security.. There are several easy tricks to make a switch spill its > guts.. They were designed for performance and no one ever promised security > :) Cisco, in fact does promise security when using thier switches. Well, most of thier switches. But I do agree that they are designed with security as an other-than-primary goal. However, they can provide a layer of abstraction, to help prevent sniffing. wheee. -Will Wesley, CCNA "Cheer up! Things are getting worse at a slower rate." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A more secure form of .htaccess?
On Sat, Apr 27, 2002 at 03:32:45AM +0200, martin f krafft wrote: > also sprach Dan Faerch <[EMAIL PROTECTED]> [2002.04.26.1955 +0200]: > > Second more, if your users are allowed to have pages on the same > > address as the login system, the browser can, without much effort, > > be tricked into giving away your systems username and password to > > a personal user page... > > how? Take a look at http://www.php.net/manual/ro/features.http-auth.php If someone's already logged in, and they visit a webpage on the same domain which asks for a username and password for the same realm as the one used to log in, the browser will send the username/password pair without asking the user for any confirmation. At least I assume that's what Dan meant above and I assume that that would happen (I haven't tried it myself). Gareth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
