Blocking version information

Sun Jun 19 17:54:50 UTC 2005

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vinny Abello wrote:
| At 01:38 AM 6/19/2005, Brad Knowles wrote:
|
|>At 12:34 AM -0400 2005-06-19, Vinny Abello wrote:
|
|
| Hi Brad. :)
|
|
|
|>>>         But if you don't know what version you're running, that makes
|>>>problem solving much more complex.
|>>
|>> Why wouldn't you know the version of BIND you setup?
|>
|>        Do you remember every single thing you've ever done in your
|>entire life?
|
|
| No, but I remember what I'm running on my servers that I'm in charge
| of. That's my job.
|
|
|>        Have you ever inherited a server that someone else set up?
|
|
| Yes, in which case I have access to it because I inherited it and can
| find out everything I want.
|
|
|>        Have you ever had a problem on another machine that you
|>don't normally administer, but the person who does is out of the
|>office so it's left up to you to try to fix?
|
|
| Can't say that I have. If they left it up to me I would assume I
| would have the ability to log into it in which case it's trivial to
| find out what is running on it.
|
|
|>        In many cases, the best kind of system documentation is
|>that which the system provides itself, and does not require the
|>admin to remember, know, write down, or update.  It just happens automatically.
|>
|>        Software version information is a good example of that type
|>of documentation.
|>
|>
|>> If they're reporting this to you, you already know the version running
|>> on the server in question.
|>
|>        Maybe.
|>
|>        More importantly, when others on this mailing
|>list/newsgroup are helping your customers debug their problems
|>while they're on-hold waiting for your helpdesk to answer the
|>phone, it is very useful for those people to be able to remotely
|>determine this information.
|
|
| Sure, that would help if they hadn't reported the version they are
| running already. If they know enough to hide that info and not give
| the versioning info to people that are trying to help them, then what
| do they expect?
|
|
|>> What's so hard about "named -v"?
|>
|>        That's assuming you have command-line access to the server
|>in question.  That's assuming that named hasn't been locked off so
|>that you have to have privileged access to that server, so that you
|>can run named at all.
|
|
| Yeah, if you're in charge of a machine and are troubleshooting a BIND
| problem I would hope you have access to it and BIND. Otherwise that
| would make it quite difficult. :)
|
|
|>> Why should someone without control of the DNS server need to know the
|>> version that's running? I just do see the reasoning. If they need to
|>> know that bad, they can contact the admin who can choose to disclose
|>> it or not.

I am running a resolver.

If a namserver keeps filling my logfile with lame server entries it is
my duty to stop it. Blocking is one way to do just that.

Interestingly enough I got rid of a whole lot of popups by blocking
the most annoying lame servers. My clients did not complain yet.

If you want to keep your system hidden, why do you publish it in the
first place?

A reasonable version identification may be what makes the difference
between a legal nameserver and a captured windows system trying to
poison my cache.

|>
|>        I guess you haven't been on this mailing list/newsgroup for
|>long. Whenever someone reports problems to this list/group and I
|>respond, one of the first questions I ask is "what version are you
|>using?" Most other old-timers on this list/group tend to do the
|>same sort of thing.
|
|
| Yes, I am aware of that which is why people are encouraged to tell
| what version they are running. Standard practice in asking for help
| here. I've been on this list for over 3 years now.
|
|
|>        If you're on the receiving end and in a panic trying to get
|>your DNS problems resolved and you can't tell what version you're
|>running, then you're unlikely to be able to get any further in
|>debugging the problems.
|
|
| Again, if you're trying to fix anything with BIND, you have command
| line access to the system and can run "named -v" if you don't already
| know it. If you don't have system access then how are you going to
| fix anything? The only thing I can think of is if you have limited
| access through some sort of NFS mount or file share... but if you're
| not supposed to have full access to the system, and the answer to
| your problem is upgrade, then you can't do anything anyway. This
| probably stems back to the issue of always having a staff member with
| full access to your servers available. Sure, not everyone can afford
| this but then again not everyone HAS to change the version number in
| BIND. I'm just saying that I like to and in our environment we've
| never had a problem with it.
|
|
|>        If your provider doesn't allow you to access this kind of
|>information, that's a good reason to consider going somewhere else.
|>Maybe not as bad has not doing reverse DNS for you or not doing
|>reverse DNS at all, but still pretty bad news.
|
|
| It is? If you want to know it that badly, ask them. If they're
| running BIND 4 and won't upgrade, THEN go somewhere else... you can
| always run BIND yourself as well.
|
|
|>        On the flip side, if you're a provider and you don't allow
|>your customers to access this information, now you know a good
|>reason why you may be losing them.
|
|
| These are the oddest statements I've heard. I've can't remember a
| customer even being interested in what version of BIND we are
| running. If they were, it probably would have been because they're
| setting up their own DNS server and wanted us to help them make
| decisions on what to use and how to configure it.
|
|
|
|>> Sure, that's different though... They should be reporting this
|>> information when asking for help. The server doesn't necessarily need
|>> to give this info up on it's own to everyone who is curious.
|>
|>        Maybe.  If you can know, a priori, precisely who should be
|>allowed to ask these questions and get answers to them, then you
|>can safely decide to block that information for everyone else.
|
|
| That's probably where the difference in opinion is happening here. I
| think the admins should know the version number. You think the
| customers should know as well.
|
|
|>> Sure, but if someone is skilled enough to fingerprint the name server,
|>> then they deserve to know what it's running.
|>
|>        So, your customers who pay you for service and are having a
|>problem don't deserve to know this information, but any black hat
|>who might want to try to break into your machines does?  Can you
|>explain that to me?
|
|
| If a customer is paying us for service, they have top notch support
| available to them which can properly diagnose the problem. They don't
| have to rely on finding out versions of software we're running and
| troubleshooting problems on their own. Again, we know what we run.
|
|
|>>                                               A casual utility or user
|>> won't be able to do that too easily. Apart from major version, I doubt
|>> you can finger print a release down to a point release. Feel free to
|>> prove me wrong. I'd be interested in how it works.
|>
|>        Try out fpdns.pl.  In many cases, it can get you down to a
|>specific point release.  It takes knowledge of the source code in
|>question, and how specific versions react differently to different
|>types of queries, but it does work.
|
|
| Doesn't seem that specific to me. It says my version is:
|
| BIND 9.2.3rc1 -- 9.4.0a0
|
| The major version of BIND 9 it discovered but nothing else really.
| Thanks for the tool though. It's interesting.
|
|
|>> Again, this is just my opinion and you are entitled to yours which I
|>> respect.
|>
|>        In this case, I'm stating a policy that I believe would be
|>good for others to follow, even if they don't necessarily know
|>why.  The kind of Best Current Practice that you might find in an
|>IETF RFC or other type of standards document, etc....
|
|
| Are you stating that disclosing the version of your DNS server is
| part of an RFC, either required or simply recommended? I don't
| believe it is but I don't read every RFC so I could be wrong.
|
|
|>        If people choose to ignore that recommendation, there's not
|>much I can do to help them.  But I can help to set that standard.
|
|
| Certainly. Do what you feel is correct and I will as well. I honestly
| don't care if others disclose this information on their servers. I
| just know I probably never will and was explaining why. Others can
| choose to follow my methodologies or yours (or anyone elses for that
| matter). It's up to them. I'm not trying to force my opinion on
| anyone, just explaining my reasoning.
|
| Vinny Abello
| Network Engineer
| Server Management
| vinny at tellurian.com
| (973)300-9211 x 125
| (973)940-6125 (Direct)
| PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0  E935 5325 FBCB 0100 977A
|
| Tellurian Networks - The Ultimate Internet Connection
| http://www.tellurian.com (888)TELLURIAN
|
| "Courage is resistance to fear, mastery of fear - not absence of
| fear" -- Mark Twain
|
|

Maybe I am a bit out of therad here but disclosing version information
is just the top of the iceberg.

Another nonsense is blocking axfr.

There are not many nameservers around that allow cloning. AXFR or even
tcp is blocked.

If you are running an authoritative server your server cannot get kashpureffed.

If you are running a resolver that caches even used horseshoes thrown at it
like some windows versions that even accecpt netbios packets for dns then it
wont take long to invite the phishermen into your company.

It wont take long until security sensitive companies will exchange zone files
volontaryly.

Regards,
Peter and Karin Dambier

- --
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-6252-599091 (O2 Genion)
+1-360-226-6583-9738 (INAIC)
mail: peter at peter-dambier.de
http://iason.site.voila.fr
http://www.kokoom.com/iason
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFCtbFmPGG/Vycj6zYRApIjAJ9SheDCxJs7LuEXRxRxh3UJTAtx4gCdHhrG
WGfspICd2lAURW9+u7dgDvI=
=EFpa
-----END PGP SIGNATURE-----