Re: Bug#130876: ssh: -5 discloses too much infomation to an attacker, security
On 10/02/02, Lazarus Long wrote: On Sat, Jan 26, 2002 at 12:25:08PM +, Matthew Vernon wrote: Lazarus Long writes: Introduces security hole by divulging too much information to an attacker about the underlying system. The rationale behind this, is that there are many instances where it is useful for a network admin to know whether the sshd on a particular machine is secure or not Of course it is useful, Matthew, but that admin can do so, safely *logged in to* the machine in question, with the 'dpkg -l ssh' command I mentioned above. There is no need to advertise any vulnerabilities to those *outside* the machine. So if you have more then 50 machines in your network to administrate which run debian, you will login into every machine typing always your passphrase or the password just to run dpkg -l ssh to find out which version of ssh is used on that machine? And ssh-agent is not a good solution here, because it might expose your passphrase or other important information. - in stable, our version of sshd gives out a version string identical to a very insecure upstream version, yet is patched. How is this in any way relevant? How shall an administrator from knowing just the version number of the sshd itself be sure that this machine runs a patched and therefor secure version of the client without having to use the procedure I described above? I reject the security-by-obscurity claim you make - attackers don't Again, security-by-obscurity (which you seem to be parroting from another misinformed individual in this thread) is properly used to refer to *source code* availability, for peer review within the crypto community, not the specifics of any given machine's implementation. No, I don't agree with you here. Security-by-obscurity doesn't only refer to those cases, but also to other problems. It's a common used term to describe a situation where one achieves security by witholding information. (I refer you to my comment about post your root password and IP address if you think obscurity is irrelevant.) And that helps you how much if the machine wants a passphrase or an otp-key? I will include a quote at the end of this message from an appropriate source, if this will help to further understanding. care what OS you're running often, they just try everything on the network. Furthermore, it is trivial [queso(8)] to find out what OS Running queso against four different machines here returns either the erroneous * Standard: Solaris 2.x, Linux 2.1.???, MacOS or else *- Not Listen, try another port. None of those machines run any of the operating systems queso reported. And when then don't you start reading either queso -h or man queso to find out how to use it? Besides, if version x of upstream has bug y, and Debian package x-n of upstream version x hasn't, then what do you care if someone tries the exploit on you? And what about the opposite scenario? Debian has very recently taken months to close a known security hole, without telling the end-users, And how many security holes have been fixed in a timely manner by Debian? Picking out one bad example is easy, but you need to look at in relation to the many security fixes that have been released much sooner. Unless you can produce a more convincing argument, I intend to close this bug. Since my own words seem to have been inadequate in the past, I'll paste here a fair-use excerpt from the most recent book from a widely-known and highly-regarded authority in the computer security (and crypto) field, whom I hope you will recognize. This excerpt is taken from p. 371f of Bruce Schneier's _Secrets and Lies, Digital Security in a Networked World_ (Wiley and Sons, 2000) One of the strengths an attacker has is knowledge of the terrain. Just as an army doesn't broadcast the location of its tanks, anti-aircraft missiles, and battalions to the enemy, there's no reason to broadcast your network topology to everyone that asks. Too many computers respond to any query with their operating system and version number; there's no reason to give out this information. Much better would be a login screen that reads: Warning: Proprietary Computer. Use of this system constitutes consent to security monitoring. All user activity is logged, including the hostname and IP address. Let the attackers wonder if you can trace them. ... An attacker shouldn't know what types of equipment are running where, what protocols are allowed under what conditions, what ports are open under what conditions. I am amazed by the number of servers, applications and protocols that announce themselves to the world: Hello! I am randomservice V2.05.Many hacking (sic) tools scan for particular versions of software running on particular machines ... known to have particular vulnerabilities. If networks
Re: Exim Relay
Markus Kolb wrote: Laurent Luyckx [EMAIL PROTECTED] wrote on 01/02/2002 (16:30) : In exim.conf, put hosts_accept_relay with a list of authorized IP. ex: hosts_accept_relay = localhost:192.168.0.0/24 ^^^ why this IP? To accept Mails from the localnet (LAN) and send them to the outside world (ISP SMTP) ? I don't use 192.168.0.x as my local net. Why not 192.168.0.0/16 ?? Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#130876: ssh: -5 discloses too much infomation to an attacker, security
retitle 130876 Sending server software version information should be optional severity 130876 wishlist quit I'll get back to you in more detail when I have time, but in the mean time - if you want to produce and maintain (since I'm damn sure upstream wouldn't want to know) a patch that creates a configuration option enabling the server to produce only the parts of the version string required by the RFC (which is in /usr/share/doc/ssh) and nothing more, I'm prepared to incorporate it. The default should be to display what the package *currently* does. call it -O 'SecurityByObscurity yes' or something. Matthew -- Rapun.sel - outermost outpost of the Pick Empire http://www.pick.ucam.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#130876: ssh: -5 discloses too much infomation to an attacker, security
Previously Matthew Vernon wrote: retitle 130876 Sending server software version information should be optional I'm not sure I agree with that: that easily leads to the configurable version response option that was discussed on openssh-dev recently where it was concluded that is not a good idea. Wichert. -- _ [EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#130876: ssh: -5 discloses too much infomation to an attacker, security
Wichert Akkerman writes: Previously Matthew Vernon wrote: retitle 130876 Sending server software version information should be optional I'm not sure I agree with that: that easily leads to the configurable version response option that was discussed on openssh-dev recently where it was concluded that is not a good idea. I'm not sure it's a good idea either. I suspect Lazarus won't accept the status quo, however. Matthew -- Rapun.sel - outermost outpost of the Pick Empire http://www.pick.ucam.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [suse-security] Emulate real ip's to access intranet hosts from outside
I'd like to access to the hosts of my intranet with private ip's from the outside. I have the following net: One or few weeks ago the same questions was up and the list concluded the discussion with the result, that this best way seems to be to ssh-portforwarding - that means, you'll use putty or such a tool to connect yourself to your firebox and the ssh-parameters will make the sshd forward all your paket with the private ip of your firebox. And the best ist - all is encrypted. IMPORTANT - there are some exploits for known vulnerabilities of older ssh-version - use the actual and ensure to force sshd to use protocol 2 (/etc/.ssh/sshd_config). And check your iptables-filter for allowed incoming/outgoing ssh-paket (port22/tcp) Just see the achieves of this list and watch 4 the VNC discussion a few weeks ago to learn more. Your Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: vtun
Am Son, 2002-02-10 um 04.50 schrieb Magus Ba'al: I'm not entirely positive, but I'm pretty sure you need to add the 2nd connection under tap1, as only one connection can be on tap0 at a time (in the server vtund.conf). You can also search thru the vtun archives, or do a search on google (vtun tap0 multiple client). ok, i have done this. But after i have done mknod /dev/tap1 c 36 16, i cant get the tap1 up. my debian say: no such device. what does it meen? HTH, Steven exitus acta probat fide, sed cui vide -Original Message- From: Thomas Kuepper [mailto:[EMAIL PROTECTED] Sent: Saturday, February 09, 2002 3:15 PM To: debian-security@lists.debian.org Subject: vtun Hi all. i have a problem with vtun. Is anybody here with knowgledge about vtun? i have one vtun server (type ether device tap0) in this server i have 2 connections added to the config file. my problem is, that only one client can connect. When one client has connectet, the other can't. how could this be? thx for help and sorry about my bad english. thomas -- 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: Bug#130876: ssh: -5 discloses too much infomation to an attacker, security
On 10/02/02, Lazarus Long wrote: On Sat, Jan 26, 2002 at 12:25:08PM +, Matthew Vernon wrote: Lazarus Long writes: Introduces security hole by divulging too much information to an attacker about the underlying system. The rationale behind this, is that there are many instances where it is useful for a network admin to know whether the sshd on a particular machine is secure or not Of course it is useful, Matthew, but that admin can do so, safely *logged in to* the machine in question, with the 'dpkg -l ssh' command I mentioned above. There is no need to advertise any vulnerabilities to those *outside* the machine. So if you have more then 50 machines in your network to administrate which run debian, you will login into every machine typing always your passphrase or the password just to run dpkg -l ssh to find out which version of ssh is used on that machine? And ssh-agent is not a good solution here, because it might expose your passphrase or other important information. - in stable, our version of sshd gives out a version string identical to a very insecure upstream version, yet is patched. How is this in any way relevant? How shall an administrator from knowing just the version number of the sshd itself be sure that this machine runs a patched and therefor secure version of the client without having to use the procedure I described above? I reject the security-by-obscurity claim you make - attackers don't Again, security-by-obscurity (which you seem to be parroting from another misinformed individual in this thread) is properly used to refer to *source code* availability, for peer review within the crypto community, not the specifics of any given machine's implementation. No, I don't agree with you here. Security-by-obscurity doesn't only refer to those cases, but also to other problems. It's a common used term to describe a situation where one achieves security by witholding information. (I refer you to my comment about post your root password and IP address if you think obscurity is irrelevant.) And that helps you how much if the machine wants a passphrase or an otp-key? I will include a quote at the end of this message from an appropriate source, if this will help to further understanding. care what OS you're running often, they just try everything on the network. Furthermore, it is trivial [queso(8)] to find out what OS Running queso against four different machines here returns either the erroneous * Standard: Solaris 2.x, Linux 2.1.???, MacOS or else *- Not Listen, try another port. None of those machines run any of the operating systems queso reported. And when then don't you start reading either queso -h or man queso to find out how to use it? Besides, if version x of upstream has bug y, and Debian package x-n of upstream version x hasn't, then what do you care if someone tries the exploit on you? And what about the opposite scenario? Debian has very recently taken months to close a known security hole, without telling the end-users, And how many security holes have been fixed in a timely manner by Debian? Picking out one bad example is easy, but you need to look at in relation to the many security fixes that have been released much sooner. Unless you can produce a more convincing argument, I intend to close this bug. Since my own words seem to have been inadequate in the past, I'll paste here a fair-use excerpt from the most recent book from a widely-known and highly-regarded authority in the computer security (and crypto) field, whom I hope you will recognize. This excerpt is taken from p. 371f of Bruce Schneier's _Secrets and Lies, Digital Security in a Networked World_ (Wiley and Sons, 2000) One of the strengths an attacker has is knowledge of the terrain. Just as an army doesn't broadcast the location of its tanks, anti-aircraft missiles, and battalions to the enemy, there's no reason to broadcast your network topology to everyone that asks. Too many computers respond to any query with their operating system and version number; there's no reason to give out this information. Much better would be a login screen that reads: Warning: Proprietary Computer. Use of this system constitutes consent to security monitoring. All user activity is logged, including the hostname and IP address. Let the attackers wonder if you can trace them. ... An attacker shouldn't know what types of equipment are running where, what protocols are allowed under what conditions, what ports are open under what conditions. I am amazed by the number of servers, applications and protocols that announce themselves to the world: Hello! I am randomservice V2.05.Many hacking (sic) tools scan for particular versions of software running on particular machines ... known to have particular vulnerabilities. If networks are
Re: Bug#130876: ssh: -5 discloses too much infomation to an attacker, security
Lazarus Long [EMAIL PROTECTED] writes: As I have said in the past, this is definitely a security risk. No, it isn't. The fact that the SSH protocol encourages implementors to exhibit version numbers has helped us greatly while recovering from the catastrophic buffer overflow bug. Of course it is useful, Matthew, but that admin can do so, safely *logged in to* the machine in question, with the 'dpkg -l ssh' command I mentioned above. There is no need to advertise any vulnerabilities to those *outside* the machine. But there is. Your local CERT might want to warn you that you are running a vulnerable implementation of a network service. We regularly disconnect Debian/timetravel systems because the version identification of a service suggests that they are still running a vulnerable version. That's tough luck for Debian users, but better be safe than sorry. -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898
Bug#130876: ssh: -5 discloses too much infomation to an attacker, security
retitle 130876 Sending server software version information should be optional severity 130876 wishlist quit I'll get back to you in more detail when I have time, but in the mean time - if you want to produce and maintain (since I'm damn sure upstream wouldn't want to know) a patch that creates a configuration option enabling the server to produce only the parts of the version string required by the RFC (which is in /usr/share/doc/ssh) and nothing more, I'm prepared to incorporate it. The default should be to display what the package *currently* does. call it -O 'SecurityByObscurity yes' or something. Matthew -- Rapun.sel - outermost outpost of the Pick Empire http://www.pick.ucam.org
Re: Bug#130876: ssh: -5 discloses too much infomation to an attacker, security
Previously Matthew Vernon wrote: retitle 130876 Sending server software version information should be optional I'm not sure I agree with that: that easily leads to the configurable version response option that was discussed on openssh-dev recently where it was concluded that is not a good idea. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#130876: ssh: -5 discloses too much infomation to an attacker, security
Wichert Akkerman writes: Previously Matthew Vernon wrote: retitle 130876 Sending server software version information should be optional I'm not sure I agree with that: that easily leads to the configurable version response option that was discussed on openssh-dev recently where it was concluded that is not a good idea. I'm not sure it's a good idea either. I suspect Lazarus won't accept the status quo, however. Matthew -- Rapun.sel - outermost outpost of the Pick Empire http://www.pick.ucam.org
Emulate real ip's to access intranet hosts from outside
Hi! I'd like to access to the hosts of my intranet with private ip's from the outside. I have the following net: A real domain name server managed by the computer which has the real ip, so I can set all the names and subdomains that I need. A firewall wich is the same host than the dns server I told before, I've got iptables in that host and it masquerades my intranet so the other hosts with private ip's use it as default gateway. I just want that when someone try to access to host1.mydomain.net from the internet my firewall (and dns server) forward the request to host1.local which has the private ip 192.168.1.20. I've looking for that in the DNS Howto's but haven't found a solution. I've been thinking of a mix between nat iptables and special dns resolving, may be with 2 name server's one for the intranet and the other one for the internet. But before starting I'd like to know if there is a sensible solution out there unknown by me. Thanks! Ramon Acedo
Re: Emulate real ip's to access intranet hosts from outside
* Ramon Acedo ([EMAIL PROTECTED]) [020210 14:43]: I just want that when someone try to access to host1.mydomain.net from the internet my firewall (and dns server) forward the request to host1.local which has the private ip 192.168.1.20. I've thought about this problem, but I don't think there's a clean solution for it on a general case. You may be able to get this working for specific services (like www, for instance) by using virtual hosting and proxying. The reason I don't think it will work in the general case is really caching. To make that clearer, let me explain how I thought the solution would have to be set up: All of the names would have to resolve to the external address. The nameserver would have to pay attention to who looked up what names and make sure that the kernel could recognize incoming connections from those folks as RELATED and DNAT them to the internal hosts. The reasons I don't think it will work: generally, a client will ask a nearby nameserver to resolve a name instead of doing it itself. This means that the initial request to your nameserver will come from the client's nameserver, not the client itself. Furthermore, this result could get cached so that other clients would never be seen by your nameserver. Also, you probably (hopefully) have secondary nameservers, so they'd have to somehow forward the information to your primary host. I think you'll see once you start to think about it some more that this way just really will not work. (Or maybe I've entirely misunderstood your question ;) Let me know if you come up with anything useful. If you decide to scope it down and want help with just an apache setup, I'm sure you can get help on the list. good times, Vineet -- Currently seeking opportunities in the SF Bay Area Please see http://www.doorstop.net/resume/ -- Satan laughs when we kill each other. Peace is the only way. pgpboLInPXbPZ.pgp Description: PGP signature
hosts deny, alow
I am new user debian linux, 1. i try to configure in hosts.deny : ALL:[EMAIL PROTECTED] and try in hosts.allow : ALL : 202.xxx.xxx.xx1, 202.xxx.xxx.xx2 But when i try from 202.xxx.xxx.xx1 and 202.xxx.xxx.xx2 the message is Connection closed by remote host. how to configure in close all and allow from that ip? 2. I try to close port 111 in services and give # on port sunrpc 111/tcp, and inetd but allways be open. Anybody could help me. Thanks. aku
