[gep2(_at_)terabites(_dot_)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(_dot_)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(_dot_)montreal(_dot_)qc(_dot_)ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg