RE: How to secure the Internet in three easy steps

2002-10-27 Thread Vivien M.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:owner-nanog@;merit.edu] On 
> Behalf Of Christopher Schulte
> Sent: October 27, 2002 9:22 PM
> To: William Warren; [EMAIL PROTECTED]
> Subject: Re: How to secure the Internet in three easy steps
> 
> In a public press release dated August, they claim to have 
> 1.8 million Internet customers.  How that compares to the 
> global pool of cable users, I cannot say.

One cable company I've done business here (Ontario, Canada) has over
500K subscribers, and I don't believe it has the largest number of cable
modems in the country. So you're probably talking around 1.5-2 million
cable modems north of the border. Then you have Europe (I think .nl has
decent cable modem penetration), Asia-Pacific, etc.

> It'll be interesting to see if att exports their filtering 
> policies to the newly acquired customers.  They'll want to 
> support a uniform configuration across the whole network, I'm sure.

They apparently don't have a uniform configuration now; we have lots of
people using AT&T BI complaining about blocked port 80s and whatnot, and
yet we have some other AT&T BI users in different locations (but I think
both were formerly-@Home AT&T BI areas) who don't have any ports
blocked. Bizarre, I have to say. 

Vivien
-- 
Vivien M.
[EMAIL PROTECTED]
Assistant System Administrator
Dynamic DNS Network Services
http://www.dyndns.org/ 




Re: How to secure the Internet in three easy steps

2002-10-27 Thread Christopher Schulte

At 09:03 PM 10/27/2002 -0500, William Warren wrote:

actually with the merger of At&t and comcast most cable inet customers 
will be through them.

Until that happens however:

In a public press release dated August, they claim to have 1.8 million
Internet customers.  How that compares to the global pool of cable
users, I cannot say.

It'll be interesting to see if att exports their filtering policies to
the newly acquired customers.  They'll want to support
a uniform configuration across the whole network, I'm sure.

--schulte




Re: How to secure the Internet in three easy steps

2002-10-27 Thread Joe

I Second that.

AT&T  blocks ports (depending where you are) but won't come
right out and say it. On a call to them over a year ago
while testing DSL versus Cable in San Jose, it took almost an hour to get
them to admit that they were blocking ports 137-139, and even then there
was no formal acknowledgement of this blocking.
If I was a betting man, which I'm not, I'd bet on them blocking udp 53 as
well.

No standard as I see it, depends on the child company managing the cable
service.

Just my  2¢s tho
-Joe

- Original Message -
From: "Joseph Barnhart" <[EMAIL PROTECTED]>
To: "Matthew S. Hallacy" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, October 27, 2002 8:46 PM
Subject: Re: How to secure the Internet in three easy steps


>
> Not really
>
> On Sun, 27 Oct 2002, Matthew S. Hallacy wrote:
>
> >
> > On Sun, Oct 27, 2002 at 02:35:23PM -0500, Eric M. Carroll wrote:
> > >
> > > Sean,
> > >
> > > At Home's policy was that servers were administratively forbidden. It
> > > ran proactive port scans to detect them (which of course were subject
to
> > > firewall ACLs) and actioned them under a complex and changing rule
set.
> > > It frequently left enforcement to the local partner depending on
> > > contractual arrangements. It did not block ports. Non-transparent
> > > proxing was used for http - you could opt out if you knew how.
> > >
> > > While many DSL providers have taken up filtering port 25, the cable
> > > industry practice is mostly to leave ports alone. I know of one large
> >
> > Untrue, AT&T filters the following *on* the CPE:
> >
> > Ports  / Direction / Protocol
> >
> > 137-139 -> any Both UDP
> > any -> 137-139 Both UDP
> > 137-139 -> any Both TCP
> > any -> 137-139 Both TCP
> > any -> 1080 Inbound TCP
> > any -> 1080 Inbound UDP
> > 68 -> 67Inbound UDP
> > 67 -> 68Inbound UDP
> > any -> 5000 Inbound TCP
> > any -> 1243 Inbound UDP
> >
> > And they block port 80 inbound TCP further out in their network.
Overall,
> > cable providers more heavily than cable providers.
> >
> > I'd say that AT&T represents a fair amount of the people served via
cable
> > internet.
> >
> > >
> > > Regards,
> > >
> > > Eric Carroll
> >
> > --
> > Matthew S. HallacyFUBAR, LART, BOFH
Certified
> > http://www.poptix.net   GPG public key
0x01938203
> >
>
>
>
> -
> Joseph Barnhart
> Florida Digital Turnpike
> Network Administrator
> http://www.fdt.net
> http://www.agilitybb.net
> -
>
>
>
>




Re: How to secure the Internet in three easy steps

2002-10-27 Thread Matthew S. Hallacy

On Sun, Oct 27, 2002 at 07:42:10PM -0600, Matthew S. Hallacy wrote:
> 
> And they block port 80 inbound TCP further out in their network. Overall,
> cable providers more heavily than cable providers.
^-- s/cable/DSL/;
-- 
Matthew S. HallacyFUBAR, LART, BOFH Certified
http://www.poptix.net   GPG public key 0x01938203



Re: How to secure the Internet in three easy steps

2002-10-27 Thread William Warren

actually with the merger of At&t and comcast most cable inet customers 
will be through them.

Joseph Barnhart wrote:
Not really

On Sun, 27 Oct 2002, Matthew S. Hallacy wrote:



On Sun, Oct 27, 2002 at 02:35:23PM -0500, Eric M. Carroll wrote:


Sean,

At Home's policy was that servers were administratively forbidden. It
ran proactive port scans to detect them (which of course were subject to
firewall ACLs) and actioned them under a complex and changing rule set.
It frequently left enforcement to the local partner depending on
contractual arrangements. It did not block ports. Non-transparent
proxing was used for http - you could opt out if you knew how. 

While many DSL providers have taken up filtering port 25, the cable
industry practice is mostly to leave ports alone. I know of one large

Untrue, AT&T filters the following *on* the CPE:

Ports  / Direction / Protocol

137-139 -> any Both UDP
any -> 137-139 Both UDP
137-139 -> any Both TCP
any -> 137-139 Both TCP
any -> 1080 Inbound TCP
any -> 1080 Inbound UDP
68 -> 67Inbound UDP
67 -> 68Inbound UDP
any -> 5000 Inbound TCP
any -> 1243 Inbound UDP

And they block port 80 inbound TCP further out in their network. Overall,
cable providers more heavily than cable providers.

I'd say that AT&T represents a fair amount of the people served via cable
internet.



Regards,

Eric Carroll


--
Matthew S. HallacyFUBAR, LART, BOFH Certified
http://www.poptix.net   GPG public key 0x01938203






-
Joseph Barnhart
Florida Digital Turnpike
Network Administrator
http://www.fdt.net
http://www.agilitybb.net
-









--
May God Bless you and everything you touch.

My "foundation" verse:
Isiah 54:17 No weapon that is formed against thee shall prosper; and 
every tongue that shall rise against thee in judgment thou shalt 
condemn. This is the heritage of the servants of the LORD, and their 
righteousness is of me, saith the LORD.




Re: How to secure the Internet in three easy steps

2002-10-27 Thread Joseph Barnhart

Not really

On Sun, 27 Oct 2002, Matthew S. Hallacy wrote:

> 
> On Sun, Oct 27, 2002 at 02:35:23PM -0500, Eric M. Carroll wrote:
> > 
> > Sean,
> > 
> > At Home's policy was that servers were administratively forbidden. It
> > ran proactive port scans to detect them (which of course were subject to
> > firewall ACLs) and actioned them under a complex and changing rule set.
> > It frequently left enforcement to the local partner depending on
> > contractual arrangements. It did not block ports. Non-transparent
> > proxing was used for http - you could opt out if you knew how. 
> > 
> > While many DSL providers have taken up filtering port 25, the cable
> > industry practice is mostly to leave ports alone. I know of one large
> 
> Untrue, AT&T filters the following *on* the CPE:
> 
> Ports  / Direction / Protocol
> 
> 137-139 -> any Both UDP
> any -> 137-139 Both UDP
> 137-139 -> any Both TCP
> any -> 137-139 Both TCP
> any -> 1080 Inbound TCP
> any -> 1080 Inbound UDP
> 68 -> 67Inbound UDP
> 67 -> 68Inbound UDP
> any -> 5000 Inbound TCP
> any -> 1243 Inbound UDP
> 
> And they block port 80 inbound TCP further out in their network. Overall,
> cable providers more heavily than cable providers.
> 
> I'd say that AT&T represents a fair amount of the people served via cable
> internet.
> 
> > 
> > Regards,
> > 
> > Eric Carroll
> 
> -- 
> Matthew S. HallacyFUBAR, LART, BOFH Certified
> http://www.poptix.net   GPG public key 0x01938203
> 



-
Joseph Barnhart
Florida Digital Turnpike
Network Administrator
http://www.fdt.net
http://www.agilitybb.net
-








Re: How to secure the Internet in three easy steps

2002-10-27 Thread Matthew S. Hallacy

On Sun, Oct 27, 2002 at 02:35:23PM -0500, Eric M. Carroll wrote:
> 
> Sean,
> 
> At Home's policy was that servers were administratively forbidden. It
> ran proactive port scans to detect them (which of course were subject to
> firewall ACLs) and actioned them under a complex and changing rule set.
> It frequently left enforcement to the local partner depending on
> contractual arrangements. It did not block ports. Non-transparent
> proxing was used for http - you could opt out if you knew how. 
> 
> While many DSL providers have taken up filtering port 25, the cable
> industry practice is mostly to leave ports alone. I know of one large

Untrue, AT&T filters the following *on* the CPE:

Ports  / Direction / Protocol

137-139 -> any Both UDP
any -> 137-139 Both UDP
137-139 -> any Both TCP
any -> 137-139 Both TCP
any -> 1080 Inbound TCP
any -> 1080 Inbound UDP
68 -> 67Inbound UDP
67 -> 68Inbound UDP
any -> 5000 Inbound TCP
any -> 1243 Inbound UDP

And they block port 80 inbound TCP further out in their network. Overall,
cable providers more heavily than cable providers.

I'd say that AT&T represents a fair amount of the people served via cable
internet.

> 
> Regards,
> 
> Eric Carroll

-- 
Matthew S. HallacyFUBAR, LART, BOFH Certified
http://www.poptix.net   GPG public key 0x01938203



NANOG26 IPv6 instructions

2002-10-27 Thread Jun-ichiro itojun Hagino

http://www.kame.net/nanog26/
itojun



NANOG26: IPv6 unreachable prefix advertised

2002-10-27 Thread Jun-ichiro itojun Hagino

it looks that there's unreachable IPv6 prefix advertised at the venue.

please stop this router advertisement (2001:468:1420:f::/64),
or fix conectivity... with this configuration i can't use IPv6 to
connect to my home.

itojun


itojun[coconut:~] traceroute6 -n -q1 2001:468:1420:f:220:e0ff:fe8d:3a8c
traceroute6 to 2001:468:1420:f:220:e0ff:fe8d:3a8c (2001:468:1420:f:220:e0ff:fe8d:3a8c) 
from 2001:298:308:1:2ae:d0ff:fe00:3b, 30 hops max, 12 byte packets
 1  2001:298:308:1:200:24ff:fec0:55de  0.878 ms
 2  3ffe:8360:1000::2000  5.885 ms
 3  3ffe:8360:1000::1  5.252 ms
 4  3ffe:8360:1000:1::3  6.879 ms
 5  3ffe:8360:0:1000::1:1  7.379 ms
 6  2001:200:0:1800:230:48ff:fe41:4e50  5.001 ms
 7  2001:200:0:1800::9c4:2  5.16 ms
 8  2001:200:0:1800::9c4:0  5.142 ms
 9  2001:200:0:6c01:290:27ff:fe3a:d8  5.557 ms
10  2001:200:0:6c01:209:11ff:fedb:19fe  144.071 ms
11  2001:468:ff:b17::1  390.569 ms
12  2001:468:ff:b17::2  389.938 ms
13  2001:468:ff:1317::1  390.554 ms
14  2001:468:ff:1213::1  402.714 ms
15  2001:468:ff:6c1::1  390.262 ms
16  2001:468:ff:306::1  397.108 ms
17  2001:468:ff:354::2  419.125 ms !A



RE: How to secure the Internet in three easy steps

2002-10-27 Thread Eric M. Carroll

Sean,

At Home's policy was that servers were administratively forbidden. It
ran proactive port scans to detect them (which of course were subject to
firewall ACLs) and actioned them under a complex and changing rule set.
It frequently left enforcement to the local partner depending on
contractual arrangements. It did not block ports. Non-transparent
proxing was used for http - you could opt out if you knew how. 

While many DSL providers have taken up filtering port 25, the cable
industry practice is mostly to leave ports alone. I know of one large
cable company that did the right thing and implemented SMTP
authentication for their mail service.  The world would be a different
place if client to server mail submission was done in an authenticated
manner consistently across the Internet. Its amazing how many ISPs don't
implement this best practice.

Regards,

Eric Carroll

-Original Message-
From: [EMAIL PROTECTED] [mailto:owner-nanog@;merit.edu] On Behalf Of
Sean Donelan
Sent: October 25, 2002 5:36 PM
To: Paul Vixie
Cc: [EMAIL PROTECTED]
Subject: Re: How to secure the Internet in three easy steps 



On Fri, 25 Oct 2002, Paul Vixie wrote:
> > Not only that, but unless _everyone_ implements 2 and/or 3, all the 
> > bad people that exploit the things these are meant to protect will 
> > migrate to the networks that lack these measures, mitigating the 
> > benefits.
>
> not just the bad people.  all the people.  a network with 2 or 3 in 
> place is useless.  there is no way to make 2 or 3 happen.

AOL?  I believe they proxy almost all their subscribers through several
large datacenters, and don't allow users to run their own servers.

@Home prohibited customer servers on their network, blocked several
ports, and proxied several services.

Its common for ISPs outside of the US to force their customers to use
the ISP's web proxy server, even hijacking connections which attempt to
bypass it.

As part of their anti-spam efforts, several providers block SMTP port
25, and force their subscribers to only use that provider's SMTP
relay/proxy to send mail.  Why not extend those same restrictions to
other (all) protocols?

Many corporate networks already proxy all their user's traffic, and
prohibit direct connections through the corporate firewalls.

I think its a bad idea, but techincally I have a hard time saying its
technically impossible.




Re: [Re: the cost of carrying routes]

2002-10-27 Thread Kurt Erik Lindqvist



egal requirements to "the bottom line".  If a site is paying you for 
transit,
there's a very strong *dis*incentive to take any action that would 
prevent a
DDoS attack - the bottom line says the Right Thing is to install just 
enough
traffic shaping so a DDoS won't melt *your* net, and bill for the 
traffic. ;)

Not really true. I have to carry that traffic through my backbone and 
in doing, the DDOS traffic might take out or affect other services such 
as IP-VPNs (that would probably generate more money anyway).

Best regards,

- kurtis -



2 breaks on TAT 14

2002-10-27 Thread Jesper Skriver

Hi,

It seems that there is 2 breaks on TAT 14, one between Manasquan (US)
and Blaabjerg (DK) and one somewhere between Blaabjerg and Pentewan,
rumors say somewhere in Holland.

The first seems to be some days old, the second failed around 12:20 CET
yesterday.

Rumors also say one of failures will be fixed around 18:00 CET today.

Does anyone have more details ?

/Jesper

-- 
Jesper Skriver, jesper(at)skriver(dot)dk  -  CCIE #5456

One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.



Re: Odd behavior

2002-10-27 Thread Scott Granados

We've seen a lot! of this, thousands of matches per hour when we put in an
acl.  We were under Ddos some time ago and all the requests were on port
137. A simple filter on netbios-ns on my upstream fixed it but its uggly.

- Original Message -
From: "Joe" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, October 26, 2002 5:24 PM
Subject: Odd behavior


>
>
>
> Anyone noticing an increase in the amount of port 137 scans?
> I've seen just just over 100 in the last 1 hour. When I probe the offender
> I see them as MS items with their Harddrives shared wide open.
> Only thing in common is they all appear to have some file called put.ini
in
> their root directory with a line that looks to be from a win.ini and
states
> brasil.pif or exe. Maybe some new virus?
> Well heads up.
>
> Cheers
> -Joe
>
>