10:09 p.m.
would it not be a good idea to NOT disclosure service versions?
https://bugzilla.redhat.com/show_bug.cgi?id=718133
you will more and more have the "problem" of 3rd party
security scans to your servers and currently in the case
of openssh the only solution is to tkae the F16-src-rpm
and rebuild it for your F15 machines
_______________________
however - why do we spit the current running versions to everyone?
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SSH-2.0-OpenSSH_5.8
10:24 p.m.
On Sat, Jan 07, 2012 at 05:09:42 +0100,
Reindl Harald <h.reindl(a)thelounge.net> wrote:
however - why do we spit the current running versions to everyone?
It can help when trouble shooting problems. The current version isn't
really that helpful to attackers anyway. It's about as easy to just to try
an exploit as it is to first test to see if the exploit might work and
then try it.
9:15 p.m.
On Sat, Jan 7, 2012 at 5:24 AM, Bruno Wolff III <bruno(a)wolff.to> wrote:
On Sat, Jan 07, 2012 at 05:09:42 +0100,
Reindl Harald <h.reindl(a)thelounge.net> wrote:
>
> however - why do we spit the current running versions to everyone?
It can help when trouble shooting problems. The current version isn't
really that helpful to attackers anyway. It's about as easy to just to try
an exploit as it is to first test to see if the exploit might work and
then try it.
Actually, knowing the exact build/version can help select the right
exploit/payload so that the exploit succeeds on the first try (and
leaves no or very little evidence behind) instead of trying 10
different variangs and causing a large log/IDS signature. Hence, the
less specific the version information is, the better.
(Address randomization is often a larger obstacle than an unknown
build/version number, but address randomization only affects a certain
class of vulnerabilities.)
In the particular case of SSH, we are really dealing with a "protocol
identifier", not a "version number" and it needs to be treated as such
- ideally by the auditors as well.
Mirek
10:46 p.m.
Reindl Harald wrote:
would it not be a good idea to NOT disclosure service versions?
https://bugzilla.redhat.com/show_bug.cgi?id=718133
you will more and more have the "problem" of 3rd party
security scans to your servers and currently in the case
of openssh the only solution is to tkae the F16-src-rpm
and rebuild it for your F15 machines
If the scan is looking at the version to determine vulnerability, it is
completely broken, useless and unsupportable, because fixes can be
backported.
Kevin Kofler
11:13 p.m.
On 6 January 2012 21:46, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Reindl Harald wrote:
> would it not be a good idea to NOT disclosure service versions?
> https://bugzilla.redhat.com/show_bug.cgi?id=718133
>
> you will more and more have the "problem" of 3rd party
> security scans to your servers and currently in the case
> of openssh the only solution is to tkae the F16-src-rpm
> and rebuild it for your F15 machines
If the scan is looking at the version to determine vulnerability, it is
completely broken, useless and unsupportable, because fixes can be
backported.
I am going with Kevin on this one. The real hacking tools check to see
if a vulnerability works or not. The broken "audit" scanners only
check to see if a header is this or that. Not putting the header only
gets you past the auditors and doesn't stop the real hacker from
getting in if the vulnerability is there.
--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd
11:31 p.m.
Am 07.01.2012 06:13, schrieb Stephen John Smoogen:
On 6 January 2012 21:46, Kevin Kofler <kevin.kofler(a)chello.at>
wrote:
> Reindl Harald wrote:
>> would it not be a good idea to NOT disclosure service versions?
>> https://bugzilla.redhat.com/show_bug.cgi?id=718133
>>
>> you will more and more have the "problem" of 3rd party
>> security scans to your servers and currently in the case
>> of openssh the only solution is to tkae the F16-src-rpm
>> and rebuild it for your F15 machines
>
> If the scan is looking at the version to determine vulnerability, it is
> completely broken, useless and unsupportable, because fixes can be
> backported.
if you have a big customer which hires a 3rd party auditor
you are NOT in the poisiton to give such arguments or
you can give them but you can not change ANYTHING in
the fact that finally "fix it or shutdown the service"
is what you have to do
I am going with Kevin on this one. The real hacking tools check to
see
if a vulnerability works or not. The broken "audit" scanners only
check to see if a header is this or that. Not putting the header only
gets you past the auditors and doesn't stop the real hacker from
getting in if the vulnerability is there.
that is not the point
the point is why in the wolrd must we spit out versions?
yes, i know it is security by obscurity
but does it hurt?
if i need to know my version of sshd or any other service
i make a "rpm -qa | grep package", if somebody else likes
to know he has to tell the question as i have for foreign
servers
11:35 p.m.
On 01/07/2012 12:31 AM, Reindl Harald wrote:
Am 07.01.2012 06:13, schrieb Stephen John Smoogen:
> On 6 January 2012 21:46, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
>> Reindl Harald wrote:
>>> would it not be a good idea to NOT disclosure service versions?
>>> https://bugzilla.redhat.com/show_bug.cgi?id=718133
>>>
>>> you will more and more have the "problem" of 3rd party
>>> security scans to your servers and currently in the case
>>> of openssh the only solution is to tkae the F16-src-rpm
>>> and rebuild it for your F15 machines
>>
>> If the scan is looking at the version to determine vulnerability, it is
>> completely broken, useless and unsupportable, because fixes can be
>> backported.
if you have a big customer which hires a 3rd party auditor
you are NOT in the poisiton to give such arguments or
you can give them but you can not change ANYTHING in
the fact that finally "fix it or shutdown the service"
is what you have to do
If you have a "security expert" who can't grasp the concept of
back-ported bug fixes, and is unwilling to test for specific
vulnerabilities' existence, it's time to get a new expert.
> I am going with Kevin on this one. The real hacking tools check
to see
> if a vulnerability works or not. The broken "audit" scanners only
> check to see if a header is this or that. Not putting the header only
> gets you past the auditors and doesn't stop the real hacker from
> getting in if the vulnerability is there.
that is not the point
the point is why in the wolrd must we spit out versions?
yes, i know it is security by obscurity
but does it hurt?
if i need to know my version of sshd or any other service
i make a "rpm -qa | grep package", if somebody else likes
to know he has to tell the question as i have for foreign
servers
Connecting programs don't have the luxury of 'rpm -q', and must rely on
the version returned by the server to know how to pass data. Things
change over time, and you certainly can't expect a server to behave the
same over (sometimes long) periods of time.
--
Digimer
E-Mail: digimer(a)alteeve.com
Freenode handle: digimer
Papers and Projects: http://alteeve.com
Node Assassin: http://nodeassassin.org
"omg my singularity battery is dead again.
stupid hawking radiation." - epitron
12:02 a.m.
Am 07.01.2012 06:35, schrieb Digimer:
> if you have a big customer which hires a 3rd party auditor
> you are NOT in the poisiton to give such arguments or
> you can give them but you can not change ANYTHING in
> the fact that finally "fix it or shutdown the service"
> is what you have to do
If you have a "security expert" who can't grasp the concept of
back-ported bug fixes, and is unwilling to test for specific
vulnerabilities' existence, it's time to get a new expert.
you are missing the point A BIG CUSTOMER has a security-expert
> if i need to know my version of sshd or any other service
> i make a "rpm -qa | grep package", if somebody else likes
> to know he has to tell the question as i have for foreign
> servers
Connecting programs don't have the luxury of 'rpm -q', and must rely on
the version returned by the server to know how to pass data. Things
change over time, and you certainly can't expect a server to behave the
same over (sometimes long) periods of time.
connecting program rely on the PROTOCL version
currently: SSH-2.0-OpenSSH_5.8
but "SSH-2.0" si the only relevant part here!
for other services like imap, smtp and whatever there is also no
single need for a client to know even the server-software
the client only needs to know the capabilities of the server
and since you wrote "concept of back-ported bug fixes" you seem
to know that the server-software / version in this context is
nonsense
12:22 a.m.
On Fri, Jan 6, 2012 at 10:02 PM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
you are missing the point A BIG CUSTOMER has a security-expert
And you, as a trusted vendor, have an opportunity to educate your
customer about their security expert, and about how the Fedora project
works.
Fedora's stance is consistent with upstream:
http://www.openssh.org/faq.html#2.14
--
Ed Marshall <esm(a)logic.net>
Felix qui potuit rerum cognoscere causas.
http://esm.logic.net/
12:52 a.m.
On 01/07/2012 01:02 AM, Reindl Harald wrote:
Am 07.01.2012 06:35, schrieb Digimer:
>> if you have a big customer which hires a 3rd party auditor
>> you are NOT in the poisiton to give such arguments or
>> you can give them but you can not change ANYTHING in
>> the fact that finally "fix it or shutdown the service"
>> is what you have to do
>
> If you have a "security expert" who can't grasp the concept of
> back-ported bug fixes, and is unwilling to test for specific
> vulnerabilities' existence, it's time to get a new expert.
you are missing the point A BIG CUSTOMER has a security-expert
No, I'm not missing the point. You're asking for a wholesale change in
how a program works so that you can have an easier time with an
uneducated customer. Your job, as a consultant or IT support is not make
sure that your solution is safe. Making you customer feel comfortable
without actually given them security is a bad idea.
--
Digimer
E-Mail: digimer(a)alteeve.com
Freenode handle: digimer
Papers and Projects: http://alteeve.com
Node Assassin: http://nodeassassin.org
"omg my singularity battery is dead again.
stupid hawking radiation." - epitron
12:59 a.m.
Am 07.01.2012 07:52, schrieb Digimer:
On 01/07/2012 01:02 AM, Reindl Harald wrote:
> Am 07.01.2012 06:35, schrieb Digimer:
>>> if you have a big customer which hires a 3rd party auditor
>>> you are NOT in the poisiton to give such arguments or
>>> you can give them but you can not change ANYTHING in
>>> the fact that finally "fix it or shutdown the service"
>>> is what you have to do
>>
>> If you have a "security expert" who can't grasp the concept of
>> back-ported bug fixes, and is unwilling to test for specific
>> vulnerabilities' existence, it's time to get a new expert.
>
> you are missing the point A BIG CUSTOMER has a security-expert
No, I'm not missing the point. You're asking for a wholesale change in
how a program works so that you can have an easier time with an
uneducated customer. Your job, as a consultant or IT support is not make
sure that your solution is safe. Making you customer feel comfortable
without actually given them security is a bad idea.
i know about the pros and cons for obscurity
but i also know that from "SSH-2.0-OpenSSH_5.8" only "SSH-2.0"
is relevant for clients and having backports in mind this must
be the truth because if the whole version would matter all
LTS distributions would be broken by design
1:02 a.m.
On 01/07/2012 01:59 AM, Reindl Harald wrote:
Am 07.01.2012 07:52, schrieb Digimer:
> On 01/07/2012 01:02 AM, Reindl Harald wrote:
>> Am 07.01.2012 06:35, schrieb Digimer:
>>>> if you have a big customer which hires a 3rd party auditor
>>>> you are NOT in the poisiton to give such arguments or
>>>> you can give them but you can not change ANYTHING in
>>>> the fact that finally "fix it or shutdown the service"
>>>> is what you have to do
>>>
>>> If you have a "security expert" who can't grasp the concept of
>>> back-ported bug fixes, and is unwilling to test for specific
>>> vulnerabilities' existence, it's time to get a new expert.
>>
>> you are missing the point A BIG CUSTOMER has a security-expert
>
> No, I'm not missing the point. You're asking for a wholesale change in
> how a program works so that you can have an easier time with an
> uneducated customer. Your job, as a consultant or IT support is not make
> sure that your solution is safe. Making you customer feel comfortable
> without actually given them security is a bad idea.
i know about the pros and cons for obscurity
but i also know that from "SSH-2.0-OpenSSH_5.8" only "SSH-2.0"
is relevant for clients and having backports in mind this must
be the truth because if the whole version would matter all
LTS distributions would be broken by design
This doesn't change the fundamental point;
You are asking for a significant change in behaviour to a program that
who-knows-how-many apps use, for no real reason other than to make a
client feel better.
--
Digimer
E-Mail: digimer(a)alteeve.com
Freenode handle: digimer
Papers and Projects: http://alteeve.com
Node Assassin: http://nodeassassin.org
"omg my singularity battery is dead again.
stupid hawking radiation." - epitron
1:09 a.m.
Am 07.01.2012 08:02, schrieb Digimer:
> i know about the pros and cons for obscurity
>
> but i also know that from "SSH-2.0-OpenSSH_5.8" only "SSH-2.0"
> is relevant for clients and having backports in mind this must
> be the truth because if the whole version would matter all
> LTS distributions would be broken by design
This doesn't change the fundamental point;
You are asking for a significant change in behaviour to a program that
who-knows-how-many apps use, for no real reason other than to make a
client feel better.
no, one keys of security is to provide as less informations as
absolutely necessary, not only for sshd, for every single
service
in the best case no single foreign person has an idea
what software you are currently running, not what OS
nor what service-software and at least no exact version
1:49 a.m.
Once upon a time, Reindl Harald <h.reindl(a)thelounge.net> said:
no, one keys of security is to provide as less informations as
absolutely necessary, not only for sshd, for every single
service
That's a key for a false sense of security.
in the best case no single foreign person has an idea
what software you are currently running, not what OS
nor what service-software and at least no exact version
Then go ahead cut the power cord. Things such as TCP fingerprinting
will always work (because no two IP stacks are identical). Connecting
to a service will often be able to identify it because no two programs
implement standards the same way.
If you think you need that level of security, you need to run a full
application-level proxy in front of every server, and then watch it
break regularly (because they never get all the application filtering
correct). Then wait for the security holes in the proxy.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
8:44 a.m.
Reindl Harald writes:
Am 07.01.2012 08:02, schrieb Digimer:
>> i know about the pros and cons for obscurity
>>
>> but i also know that from "SSH-2.0-OpenSSH_5.8" only
"SSH-2.0"
>> is relevant for clients and having backports in mind this must
>> be the truth because if the whole version would matter all
>> LTS distributions would be broken by design
>
> This doesn't change the fundamental point;
>
> You are asking for a significant change in behaviour to a program that
> who-knows-how-many apps use, for no real reason other than to make a
> client feel better.
no, one keys of security is to provide as less informations as
absolutely necessary, not only for sshd, for every single
service
in the best case no single foreign person has an idea
what software you are currently running, not what OS
nor what service-software and at least no exact version
Ok, then why are you even running ssh on the default port?
8:55 a.m.
Am 07.01.2012 15:44, schrieb Sam Varshavchik:
> no, one keys of security is to provide as less informations as
> absolutely necessary, not only for sshd, for every single
> service
>
> in the best case no single foreign person has an idea
> what software you are currently running, not what OS
> nor what service-software and at least no exact version
Ok, then why are you even running ssh on the default port?
do i this?
no i do not!
so please do not make any assumptions out of the blue!
ssh is running on a hidden port, only accepting key-auth
and only accepting exactly 3 users for login and allows
only 30 connections per minute - said that about my
knowledge to setup a service properly
and that is why i am pissed of get "Medium" alerts only
because sshd is spiting out his version
and no it does not interest me if a 10 years old client
could have any problems - such old clients have to be
updated or deleted as soon as possible from security
point of view
i, and only i am responsible for the machines so why
do i not have a option only "SSH-2.0-OpenSSH" provide
to a anonymous client?
9:01 a.m.
On Sat, Jan 07, 2012 at 15:55:34 +0100,
Reindl Harald <h.reindl(a)thelounge.net> wrote:
i, and only i am responsible for the machines so why
do i not have a option only "SSH-2.0-OpenSSH" provide
to a anonymous client?
You do have that option. That's the nice thing about free software. You
can rebuild the rpm with a changed version string.
1:44 a.m.
Once upon a time, Reindl Harald <h.reindl(a)thelounge.net> said:
but i also know that from "SSH-2.0-OpenSSH_5.8" only
"SSH-2.0"
is relevant for clients
That's not actually true for SSH. The additional bits can be used to
work around known problems with specific versions.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
9:02 a.m.
Reindl Harald wrote:
but i also know that from "SSH-2.0-OpenSSH_5.8" only
"SSH-2.0"
is relevant for clients
"SSH-2.0" brings no information at all. ANY even remotely current SSH server
will report "SSH-2.0". That doesn't tell you anything about implementation-
specific behavior an SSH client may need to check.
Kevin Kofler
9:06 a.m.
Am 07.01.2012 16:02, schrieb Kevin Kofler:
Reindl Harald wrote:
> but i also know that from "SSH-2.0-OpenSSH_5.8" only "SSH-2.0"
> is relevant for clients
"SSH-2.0" brings no information at all. ANY even remotely current SSH server
will report "SSH-2.0". That doesn't tell you anything about
implementation-
specific behavior an SSH client may need to check
this argumentation is borked
what does this tell a client?
SSH-2.0-OpenSSH_4.3
nothing, it is a RHEL5, the client has no idea what
patches are included in this package and if they
maybe change any behavior cuased by a security fix
in the past
1:43 a.m.
Once upon a time, Reindl Harald <h.reindl(a)thelounge.net> said:
Am 07.01.2012 06:35, schrieb Digimer:
> If you have a "security expert" who can't grasp the concept of
> back-ported bug fixes, and is unwilling to test for specific
> vulnerabilities' existence, it's time to get a new expert.
you are missing the point A BIG CUSTOMER has a security-expert
Well, a big customer has a so-called or self-proclaimed security expert.
That is your opportunity to educate the customer and possibly gain some
security business for yourself.
Do you actually use Fedora for security-conscious big-buisness
customers? I use RHEL, and if they question versions from some external
scan, I quote Red Hat's backport policy. Any sane scan will reference
CVEs, and fixed CVEs are listed in the RPM changelogs (so I can quote
those to show security).
If you filter out versions, you're liable to get a security "report"
that lists every vulnerability in Apache, OpenSSH, sendmail/postfix/etc.
If you manage to filter out program names (not always possible), you'll
get a list of every CVE referencing the service listening on a port
("port 53 looks like it is running a DNS server; here's a list of things
that might be wrong").
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
8:43 a.m.
Reindl Harald writes:
Am 07.01.2012 06:35, schrieb Digimer:
>> if you have a big customer which hires a 3rd party auditor
>> you are NOT in the poisiton to give such arguments or
>> you can give them but you can not change ANYTHING in
>> the fact that finally "fix it or shutdown the service"
>> is what you have to do
>
> If you have a "security expert" who can't grasp the concept of
> back-ported bug fixes, and is unwilling to test for specific
> vulnerabilities' existence, it's time to get a new expert.
you are missing the point A BIG CUSTOMER has a security-expert
Tell your customer to ask for their money back. Offer to set up a test
server that their fustercluck of a scanner will claim to be vulnerable, yet
is not.
Or, better yet, tell your customer that you'll be happy to set up a server
that'll pass their nonsense of a scan, yet is vulnerable to some old exploit.
12:18 a.m.
On 6 January 2012 22:31, Reindl Harald <h.reindl(a)thelounge.net> wrote:
Am 07.01.2012 06:13, schrieb Stephen John Smoogen:
> On 6 January 2012 21:46, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
>> Reindl Harald wrote:
>>> would it not be a good idea to NOT disclosure service versions?
>>> https://bugzilla.redhat.com/show_bug.cgi?id=718133
>>>
>>> you will more and more have the "problem" of 3rd party
>>> security scans to your servers and currently in the case
>>> of openssh the only solution is to tkae the F16-src-rpm
>>> and rebuild it for your F15 machines
>>
>> If the scan is looking at the version to determine vulnerability, it is
>> completely broken, useless and unsupportable, because fixes can be
>> backported.
if you have a big customer which hires a 3rd party auditor
you are NOT in the poisiton to give such arguments or
you can give them but you can not change ANYTHING in
the fact that finally "fix it or shutdown the service"
is what you have to do
Yes, if you have a big customer that is the case. I have been on the
receiving end of that "shutdown the service". In the case you are
mentioning, turning off warnings will not "fix" the problem. Many
auditors will use a secondary set of tools on systems that have no
version and then will label such systems at fault for falsifying data.
> I am going with Kevin on this one. The real hacking tools check
to see
> if a vulnerability works or not. The broken "audit" scanners only
> check to see if a header is this or that. Not putting the header only
> gets you past the auditors and doesn't stop the real hacker from
> getting in if the vulnerability is there.
that is not the point
the point is why in the wolrd must we spit out versions?
Versions can be useful in everything from debugging to security
scanning. The difference is whether or not the auditor is going to do
a deep scan or not.
yes, i know it is security by obscurity
but does it hurt?
I have seen several breakins where the system administrator turned off
versions thinking that would protect him from breakins.
if i need to know my version of sshd or any other service
i make a "rpm -qa | grep package", if somebody else likes
to know he has to tell the question as i have for foreign
servers
The good auditing tools will make a best guess for a service using
either fingerprints or active vulnerability scans to figure out what
is running. Now in any case you have a customer who has an audit and
they need this fixed. What you need to do is find out what will fix it
for that customer without making it worse for them. If the audit rules
are they need to run the latest software, then they need to run the
latest software because it can cause larger problems if the audit
finds that the versions "lied to the auditors" what was run. [In some
audits this is not the case, but more seem to be going to this
method.] Other audits rules of engagement will want versions not to be
printed. In those cases a custom set of packages are usually required
if it is hard coded in the software.
--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd
8:40 a.m.
Reindl Harald wrote:
if you have a big customer which hires a 3rd party auditor
you are NOT in the poisiton to give such arguments or
you can give them but you can not change ANYTHING in
the fact that finally "fix it or shutdown the service"
is what you have to do
They need to fire the auditor who doesn't understand security at all.
if i need to know my version of sshd or any other service
i make a "rpm -qa | grep package", if somebody else likes
to know he has to tell the question as i have for foreign
servers
What's going to stop the auditor from running rpm -qa? (I assume a competent
auditor will request at least an unprivileged shell account to test for
local privilege escalation vulnerabilities.)
Kevin Kofler
8:49 a.m.
Am 07.01.2012 15:40, schrieb Kevin Kofler:
Reindl Harald wrote:
> if you have a big customer which hires a 3rd party auditor
> you are NOT in the poisiton to give such arguments or
> you can give them but you can not change ANYTHING in
> the fact that finally "fix it or shutdown the service"
> is what you have to do
They need to fire the auditor who doesn't understand security at all.
you know this, i know this
but things are not so easy :-)
> if i need to know my version of sshd or any other service
> i make a "rpm -qa | grep package", if somebody else likes
> to know he has to tell the question as i have for foreign
> servers
What's going to stop the auditor from running rpm -qa? (I assume a competent
auditor will request at least an unprivileged shell account to test for
local privilege escalation vulnerabilities.)
I AM going to stop
as long is i live nobody out there will get shell-access to
a machine serving also other customers and it has to be enough
exlduse mod_security for the scanner-ip while they initially
wanted 2 class-c nets exluded which will never happen
i know that they are incompetent becaue they are also classify
default "robots.txt" with any Disallow as "medium" and has to
be fixed - so yes they should be fired, but i can not make this
decision for a customer :-(
2:06 p.m.
On 01/06/2012 11:31 PM, Reindl Harald wrote:
yes, i know it is security by obscurity
but does it hurt?
Yes, it hurts.
It hurts every time we make life a little more difficult to satisfy
someone's misguided idea of "securitee". I refer you to the
Transportation Security Administration if you have any doubt of this.
(And I'm speaking as someone who has helped my customers fight the
automated security scan vs. backporting battle.)
--
========================================================================
Ian Pilcher arequipeno(a)gmail.com
"If you're going to shift my paradigm ... at least buy me dinner first."
========================================================================
2:46 p.m.
Am 08.01.2012 21:06, schrieb Ian Pilcher:
On 01/06/2012 11:31 PM, Reindl Harald wrote:
> yes, i know it is security by obscurity
> but does it hurt?
Yes, it hurts.
It hurts every time we make life a little more difficult to satisfy
someone's misguided idea of "securitee". I refer you to the
Transportation Security Administration if you have any doubt of this.
there are no misguided ideas
EVERY security specialist will tell you that you should never
disclose details, versions, configurations - NEVER if you
can avoid it
you need an example?
* disclose as defaults do OS, Apache-Version und PHP-Version
* what needs an attacker to do?
* receive ANY page, analyze the header
* after that he knows EXACTLY what exploits are working
if you do NOT disclose this informations he must try every
possible exploit - this will only happen if you diretly
targeted
but in the real world there are thousands of bots searching
for vulerable services 24 hours a day on the whole web
and if a signature matches someone is getting notified
if you are not aware of this fact i recommend you some
education in security!
SSH was here only an example
i meant GENERALLY how fedora/RHEL is dealing with defaults
_______________________
this is a worst-case example of a ubuntu-server and the
default footer if a directory-listing (only after authentication
but a software-source i know which i do not disclose here)
Apache/2.2.8 (Ubuntu) mod_jk/1.2.25 mod_python/3.3.1 Python/2.5.2 PHP/5.2.4-2ubuntu5.14
with Suhosin-Patch
mod_ssl/2.2.8 OpenSSL/0.9.8g mod_perl/2.0.3 Perl/v5.8.8 Server at **** Port 80
and such things are only happening if maintainers do not choose
defaults with care - if you are too late with a security update
or there is a known vulerability with no updates yet you are
blowing out that you are vulnerable which is the same as a
documentation how to get hacked!
4:16 p.m.
On 01/08/2012 01:46 PM, Reindl Harald wrote:
Am 08.01.2012 21:06, schrieb Ian Pilcher:
> On 01/06/2012 11:31 PM, Reindl Harald wrote:
>> yes, i know it is security by obscurity
>> but does it hurt?
>
> Yes, it hurts.
>
> It hurts every time we make life a little more difficult to satisfy
> someone's misguided idea of "securitee". I refer you to the
> Transportation Security Administration if you have any doubt of this.
there are no misguided ideas
EVERY security specialist will tell you that you should never
disclose details, versions, configurations - NEVER if you
can avoid it
you need an example?
* disclose as defaults do OS, Apache-Version und PHP-Version
* what needs an attacker to do?
* receive ANY page, analyze the header
* after that he knows EXACTLY what exploits are working
if you do NOT disclose this informations he must try every
possible exploit - this will only happen if you diretly
targeted
but in the real world there are thousands of bots searching
for vulerable services 24 hours a day on the whole web
and if a signature matches someone is getting notified
if you are not aware of this fact i recommend you some
education in security!
SSH was here only an example
i meant GENERALLY how fedora/RHEL is dealing with defaults
_______________________
this is a worst-case example of a ubuntu-server and the
default footer if a directory-listing (only after authentication
but a software-source i know which i do not disclose here)
Apache/2.2.8 (Ubuntu) mod_jk/1.2.25 mod_python/3.3.1 Python/2.5.2 PHP/5.2.4-2ubuntu5.14
with Suhosin-Patch
mod_ssl/2.2.8 OpenSSL/0.9.8g mod_perl/2.0.3 Perl/v5.8.8 Server at **** Port 80
and such things are only happening if maintainers do not choose
defaults with care - if you are too late with a security update
or there is a known vulerability with no updates yet you are
blowing out that you are vulnerable which is the same as a
documentation how to get hacked!
So from my logs. Not a probe first, just plain trying to get data using
a hopeful exploit. They don't care what version of anything I'm running.
/chronoPopup.php?PERIOD=../../../../../../../../../../etc/passwd%00 HTTP
Response 200
/chronoPopup.php?PERIOD=/etc/passwd HTTP Response 200
/chronoPopup.php?PERIOD=/../../../../../../../../../../proc/self/environ%00
HTTP Response 200
/chronoPopup.php?PERIOD=../../../../../../../../../../proc/self/environ
HTTP Response 200
/chronoPopup.php?PERIOD=../../../../../../../../../../etc/passwd
HTTP Response 200
/chronoPopup.php?PERIOD=/../../../../../../../../../../etc/passwd%00
HTTP Response 200
/chronoPopup.php?PERIOD=/../../../../../../../../../../etc/passwd
HTTP Response 200
I realize it looks like they got the files they wanted, but in reality
it ignored the request and sent the data it always does...
In any case, I still get tons of requests for Default.aspx, as well as a
whole host of requests for IIS vulnerabilities. Even though I run Linux
and Apache. Hiding the version changes nothing. The software doing all
this scanning simply *tries* to exploit, not find out exploitable
machines so it can tell some random human to then run a script against
it....
--
Nathanael d. Noblet
5:24 p.m.
Am 08.01.2012 23:16, schrieb Nathanael Noblet:
So from my logs. Not a probe first, just plain trying to get data
using a hopeful exploit. They don't care what
version of anything I'm running.
I realize it looks like they got the files they wanted, but in reality it ignored the
request and sent the data it
always does...
In any case, I still get tons of requests for Default.aspx, as well as a whole host of
requests for IIS
vulnerabilities. Even though I run Linux and Apache. Hiding the version changes nothing.
The software doing all
this scanning simply *tries* to exploit, not find out exploitable machines so it can tell
some random human to then
run a script against it....
and you think that some random examples prove anything?
some webserver logs are showing nothing about real exploits
there was and there will be exploits you will never see
in your webserver-log because if they worked CODE was
executed in the context of your webserver
fact is that nobody out there needs to know your software-version
for something useful and one of the most important rules in
server-administration disable and disclose ANYTHING which is not
explicit needed to prevent exploit-cases you can not imagine
while configure your machine
7:36 p.m.
On 01/08/2012 04:24 PM, Reindl Harald wrote:
and you think that some random examples prove anything?
some webserver logs are showing nothing about real exploits
there was and there will be exploits you will never see
in your webserver-log because if they worked CODE was
executed in the context of your webserver
fact is that nobody out there needs to know your software-version
for something useful and one of the most important rules in
server-administration disable and disclose ANYTHING which is not
explicit needed to prevent exploit-cases you can not imagine
while configure your machine
Umm aren't you saying precisely what everyone is saying?
"fact is that nobody out there needs to know your software-version for
something useful"
Which was the point of my weblog examples. I am aware that it means
nothing except someone tried something. The fact is people don't need
the software version to exploit. So displaying changes nothing. That
seems to be the point of this thread.
7:42 p.m.
Am 09.01.2012 02:36, schrieb Nathanael Noblet:
On 01/08/2012 04:24 PM, Reindl Harald wrote:
> and you think that some random examples prove anything?
> some webserver logs are showing nothing about real exploits
>
> there was and there will be exploits you will never see
> in your webserver-log because if they worked CODE was
> executed in the context of your webserver
>
> fact is that nobody out there needs to know your software-version
> for something useful and one of the most important rules in
> server-administration disable and disclose ANYTHING which is not
> explicit needed to prevent exploit-cases you can not imagine
> while configure your machine
Umm aren't you saying precisely what everyone is saying?
no, maybe you should read AND try to understand
"fact is that nobody out there needs to know your
software-version for something useful"
Which was the point of my weblog examples. I am aware that it means nothing except
if something is not needed for any useful things it should not disclosed
you are missing administration basics
So displaying changes nothing
it changes the fact that there are bots scanning 24 hours a day
for specific exploits and these individuals are NOT trying all possible
exploits all day long!
if a software-package, information, disclosure is NOT NEEDED it has
to be disabled - again: take some security education!
12:27 a.m.
On Sun, Jan 8, 2012 at 5:42 PM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
if a software-package, information, disclosure is NOT NEEDED it has
to be disabled - again: take some security education!
And, there we go.
Convince upstream to change their behavior (but, read their FAQ on
this exact question first, and try to understand why they've chosen
that stance), or convince the current openssh package maintainers why
they should patch the Fedora version of openssh in defiance of
upstream's wishes.
That will be much more productive than insisting that people who are
disagreeing with you in good faith are uneducated.
--
Ed Marshall <esm(a)logic.net>
Felix qui potuit rerum cognoscere causas.
http://esm.logic.net/
2:07 a.m.
Am 09.01.2012 07:27, schrieb Ed Marshall:
On Sun, Jan 8, 2012 at 5:42 PM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
> if a software-package, information, disclosure is NOT NEEDED it has
> to be disabled - again: take some security education!
And, there we go.
Convince upstream to change their behavior (but, read their FAQ on
this exact question first, and try to understand why they've chosen
that stance), or convince the current openssh package maintainers why
they should patch the Fedora version of openssh in defiance of
upstream's wishes.
would you please realize that sshd was only ONE sample
but well, so i will hestititate useful requests in the future and
continue rebuilding half of the distribution by my own to get rid
of nonsense like unsecure defaults, missing systemd-integration
and automatic restarts of services while packages are updated
That will be much more productive than insisting that people who are
disagreeing with you in good faith are uneducated
sorry, but if somebody does not realize that "ServerTokens OS" is
a unsecure httpd-default while every security-expert and most
documentations out there will tell you why this is the logical
conclusion and not insisting anyone
the only sense in "ServerTokens OS" is that you can see bad
administration with one look in the header - the problem is
that this information is enough for bad guys to look closer
on other services too
7:09 a.m.
On Mon, Jan 9, 2012 at 9:07 AM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
Am 09.01.2012 07:27, schrieb Ed Marshall:
> On Sun, Jan 8, 2012 at 5:42 PM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
>> if a software-package, information, disclosure is NOT NEEDED it has
>> to be disabled - again: take some security education!
>
> And, there we go.
>
> Convince upstream to change their behavior (but, read their FAQ on
> this exact question first, and try to understand why they've chosen
> that stance), or convince the current openssh package maintainers why
> they should patch the Fedora version of openssh in defiance of
> upstream's wishes.
would you please realize that sshd was only ONE sample
but well, so i will hestititate useful requests in the future and
continue rebuilding half of the distribution by my own to get rid
of nonsense like unsecure defaults
If not showing the version makes you fell more secure you are free to
do that it is free software after all. But just because it makes *you*
*fell* more secure does not mean that you gain any security by doing
so but well... that is no reason to change half of the distribution to
unnecessarily diverge from upstream.
8:08 a.m.
On Mon, Jan 09, 2012 at 02:42:10AM +0100, Reindl Harald wrote:
no, maybe you should read AND try to understand
This kind of behaviour isn't acceptable within the project. Treat your
fellow community members with respect. You're expected to follow the
Fedora Code of Conduct
(http://fedoraproject.org/wiki/Community_working_group/Code_of_Conduct)
while using project resources.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
10:03 a.m.
On 01/09/2012 09:08 AM, Matthew Garrett wrote:
On Mon, Jan 09, 2012 at 02:42:10AM +0100, Reindl Harald wrote:
> no, maybe you should read AND try to understand
This kind of behaviour isn't acceptable within the project. Treat your
fellow community members with respect. You're expected to follow the
Fedora Code of Conduct
(http://fedoraproject.org/wiki/Community_working_group/Code_of_Conduct)
while using project resources.
For the record, it was Ed Marshall <esm(a)logic.net> who wrote the quoted
sentence. In any case, I join Matthew in asking everyone to stay
excellent, and keep the discussion on topic and friendly in tone.
Regarding the merits of hiding the SSH version, in my opinion it's
counterproductive: the scanners might as well say "Oh, lookee here,
they're hiding the SSH version, presumably because they don't patch, so
let's try all the exploits".
If you do insist, how about
perl -i.bak -pe 's/OpenSSH_5.8/ClosedSSH_1/g' /usr/bin/sshd
Disclaimer: untested, fragile, contents may settle, do not iron while
wearing clothes.
11:03 a.m.
No, I most certainly did not write the quoted statement.
(My contribution has solely been suggesting that they get upstream on board; or, failing
that, find a convincing argument for the Fedora package maintainer to diverge from
upstream.)
--
Ed Marshall <esm(a)logic.net>
http://esm.logic.net/
On Jan 9, 2012, at 8:03 AM, Przemek Klosowski <przemek.klosowski(a)nist.gov> wrote:
On 01/09/2012 09:08 AM, Matthew Garrett wrote:
> On Mon, Jan 09, 2012 at 02:42:10AM +0100, Reindl Harald wrote:
>
>> no, maybe you should read AND try to understand
>
> This kind of behaviour isn't acceptable within the project. Treat your
> fellow community members with respect. You're expected to follow the
> Fedora Code of Conduct
> (http://fedoraproject.org/wiki/Community_working_group/Code_of_Conduct)
> while using project resources.
>
For the record, it was Ed Marshall <esm(a)logic.net> who wrote the quoted sentence.
In any case, I join Matthew in asking everyone to stay excellent, and keep the discussion
on topic and friendly in tone.
Regarding the merits of hiding the SSH version, in my opinion it's counterproductive:
the scanners might as well say "Oh, lookee here, they're hiding the SSH version,
presumably because they don't patch, so let's try all the exploits".
If you do insist, how about
perl -i.bak -pe 's/OpenSSH_5.8/ClosedSSH_1/g' /usr/bin/sshd
Disclaimer: untested, fragile, contents may settle, do not iron while wearing clothes.
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
12:42 p.m.
On Mon, Jan 09, 2012 at 11:03:43AM -0500, Przemek Klosowski wrote:
On 01/09/2012 09:08 AM, Matthew Garrett wrote:
>On Mon, Jan 09, 2012 at 02:42:10AM +0100, Reindl Harald wrote:
>
>>no, maybe you should read AND try to understand
>
>This kind of behaviour isn't acceptable within the project. Treat your
>fellow community members with respect. You're expected to follow the
>Fedora Code of Conduct
>(http://fedoraproject.org/wiki/Community_working_group/Code_of_Conduct)
>while using project resources.
>
For the record, it was Ed Marshall <esm(a)logic.net> who wrote the
quoted sentence.
Pretty sure it wasn't!
--
Matthew Garrett | mjg59(a)srcf.ucam.org
1:22 p.m.
On Mon, Jan 9, 2012 at 5:03 PM, Przemek Klosowski <
przemek.klosowski(a)nist.gov> wrote:
On 01/09/2012 09:08 AM, Matthew Garrett wrote:
> On Mon, Jan 09, 2012 at 02:42:10AM +0100, Reindl Harald wrote:
>
> no, maybe you should read AND try to understand
>>
>
> This kind of behaviour isn't acceptable within the project. Treat your
> fellow community members with respect. You're expected to follow the
> Fedora Code of Conduct
> (http://fedoraproject.org/**wiki/Community_working_group/**
>
Code_of_Conduct<http://fedoraproject.org/wiki/Community_working_group/...
> )
> while using project resources.
>
>
For the record, it was Ed Marshall <esm(a)logic.net> who wrote the quoted
sentence. In any case, I join Matthew in asking everyone to stay excellent,
and keep the discussion on topic and friendly in tone.
Regarding the merits of hiding the SSH version, in my opinion it's
counterproductive: the scanners might as well say "Oh, lookee here, they're
hiding the SSH version, presumably because they don't patch, so let's try
all the exploits".
Hiding the version number or servers type (http, ftp ecc) reduces the
possibility
of automated attacks (if you know which tool are mostly used
for fingerprint and how to do correctly anti-fingerprint) , which also are
part of the tools and methods used by the professional penetration
testersand ethical hacker, as i am - mostly ethical probably :=). In
the case of openssh the version number is part of the Protocol
http://www.ietf.org/rfc/rfc4253.txt (see par. 4.2), then deleting it could be
harmful. Of course there may be some false positives in the scanning phase
of a pen test (eg
http://www.nessus.org/plugins/index.php?view=single&id=11837).
But in general is it not true that this form of information hiding is not
useful at all.
For example mostly of the methodology used for penetration testing - such as
those of SANS 560 (and GIAC GPEN certification) just for an example - had
as goals of scanning phase something like :
........
determining which port are open, and we also want to verify which service
is listening and ..... the VERSION of the given application or
application-level protocol (..., HTTP, SSH)
.....
ecc.
I personally hide always the HTTP server type with something difficult to
learn from a advanced attacker, but it is not always possibile, sure.
I doubt that organizations such as SANS can be defined as non-qualified in
their field.
Just an other opinion.
Greetings
10:57 p.m.
On 01/06/2012 11:09 PM, Reindl Harald wrote:
would it not be a good idea to NOT disclosure service versions?
https://bugzilla.redhat.com/show_bug.cgi?id=718133
you will more and more have the "problem" of 3rd party
security scans to your servers and currently in the case
of openssh the only solution is to tkae the F16-src-rpm
and rebuild it for your F15 machines
_______________________
however - why do we spit the current running versions to everyone?
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SSH-2.0-OpenSSH_5.8
Security through obscurity...
--
Digimer
E-Mail: digimer(a)alteeve.com
Freenode handle: digimer
Papers and Projects: http://alteeve.com
Node Assassin: http://nodeassassin.org
"omg my singularity battery is dead again.
stupid hawking radiation." - epitron
1:52 a.m.
* Reindl Harald [07/01/2012 08:37] :
however - why do we spit the current running versions to everyone?
In the case of openssh, it's to allow the client to work around known bugs
in the server. In other cases, it's simply of case of not wanting to patch
gratuitously packages.
Emmanuel
4:53 a.m.
On Sat, 7 Jan 2012, Reindl Harald wrote:
would it not be a good idea to NOT disclosure service versions?
https://bugzilla.redhat.com/show_bug.cgi?id=718133
you will more and more have the "problem" of 3rd party
security scans to your servers and currently in the case
of openssh the only solution is to tkae the F16-src-rpm
and rebuild it for your F15 machines
_______________________
however - why do we spit the current running versions to everyone?
Spitting out versions makes your OWN network monitor easier, as you
can depend on version strings, instead of brute forcing unversioned
services to do a security scan/audit.
With or without versions, attackers will always brute force anyway.
Hiding therefor services no purpose other then make your own process of
inventory harder.
Paul
5:13 p.m.
New subject: service and user-agent disclosure - please consider privacy
Hi,
many of the different user agent and service banners are way too detailed
for my taste.
It sucks privacy wise - disclosing Fedora version, CPU, kernel version,
browser version and a few other details mindlessly included in many user
agent/service banners would in many cases allow near foolproof tracking
even without cookies or paypal/fb bugs.
Of course I can individually opt out of this brain damage, but what are the
options of a single individual - ?
* use fake Internet Explorer user agent identification: my browser will get
suboptimal and broken page content and I will "improve" MS market share,
not exactly my intention.
* use custom user agent string - usually achieves the opposite effect making
myself even easier trackable. That is, unless a large majority of Fedora
users will use the same standardized UA string I will be still very easilly
trackable.
* write my own browser or extension which rotates user agent strings smartly,
making sure it manages cookies and tcp/ip fingerprints consistently with rotating
user agent strings. Not the easiest thing - anyone knows an extension which
actually does that? At least reset TCP sequence number generation?
* run TOR for everything, make myself prime suspect and enjoy broken service
* more ideas??
Then consider how much easier it would be for Fedora and other distros to
limit information disclosure by user agents and service banners as default
or optional policy.
I would argue it should be default policy for desktops. Since most Linux
desktops will also run quite a few services those should have a privacy-aware
policy as well but as long as the policy is switchable it should not hurt.
It has a long tradition to proudly announce every detail of your soft & hardware
as well as familiar background and pets in user agent strings but for most users
is it not such a good thing to do today.
Richard
---
Name and OpenPGP keys available from pgp key servers
6:22 p.m.
New subject: service and user-agent disclosure - please consider privacy
Am 10.01.2012 00:13, schrieb Richard:
many of the different user agent and service banners are way
too detailed for my taste
thank you for supporting my opinion that a software should
per default disclose as less informations as possible
SAMBA is currently my hate candidate in a LAN
Nessus/OpenVAS can tell you the exact RPM version
nice if you have some bot-infected workstation in your
LAN to help searching vulnerabilities on other machines
8:24 a.m.
New subject: service and user-agent disclosure - please consider privacy
On Tue, Jan 10, 2012 at 1:22 AM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
Am 10.01.2012 00:13, schrieb Richard:
> many of the different user agent and service banners are way
> too detailed for my taste
thank you for supporting my opinion that a software should
per default disclose as less informations as possible
SAMBA is currently my hate candidate in a LAN
Nessus/OpenVAS can tell you the exact RPM version
nice if you have some bot-infected workstation in your
LAN to help searching vulnerabilities on other machines
Why is that a topic for fedora? I don't think, we should patch
programs and remove the versions printing everywhere. You are free to
discuss this with upstream and that's it (or do a foo-privacy fork of
course ;)).
It's more important to patch the vulnerabilities with security update
than simply hide them and hope your bot-infected workstation won't try
them.
Greetings,
Tom
3:50 p.m.
New subject: service and user-agent disclosure - please consider privacy
On Tue, Jan 10, 2012 at 03:24:14PM +0100, Thomas Spura wrote:
Why is that a topic for fedora? I don't think, we should patch
programs and remove the versions printing everywhere. You are free to
discuss this with upstream and that's it (or do a foo-privacy fork of
course ;)).
the privacy issue is a topic for Fedora because Fedora desktop users
have a substantial disadvantage compared to users of more frequently
used desktops. Intercepting a Fedora version string will in most
regions of the world identify a particular user.
A privacy fork will not help that - using a particular fork with some
dozens of users will make those users even easier trackable.
Richard
---
Name and OpenPGP keys available from pgp key servers
3:53 p.m.
New subject: service and user-agent disclosure - please consider privacy
On Tue 10 Jan 2012 22:50:53 CET, Richard wrote:
On Tue, Jan 10, 2012 at 03:24:14PM +0100, Thomas Spura wrote:
> Why is that a topic for fedora? I don't think, we should patch
> programs and remove the versions printing everywhere. You are free to
> discuss this with upstream and that's it (or do a foo-privacy fork of
> course ;)).
the privacy issue is a topic for Fedora because Fedora desktop users
have a substantial disadvantage compared to users of more frequently
used desktops. Intercepting a Fedora version string will in most
regions of the world identify a particular user.
A privacy fork will not help that - using a particular fork with some
dozens of users will make those users even easier trackable.
Richard
---
Name and OpenPGP keys available from pgp key servers
Fonts are a bigger threat to privacy, see here:
http://panopticlick.eff.org/
Privacy conscious users are able to install a user agent switching
extension.
4:09 p.m.
New subject: service and user-agent disclosure - please consider privacy
nodata (lsof(a)nodata.co.uk) said:
Fonts are a bigger threat to privacy, see here:
http://panopticlick.eff.org/
Privacy conscious users are able to install a user agent switching
extension.
... which (at least according to the referenced paper there) makes you
actually *more* trackable, in most cases.
Bill
5:43 a.m.
New subject: service and user-agent disclosure - please consider privacy
On Tue, Jan 10, 2012 at 10:53:52PM +0100, nodata wrote:
Fonts are a bigger threat to privacy, see here:
http://panopticlick.eff.org/
that apparently can be worked around at least partially with noscript but the user
agent string is insanely revealing (I do not even use lynx most of the time).
Even if I enable eff.org all of the javascript tests fail - with javascript
and cookies *enabled* I get this:
Browser Characteristic | bits of identifying information | one in x browsers have this
value
User Agent | 20.87+ | 1918455
HTTP_ACCEPT Headers | 3.79 | 13.8
Browser Plugin Details | 1.91 | 3.75 - no javascript
Time Zone | 1.9 | 3.73 - no javascript
Screen Size etc | 1.9 | 3.73 - no javascript
System Fonts | 1.9 | 3.73 - no javascript
Are Cookies Enabled? | 0.39 | 1.31 Yes
supercookie test | 1.9 | 3.73 - no javascript
It seems not surprising that eff.org visitors are paranoid so the javascript blocking
may be slightly more identifying than suggested by these numbers but still nowhere
close to the user agent. Btw I am pretty sure that the eff numbers are an underestimate,
I can not imagine anyone else in the world has the same user agent string like me
and there ought to be some more than 1918455 browsers worldwide.
Privacy conscious users are able to install a user agent switching
extension.
have one of those. How effective is that? Many users will pick some fake
browser id which is trivially detectable as fake. Each time I switch I must
also clear cookies and beware of referrer headers as an absolute minimum.
How many users are able to handle this?
Every little mistake makes you perfectly unique.
Also, do I as proud Fedora user really want to use a MS or some other fake user
agent string?
Compare how much better privacy protection we could get if the user agent did
reveal just "Fedora" and browser type for all Fedora users by default.
Does any Fedora user really *want* to advertise the exact defaults of his soft
and hardware to every visited website, does it ever help anyone except marketing
companies or criminals?
The browser is just one small part of the puzzle. For example my email program
is revealing, and my smtp server adds even more info to it.
Richard
---
Name and OpenPGP keys available from pgp key servers
8:21 a.m.
New subject: service and user-agent disclosure - please consider privacy
On 01/11/2012 12:43 PM, Richard wrote:
On Tue, Jan 10, 2012 at 10:53:52PM +0100, nodata wrote:
> Fonts are a bigger threat to privacy, see here:
> http://panopticlick.eff.org/
Maybe I am missing something, but isn't this only relevant if your IP is
not visible to the web server? Otherwise, you can trivially be tracked
by your IP address.
8:56 a.m.
New subject: service and user-agent disclosure - please consider privacy
Am 11.01.2012 15:21, schrieb Emanuel Rietveld:
On 01/11/2012 12:43 PM, Richard wrote:
> On Tue, Jan 10, 2012 at 10:53:52PM +0100, nodata wrote:
>
>> Fonts are a bigger threat to privacy, see here:
>> http://panopticlick.eff.org/
Maybe I am missing something, but isn't this only relevant if your IP is
not visible to the web server? Otherwise, you can trivially be tracked
by your IP address.
and since most people use mobile devices and/or have dynamic ip-addresses
or sometimes are in a big NAT-LAN in companies or in case of mobile
devices sharing the same gateway-ip with thousands of other random
customers maybe with some of them having also fedora -> you know
what i mean?
9:03 a.m.
New subject: service and user-agent disclosure - please consider privacy
On 01/11/2012 09:21 AM, Emanuel Rietveld wrote:
On 01/11/2012 12:43 PM, Richard wrote:
> On Tue, Jan 10, 2012 at 10:53:52PM +0100, nodata wrote:
>
>> Fonts are a bigger threat to privacy, see here:
>> http://panopticlick.eff.org/
Maybe I am missing something, but isn't this only relevant if your IP is
not visible to the web server? Otherwise, you can trivially be tracked
by your IP address.
You're probably missing something ... at least pre IP6 world ...
IP6 makes you more easily identifiable of course because there is no
NAT anymore and thus every machine is identifiable even if not routable.
Odd as it is, IP6 reduces privacy - it was not designed with privacy
in mind.
this scheme identifies you whether or not your IP changes and whether
or not there are multiple users behind same IP (imagine a household with
4 users, or a corporation with 5,000 users behind same IP) where NAT is
being used.
In any case it allows them to identify you - even if you're on a
laptop changing IP's all the time ...
9:11 a.m.
New subject: service and user-agent disclosure - please consider privacy
On Wed, Jan 11, 2012 at 10:03:39AM -0500, Genes MailLists wrote:
On 01/11/2012 09:21 AM, Emanuel Rietveld wrote:
> On 01/11/2012 12:43 PM, Richard wrote:
>> On Tue, Jan 10, 2012 at 10:53:52PM +0100, nodata wrote:
>>
>>> Fonts are a bigger threat to privacy, see here:
>>> http://panopticlick.eff.org/
>
> Maybe I am missing something, but isn't this only relevant if your IP is
> not visible to the web server? Otherwise, you can trivially be tracked
> by your IP address.
You're probably missing something ... at least pre IP6 world ...
IP6 makes you more easily identifiable of course because there is no
NAT anymore and thus every machine is identifiable even if not routable.
Odd as it is, IP6 reduces privacy - it was not designed with privacy
in mind.
http://ipv6int.net/systems/linux-ipv6.html#privacy
--
Tomasz Torcz "God, root, what's the difference?"
xmpp: zdzichubg(a)chrome.pl "God is more forgiving."
12:41 p.m.
New subject: service and user-agent disclosure - please consider privacy
On 01/11/2012 10:11 AM, Tomasz Torcz wrote:
On Wed, Jan 11, 2012 at 10:03:39AM -0500, Genes MailLists wrote:
> Odd as it is, IP6 reduces privacy - it was not designed with
privacy
> in mind.
http://ipv6int.net/systems/linux-ipv6.html#privacy
Good point thank you - indeed that helps IP6 not use the MAC address
as part of your IP6 address and is very useful - is it on by default now?
4:16 p.m.
New subject: service and user-agent disclosure - please consider privacy
On Tue, Jan 10, 2012 at 22:50:53 +0100,
Richard <rz(a)linux-m68k.org> wrote:
the privacy issue is a topic for Fedora because Fedora desktop users
have a substantial disadvantage compared to users of more frequently
used desktops. Intercepting a Fedora version string will in most
regions of the world identify a particular user.
If you are talking about a useragent header for your browser, that header
is an optional header according to the http standard. You can easily block
sending one in Firefox (in other browsers it may not be easy) by setting
general.useragent.override to the empty string.
There are other variant headers that can be used to identify users, such
as http_accept header.
The following has information on the amount of information in just
the useragent header:
https://www.eff.org/deeplinks/2010/01/tracking-by-user-agent
The following is a page that provides information on the uniqueness of
the browser you are using:
http://panopticlick.eff.org/index.php?action=log
4488
days inactive
4492
days old
55 comments
24 participants
participants (24)
-
Bill Nottingham -
Bruno Wolff III -
Chris Adams -
Digimer -
drago01 -
Ed Marshall -
Emanuel Rietveld -
Emmanuel Seyman -
Genes MailLists -
Ian Pilcher -
Kevin Kofler -
Matthew Garrett -
Miloslav Trmač -
Nathanael D. Noblet -
nodata -
Paul Wouters -
Przemek Klosowski -
Reindl Harald -
Richard Z -
Sam Varshavchik -
Stephen John Smoogen -
Thomas Spura -
Tomasz Torcz -
yersinia