Re: Is NAT can provide some kind of protection?

[Merike Kaeo]

PCI DSS just came up with version 2 in October 2010 and one of the changes was:

"Removed specific references to IP masquerading and use of network address 
translation (NAT) technologies and added examples of methods for preventing 
private IP address disclosure."

- merike


On Jan 12, 2011, at 10:01 PM, Owen DeLong wrote:

> PCI DSS does not require it. It suggests it. It allows you to do other things
> which show equivalent security.
> 
> Also, the PCI DSS requirements for NAT are not on the web server, they
> are on the back-end processing machine which should NOT be the same
> machine that is talking to the customers. (I believe that's also part of the
> PCI DSS, but, I haven't read it recently).
> 
> PCI DSS is in desperate need of revision and does not incorporate
> current knowledge.
> 
> Owen
> 
> On Jan 12, 2011, at 9:02 PM, Justin Scott wrote:
> 
>> Unfortunately there are some sets of requirements which require this
>> type of configuration.  The PCI-DSS comes to mind for those who deal
>> with credit card transactions.
>> 
>> -Justin
>> 
>> On Wednesday, January 12, 2011, Dobbins, Roland  wrote:
>>> 
>>> On Mar 21, 2007, at 5:41 AM, Tarig Ahmed wrote:
>>> 
 Security guy told me is not correct to assign public ip to a server, it 
 should have private ip for security reasons.
>>> 
>>> He's wrong.
>>> 
 Is it true that NAT can provide more security?
>>> 
>>> 
>>> No, it makes things worse from an availability perspective.  Servers should 
>>> never be NATted or placed behind a stateful firewall.
>>> 
>>> ---
>>> Roland Dobbins  // 
>>> 
>>>Sell your computer and buy a guitar.
>>> 
>>> 
>>> 
>>> 
>>> 
> 
> 

Re: Is NAT can provide some kind of protection?

[Dave Pooser]

On 1/12/11 1:03 PM, "Owen DeLong"  wrote:

> NATing IPv6 doesn't do anything good. There's no benefit, only cost.

Except for making sure you can switch providers without renumbering, which
can be a significant benefit. (Yes, PI space accomplishes the same thing,
but that's harder to get for most SMBs.)
-- 
Dave Pooser, ACSA
Manager of Information Services
Alford Media  http://www.alfordmedia.com

RE: Is Cisco equpiment de facto for you?

[Scott Weeks]

--- brandon@brandontek.com wrote:
From: Brandon Kim 

To be fair to Cisco and maybe I'm way off here. But it seems they do come out 
with a way to do things first which then become a standard that
they have to follow.

ISL/DOT1Q
HSRP/VRRP
etherchannel/LACP



A bit of a late response, but 
http://en.wikipedia.org/wiki/Multiprotocol_Label_Switching#History 

scott

Re: Is NAT can provide some kind of protection?

[Owen DeLong]

PCI DSS does not require it. It suggests it. It allows you to do other things
which show equivalent security.

Also, the PCI DSS requirements for NAT are not on the web server, they
are on the back-end processing machine which should NOT be the same
machine that is talking to the customers. (I believe that's also part of the
PCI DSS, but, I haven't read it recently).

PCI DSS is in desperate need of revision and does not incorporate
current knowledge.

Owen

On Jan 12, 2011, at 9:02 PM, Justin Scott wrote:

> Unfortunately there are some sets of requirements which require this
> type of configuration.  The PCI-DSS comes to mind for those who deal
> with credit card transactions.
> 
> -Justin
> 
> On Wednesday, January 12, 2011, Dobbins, Roland  wrote:
>> 
>> On Mar 21, 2007, at 5:41 AM, Tarig Ahmed wrote:
>> 
>>> Security guy told me is not correct to assign public ip to a server, it 
>>> should have private ip for security reasons.
>> 
>> He's wrong.
>> 
>>> Is it true that NAT can provide more security?
>> 
>> 
>> No, it makes things worse from an availability perspective.  Servers should 
>> never be NATted or placed behind a stateful firewall.
>> 
>> ---
>> Roland Dobbins  // 
>> 
>> Sell your computer and buy a guitar.
>> 
>> 
>> 
>> 
>> 

Re: Is NAT can provide some kind of protection?

[Dobbins, Roland]

On Jan 13, 2011, at 12:02 AM, Justin Scott wrote:

>   The PCI-DSS comes to mind for those who deal with credit card transactions.

Luckily, there are ways to 'comply' with the PCI-DSS security theater regime 
without placing the availability and overall security of one's public-facing 
servers at risk, starting with mod_security.

;>

---
Roland Dobbins  // 

 Sell your computer and buy a guitar.

Re: IPv6 prefix lengths

[Cameron Byrne]

On Jan 12, 2011 7:50 PM, "Richard Barnes"  wrote:
>
> Hi all,
>
> What IPv6 prefix lengths are people accepting in BGP from
> peers/customers?  My employer just got a /48 allocation from ARIN, and
> we're trying to figure out how to support multiple end sites out of
> this (probably around 10).  I was thinking about assigning a /56 per
> site, but looking at the BGP table stats on potaroo.net [1], it looks
> like this is not too common (only .29% of prefixes).  Thoughts?
>

Is it possible you should be using PA space from your ISP? An ISP would have
no issue providing a /48 per site. Not too many details were given about
your requirements or circumstances ... PA may fit.

> Thanks,
> --Richard
>
>
> [1] 
>

Re: Is NAT can provide some kind of protection?

[Justin Scott]

Unfortunately there are some sets of requirements which require this
type of configuration.  The PCI-DSS comes to mind for those who deal
with credit card transactions.

-Justin

On Wednesday, January 12, 2011, Dobbins, Roland  wrote:
>
> On Mar 21, 2007, at 5:41 AM, Tarig Ahmed wrote:
>
>> Security guy told me is not correct to assign public ip to a server, it 
>> should have private ip for security reasons.
>
> He's wrong.
>
>> Is it true that NAT can provide more security?
>
>
> No, it makes things worse from an availability perspective.  Servers should 
> never be NATted or placed behind a stateful firewall.
>
> ---
> Roland Dobbins  // 
>
>              Sell your computer and buy a guitar.
>
>
>
>
>

Re: Is NAT can provide some kind of protection?

[Dobbins, Roland]

On Mar 21, 2007, at 5:41 AM, Tarig Ahmed wrote:

> Security guy told me is not correct to assign public ip to a server, it 
> should have private ip for security reasons.

He's wrong.

> Is it true that NAT can provide more security?


No, it makes things worse from an availability perspective.  Servers should 
never be NATted or placed behind a stateful firewall.

---
Roland Dobbins  // 

 Sell your computer and buy a guitar.

Re: IPv6 prefix lengths

[William Pitcock]

Hi,

On Wed, 12 Jan 2011 22:49:15 -0500
Richard Barnes  wrote:

> Hi all,
> 
> What IPv6 prefix lengths are people accepting in BGP from
> peers/customers?  My employer just got a /48 allocation from ARIN, and
> we're trying to figure out how to support multiple end sites out of
> this (probably around 10).  I was thinking about assigning a /56 per
> site, but looking at the BGP table stats on potaroo.net [1], it looks
> like this is not too common (only .29% of prefixes).  Thoughts?

Traditionally, /48s are per-site.  You should get a /48 for each site,
in reality something like a /44 will do nicely giving you two
additional /48 for growth.

William

Re: IPv6 prefix lengths

[Owen DeLong]

If you have to route them separately, your best bet is to go back to ARIN
under the Multiple Discreet Networks policy and get a block of /48s.

Tastes great, fewer problems.

Owen

On Jan 12, 2011, at 7:49 PM, Richard Barnes wrote:

> Hi all,
> 
> What IPv6 prefix lengths are people accepting in BGP from
> peers/customers?  My employer just got a /48 allocation from ARIN, and
> we're trying to figure out how to support multiple end sites out of
> this (probably around 10).  I was thinking about assigning a /56 per
> site, but looking at the BGP table stats on potaroo.net [1], it looks
> like this is not too common (only .29% of prefixes).  Thoughts?
> 
> Thanks,
> --Richard
> 
> 
> [1] 

Re: co-location and access to your server

[JC Dill]

 On 12/01/11 4:28 PM, Jeroen van Aart wrote:

George Bonser wrote:
Awesome.  It's good to know that there are still operations like that 
around.  That is probably found more often in local providers and not 
so often in the big operations.  The more community oriented 
providers would be much more accepting of such a situation than a 
large operation.


Community oriented provider, that's what I am talking about. I just 
couldn't find the right term.


but having someone "on call" probably isn't that bad if it is 
infrequently needed.


I'd be willing to pay extra for access after hours, either a recurring 
fee or on a case by case basis. I am not searching for the cheapest 
option and demanding that in addition my car be detailed weekly. But 
just some co-locating space for one or a few servers where I don't 
have to plan a week ahead or miss half a day of $dayjob in order to 
work on it (which would cost me more).


Scruz is ~30-45 minutes from the heart of the internet on the west coast 
(Silicon Valley).  If your $dayjob isn't in scruz, then it's most likely 
IN Silicon Valley.  So locate your 1U server in Silicon Valley, where 
there are a plethora of colos with varying costs and access options.  I 
suggest looking at layer42 - the last time I did a RFQ for a 1U server, 
they had the best price and most robust colo (providers and peering, 
adequate cooling, backup power, etc.) over other providers (offering 1U 
services) in the SF Bay Area.  Yes, if you have an outage at night you 
have a longer drive to the colo.  But it does no you good to locate your 
server in a "closer" colo if you can't access it at night anyway!


From the colo provider's perspective, 1U clients are the least 
profitable clients.  Setting them up and servicing them involves the 
most paperwork and communication "per dollar", and 1U clients tend to 
need more hand holding, ask stupid questions, etc. on average than 
bigger clients.  To further complicate matters, 1U clients tend to be 
VERY cost conscious, so they don't want to pay what it really costs the 
colo to provide service to a 1U client (factoring in the sales time 
cost, the customer service time cost, etc.).


jc

Re: IPv6 prefix lengths

[Randy Carpenter]

If you are going to have each site connected separately to the outside world, 
you will want a /48 for each site.

If you are going to aggregate them internally, you can use whatever you want, 
although you should be able to get a /48 for each site anyway.

You don't want to announce anything longer than a /48 to the outside world.

-Randy

--
| Randy Carpenter
| Vice President - IT Services
| Red Hat Certified Engineer
| First Network Group, Inc.
| (800)578-6381, Opt. 1


- Original Message -
> Hi all,
> 
> What IPv6 prefix lengths are people accepting in BGP from
> peers/customers? My employer just got a /48 allocation from ARIN, and
> we're trying to figure out how to support multiple end sites out of
> this (probably around 10). I was thinking about assigning a /56 per
> site, but looking at the BGP table stats on potaroo.net [1], it looks
> like this is not too common (only .29% of prefixes). Thoughts?
> 
> Thanks,
> --Richard
> 
> 
> [1] 

Re: IPv6 prefix lengths

[Mark Andrews]

In message <4d2e776f.2080...@kenweb.org>, ML writes:
> On 1/12/2011 10:49 PM, Richard Barnes wrote:
> > Hi all,
> >
> > What IPv6 prefix lengths are people accepting in BGP from
> > peers/customers?  My employer just got a /48 allocation from ARIN, and
> > we're trying to figure out how to support multiple end sites out of
> > this (probably around 10).  I was thinking about assigning a /56 per
> > site, but looking at the BGP table stats on potaroo.net [1], it looks
> > like this is not too common (only .29% of prefixes).  Thoughts?
> >
> > Thanks,
> > --Richard
> >
> >
> > [1]
> >
> 
> Are you talking about assigning /56s per POP, enterprise site?
> 
> If /56s are just in your iBGP..shouldn't be a problem.  You're going to 
> aggregate and just announce your /48 to your eBGP peers, yes??

If there are multiple indendent end sites then get a /48 for each of them.
A /48 is for a SITE not a ENTERPRISE.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: IPv6 prefix lengths

[ML]

On 1/12/2011 10:49 PM, Richard Barnes wrote:

Hi all,

What IPv6 prefix lengths are people accepting in BGP from
peers/customers?  My employer just got a /48 allocation from ARIN, and
we're trying to figure out how to support multiple end sites out of
this (probably around 10).  I was thinking about assigning a /56 per
site, but looking at the BGP table stats on potaroo.net [1], it looks
like this is not too common (only .29% of prefixes).  Thoughts?

Thanks,
--Richard


[1]



Are you talking about assigning /56s per POP, enterprise site?

If /56s are just in your iBGP..shouldn't be a problem.  You're going to 
aggregate and just announce your /48 to your eBGP peers, yes??

IPv6 prefix lengths

[Richard Barnes]

Hi all,

What IPv6 prefix lengths are people accepting in BGP from
peers/customers?  My employer just got a /48 allocation from ARIN, and
we're trying to figure out how to support multiple end sites out of
this (probably around 10).  I was thinking about assigning a /56 per
site, but looking at the BGP table stats on potaroo.net [1], it looks
like this is not too common (only .29% of prefixes).  Thoughts?

Thanks,
--Richard


[1] 

Re: Is NAT can provide some kind of protection?

[Owen DeLong]

On Jan 12, 2011, at 7:23 PM, David Barak wrote:

> I hesitate to venture into this thread, but while Owen is correct in the 
> general 
> case ("NAT qua NAT provides no more security than a stateful firewall"), 
> there 
> is a corner case in which security is improved via NAT.  The case is that of 
> an 
> enterprise network which uses 1918 addressing for all internal hosts, and 
> uses 
> proxies or other bastions as middleboxes to relay outbound communication.  
> 
> The security provided is that in the event of an accidental bridging of 
> "inside" 
> and "outside" networks (i.e. engineer plugged a cable between the wrong two 
> switches), the hosts will not be able to initiate communication with Internet 
> hosts.  Additionally, this same resiliency to accidental bridging does mean 
> that 
> the enterprise has a smaller number of possible Internet-facing machines, and 
> thus can spend the time and effort to make them more robust.
> 
> That benefit is not huge (and not relevant to the typical home user, who is 
> not 
> configuring a super-duper scanning proxy server), but it does exist, and it 
> certainly fuels some of the pro-NAT feeling I've encountered among customers.
> David Barak
> Need Geek Rock?  Try The Franchise: 
> http://www.listentothefranchise.com
> 
> 
> 

If you are proxying everything, then, there isn't any actual NAT. There are
inside sessions and outside sessions.

In that case, your security comes from the disconnected addresses and the
proxy that sits in the middle interfacing every outside session with its
related inside session.

No packet is forwarded from inside to outside with only the address and port
fields mangled. Each session is a separate and distinct interior and exterior
session. There is a state machine between the internal client and the proxy
server and a separate state machine between the external server and the
proxy client. Separate sets of sequence numbers, etc.

I am not denying that you may be able to get some additional isolation
by having network numbers that aren't routable on the outside world
if you don't have NAT. I'm saying that if you have NAT, it doesn't add
to your security.

Owen

Re: Is NAT can provide some kind of protection?

[David Barak]

I hesitate to venture into this thread, but while Owen is correct in the 
general 
case ("NAT qua NAT provides no more security than a stateful firewall"), there 
is a corner case in which security is improved via NAT.  The case is that of an 
enterprise network which uses 1918 addressing for all internal hosts, and uses 
proxies or other bastions as middleboxes to relay outbound communication.  

The security provided is that in the event of an accidental bridging of 
"inside" 
and "outside" networks (i.e. engineer plugged a cable between the wrong two 
switches), the hosts will not be able to initiate communication with Internet 
hosts.  Additionally, this same resiliency to accidental bridging does mean 
that 
the enterprise has a smaller number of possible Internet-facing machines, and 
thus can spend the time and effort to make them more robust.

That benefit is not huge (and not relevant to the typical home user, who is not 
configuring a super-duper scanning proxy server), but it does exist, and it 
certainly fuels some of the pro-NAT feeling I've encountered among customers.
 David Barak
Need Geek Rock?  Try The Franchise: 
http://www.listentothefranchise.com


  

nanog@nanog.org

[Michael Ruiz]

Hello all,

 

I am having very unusual problem with the CSM.  This is
what my problems.  I have my active CSM setup for a Fault Tolerance
group with a priority of 100 and an alternate of 30 and set to preempt.
Now for some reason I cannot get the standby configure to get the
configuration from the Active.  I did a debug and it appears the CSM on
the standby is deleting it's configuration and the active fails to sends
its configuration.  So I know the Active is talking across the VLAN I
have created for this purpose.  I can see the information coming up on
my debug from both ends.  Below is my configuration.  Any help on this
is appreciated.  Thank you in advance. 

 

DR01.SNATXDC1#  show module csm 8 ft detail 

FT group 2, vlan 45

This box is active

Configuration is out-of-sync

priority 100, heartbeat 1, failover 3, preemption is on

alternate priority 30

total buffer count 6214, illegal state transitions 0

receive buffers not committed 0, send buffers not committed 0

updates:  sent 4, received 0, committed 0

coup msgs:  sent 0, received 0

election msgs:  sent 0, received 2

heartbeat msgs:  sent 1057, received 594

relinquish msgs:  sent 0, received 0

conn replicate msgs: sent 462, received 0

conn refresh msgs: sent 462, received 0

conn reset msgs: sent 61, received 0

conn redundancy errors: msgs lost 0, msgs rejected 0

packets:  total received 0, total dropped 0, duplicates 0

   checksum failed 0, dumped 0, buffer unavailable 0

number of state updates in last 8 transfers:

0  0  0  0  0  0  0  0 

 Critical device and interface tracking:

 

 

DR01.SNATXDC1#

 

DR02.SNATXDC1#show module csm 8 ft detail 

FT group 2, vlan 45

This box is in standby state

Configuration is out-of-sync

priority 10, heartbeat 1, failover 3, preemption is off

total buffer count 6214, illegal state transitions 10

receive buffers not committed 0, send buffers not committed 0

updates:  sent 4, received 0, committed 0

coup msgs:  sent 0, received 0

election msgs:  sent 2, received 0

heartbeat msgs:  sent 0, received 984

relinquish msgs:  sent 0, received 0

conn replicate msgs: sent 0, received 0

conn refresh msgs: sent 0, received 0

conn reset msgs: sent 0, received 0

conn redundancy errors: msgs lost 0, msgs rejected 0

packets:  total received 5056012, total dropped 0, duplicates 0

   checksum failed 0, dumped 0, buffer unavailable 0

number of state updates in last 8 transfers:

0  0  0  0  0  0  0  0 

 Critical device and interface tracking:

 

 

DR02.SNATXDC1#

 

!

ft group 2 vlan 45 

  priority 100 alt 30

  preempt

 

 

 

DR02.SNATXDC1#show run module 8

Building configuration...

 

Current configuration : 5 bytes

end

 

DR02.SNATXDC1#

 

 

M.A.R

 

Re: Is NAT can provide some kind of protection?

[Owen DeLong]

On Jan 12, 2011, at 6:13 PM, William Herrin wrote:

> On Wed, Jan 12, 2011 at 12:16 PM,   wrote:
>> On Wed, 12 Jan 2011 12:04:01 EST, William Herrin said:
>>> In a client (rather than server) scenario, the picture is different.
>>> Depending on the specific "NAT" technology in use, the firewall may be
>>> incapable of selecting a target for unsolicited communications inbound
>>> from the public Internet. In fact, it may be theoretically impossible
>>> for it to do so. In those scenarios, the presence of NAT in the
>>> equation makes a large class of direct attacks on the interior host
>>> impractical, requiring the attacker to fall back on other methods like
>>> attempting to breach the firewall itself or indirectly polluting the
>>> responses to communication initiated by the internal host.
>> 
>> Note that the presence of a firewall with a 'default deny' rule for inbound
>> packets provides the same level of impracticality.
> 
> Hi Valdis,
> 
> There's actually a large difference between something that's
> impossible for a technology to do (even in theory), something that the
> technology has been programmed not to do and something that a
> technology is by default configured not to do.
> 
> The hacker can't make the equipment do something impossible. He can
> only go around it, try a different attack vector. To push through
> something the technology has been programmed not to do, he needs to
> identify a suitable bug: hard but not quite impractical. As for
> default configurations... human error is a *major* part of the
> security equation. Identifying and exploiting configuration errors is
> a hacker's fertile hunting ground.
> 
> 
NAT boxes without the ability to do port forwarding are few and far
between. Human error can poke a hole in a NAT as easily as in a
stateful firewall with a default deny.


> On Wed, Jan 12, 2011 at 2:35 PM, Owen DeLong  wrote:
>> On Jan 12, 2011, at 9:36 AM, Jack Bates wrote:
>>> As my corp IT guy put it to me, PAT forces a routing disconnect
>>> between internal and external. There is no way to reach the hosts
>>> without the firewall performing it's NAT function. Given that the
>>> internal is exclusively PAT, the DMZ is public with stateful/proxy,
>>> this provides protection for the internal network while limiting the
>>> dmz exposure.
>> 
>> The corp IT guy is delusional. The solution to the routing disconnect is
>> map+encap or tunnels.
> 
> Logical fallacy, ad hominem: the sanity of Jack's IT guy is not at issue.
> 
The logical fallacy is believing that NAT provides any protection.

> Logical fallacy, straw man: that a security technology failed to close
> attack vectors it was not claimed to have closed makes no statement as
> to whether the tech blocked the attack vectors it did claim to block.
> The only technology which stops all possible network attack vectors is
> the off switch.
> 
It claimed to provide routing isolation. That alleged isolation is easily
circumvented or even configured out of relevance by human error
or deliberately.

> Logical fallacy, circular reasoning: to bring your magic tunnels into
> existence, the firewall must have already been breached. Yet you claim
> the tunnels allow you to breach the firewall, allegedly proving that
> the PAT routing disconnect is a no-op.
> 
No, the firewall is presumably configured to intentionally allow access
by end users to web sites. Once you allow that, point-click-pwnm3
takes over.

> It took you only 17 words to get the trifecta. Congratulations, or something.
> 
Seriously, Bill... Just because you keep repeating the same sophistry
doesn't make it any more believable.

> 
> On Wed, Jan 12, 2011 at 2:09 PM, Owen DeLong  wrote:
>> No, NAT doesn't provide additional security. The stateful inspection that
>> NAT cannot operate without provides the security. Take away the
>> address mangling and the stateful inspection still provides the same
>> level of security.
> 
> When you'd care to offer a refutation of my explanation (above) of
> exactly how NAT impacts the security process beyond what the stateful
> inspection does, a refutation that doesn't involve a bunch of bald
> assertions, hand-waving and logical fallacies, you let me know.
> Perhaps the "security expert" you tell me you relied on when
> formulating your viewpoint could help you out with that?
> 
Logical fallacy -- Circular argument. Since you call any refutation I offer
"bald assertions" or "hand waving" when in reality they are behaviors
I have observed in the real world, I doubt we'll ever come to agreement
on this point.

Also, saying things like `the "security expert" you tell me you relied on'
come across as condescending. I have told you that I have discussed
the matter with multiple security experts on multiple occasions. The
fact that most of them have not given me permission to disclose their
contact details to you does not render them any less correct.

Finally, I've never told you that I relied on them in forming my viewpoint,
only

Re: Is NAT can provide some kind of protection?

[Mark Andrews]

In message , 
William
 Herrin writes:
> On Wed, Jan 12, 2011 at 12:16 PM,   wrote:
> > On Wed, 12 Jan 2011 12:04:01 EST, William Herrin said:
> >> In a client (rather than server) scenario, the picture is different.
> >> Depending on the specific "NAT" technology in use, the firewall may be
> >> incapable of selecting a target for unsolicited communications inbound
> >> from the public Internet. In fact, it may be theoretically impossible
> >> for it to do so. In those scenarios, the presence of NAT in the
> >> equation makes a large class of direct attacks on the interior host
> >> impractical, requiring the attacker to fall back on other methods like
> >> attempting to breach the firewall itself or indirectly polluting the
> >> responses to communication initiated by the internal host.
> >
> > Note that the presence of a firewall with a 'default deny' rule for inbou=
> nd
> > packets provides the same level of impracticality.
> 
> Hi Valdis,
> 
> There's actually a large difference between something that's
> impossible for a technology to do (even in theory), something that the
> technology has been programmed not to do and something that a
> technology is by default configured not to do.

Well ask the firewall vendor not to give you the knob to open it
up completely.

Note the CPE NAT boxes I've seen all have the ability to send
anything that isn't being NAT'd to a internal box so it isn't like
NAT boxes don't already have the flaw you are complaining about.
Usually it's labeled as DMZ host or something similar.

They also have the ability to send traffic for individual port to
particular boxes on the inside without it being initiated from the
inside.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Is NAT can provide some kind of protection?

[William Herrin]

On Wed, Jan 12, 2011 at 12:16 PM,   wrote:
> On Wed, 12 Jan 2011 12:04:01 EST, William Herrin said:
>> In a client (rather than server) scenario, the picture is different.
>> Depending on the specific "NAT" technology in use, the firewall may be
>> incapable of selecting a target for unsolicited communications inbound
>> from the public Internet. In fact, it may be theoretically impossible
>> for it to do so. In those scenarios, the presence of NAT in the
>> equation makes a large class of direct attacks on the interior host
>> impractical, requiring the attacker to fall back on other methods like
>> attempting to breach the firewall itself or indirectly polluting the
>> responses to communication initiated by the internal host.
>
> Note that the presence of a firewall with a 'default deny' rule for inbound
> packets provides the same level of impracticality.

Hi Valdis,

There's actually a large difference between something that's
impossible for a technology to do (even in theory), something that the
technology has been programmed not to do and something that a
technology is by default configured not to do.

The hacker can't make the equipment do something impossible. He can
only go around it, try a different attack vector. To push through
something the technology has been programmed not to do, he needs to
identify a suitable bug: hard but not quite impractical. As for
default configurations... human error is a *major* part of the
security equation. Identifying and exploiting configuration errors is
a hacker's fertile hunting ground.


On Wed, Jan 12, 2011 at 2:35 PM, Owen DeLong  wrote:
> On Jan 12, 2011, at 9:36 AM, Jack Bates wrote:
>> As my corp IT guy put it to me, PAT forces a routing disconnect
>> between internal and external. There is no way to reach the hosts
>> without the firewall performing it's NAT function. Given that the
>> internal is exclusively PAT, the DMZ is public with stateful/proxy,
>> this provides protection for the internal network while limiting the
>> dmz exposure.
>
> The corp IT guy is delusional. The solution to the routing disconnect is
> map+encap or tunnels.

Logical fallacy, ad hominem: the sanity of Jack's IT guy is not at issue.

Logical fallacy, straw man: that a security technology failed to close
attack vectors it was not claimed to have closed makes no statement as
to whether the tech blocked the attack vectors it did claim to block.
The only technology which stops all possible network attack vectors is
the off switch.

Logical fallacy, circular reasoning: to bring your magic tunnels into
existence, the firewall must have already been breached. Yet you claim
the tunnels allow you to breach the firewall, allegedly proving that
the PAT routing disconnect is a no-op.

It took you only 17 words to get the trifecta. Congratulations, or something.


On Wed, Jan 12, 2011 at 2:09 PM, Owen DeLong  wrote:
> No, NAT doesn't provide additional security. The stateful inspection that
> NAT cannot operate without provides the security. Take away the
> address mangling and the stateful inspection still provides the same
> level of security.

When you'd care to offer a refutation of my explanation (above) of
exactly how NAT impacts the security process beyond what the stateful
inspection does, a refutation that doesn't involve a bunch of bald
assertions, hand-waving and logical fallacies, you let me know.
Perhaps the "security expert" you tell me you relied on when
formulating your viewpoint could help you out with that?


On Wed, Jan 12, 2011 at 2:21 PM, Paul Ferguson  wrote:
> There is a least one situation where NAT *does* provide a small amount of
> necessary security.
>
> Try this at home, with/without NAT:
>
> 1. Buy a new PC with Windows installed
> 2. Install all security patches needed since the OS was installed
>
> Without NAT, you're unpatched PC will get infected in less than 1 minute.

Hi Paul,

That doesn't really prove your point. Owen is correct that any
reasonably configured firewall of any type would tend to prevent such
infections. The different firewall types don't begin to exhibit a
major difference in security effectiveness until you factor in the
impact of human error in specific scenarios.

Regards,
Bill Herrin

-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Routing Suggestions

[jim deleskie]

What Joe Said.

 Static with 1918 space.  If they NEED global space, explain 1918
space will work and tell them to use it.


-jim

On Wed, Jan 12, 2011 at 9:02 PM, Joe Hamelin  wrote:
>>> There are two companies, Company A and Company B, that are planning to
>>> continuously exchange a large amount of sensitive data and are located in a
>>> mutual datacenter. They decide to order a cross connect and peer privately
>>> for the obvious reasons.
>
> Second NIC on a secure server at "A" wired with a crossover cable to a
> second NIC a secure server at "B". Use an RFC1918 /30 that is null
> routed on both companies routers.
>
> KISS.  Hand it off to the developers.
>
> --
> Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474
>
>

Re: Routing Suggestions

[Adrian Chadd]

On Wed, Jan 12, 2011, Jon Lewis wrote:

> >Unless you'd like to ensure the sensitive traffic doesn't cross an
> >"unsafer" default rout path if the XC is down.
> 
> BGP would have that same issue since B is default routing to their 
> provider.
> 
> [config for B]
> ip route   
> ip route   null0 250
> ip route 0.0.0.0 0.0.0.0 
> 
> problem solved.  If the gw to A is reachable, traffic goes via the cross 
> connect.  If the gw is down, traffic goes nowhere.

I was just making the observation; the solution is pretty simple.
(Yes, I've seen "secure" network cross-connects get bitten by this. :-)



Adrian

-- 
- Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support -
- $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA -

Re: co-location and access to your server

[Patrick Giagnocavo]

On 1/12/2011 3:24 PM, Jeroen van Aart wrote:
> 
> What is considered normal with regards to access to your co-located
> server(s)? Especially when you're just co-locating one or a few servers.

Depends on how much you are paying really.  If you decide to go with
this provider, get dual power supplies, RAID, etc. on the server you
will be giving them.

You might want instead to look for another provider who offers decent
remote hands 24x7 who is in a major market - price should be about the
same.

--Patrick

Re: co-location and access to your server

[Kevin Stange]

On 01/12/2011 06:57 PM, Justin Scott wrote:
>> I was thinking that it was great just to find someone these days
>> that would accept a one-off server and that should be enough to
>> be thankful for!
> 
> Especially true with providers like SoftLayer which can turn up a
> fully dedicated server to spec at any of several locations within a
> few hours.  No hardware to manage or worrying about getting direct
> access at all.  They even give you the ability to cycle the outlet(s)
> the server is plugged into if needed.  Unless there is some really
> specialized hardware, location-specific or regulatory need, I couldn't
> imagine a desire to deal with putting my own single box at a co-lo
> anymore.  Of course, since you're leasing the box you pay a premium
> over a pure bare-bones co-lo, but it vastly simplifies things.

That's true.  Most dedicated server providers will get you remote power
outlet control and many can get you remote console (IPMI, DRAC) as an
included feature, so you can take care of almost all administration on
your own, including OS reinstalls and fscks.

There's still sometimes an edge in price and control when you use your
own hardware and that's definitely worth it for some.

-- 
Kevin Stange
Chief Technology Officer
Steadfast Networks
http://steadfast.net
Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867



signature.asc
Description: OpenPGP digital signature

Re: Routing Suggestions

[Joe Hamelin]

>> There are two companies, Company A and Company B, that are planning to
>> continuously exchange a large amount of sensitive data and are located in a
>> mutual datacenter. They decide to order a cross connect and peer privately
>> for the obvious reasons.

Second NIC on a secure server at "A" wired with a crossover cable to a
second NIC a secure server at "B". Use an RFC1918 /30 that is null
routed on both companies routers.

KISS.  Hand it off to the developers.

--
Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474

Re: Routing Suggestions

[Jon Lewis]

On Thu, 13 Jan 2011, Adrian Chadd wrote:


On Wed, Jan 12, 2011, Jon Lewis wrote:

On Wed, 12 Jan 2011, Jared Mauch wrote:


I suggest using one of the reserved/private BGP asns for this purpose.

ASNumber:   64512 - 65535


It sounds to me like Company B isn't doing BGP (probably has no experience
with it) and if there's only a single prefix per side of the cross
connect, especially if the cross connect is going into routers smart
enough to remove a route from the table if the destination interface is
down, static would do just fine.


Unless you'd like to ensure the sensitive traffic doesn't cross an
"unsafer" default rout path if the XC is down.


BGP would have that same issue since B is default routing to their 
provider.


[config for B]
ip route   
ip route   null0 250
ip route 0.0.0.0 0.0.0.0 

problem solved.  If the gw to A is reachable, traffic goes via the cross 
connect.  If the gw is down, traffic goes nowhere.


--
 Jon Lewis, MCP :)   |  I route
 Senior Network Engineer |  therefore you are
 Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: co-location and access to your server

[Justin Scott]

> I was thinking that it was great just to find someone these days
> that would accept a one-off server and that should be enough to
> be thankful for!

Especially true with providers like SoftLayer which can turn up a
fully dedicated server to spec at any of several locations within a
few hours.  No hardware to manage or worrying about getting direct
access at all.  They even give you the ability to cycle the outlet(s)
the server is plugged into if needed.  Unless there is some really
specialized hardware, location-specific or regulatory need, I couldn't
imagine a desire to deal with putting my own single box at a co-lo
anymore.  Of course, since you're leasing the box you pay a premium
over a pure bare-bones co-lo, but it vastly simplifies things.


-Justin Scott

Re: Routing Suggestions

[Joe Provo]

On Wed, Jan 12, 2011 at 07:13:53PM -0500, Lars Carter wrote:
[snip]
> There are two companies, Company A and Company B, that are planning to
> continuously exchange a large amount of sensitive data and are located in a
> mutual datacenter. They decide to order a cross connect and peer privately
> for the obvious reasons. Company A has a small but knowledgable engineering
> staff and it's network is running BGP as its only routing protocol with
> multiple transit vendors and a handful of other larger peers. Company B is a
> smaller shop that is single homed behind one ISP through a default static
> route, they have hardware that can handle advanced routing protocols but
> have not had the need to implement them as of yet. There is a single prefix
> on both sides that will need to be routed to the other party. It is rare
> that prefixes would need to change or for additional prefixes to be added.
> 
> 
> From an technical, operational, and security standpoint what would be the
> preferred way to route traffic between these two networks?

Use eBGP. Company B runs a mutually-agreed private ASN (at least from 
company A's unused list).  This scales from the initial deployment to 
multiple cross-connects for failover [or even IPSEC tunnel over public 
interfaces].  Company B should have Company A provide some clues to 
their staff if needed (and get more out of the deal).

"Simple" static solutions wind up being entrenched, so move/add/change 
becomes convoluted.  And how many times has one prefix really stayed 
that way? :-)


-- 
 RSUC / GweepNet / Spunk / FnB / Usenix / SAGE

Re: Routing Suggestions

[Daniel Roesen]

On Wed, Jan 12, 2011 at 07:13:53PM -0500, Lars Carter wrote:
> From an technical, operational, and security standpoint what would be the
> preferred way to route traffic between these two networks?

Static routing - at least "on" the direct link. For extra "security", you
might want to make sure that the sensitive traffic won't take the internet
path, but only the directconnection.

Example: 192.168.0.0/24 being the prefix in question. Drop traffic for that
/24 via a static Null0 (IOS et al) / discard or reject (JUNOS) route. Then
add /25 statics for 192.168.0.0/25 and .128/25 via the direct link. On the
BGP speaking network, make sure you don't accept 192.168.0.0/24 or more
specifics of that via BGP from untrusted parties.

In case the link goes down, the /25s should become inactive, and the /24
Null/discard/reject route prevents leakage of sensitive data in unintended
(untrusted) directions (e.g. Internet) via default or covering aggregate
routes.

Of course all this assumes "no dynamic redundancy" etc. and some other
things not further specified in your scenario. There are many ways to
skin a cat.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: d...@cluenet.de -- d...@ircnet -- PGP: 0xA85C8AA0

Re: Routing Suggestions

[james]

Since it sounds like there is no alternate path, it sounds like the most 
secure, simplest to operate would be static routes.  It's not sexy, but no need 
to toss in a routing protocol if it's such a static setup.

--Original Message--
From: Lars Carter
To: NANOG@NANOG.org
Subject: Routing Suggestions
Sent: Jan 12, 2011 7:13 PM

Hi NANOG list,

I have a simple, hypothetical question regarding preferred connectivity
methods for you guys that I would like to get the hive mind opinion about.


There are two companies, Company A and Company B, that are planning to
continuously exchange a large amount of sensitive data and are located in a
mutual datacenter. They decide to order a cross connect and peer privately
for the obvious reasons. Company A has a small but knowledgable engineering
staff and it's network is running BGP as its only routing protocol with
multiple transit vendors and a handful of other larger peers. Company B is a
smaller shop that is single homed behind one ISP through a default static
route, they have hardware that can handle advanced routing protocols but
have not had the need to implement them as of yet. There is a single prefix
on both sides that will need to be routed to the other party. It is rare
that prefixes would need to change or for additional prefixes to be added.


>From an technical, operational, and security standpoint what would be the
preferred way to route traffic between these two networks?


Cheers,

Lars


Sent from my “contract free” BlackBerry® smartphone on the WIND network.

Re: co-location and access to your server

[Jeroen van Aart]

George Bonser wrote:

Awesome.  It's good to know that there are still operations like that around.  
That is probably found more often in local providers and not so often in the 
big operations.  The more community oriented providers would be much more 
accepting of such a situation than a large operation.


Community oriented provider, that's what I am talking about. I just 
couldn't find the right term.



but having someone "on call" probably isn't that bad if it is infrequently 
needed.


I'd be willing to pay extra for access after hours, either a recurring 
fee or on a case by case basis. I am not searching for the cheapest 
option and demanding that in addition my car be detailed weekly. But 
just some co-locating space for one or a few servers where I don't have 
to plan a week ahead or miss half a day of $dayjob in order to work on 
it (which would cost me more).


Greetings,
Jeroen

--
http://goldmark.org/jeff/stupid-disclaimers/
http://linuxmafia.com/~rick/faq/plural-of-virus.html

Re: Routing Suggestions

[Adrian Chadd]

On Wed, Jan 12, 2011, Jon Lewis wrote:
> On Wed, 12 Jan 2011, Jared Mauch wrote:
> 
> >I suggest using one of the reserved/private BGP asns for this purpose.
> >
> >ASNumber:   64512 - 65535
> 
> It sounds to me like Company B isn't doing BGP (probably has no experience 
> with it) and if there's only a single prefix per side of the cross 
> connect, especially if the cross connect is going into routers smart 
> enough to remove a route from the table if the destination interface is 
> down, static would do just fine.

Unless you'd like to ensure the sensitive traffic doesn't cross an
"unsafer" default rout path if the XC is down.

(Assuming the prefixes are both public IPv4/6 space to begin with.)


Adrian

-- 
- Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support -
- $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA -

Re: Routing Suggestions

[Roy]

On 1/12/2011 4:13 PM, Lars Carter wrote:

Hi NANOG list,

I have a simple, hypothetical question regarding preferred connectivity
methods for you guys that I would like to get the hive mind opinion about.


There are two companies, Company A and Company B, that are planning to
continuously exchange a large amount of sensitive data and are located in a
mutual datacenter. They decide to order a cross connect and peer privately
for the obvious reasons. Company A has a small but knowledgable engineering
staff and it's network is running BGP as its only routing protocol with
multiple transit vendors and a handful of other larger peers. Company B is a
smaller shop that is single homed behind one ISP through a default static
route, they have hardware that can handle advanced routing protocols but
have not had the need to implement them as of yet. There is a single prefix
on both sides that will need to be routed to the other party. It is rare
that prefixes would need to change or for additional prefixes to be added.


> From an technical, operational, and security standpoint what would be the
preferred way to route traffic between these two networks?


Cheers,

Lars



Apply the KISS principle.  Use a static route

Re: Routing Suggestions

[Jon Lewis]

On Wed, 12 Jan 2011, Jared Mauch wrote:


I suggest using one of the reserved/private BGP asns for this purpose.

ASNumber:   64512 - 65535


It sounds to me like Company B isn't doing BGP (probably has no experience 
with it) and if there's only a single prefix per side of the cross 
connect, especially if the cross connect is going into routers smart 
enough to remove a route from the table if the destination interface is 
down, static would do just fine.


--
 Jon Lewis, MCP :)   |  I route
 Senior Network Engineer |  therefore you are
 Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Routing Suggestions

[Jared Mauch]

On Jan 12, 2011, at 7:13 PM, Lars Carter wrote:

> Hi NANOG list,
> 
> I have a simple, hypothetical question regarding preferred connectivity
> methods for you guys that I would like to get the hive mind opinion about.
> 
> 
> There are two companies, Company A and Company B ... [ trimmed, but they want 
> to interconnect directly, one does static, the other can do bgp]

> From an technical, operational, and security standpoint what would be the
> preferred way to route traffic between these two networks?

I suggest using one of the reserved/private BGP asns for this purpose.

ASNumber:   64512 - 65535
ASName: IANA-RSVD2
ASHandle:   AS64512
RegDate:1995-04-06
Updated:2009-01-14
Comment:Designated for private use [RFC1930]

- Jared

Routing Suggestions

[Lars Carter]

Hi NANOG list,

I have a simple, hypothetical question regarding preferred connectivity
methods for you guys that I would like to get the hive mind opinion about.


There are two companies, Company A and Company B, that are planning to
continuously exchange a large amount of sensitive data and are located in a
mutual datacenter. They decide to order a cross connect and peer privately
for the obvious reasons. Company A has a small but knowledgable engineering
staff and it's network is running BGP as its only routing protocol with
multiple transit vendors and a handful of other larger peers. Company B is a
smaller shop that is single homed behind one ISP through a default static
route, they have hardware that can handle advanced routing protocols but
have not had the need to implement them as of yet. There is a single prefix
on both sides that will need to be routed to the other party. It is rare
that prefixes would need to change or for additional prefixes to be added.


>From an technical, operational, and security standpoint what would be the
preferred way to route traffic between these two networks?


Cheers,

Lars

RE: co-location and access to your server

[George Bonser]

> From: Kevin Stange 

> You're talking about a dedicated server business versus colocation.
> Colocation can be a better solution if you have special needs for
> hardware or want to not pay for the extra overhead that needs to be
> built-in for supporting dedicated hardware (like stocking replacement
> parts, paying for the server's original purchase cost, extra fees for
> upgrade hardware, etc).
> 
> Colo also lets customers move their hardware around if they ever want
> to change providers, rather than have to do a soft migration and to
> deliver a prepared server to a facility they can set up at home or in
> their office beforehand.  Depending on your exact needs, some of these
> things might outweigh the benefits of a dedicated server from the data
> center operator.

Agreed on the above two points.  I was thinking that it was great just to find 
someone these days that would accept a one-off server and that should be enough 
to be thankful for!  The access requirements can be a pain but if you are in a 
shared cabinet, you have people installing rack mounts, pulling servers in and 
out around your stuff, etc.  I can see where I would probably want the colo 
provider to have someone supervising what that other customer is doing right 
next to my server (did he cover my air vents with a bunch of cables?)  The 
degree of clue varies widely between people who might want to collocate a 
single server and if I am unlucky enough to be hosted directly above/below 
someone who is in/out of their server every week, I might get a little nervous. 
 Knowing that there is someone with a bit more clue (does that for a living) 
supervising (or at least witnessing) might ease my anxiety somewhat about what 
is going on in the cabinet where I am being hosted.
 
> As a colo provider, if you set up and enforce rules regarding mounting,
> air flow, cabling, etc and confirm them when the customer brings them
> to the facility, this problem does not really exist.

To some extent, that is true. I guess it depends on what is going on, too.  
Does the customer arrive, request their server and the colo provider pulls it 
for them and deliver it to a work area or does the customer go get the server 
themselves under supervision of the colo provider?  There can be a lot of 
variables.  

> In our facilities, customers are welcome to come in to work on their
> hardware at any time 24/7.  We do not guarantee or offer that we will
> have the parts or tools needed to service the equipment and encourage
> customers to send us those things as needed or take care of the
> hardware personally in order to deal with any such concerns.
> 
> This has never been a problem for us.

Awesome.  It's good to know that there are still operations like that around.  
That is probably found more often in local providers and not so often in the 
big operations.  The more community oriented providers would be much more 
accepting of such a situation than a large operation.

But having clueful people around 24x7 to assist customers in shared cabinets 
may not be effective for them if they have just opened up and might not have a 
lot of customers yet.  If they only get one or two customers who come in after 
hours, I could see where they might figure it isn't cost effective for them to 
have staff on the swing and graveyard shifts. Larger operations might have an 
easier time with that, but having someone "on call" probably isn't that bad if 
it is infrequently needed.

BT Support#

[Natarajan Balasubramanian]

Hi,
 
I am looking for the Enterprise (24x7) technical support contact# for British 
Telecom (BT), services provided in USA.
 
 
Thanks & Regards,
 
Natarajan Balasubramanian

Re: co-location and access to your server

[Jeroen van Aart]

Kevin Stange wrote:

I guess what you're saying holds true if the facility doesn't already
offer /anyone/ this access regardless of how much equipment and space
they have.


They offer 24/7 access to 1/3 racks or more.

The price is not that low, $100/month for 1*1U and 1 IP. I'd say that's 
not a sales bin style rock bottom price where expecting even free coffee 
is excessive. ;-)


There is another small colo in town which to the best of my knowledge 
does provide 24/7 access with a keycard.


Greetings,
Jeroen

--
http://goldmark.org/jeff/stupid-disclaimers/
http://linuxmafia.com/~rick/faq/plural-of-virus.html

Re: co-location and access to your server

[Justin Wilson]

If it were cheap and I needed a secondary site for backups and DR then I
would live with that.  Otherwise no.
-- 
Justin Wilson 
Aol & Yahoo IM: j2sw
http://www.mtin.net/blog ­ xISP News
http://www.twitter.com/j2sw ­ Follow me on Twitter
Wisp Consulting ­ Tower Climbing ­ Network Support

Re: co-location and access to your server

[Kevin Stange]

On 01/12/2011 03:50 PM, George Bonser wrote:
> I would say even that hosting other people's hardware on a "one off"
> basis isn't even really cost effective.  Better, in my opinion, for the
> service provider to simply buy a rack from Rackable or another vendor
> and rent the servers out to people.  At least you are then dealing with
> a known entity as far as hardware goes.  Housing who knows what gives
> you a potential mix of things like front to back, back to front, and
> side to side airflow; an assortment of network issues due to an
> assortment of NICs in the network; people wanting physical access to
> their servers for things like driver replacement, etc. 

You're talking about a dedicated server business versus colocation.
Colocation can be a better solution if you have special needs for
hardware or want to not pay for the extra overhead that needs to be
built-in for supporting dedicated hardware (like stocking replacement
parts, paying for the server's original purchase cost, extra fees for
upgrade hardware, etc).

Colo also lets customers move their hardware around if they ever want to
change providers, rather than have to do a soft migration and to deliver
a prepared server to a facility they can set up at home or in their
office beforehand.  Depending on your exact needs, some of these things
might outweigh the benefits of a dedicated server from the data center
operator.

As a colo provider, if you set up and enforce rules regarding mounting,
air flow, cabling, etc and confirm them when the customer brings them to
the facility, this problem does not really exist.

In our facilities, customers are welcome to come in to work on their
hardware at any time 24/7.  We do not guarantee or offer that we will
have the parts or tools needed to service the equipment and encourage
customers to send us those things as needed or take care of the hardware
personally in order to deal with any such concerns.

This has never been a problem for us.

-- 
Kevin Stange
Chief Technology Officer
Steadfast Networks
http://steadfast.net
Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867



signature.asc
Description: OpenPGP digital signature

Re: co-location and access to your server

[Kevin Stange]

On 01/12/2011 03:44 PM, david raistrick wrote:
> On Wed, 12 Jan 2011, Jeroen van Aart wrote:
> 
>> I guess knowing who entered the building by means of a keycard and
>> having cameras isn't considered enough to deter potential "evil
>> doers". I know it's not enough for places like equinix, but that's of
>> a different caliber.
> 
> Paying for 1u of colo justifys a keycard for you, cameras and keycard
> hardware for the facility?   you're paying what, 50-100$ a month, maybe
> less?   you realize that low prices comes at the cost of reduced services?

Having the infrastructure in place to support full cab customers already
and 24/7 remote hands, the cost of providing 24/7 access to smaller colo
customers is negligible.

We could issue a card to every single server one of our colo customers
for only the one-time cost of the card.  It doesn't make sense for most
single-server customers because a tech still has to go into the data
center, unlock the cabinet, fetch a crash cart, etc, so he might as well
let them in the front door.

I guess what you're saying holds true if the facility doesn't already
offer /anyone/ this access regardless of how much equipment and space
they have.

-- 
Kevin Stange
Chief Technology Officer
Steadfast Networks
http://steadfast.net
Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867



signature.asc
Description: OpenPGP digital signature

Re: co-location and access to your server

[Seth Mattinen]

On 1/12/2011 12:24, Jeroen van Aart wrote:
> Cruzio in Santa Cruz recently opened a little co-location facility. That
> makes two of such facilities in Santa Cruz (the other being got.net),
> which could be a good thing for competition.
> 
> Their 1U offer comes with limited access to your server, only from 10AM
> to 6 PM. I find that not acceptable. Why wait until 10 AM when a disk
> breaks at 8 PM? But maybe I am being too picky.
> 
> What is considered normal with regards to access to your co-located
> server(s)? Especially when you're just co-locating one or a few servers.
> 


I treat all my colo customers as 24 hour (escorted) access.

~Seth

RE: co-location and access to your server

[George Bonser]

> From: david raistrick 
> Sent: Wednesday, January 12, 2011 1:44 PM
> To: Jeroen van Aart
> Cc: NANOG list
> Subject: Re: co-location and access to your server
> 
> On Wed, 12 Jan 2011, Jeroen van Aart wrote:
> 
> > I guess knowing who entered the building by means of a keycard and
> having
> > cameras isn't considered enough to deter potential "evil doers". I
> know it's
> > not enough for places like equinix, but that's of a different
> caliber.
> 
> Paying for 1u of colo justifys a keycard for you, cameras and keycard
> hardware for the facility?   you're paying what, 50-100$ a month,
maybe
> less?   you realize that low prices comes at the cost of reduced
> services?

I would say even that hosting other people's hardware on a "one off"
basis isn't even really cost effective.  Better, in my opinion, for the
service provider to simply buy a rack from Rackable or another vendor
and rent the servers out to people.  At least you are then dealing with
a known entity as far as hardware goes.  Housing who knows what gives
you a potential mix of things like front to back, back to front, and
side to side airflow; an assortment of network issues due to an
assortment of NICs in the network; people wanting physical access to
their servers for things like driver replacement, etc. 

Even having someone willing to allow individuals to house their own
single servers in a rack is amazing.  Complaining about the service as
far as access just seems like looking the gift horse in the mouth!

Re: co-location and access to your server

[david raistrick]

On Wed, 12 Jan 2011, Jeroen van Aart wrote:

I guess knowing who entered the building by means of a keycard and having 
cameras isn't considered enough to deter potential "evil doers". I know it's 
not enough for places like equinix, but that's of a different caliber.


Paying for 1u of colo justifys a keycard for you, cameras and keycard 
hardware for the facility?   you're paying what, 50-100$ a month, maybe 
less?   you realize that low prices comes at the cost of reduced services?




--
david raistrickhttp://www.netmeister.org/news/learn2quote.html
dr...@icantclick.org http://www.expita.com/nomime.html

Re: co-location and access to your server

[Jeroen van Aart]

todd glassey wrote:

On 1/12/2011 12:28 PM, Matt Kelly wrote:
When you are talking single or partial rack colo it is generally done 


policy.  The ISP's limited access policy has to do with their overhead 
models and that's all there is to that.


Sorry to bring daylight into this but it is what it is... YOU MUST plan 
for redundancy.


Thanks for all the replies, I understand that allowing access to other 
people's servers unsupervised could be a bad idea. Problem for my 
specific situation is that the 10 to 6 access is exactly the time I 
generally am NOT in town.


I guess knowing who entered the building by means of a keycard and 
having cameras isn't considered enough to deter potential "evil doers". 
I know it's not enough for places like equinix, but that's of a 
different caliber.


Thanks,
Jeroen

--
http://goldmark.org/jeff/stupid-disclaimers/
http://linuxmafia.com/~rick/faq/plural-of-virus.html

Re: Is NAT can provide some kind of protection?

[Paul Ferguson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Jan 12, 2011 at 1:16 PM,   wrote:

> On Wed, 12 Jan 2011 15:13:43 EST, Scott Helms said:
>> Few home users have a stateful firewall configured
>
> What percent of home users are running a Windows older than XP SP2?
>

I don't have stats per specific XP SP version, but a sampling of OSs
visiting a blog that I admin:

43.40%  WinXP
26.33%  Win7
13.00%  MacOSX
12.60%  WinVista
1.60%   unknown
1.00%   iOS
0.87%   Linux
0.87%   Android
0.13%   Win2003
0.13%   Win2000
0.07%   SymbianOS

Of course, this is just a sampling that may or may not be relevant.

- - ferg


-BEGIN PGP SIGNATURE-
Version: PGP Desktop 9.5.3 (Build 5003)

wj8DBQFNLhzuq1pz9mNUZTMRAgN0AJ4hrUq0qSfLLNMWq6RAXleb8bya2ACglxTU
tT/sP0oVu89WeWrG6XodcKU=
=+pa8
-END PGP SIGNATURE-

-- 
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawgster(at)gmail.com
 ferg's tech blog: http://fergdawg.blogspot.com/

Re: Is NAT can provide some kind of protection?

[Owen DeLong]

On Jan 12, 2011, at 1:05 PM, Scott Helms wrote:

> 
>> 
>> That's simply not true. Every end user running NAT is running a stateful 
>> firewall with a default inbound deny.
> 
> Really?  I just tested this with 8 different router models from 5 different 
> manufacturers and in all cases the default behavior was the same.  Put a 
> public IP on a PC behind the router, tell the router how to connect (DHCP in 
> this case), and leaving everything else as default meant that all traffic to 
> the public IP was allowed through unless I configured rules.  One of the 
> Netgear models (IIRC) did block ICMP but any TCP or UDP traffic was allowed 
> through.  Now, this certainly isn't an exhaustive test, but it tested the 
> devices we needed checked.  If someone knows of a model that does block 
> incoming (non-established TCP) traffic by default I'd like to know about it.  
> That's especially true of combo DSL modem routers.
> 
It may be that the default behavior of the models you tested is to turn off the 
stateful firewall if there's a public
inside address, but, the same code that does the stateful inspection for NAT 
can do it without NAT if the
vendor chooses.

I suspect that the vendors chose to automatically disable stateful inspection 
to avoid tech support calls from
ignorant users with public IPs that didn't understand why their packets weren't 
getting through.


Owen

Re: Is NAT can provide some kind of protection?

[Paul Ferguson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Jan 12, 2011 at 1:18 PM,   wrote:

> On Wed, 12 Jan 2011 11:21:24 PST, Paul Ferguson said:
>
>> Try this at home, with/without NAT:
>>
>> 1. Buy a new PC with Windows installed
>> 2. Install all security patches needed since the OS was installed
>>
>> Without NAT, you're unpatched PC will get infected in less than 1
>> minute.
>
> What release of Windows?
>

Okay, okay -- you got me on that one. :-)

It used to be a much bigger problem when XP was shipping on PCs, but of
course that has changed.

I suppose there's a sliding-window principle (no pun intended) with regards
to the number of security vulnerabilities that are remotely exploitable and
the amount of time since the OS version was introduced, but you get my
point. :-)

- - ferg

-BEGIN PGP SIGNATURE-
Version: PGP Desktop 9.5.3 (Build 5003)

wj8DBQFNLhwjq1pz9mNUZTMRAstGAKDhsX9AYZL6sGMIH5WWJM2GpilQNQCgm3TH
UQ26ucDTFifTB3eAQEZxj0M=
=Lh9p
-END PGP SIGNATURE-



-- 
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawgster(at)gmail.com
 ferg's tech blog: http://fergdawg.blogspot.com/

Re: World IPv6 Day

[Mark Smith]

On Wed, 12 Jan 2011 11:10:03 -0800
Randy Bush  wrote:

> > the first global-scale trial of IPv6, the long-anticipated upgrade to
> > the Internet's main communications protocol known as IPv4.
> 
> this phrasing is both amusing and deeply sad.  amusing because many folk
> have been running ipv6 globaly for over a decade.  deeply sad because
> this is taken to be shiny and new as we approach the end of the iana
> ipv4 free pool.  what have people been smoking?
> 

IPv4.

Every now and then it is worth remembering that IPv4 was a protocol
that was designed for a small experimental network that managed to
escape into production. How long it has been usable is actually quite
remarkable, and has only been achieved through a series of neat hacks
like classes, subnets and CIDR.


Regards,
Mark.

Re: Is NAT can provide some kind of protection?

[Valdis . Kletnieks]

On Wed, 12 Jan 2011 16:05:42 EST, Scott Helms said:
> > That's simply not true. Every end user running NAT is running a stateful 
> > firewall with a default inbound deny.

> Really?  I just tested this with 8 different router models from 5 
> different manufacturers and in all cases the default behavior was the 
> same.  Put a public IP on a PC behind the router

At which point you're not running NAT, so it's a different configuration than
the one under discussion.



pgp0Mhy8ygaKl.pgp
Description: PGP signature

Re: Is NAT can provide some kind of protection?

[Valdis . Kletnieks]

On Wed, 12 Jan 2011 11:21:24 PST, Paul Ferguson said:

> Try this at home, with/without NAT:
> 
> 1. Buy a new PC with Windows installed
> 2. Install all security patches needed since the OS was installed
> 
> Without NAT, you're unpatched PC will get infected in less than 1 minute.

What release of Windows?


pgp0eBWvkExWE.pgp
Description: PGP signature

Re: Is NAT can provide some kind of protection?

[Jack Bates]

On 1/12/2011 3:05 PM, Scott Helms wrote:

If someone knows of a model that does block incoming (non-established
TCP) traffic by default I'd like to know about it.  That's especially
true of combo DSL modem routers.


I believe Visionnet's v6 dsl modem does, as well as comtrends.


Jack

Re: Is NAT can provide some kind of protection?

[Valdis . Kletnieks]

On Wed, 12 Jan 2011 15:13:43 EST, Scott Helms said:
> Few home users have a stateful firewall configured

What percent of home users are running a Windows older than XP SP2?


pgp0QIpK5GmKt.pgp
Description: PGP signature

Re: Is NAT can provide some kind of protection?

[Scott Helms]

That's simply not true. Every end user running NAT is running a stateful 
firewall with a default inbound deny.


Really?  I just tested this with 8 different router models from 5 
different manufacturers and in all cases the default behavior was the 
same.  Put a public IP on a PC behind the router, tell the router how to 
connect (DHCP in this case), and leaving everything else as default 
meant that all traffic to the public IP was allowed through unless I 
configured rules.  One of the Netgear models (IIRC) did block ICMP but 
any TCP or UDP traffic was allowed through.  Now, this certainly isn't 
an exhaustive test, but it tested the devices we needed checked.  If 
someone knows of a model that does block incoming (non-established TCP) 
traffic by default I'd like to know about it.  That's especially true of 
combo DSL modem routers.



--
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000

Looking for hand-selected news, views and
tips for independent broadband providers?

Follow us on Twitter! http://twitter.com/ZCorum

RE: TeliaSonera US contact?

[George Bonser]

Thanks, folks, I got the contact I needed and the ball is rolling. 

George


> -Original Message-
> From: George Bonser [mailto:gbon...@seven.com]
> Sent: Wednesday, January 12, 2011 12:32 PM
> To: nanog@nanog.org
> Subject: TeliaSonera US contact?
> 
> Does anyone have a (preferably sales) contact with TeliaSonera in the
> US?  I have been trying to get someone to speak to me about a product
> of
> theirs (have exchanged email but can't get them on the phone). It
might
> be the time difference with Europe making things difficult so I am
> wondering if someone might have a contact in North America.
> 
> Thanks.
> 
> G
> 
> 

Re: Is NAT can provide some kind of protection?

[Jeff Kell]

On 1/12/2011 2:57 PM, Owen DeLong wrote:
>> Try this at home, with/without NAT:
>>
>> 1. Buy a new PC with Windows installed
>> 2. Install all security patches needed since the OS was installed
>>
>> Without NAT, you're unpatched PC will get infected in less than 1 minute.
> Wrong.
> Repeat the experiment with stateful firewall with default inbound deny and no 
> NAT.
> Yep... Same results as NAT.

Now let that laptop (or another one on the home subnet) show up with
Bridging or Internet Connection Sharing enabled with wired/wireless
connections and see what you get.  Still maybe OK if it's the "host"
firewall, and it's turned on, and it's not domain-joined with the local
subnet allowed, etc., but that was post-SP2 and assumes some malware [or
the  user] hasn't turned it off.

NAT+RFC1918 = no accidental leakage/bridging (yes, they could spoof
RFC1918 destinations, assuming they get routed all the way to the
endpoint... but that's a bigger "if" than a public address)

"Perfect stateful firewall with perfect default inbound deny and no
other variables thrown in the mix" and yes, but it's breakable in
contrast to the NAT+RFC1918 case.

There is something to be said for "unreachable" (i.e., "not in your
forwarding table") -- else the VPN / VRF / MPLS / etc folks wouldn't
have a leg to stand on :-)

With that said, this isn't a one-size-fits-all, everybody's perfect
solution.  We've covered the gamut from home CPE to server farms here,
with the original question being about a DMZ case.  They are however
legitimate security layers applied to certain cloves of this particular
bulb of garlic (a more appropriate model than the homogeneous "onion")  :-)

Jeff

Re: co-location and access to your server

[todd glassey]

On 1/12/2011 12:28 PM, Matt Kelly wrote:

When you are talking single or partial rack colo it is generally done as 
escorted only, due to security.  They can't have anyone coming in and poking 
around other customers hardware without being watched.  We do the same thing 
but we allow 24x7 escorted access.  Half and full racks get 24x7 access also 
but that is because they are individually locked.


--
Matt


On Jan 12, 2011, at 3:24 PM, Jeroen van Aart wrote:


Cruzio in Santa Cruz recently opened a little co-location facility. That makes 
two of such facilities in Santa Cruz (the other being got.net), which could be 
a good thing for competition.

Their 1U offer comes with limited access to your server, only from 10AM to 6 
PM. I find that not acceptable. Why wait until 10 AM when a disk breaks at 8 
PM? But maybe I am being too picky.

What is considered normal with regards to access to your co-located server(s)? 
Especially when you're just co-locating one or a few servers.

Thanks,
Jeroen

--
http://goldmark.org/jeff/stupid-disclaimers/
http://linuxmafia.com/~rick/faq/plural-of-virus.html





This is beginning to sound like the blind leading the blind & this 
commentary is too funny.


If you outsource your IT facilities to a ISP and you do not plan for 
redundancy then the failure is YOURS and not the ISP's limited access 
policy.  The ISP's limited access policy has to do with their overhead 
models and that's all there is to that.


Sorry to bring daylight into this but it is what it is... YOU MUST plan 
for redundancy.


Todd Glassey - as a GOT.NET Client


-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1191 / Virus Database: 1435/3375 - Release Date: 01/12/11

Re: Is NAT can provide some kind of protection?

[Scott Helms]

Miquel,

Almost no home users have an IPv6 connection currently and the ones 
that do are the extreme outliers.  IPv6 gear (depending on the 
deployment method) will hopefully handle this well, but no I haven't 
seen any that did a default drop all.  In truth most of the CPE I've 
seen don't even run v6 well even if their marketing claims otherwise.  
However, v6 is an entirely different generation of gear that will 
_hopefully_ get things right since they will _hopefully_ avoid NAT.  
Having said that so far the smoothest (from an end user perspective) way 
of moving forward is often 4 to 6 in the home and I expect that to be 
dirt common for very long time in the future.


On 1/12/2011 3:37 PM, Miquel van Smoorenburg wrote:

In article,
Scott Helms  wrote:

Few home users have a stateful firewall configured and AFAIK none of the
consumer models come with a good default set of rules much less a drop
all unknown.

The v6 capable CPEs for home users I've seen so far all include
stateful firewalling with inbound default deny.

(including the one I'm using right now)

Is your experience with such CPEs any different ?

Mike.




--
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000

Looking for hand-selected news, views and
tips for independent broadband providers?

Follow us on Twitter! http://twitter.com/ZCorum

Re: Is NAT can provide some kind of protection?

[david raistrick]

On Wed, 12 Jan 2011, Chris Adams wrote:


Yes, they do.  NAT requires a stateful firewall.  Why is that so hard to
understand?


Um.  No.  NAT requires stateful inspection (because NAT needs to maintain 
a state table), but does not require a stateful firewall.  You can (and 
many CPE appliances do/did) have no firewall, or stateless firewall in 
front of NAT.



All NAT does is give you an implied deny-all-inbound rule, but doesn't, in 
and of itself, prevent someone probing open (configured by you or the 
vendor) ports that are forwarded or on the device.   Or from having 
unfettered inside access of 1 internal IP if you NAT all external ports to 
an internal IP.





--
david raistrickhttp://www.netmeister.org/news/learn2quote.html
dr...@icantclick.org http://www.expita.com/nomime.html

Re: Is NAT can provide some kind of protection?

[Owen DeLong]

On Jan 12, 2011, at 12:13 PM, Scott Helms wrote:

> Few home users have a stateful firewall configured and AFAIK none of the 
> consumer models come with a good default set of rules much less a drop all 
> unknown.  For end users NAT is and will likely to continue to be the most 
> significant and effective front line security they have.  Home router

That's simply not true. Every end user running NAT is running a stateful 
firewall with a default inbound deny. 

It then takes the extra step of mangling the packet header. This header 
mangling step is unnecessary in IPv6 and is not part of the
security mechanism.

Unfortunately, because these two features have been bundled for so long in 
IPv4, many people, apparently yourself included, don't
see that what most people call a "NAT" box is actually a 
stateful-inspection+NAT box doing both steps.

> manufacturers have very limited budgets for training or support for home end 
> users so the approach is likely to remain the least expensive thing that 
> produces the fewest inbound support calls.  If the question is whether NAT 
> was designed to be a security level then I agree your stance and I'd also 
> agree that correctly configured firewalls do a better job at security.  Where 
> I disagree is your position that there is no extra security inherent in the 
> default NAT behavior.  Until someone makes an effort to create either a DMZ 
> entry or starts doing port forwarding all (AFAIK) of the common routers will 
> drop packets that they don't know where to forward them.
> 
And there's no reason they can't function exactly that way in IPv6 without 
mangling the packet header.

> Is this a tenuous and accidental security level based on current defaults in 
> cheap gear?  Of course, but given how normal users behave until routers can 
> automagically configure firewall settings in a safe (i.e. not UPNP) manner I 
> don't see things changing.
> 
Actually, even if it's deliberate, the point here is that it's a three-step 
process:
1.  State table update/match
2.  Mangle packet header
3.  Forward packet

In IPv6, we can discard step 2 without changing the security provided by step 1 
and improve the functionality of step 3.

Owen

> On 1/12/2011 2:57 PM, Owen DeLong wrote:
>> On Jan 12, 2011, at 11:21 AM, Paul Ferguson wrote:
>> 
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>> 
>>> On Wed, Jan 12, 2011 at 11:09 AM, Owen DeLong  wrote:
>>> 
 No, NAT doesn't provide additional security. The stateful inspection that
 NAT cannot operate without provides the security. Take away the
 address mangling and the stateful inspection still provides the same
 level of security.
 
>>> There is a least one situation where NAT *does* provide a small amount of
>>> necessary security.
>>> 
>>> Try this at home, with/without NAT:
>>> 
>>> 1. Buy a new PC with Windows installed
>>> 2. Install all security patches needed since the OS was installed
>>> 
>>> Without NAT, you're unpatched PC will get infected in less than 1 minute.
>>> 
>> Wrong.
>> 
>> Repeat the experiment with stateful firewall with default inbound deny and 
>> no NAT.
>> 
>> Yep... Same results as NAT.
>> 
>> NAT != security. Stateful inspection = some security.
>> 
>> Next!!
>> 
>> Owen
>> 
>> 
>> 
> 
> 
> -- 
> Scott Helms
> Vice President of Technology
> ISP Alliance, Inc. DBA ZCorum
> (678) 507-5000
> 
> Looking for hand-selected news, views and
> tips for independent broadband providers?
> 
> Follow us on Twitter! http://twitter.com/ZCorum
> 
> 

Re: co-location and access to your server

[david raistrick]

On Wed, 12 Jan 2011, Jeroen van Aart wrote:

What is considered normal with regards to access to your co-located 
server(s)? Especially when you're just co-locating one or a few servers.


For less than 1 rack, or specialty racks with lockable sections (1/2 or 
1/3 or 1/4 racks with their own doors), I'd consider any physical access 
to simply be a plus.  I wouldn't expect any at all.   You're not paying 
for enough space to justify the costs involved in 24x7 independant access, 
and the risks to other customers gear.



When you get a full rack+, or cage+, I'd expect unfettered 24x7 access 
since your gear should be seperated and secured from other folks gear. 
Some specialty providers would be exceptions, of course (ie, I used to 
colo gear inside tv stations, satellite downlink stations, etc).



Telecom colo (switch and network gear in a dedicated but shared space for 
providers providing service) would be an exception, of course.



--
david raistrickhttp://www.netmeister.org/news/learn2quote.html
dr...@icantclick.org http://www.expita.com/nomime.html

Re: Is NAT can provide some kind of protection?

[Scott Helms]

No it really doesn't.  Thank you for leaving the key word when you 
quoted me (configured).  The difference is the _default_ behavior of the 
two.  NAT by _default_ drops packets it doesn't have a mapped PAT 
translation for.  Home firewalls do not _default_ to dropping all 
packets they don't have a rule to explicitly allow.  The behaviors when 
configured by someone knowledgeable behave the in a similar fashion 
(allowing packets that are configured to pass and dropping all others) 
but end users don't do that as a rule.


On 1/12/2011 3:31 PM, Chris Adams wrote:

Once upon a time, Scott Helms  said:

Few home users have a stateful firewall configured

Yes, they do.  NAT requires a stateful firewall.  Why is that so hard to
understand?



--
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000

Looking for hand-selected news, views and
tips for independent broadband providers?

Follow us on Twitter! http://twitter.com/ZCorum

RE: co-location and access to your server

[Brandon Kim]

If you're co-locating with us, you have access to your equipment 24x7.

And we are also staffed 24x7 in the event you can't get to our location for 
whatever reason...(vacation etc...)

Colo's have their own rules I suppose, did you know about this before hosting 
with them?



> Date: Wed, 12 Jan 2011 12:24:18 -0800
> From: jer...@mompl.net
> To: nanog@nanog.org
> Subject: co-location and access to your server
> 
> Cruzio in Santa Cruz recently opened a little co-location facility. That 
> makes two of such facilities in Santa Cruz (the other being got.net), 
> which could be a good thing for competition.
> 
> Their 1U offer comes with limited access to your server, only from 10AM 
> to 6 PM. I find that not acceptable. Why wait until 10 AM when a disk 
> breaks at 8 PM? But maybe I am being too picky.
> 
> What is considered normal with regards to access to your co-located 
> server(s)? Especially when you're just co-locating one or a few servers.
> 
> Thanks,
> Jeroen
> 
> -- 
> http://goldmark.org/jeff/stupid-disclaimers/
> http://linuxmafia.com/~rick/faq/plural-of-virus.html
> 
  

Re: TeliaSonera US contact?

[Jeffrey Lyon]

George,

Try Stephen Brown, stephen.br...@teliasonera.com . He is based in
Virginia and has always been very good about telephone contact.

Jeff

On Wed, Jan 12, 2011 at 3:32 PM, George Bonser  wrote:
> Does anyone have a (preferably sales) contact with TeliaSonera in the
> US?  I have been trying to get someone to speak to me about a product of
> theirs (have exchanged email but can't get them on the phone). It might
> be the time difference with Europe making things difficult so I am
> wondering if someone might have a contact in North America.
>
> Thanks.
>
> G
>
>
>
>



-- 
Jeffrey Lyon, Leadership Team
jeffrey.l...@blacklotus.net | http://www.blacklotus.net
Black Lotus Communications - AS32421
First and Leading in DDoS Protection Solutions

Re: Is NAT can provide some kind of protection?

[Miquel van Smoorenburg]

In article ,
Scott Helms   wrote:
>Few home users have a stateful firewall configured and AFAIK none of the 
>consumer models come with a good default set of rules much less a drop 
>all unknown.

The v6 capable CPEs for home users I've seen so far all include
stateful firewalling with inbound default deny.

(including the one I'm using right now)

Is your experience with such CPEs any different ?

Mike.

Re: Is NAT can provide some kind of protection?

[Jack Bates]

On 1/12/2011 2:13 PM, Scott Helms wrote:

Until someone makes an effort to create either a DMZ entry or starts
doing port forwarding all (AFAIK) of the common routers will drop
packets that they don't know where to forward them.


This can be easily implemented in stateful firewalls for home routers. 
The code is almost identical to NAT, just no address mangling. I suspect 
that v4 NAT and v6 stateful inspection will actually use the same code 
in many cases.


Not to say NAT doesn't have other uses, but they generally are useful 
for enterprise networks or sometimes service providers, not home routers.



Jack

Re: co-location and access to your server

[Stephen Davis]

> What is considered normal with regards to access to your co-located
> server(s)? Especially when you're just co-locating one or a few servers.

Normally you need an escort so you don't go fiddling with other
people's hardware. Our provider has a callout fee if we want to get in
at nights or weekends.

TeliaSonera US contact?

[George Bonser]

Does anyone have a (preferably sales) contact with TeliaSonera in the
US?  I have been trying to get someone to speak to me about a product of
theirs (have exchanged email but can't get them on the phone). It might
be the time difference with Europe making things difficult so I am
wondering if someone might have a contact in North America.

Thanks.

G

Re: Is NAT can provide some kind of protection?

[Chris Adams]

Once upon a time, Scott Helms  said:
> Few home users have a stateful firewall configured

Yes, they do.  NAT requires a stateful firewall.  Why is that so hard to
understand?
-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: co-location and access to your server

[Jack Carrozzo]

The answer, as always, is "how much do you want to pay?" There are lots of
cheap places that make it a hassle for you to get in so you use their remote
hands, or just let you in on their terms so they don't have to keep the
place open at night.

-Jack Carrozzo

On Wed, Jan 12, 2011 at 3:24 PM, Jeroen van Aart  wrote:

> Cruzio in Santa Cruz recently opened a little co-location facility. That
> makes two of such facilities in Santa Cruz (the other being got.net),
> which could be a good thing for competition.
>
> Their 1U offer comes with limited access to your server, only from 10AM to
> 6 PM. I find that not acceptable. Why wait until 10 AM when a disk breaks at
> 8 PM? But maybe I am being too picky.
>
> What is considered normal with regards to access to your co-located
> server(s)? Especially when you're just co-locating one or a few servers.
>
> Thanks,
> Jeroen
>
> --
> http://goldmark.org/jeff/stupid-disclaimers/
> http://linuxmafia.com/~rick/faq/plural-of-virus.html
>
>

Re: co-location and access to your server

[Matt Kelly]

When you are talking single or partial rack colo it is generally done as 
escorted only, due to security.  They can't have anyone coming in and poking 
around other customers hardware without being watched.  We do the same thing 
but we allow 24x7 escorted access.  Half and full racks get 24x7 access also 
but that is because they are individually locked.


--
Matt


On Jan 12, 2011, at 3:24 PM, Jeroen van Aart wrote:

> Cruzio in Santa Cruz recently opened a little co-location facility. That 
> makes two of such facilities in Santa Cruz (the other being got.net), which 
> could be a good thing for competition.
> 
> Their 1U offer comes with limited access to your server, only from 10AM to 6 
> PM. I find that not acceptable. Why wait until 10 AM when a disk breaks at 8 
> PM? But maybe I am being too picky.
> 
> What is considered normal with regards to access to your co-located 
> server(s)? Especially when you're just co-locating one or a few servers.
> 
> Thanks,
> Jeroen
> 
> -- 
> http://goldmark.org/jeff/stupid-disclaimers/
> http://linuxmafia.com/~rick/faq/plural-of-virus.html
> 

Re: co-location and access to your server

[Mike Lyon]

24x7x365



On Wed, Jan 12, 2011 at 12:24 PM, Jeroen van Aart  wrote:

> Cruzio in Santa Cruz recently opened a little co-location facility. That
> makes two of such facilities in Santa Cruz (the other being got.net),
> which could be a good thing for competition.
>
> Their 1U offer comes with limited access to your server, only from 10AM to
> 6 PM. I find that not acceptable. Why wait until 10 AM when a disk breaks at
> 8 PM? But maybe I am being too picky.
>
> What is considered normal with regards to access to your co-located
> server(s)? Especially when you're just co-locating one or a few servers.
>
> Thanks,
> Jeroen
>
> --
> http://goldmark.org/jeff/stupid-disclaimers/
> http://linuxmafia.com/~rick/faq/plural-of-virus.html
>
>

co-location and access to your server

[Jeroen van Aart]

Cruzio in Santa Cruz recently opened a little co-location facility. That 
makes two of such facilities in Santa Cruz (the other being got.net), 
which could be a good thing for competition.


Their 1U offer comes with limited access to your server, only from 10AM 
to 6 PM. I find that not acceptable. Why wait until 10 AM when a disk 
breaks at 8 PM? But maybe I am being too picky.


What is considered normal with regards to access to your co-located 
server(s)? Especially when you're just co-locating one or a few servers.


Thanks,
Jeroen

--
http://goldmark.org/jeff/stupid-disclaimers/
http://linuxmafia.com/~rick/faq/plural-of-virus.html

Re: Is NAT can provide some kind of protection?

[Jack Bates]

On 1/12/2011 1:35 PM, Owen DeLong wrote:

The corp IT guy is delusional. The solution to the routing disconnect
is map+encap or tunnels. Many exploits now take advantage of these
technologies to use a system compromised through point-click-pwn3d to
provide a route into the rest of the network. If you allow outbound
access to TCP/80, TCP/443, or TCP/22, then, it is trivial to create
an inbound path to your network, NAT or no.



This presumes the inside network is already compromised. In such a case, 
a stateful/non-proxy firewall would also be subject to such a thing. 
This is not what PAT prevents that a stateful firewall doesn't.



The argument everyone is making is that a stateful firewall without
mangling the headers is just as secure (and just as insecure) as one
with PAT.



Except that the routing isolation means that it is not just as secure. 
It has one extra vulnerability over NAT.



Both can and are trivially compromised.



Agreed that there are still ways around them. Anyone relying on a single 
mechanism for security will often find their security to be inefficient.



As to the PAT scenario only exposing a single port on a single host,
not entirely accurate, either. I have seen errant mappings which
exposed much more in a single mapping command on some systems.



On a standard port redirect, I'd be interested to hear the specifics. 
However, as my IT guy points out, he doesn't do port or 1-1 redirects 
through NAT.



Then there are the NAT Traversal mechanisms which are necessary to
make things function but can also be exploited.



Things don't function through his firewall. He likes breakage.


The list of problems created by PAT goes on and on.



PAT creates a lot of issues. However, for some environments, what it 
breaks are perfectly acceptable. Utilizing PAT in home routers and 
facilities that have a more open use of technology, would be crippling 
the protocol needlessly.



I've seen PAT bugs that exposed multiple hosts. This is false sense
of security.



Specifics.


Paraphrased: A bank vault with a screen door is more secure than a
bank vault without a screen door.

Pay no attention to the fact that the bank vault was, in this case,
built with a skylight.


If you installed a skylight, that's your own fault. Nowhere have I said, 
PAT is the ultimate in security and forget everything else. I've said 
the opposite. PAT has it's uses and does provide certain safeguards. It 
is one small piece in a huge arsenal of security mechanisms implemented 
in a network. The entire edge firewall system is only a small piece in 
network security. If you strictly depend on the edge firewall for 
security, you may someday learn the error of doing so. Many companies have.



Jack

Re: Cisco Sanitization

[Michael Hallgren]

Le mercredi 12 janvier 2011 à 11:41 -0800, JC Dill a écrit :

> Randy,
> 
> If you want to cite list policy, let's start by noting that it's a clear 
> violation of the nanog list AUP to setup an autoresponder reply to list 
> email[1], no matter if the autoresponder replies to the list or just to 
> the poster.  You must whitelist email from the list before applying an 
> autoresponder.  If you don't want to see the disclaimer-laden emails, 
> then you can whitelist, then send posts with disclaimers (along with all 
> other posts you don't care to read) to dev/null.
> 
> OTOH, there is nothing in the AUP about disclaimers.  Disclaimers, top 
> posting, excessive quoting, etc. are discouraged (considered poor 
> netiquette) but not outright forbidden.

Either way, a 15-50 or more lines legal notification style appendix to
a mail in an informal operation's forum... ... seems at the very best...
to be of... bad taste... (to me). (Who's reading these? :))

Cheers,

mh

Re: Cruzio peering

[Jeroen van Aart]

Matthew Kaufman wrote:

Have you considered simply asking them?


Sadly the person I contacted with regards to some colocation business 
wasn't able to answer the simplest of question (i.e. from which netblock 
do they assign IPs). Or at least the question was met with silence (he 
may still be researching the answer :-). So I felt that asking about 
peering would be met with even more silence.


Someone sent me this link: http://bgp.he.net/AS11994#_peers

Thanks,
Jeroen

--
http://goldmark.org/jeff/stupid-disclaimers/
http://linuxmafia.com/~rick/faq/plural-of-virus.html

Re: Is NAT can provide some kind of protection?

[Scott Helms]

Few home users have a stateful firewall configured and AFAIK none of the 
consumer models come with a good default set of rules much less a drop 
all unknown.  For end users NAT is and will likely to continue to be the 
most significant and effective front line security they have.  Home 
router manufacturers have very limited budgets for training or support 
for home end users so the approach is likely to remain the least 
expensive thing that produces the fewest inbound support calls.  If the 
question is whether NAT was designed to be a security level then I agree 
your stance and I'd also agree that correctly configured firewalls do a 
better job at security.  Where I disagree is your position that there is 
no extra security inherent in the default NAT behavior.  Until someone 
makes an effort to create either a DMZ entry or starts doing port 
forwarding all (AFAIK) of the common routers will drop packets that they 
don't know where to forward them.


Is this a tenuous and accidental security level based on current 
defaults in cheap gear?  Of course, but given how normal users behave 
until routers can automagically configure firewall settings in a safe 
(i.e. not UPNP) manner I don't see things changing.


On 1/12/2011 2:57 PM, Owen DeLong wrote:

On Jan 12, 2011, at 11:21 AM, Paul Ferguson wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Jan 12, 2011 at 11:09 AM, Owen DeLong  wrote:


No, NAT doesn't provide additional security. The stateful inspection that
NAT cannot operate without provides the security. Take away the
address mangling and the stateful inspection still provides the same
level of security.


There is a least one situation where NAT *does* provide a small amount of
necessary security.

Try this at home, with/without NAT:

1. Buy a new PC with Windows installed
2. Install all security patches needed since the OS was installed

Without NAT, you're unpatched PC will get infected in less than 1 minute.


Wrong.

Repeat the experiment with stateful firewall with default inbound deny and no 
NAT.

Yep... Same results as NAT.

NAT != security. Stateful inspection = some security.

Next!!

Owen






--
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000

Looking for hand-selected news, views and
tips for independent broadband providers?

Follow us on Twitter! http://twitter.com/ZCorum

Re: World IPv6 Day

[Mike Leber]

On 1/12/11 11:10 AM, Randy Bush wrote:

the first global-scale trial of IPv6, the long-anticipated upgrade to
the Internet's main communications protocol known as IPv4.


this phrasing is both amusing and deeply sad.  amusing because many folk
have been running ipv6 globaly for over a decade.  deeply sad because
this is taken to be shiny and new


For the people they are trying to reach, it is.

Mike.

Re: Is NAT can provide some kind of protection?

[Owen DeLong]

On Jan 12, 2011, at 11:21 AM, Paul Ferguson wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Wed, Jan 12, 2011 at 11:09 AM, Owen DeLong  wrote:
> 
>> No, NAT doesn't provide additional security. The stateful inspection that
>> NAT cannot operate without provides the security. Take away the
>> address mangling and the stateful inspection still provides the same
>> level of security.
>> 
> 
> There is a least one situation where NAT *does* provide a small amount of
> necessary security.
> 
> Try this at home, with/without NAT:
> 
> 1. Buy a new PC with Windows installed
> 2. Install all security patches needed since the OS was installed
> 
> Without NAT, you're unpatched PC will get infected in less than 1 minute.
> 
Wrong.

Repeat the experiment with stateful firewall with default inbound deny and no 
NAT.

Yep... Same results as NAT.

NAT != security. Stateful inspection = some security.

Next!!

Owen

Re: Cisco Sanitization

[JC Dill]

 On 12/01/11 11:05 AM, Randy Bush wrote:

Well, here it is. Perhaps you might consider getting a gmail or other
account, and posting on NANOG from there. Either that, or filter Randy
out. Personally, I find those silly disclaimers annoying, but am far too
lazy to set up a script such as Randy has.

disclaimers used to be against nanog list policy.


Randy,

If you want to cite list policy, let's start by noting that it's a clear 
violation of the nanog list AUP to setup an autoresponder reply to list 
email[1], no matter if the autoresponder replies to the list or just to 
the poster.  You must whitelist email from the list before applying an 
autoresponder.  If you don't want to see the disclaimer-laden emails, 
then you can whitelist, then send posts with disclaimers (along with all 
other posts you don't care to read) to dev/null.


OTOH, there is nothing in the AUP about disclaimers.  Disclaimers, top 
posting, excessive quoting, etc. are discouraged (considered poor 
netiquette) but not outright forbidden.


jc

[1]  http://www.nanog.org/mailinglist/index.php

8)  Autoresponders sending mail either to the list or to the poster are 
prohibited.

Re: Is NAT can provide some kind of protection?

[Owen DeLong]

On Jan 12, 2011, at 9:36 AM, Jack Bates wrote:

> On 1/12/2011 11:21 AM, George Bonser wrote:
>> PAT makes little sense to me for v6, but I suspect you are correct.  In
>> addition, we are putting the "fire suit" on each host in addition to the
>> firewall. Kernel firewall rules on each host for the *nix boxen.
>> 
> 
> As my corp IT guy put it to me, PAT forces a routing disconnect between 
> internal and external. There is no way to reach the hosts without the 
> firewall performing it's NAT function. Given that the internal is exclusively 
> PAT, the DMZ is public with stateful/proxy, this provides protection for the 
> internal network while limiting the dmz exposure.
> 
The corp IT guy is delusional. The solution to the routing disconnect is 
map+encap or tunnels. Many exploits now take advantage of these technologies to 
use a system compromised through point-click-pwn3d to provide a route into the 
rest of the network. If you allow outbound access to TCP/80,
TCP/443, or TCP/22, then, it is trivial to create an inbound path to your 
network, NAT or no.

> The argument everyone makes is that a stateful firewall defaults to deny. 
> However, a single mistake prior to the deny allows traffic in. The only 
> equivalent in a PAT scenario is to screw up port forwarding which would cause 
> a single host to expose a single port unknowingly per mistake (which said 
> port/host combo may not be vulnerable). In a stateful firewall, a screw up 
> could expose all ports on a host or multiple hosts in a single mistake.
> 
The argument everyone is making is that a stateful firewall without mangling 
the headers is just as secure (and just as insecure) as one with PAT.

Both can and are trivially compromised.

As to the PAT scenario only exposing a single port on a single host, not 
entirely accurate, either. I have seen errant mappings which
exposed much more in a single mapping command on some systems.

Then there are the NAT Traversal mechanisms which are necessary to make things 
function but can also be exploited.

The list of problems created by PAT goes on and on.

> Then there are the firewall software bugs. In PAT, such bugs don't suddenly 
> expose all your hosts behind the firewall for direct communication from the 
> outside world. In v6 stateful firewall, such a bug could allow circumvention 
> of the entire firewall ruleset and the hosts would be directly addressable 
> from the outside.
> 
I've seen PAT bugs that exposed multiple hosts. This is false sense of security.

> PAT offers the smallest of security safeguards. However, many corp IT 
> personnel feel more secure having that small safeguard in place along with 
> the many other safeguards they deploy. In a corporate environment where they 
> often love to break everything and anything, I don't blame them.
> 
Paraphrased: A bank vault with a screen door is more secure than a bank vault 
without a screen door.

Pay no attention to the fact that the bank vault was, in this case, built with 
a skylight.

Owen

Re: Is NAT can provide some kind of protection?

[Steven Kurylo]

> There is a least one situation where NAT *does* provide a small amount of
> necessary security.
>
> Try this at home, with/without NAT:
>
> 1. Buy a new PC with Windows installed
> 2. Install all security patches needed since the OS was installed
>
> Without NAT, you're unpatched PC will get infected in less than 1 minute.

Its the firewall included with the NAT which protects against the
infection, not the NAT.

So you can remove the NAT, leave the firewall, and be just as secure.

Re: Is NAT can provide some kind of protection?

[Michel de Nostredame]

On Wed, Mar 21, 2007 at 2:41 AM, Tarig Ahmed  wrote:
> We have wide range of Public IP addresses, I tried to assign public ip
> directly to a server behined firewall( in DMZ), but I have been resisted.
> Security guy told me is not correct to assign public ip to a server, it
> should have private ip for security reasons.
>
> Is it true that NAT can provide more security?
>
> Thanks,
>
> Tarig Yassin Ahmed

I assume you are talking about the protection to the current running
"public facing" servers, hence the NAT could not provide more
protection to them compares to a proper configed firewall.

However, for a small business who does not have its own ASN & Provider
Independent IP block(s), a NAT (NAT44 and NAT66) could provide lots of
protection on IT resources when there is a need to install multiple
Internet access lines for providing quickly failover (manual or
automatic, doesn't matter) and/or load-sharing capability to end
users.

--
Michel~

Re: IPv6 - real vs theoretical problems

[Owen DeLong]

On Jan 12, 2011, at 9:34 AM, Ted Fischer wrote:

> At 11:59 AM 1/12/2011, Jim postulated wrote:
> 
>> On 01/11/2011 01:31 PM, Owen DeLong wrote:
>> > It's not about the number of devices. That's IPv4-think. It's about the 
>> > number
>> > of segments. I see a world where each home-entertainment cluster would
>> > be a separate segment (today, few things use IP, but, future HE solutions
>> > will include Monitors, Amps, Blu-Ray players, and other Media gateways
>> > that ALL have ethernet ports for control and software update).
>> 
>> Your future is now, Owen.  I have four network devices at my primary
>> television -- the TV itself, TiVo, PS3, and Wii (using the wired
>> adapter).  All told, I have seven networked home entertainment devices
>> in my house, with another (Blu-Ray player) likely coming soon.  I feel
>> confident in saying that my use case isn't unusual these days.
>> 
>> While a lot of the scalability concerns are blown off as "not applying
>> to typical consumers," we're quickly getting to the point where your
>> average joe IS somewhat likely to have different classes of devices that
>> might benefit from being on separate subnets.
>> 
>> Jima
> 
> I helped a friend setup his "home network" recently.  He is using an old 
> Linksys Router with no v6 support.  I like to be conservative and only 
> allocate what might be needed ... part of my "Defense in Depth" strategy to 
> provide some layer of "security" with NAT (yes, I know - my security by 
> obscurity is to use something from 172.16) and a limited amount of addresses 
> to allocate (not to mention WPA2 - he had default no security when I first 
> got there).  Used to be a /29 would be sufficient for any home.  But, before 
> I knew it, he had a wireless printer, laptop, and 4 iPhones all needing the 
> new wireless passphrase to connect, plus he was anticipating 2 more laptops 
> (one each for his children - to whom 2 of the iPhones belonged), and 
> addresses set aside for guests and the occasional business visitor (he works 
> from home).  I left him configured with a /28, and told him to call me if he 
> anticipated more.
> 
> As a side security note - we lost the laptop on the "new" secured network 
> before I tracked down that it had automatically logged in to his neighbor's 
> (also unprotected) network on reboot.
> 
> Ted
> 

I'm not sure how you see limiting available addresses as a security feature 
rather than just a nuisance, but, to each their own.


Owen

Re: Is NAT can provide some kind of protection?

[Paul Ferguson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Jan 12, 2011 at 11:09 AM, Owen DeLong  wrote:

> No, NAT doesn't provide additional security. The stateful inspection that
> NAT cannot operate without provides the security. Take away the
> address mangling and the stateful inspection still provides the same
> level of security.
>

There is a least one situation where NAT *does* provide a small amount of
necessary security.

Try this at home, with/without NAT:

1. Buy a new PC with Windows installed
2. Install all security patches needed since the OS was installed

Without NAT, you're unpatched PC will get infected in less than 1 minute.

Cheers,

- - ferg

-BEGIN PGP SIGNATURE-
Version: PGP Desktop 9.5.3 (Build 5003)

wj8DBQFNLf8gq1pz9mNUZTMRAjduAJ4w7az13wwn1zsze0DoLTRvOajxxQCgmWMG
ZckeFBpLWyoqG/g9iD2cKIk=
=yYof
-END PGP SIGNATURE-



-- 
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawgster(at)gmail.com
 ferg's tech blog: http://fergdawg.blogspot.com/

Re: Is NAT can provide some kind of protection?

[Owen DeLong]

On Jan 12, 2011, at 9:04 AM, William Herrin wrote:

> On Wed, Mar 21, 2007 at 5:41 AM, Tarig Ahmed  wrote:
>> We have wide range of Public IP addresses, I tried to assign public ip
>> directly to a server behined firewall( in DMZ), but I have been resisted.
>> Security guy told me is not correct to assign public ip to a server, it
>> should have private ip for security reasons.
>> 
>> Is it true that NAT can provide more security?
> 
> Hi Tarig,
> 
> Yes NAT can provide more security, but not in the particular scenario
> you described.
> 
> In your scenario, the firewall knows how to map incoming connections
> for the public address to your server's private address, so you won't
> see any benefit from NAT versus a merely stateful firewall -- a
> connection request will either get through the filter or it won't. If
> it gets through, the firewall knows where to send it. On the other
> hand, the use of any kind of stateful firewall (most of what we refer
> to as NAT firewalls keep per-connection state) increases your
> vulnerability to denial of services attacks: folks DOSing you can
> target both the server and the firewall's state table. So the use of
> NAT there is potentially counterproductive.
> 
> In a client (rather than server) scenario, the picture is different.
> Depending on the specific "NAT" technology in use, the firewall may be
> incapable of selecting a target for unsolicited communications inbound
> from the public Internet. In fact, it may be theoretically impossible
> for it to do so. In those scenarios, the presence of NAT in the
> equation makes a large class of direct attacks on the interior host
> impractical, requiring the attacker to fall back on other methods like
> attempting to breach the firewall itself or indirectly polluting the
> responses to communication initiated by the internal host.
> 
No, NAT doesn't provide additional security. The stateful inspection that
NAT cannot operate without provides the security. Take away the
address mangling and the stateful inspection still provides the same
level of security.

Owen

Re: Is NAT can provide some kind of protection?

[Owen DeLong]

On Jan 12, 2011, at 9:07 AM, Jack Bates wrote:

> 
> 
> On 1/12/2011 11:01 AM, George Bonser wrote:
>> NAT66 is just
>> straight static NAT that maps one prefix to a different prefix.
>> 
> 
> I'd eat a hat if a vendor didn't implement a PAT equivalent. It's demanded 
> too much. There is money for it, so it will be there.
> 
> 
> Jack

Fortunately, so far, it isn't. Hopefully we can cure the demand through 
education instead of acquiescence and profiteering.

Owen

Re: World IPv6 Day

[Randy Bush]

> the first global-scale trial of IPv6, the long-anticipated upgrade to
> the Internet's main communications protocol known as IPv4.

this phrasing is both amusing and deeply sad.  amusing because many folk
have been running ipv6 globaly for over a decade.  deeply sad because
this is taken to be shiny and new as we approach the end of the iana
ipv4 free pool.  what have people been smoking?

randy

Re: Is NAT can provide some kind of protection?

[Owen DeLong]

On Jan 12, 2011, at 8:54 AM, Fernando Gont wrote:

> On 12/01/2011 01:17 p.m., George Bonser wrote:
> 
>> But your security person needs to shift their thinking because the
>> purpose of NAT and private addressing is to conserve IP address, not to
>> provide security.  With IPv6, the concept of NAT goes away.  
> 
> You have heard about NAT66, right?
> 
Yes... Hopefully it was just a bad dream.

NATing IPv6 doesn't do anything good. There's no benefit, only cost.

Owen

Re: Cisco Sanitization

[Randy Bush]

> Well, here it is. Perhaps you might consider getting a gmail or other 
> account, and posting on NANOG from there. Either that, or filter Randy 
> out. Personally, I find those silly disclaimers annoying, but am far too 
> lazy to set up a script such as Randy has.

disclaimers used to be against nanog list policy.  dunno about now.

but whomever does not have much sympathy from me.

randy

Re: Cisco Sanitization

[Justin M. Streiner]

On Wed, 12 Jan 2011, Lynda wrote:


On 1/12/2011 8:04 AM, Greg Whynott wrote:


 list,  sorry for this but this is getting a little annoying.  I've
 tried sending Randy email without luck.. think i'm black listed by
 his kit,  so if someone would kindly forward this to him?


Well, here it is. Perhaps you might consider getting a gmail or other 
account, and posting on NANOG from there. Either that, or filter Randy out. 
Personally, I find those silly disclaimers annoying, but am far too lazy to 
set up a script such as Randy has.


You don't want to be annoyed? Lose the disclaimer, use a different email 
address, or filter Randy out. This is NOT the first time you've complained 
about this (although we know, for sure, that Randy is going to send this off, 
automagically, to anyone that has the silly disclaimer thing going for them). 
Get over it. Please don't post on this again. Thanks in advance.


While I agree that the disclaimers are annoying, I also recognize that:
1. Many companies have policies that require them to append those 
disclaimers to every outgoing email message, and the people who post to 
NANOG often don't have any control over that policy.  Debating on 
this list whether those policies are right or wrong really isn't 
constructive.
2. Some companies have very strict policies against unauthorized surfing 
on company time, and checking a gmail account could fall under their 
definition of unauthorized surfing, even if the purpose of checking said 
gmail account is to try to resolve a work issue without offending 
someone's procmail filters with your company's auto-disclaimer.  Debating 
on this list whether those policies are right or wrong really isn't 
constructive either.


That said, sending the "You sent me a message with a disclaimer that I 
do not accept and have thrown in the bitbucket" response back to NANOG, 
for the enjoyment of the other 10,000+ people on the list is even more 
annoying


This will be my only post to this particular tangent of the original 
thread.


jms

Re: Is NAT can provide some kind of protection?

[Jack Bates]

On 1/12/2011 11:57 AM, Steven Kurylo wrote:


Some benefit?  Yes.  Enough benefit to be worth the trouble?  I
personally am not convinced.



Some people believe it is. Who am I to tell them how to run their 
network? They block facebook and yahoo. I, unfortunately, can't. :)



Considering the amount of people who mistake the amount of security
NAT provides, we're probably better off without it to remove that
false sense of security.


People will then have a false sense of security with stateful firewalls 
that perform no better than NAT, just without the address translation. 
The type of stateful firewall with or without address translation will 
not suddenly make people become wiser and implement better security 
policies. Vendors will always make a cheap setup which people will use 
and consider themselves secure.


Jack

Re: Is NAT can provide some kind of protection?

[Jack Bates]

On 1/12/2011 11:52 AM, Nathan Eisenberg wrote:


I'd argue that the above has everything to do with firewalling, and nothing to 
do with NAT.



I agree, but both effectively handle the job. My point is that just 
because we have lots of infections behind NAT, doesn't mean that NAT (or 
a firewall) doesn't still serve a purpose.



Slightly OT: It boggles the mind a bit when I find desktop shops -not- using 
imaging.  I would think most people would prefer not to stare at OS install 
screens - and when you can blast out a fully patched XP image easily in sub-10 
minutes, the ROI is staggering.


Hardware drivers?


Jack

Re: Is NAT can provide some kind of protection?

[Steven Kurylo]

On Wed, Jan 12, 2011 at 9:36 AM, Jack Bates  wrote:
>
> As my corp IT guy put it to me, PAT forces a routing disconnect between
> internal and external. There is no way to reach the hosts without the
> firewall performing it's NAT function.

But that's not true.  If you have NAT, without a firewall, I can
access your internal hosts (by addressing their RFC 1918 address)
because you'll be leaking your RFC 1918 addresses in and out.
Granted, I might have to be in your immediate upstream, but it can be
done.

So at best, all it does is limit how many hops away I need to be from
you to attack you.

Some benefit?  Yes.  Enough benefit to be worth the trouble?  I
personally am not convinced.

Considering the amount of people who mistake the amount of security
NAT provides, we're probably better off without it to remove that
false sense of security.

RE: Is NAT can provide some kind of protection?

[Nathan Eisenberg]

> And yet blaster type worms are less common now, and I still get the
> occasional reinfection reported where a computer shop installs XP pre-patch
> with a public IP. A simple stateful firewall or NAT router would stop that and
> allow them to finish patching the OS. There is always a new attack vector.
> 
> Jack

I'd argue that the above has everything to do with firewalling, and nothing to 
do with NAT.

Slightly OT: It boggles the mind a bit when I find desktop shops -not- using 
imaging.  I would think most people would prefer not to stare at OS install 
screens - and when you can blast out a fully patched XP image easily in sub-10 
minutes, the ROI is staggering.

Nathan

Re: Is NAT can provide some kind of protection?

[Jack Bates]

On 1/12/2011 11:21 AM, George Bonser wrote:

PAT makes little sense to me for v6, but I suspect you are correct.  In
addition, we are putting the "fire suit" on each host in addition to the
firewall. Kernel firewall rules on each host for the *nix boxen.



As my corp IT guy put it to me, PAT forces a routing disconnect between 
internal and external. There is no way to reach the hosts without the 
firewall performing it's NAT function. Given that the internal is 
exclusively PAT, the DMZ is public with stateful/proxy, this provides 
protection for the internal network while limiting the dmz exposure.


The argument everyone makes is that a stateful firewall defaults to 
deny. However, a single mistake prior to the deny allows traffic in. The 
only equivalent in a PAT scenario is to screw up port forwarding which 
would cause a single host to expose a single port unknowingly per 
mistake (which said port/host combo may not be vulnerable). In a 
stateful firewall, a screw up could expose all ports on a host or 
multiple hosts in a single mistake.


Then there are the firewall software bugs. In PAT, such bugs don't 
suddenly expose all your hosts behind the firewall for direct 
communication from the outside world. In v6 stateful firewall, such a 
bug could allow circumvention of the entire firewall ruleset and the 
hosts would be directly addressable from the outside.


PAT offers the smallest of security safeguards. However, many corp IT 
personnel feel more secure having that small safeguard in place along 
with the many other safeguards they deploy. In a corporate environment 
where they often love to break everything and anything, I don't blame them.


Then we go to the educational sector, where the admins often prefer as 
much openness as possible. In their case, they will prefer to do away 
with PAT.



Jack

Re: IPv6 - real vs theoretical problems

[Ted Fischer]

At 11:59 AM 1/12/2011, Jim postulated wrote:


On 01/11/2011 01:31 PM, Owen DeLong wrote:
> It's not about the number of devices. That's IPv4-think. It's 
about the number

> of segments. I see a world where each home-entertainment cluster would
> be a separate segment (today, few things use IP, but, future HE solutions
> will include Monitors, Amps, Blu-Ray players, and other Media gateways
> that ALL have ethernet ports for control and software update).

 Your future is now, Owen.  I have four network devices at my primary
television -- the TV itself, TiVo, PS3, and Wii (using the wired
adapter).  All told, I have seven networked home entertainment devices
in my house, with another (Blu-Ray player) likely coming soon.  I feel
confident in saying that my use case isn't unusual these days.

 While a lot of the scalability concerns are blown off as "not applying
to typical consumers," we're quickly getting to the point where your
average joe IS somewhat likely to have different classes of devices that
might benefit from being on separate subnets.

 Jima


I helped a friend setup his "home network" recently.  He is using an 
old Linksys Router with no v6 support.  I like to be conservative and 
only allocate what might be needed ... part of my "Defense in Depth" 
strategy to provide some layer of "security" with NAT (yes, I know - 
my security by obscurity is to use something from 172.16) and a 
limited amount of addresses to allocate (not to mention WPA2 - he had 
default no security when I first got there).  Used to be a /29 would 
be sufficient for any home.  But, before I knew it, he had a wireless 
printer, laptop, and 4 iPhones all needing the new wireless 
passphrase to connect, plus he was anticipating 2 more laptops (one 
each for his children - to whom 2 of the iPhones belonged), and 
addresses set aside for guests and the occasional business visitor 
(he works from home).  I left him configured with a /28, and told him 
to call me if he anticipated more.


As a side security note - we lost the laptop on the "new" secured 
network before I tracked down that it had automatically logged in to 
his neighbor's (also unprotected) network on reboot.


Ted

World IPv6 Day

[Scott Howard]

>From http://www.networkworld.com/news/2011/011211-world-ipv6-day.html

Several of the Internet's most popular Web sites - including Facebook,
Google and Yahoo - have agreed to participate in the first global-scale
trial of IPv6, the long-anticipated upgrade to the Internet's main
communications protocol known as IPv4.

The trial — dubbed "World IPv6 Day" — requires participants to support
native IPv6 traffic on their main Web sites on June 8, 2011. Leading content
delivery networks Akamai and Limelight Networks also committed to the IPv6
trial, which is being sponsored by the Internet Society.
[...]


  Scott.