[Asrg] Re: Asrg Digest, DNSBL BCP v.2.0
der Mouse
mouse at Rodents.Montreal.QC.CA
Fri Mar 2 19:56:36 EST 2007
[gep2 at terabites.com]
> Part of the problem is that it is a VERY blunt instrument, especially
> for companies which operate a large network from behind a NAT router.
This is true. That's a good reason to avoid putting mixed services
behind the same world-facing IP - whether with a NAT box, with multiple
daemons on a single host, or anything else.
> Not being able to issue credits, deliver invoices, and send price
> updates (and in the oil and gas business, prices change daily) is a
> monumental burden on a company which is guilty of nothing more than
> being a victim,
No; they are also guilty of setting themselves up to be victimized.
That they were running something Symantec *could* run on indicates that
they were putting themselves at risk.
A man who writes his PIN on his bank card bears at least some of the
blame if the card is stolen and abused. (Not all, but some.) A woman
who routinely leaves her ground-floor windows standing open bears some
(not all, but some) of the blame if her house is burglarized.
And a company that runs Windows bears at least some of the blame when
(note I don't say "if") they get infected with malware.
> Worse, from a Internet strategic standpoint, [this] will force more
> companies to insist on MORE DANGEROUS separate, routable IP addresses
> for each machine in their company.... so that blocking will affect
> JUST ONE of their machines and not put the whole company out of
> business.
What's wrong with just arranging to not get infected in the first place?
> Ultimately, this "solution" just puts dramatically more (and very
> unwanted) pressure on the limited IP address space,
...IPv6...IPv6...IPv6...
(Yes, it's limited too. The limit is so much higher, though, that in
practice I expect it to be at least another 25-50 years before it
starts to get uncomfortable - longer, if we can figure out how to route
in better ways, less related to connectivity topology.)
> and INCREASES the likelihood of getting the company's machines
> infected since now their machines each have a real, routable IP
> address that can be attacked by scanners and other exploits
> originating from outside the company.
And thereby increases the probability that they will actually get
*fixed* rather than just papered over. I have trouble seeing this as a
bad thing. (One of the very few bright sides I see in the current crop
of Windows malware is that it bringing evolutionary pressure against
Windows. This is an excellent example of why I hate monocultures.)
> [...] such an approach would [...] efficiently perform such triage on
> the messages coming from dear old Aunt Gertie's machine, allowing her
> legitimate mail to continue to be delivered while effectively
> guaranteeing that the spambot-generated garbage running on her same
> machine and transiting the same server(s) would be T-canned
...and thereby removing any incentive for anyone to even clean up the
infection, never mind cleaning up the principal reason the infection
happened in the first place. This is good?
["william(at)elan.net" <william at elan.net>]
>>> [...above-excerpted story...]
>> The main problem in this case is NATs, and the clueless consultants
>> who specify and deploy them. The solution is to not put critical
>> services behind them.
> You maybe forgetting clueless IT managers that force use of NAT as a
> policy in some organizations.
That's those organizations' problem. Cluelessness on *your* part does
not constitute an emergency on *my* part. (That's a generic "your",
not a personal one.) Companies that can't/don't find non-clueless IT
managers may go under as a result. This is a good thing.
> Plus such organizations need something done and and quickly and don't
> care if some consultant says they should not be using nat - the
> question asked, can you do it or not?
If you hire a consultant that way, you deserve everything you get.
Which, yes, may include going out of business. This is bad...why?
There are many pitfalls in running a business, many mistakes that can
kill the company. I don't see why you think this one should be
eliminated as a possibility.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
More information about the Asrg
mailing list