Mailing List Archive: NANOG: users

ISP port blocking practice

1 2 3

View All

Index | Next | Previous | View Threaded

jmaimon at ttec

Oct 25, 2009, 5:52 PM

Post #51 of 57 (95 views)
Permalink

Re: ingress filtering and multiple Internet conenctions [In reply to]

Joe Greco wrote:
>> Joe Greco wrote:

>>
>> Right now things still suck pretty hard, depending on what you are using.
>
> Who defines what "The Right Thing" is?

The right thing is to allow the operator to twiddle the knobs so that
everything works properly with multiple internet connections
specifically when the ISP is using BCP38.

> Basically, allowing this dooms BCP38.
>
> ... JG

Basically getting this wrong dooms BCP38.

owen at delong

Oct 25, 2009, 8:51 PM

Post #52 of 57 (93 views)
Permalink

Re: ingress filtering and multiple Internet conenctions [In reply to]

On Oct 25, 2009, at 4:05 PM, Joe Maimon wrote:

>
>
> Joe Greco wrote:
>
>> There's a problem: I can validly emit a variety of other
>> addresses, in
>> particular any address in 206.55.64.0/20 and some other networks.
>> I am
>> not "forging" packets if I emit 206.55.64.0/20-sourced addresses
>> down a
>> Comcast pipe.
>> How many people realistically have this problem? Well, potentially,
>> lots. Anyone who uses a VPN could have a legitimate IP address on
>> their
>> machine; because of BCP38 (and other security policy) it is common
>> for a VPN setup to forward Internet-bound traffic back to the VPN
>> server rather than directly out the Internet. In some cases, one
>> could
>> reasonably argue that this is undesirable.
>
>
> I would like to take the opportunity to urge vendors of routers and
> firewalls to take extra special care and attention to make sure that
> The Right Thing can always happen whenever multiple egress services
> are employed.
>
> This means that policy routing for network AND ALL locally generated
> traffic should be available and work as the operator intends it to.
>
This includes the ability to turn OFF stateful inspection in all cases
if desired, and, full ability to
support asymmetrical (or Triangle) routing in cases where it is desired.

Also, not breaking PMTU-D would be good.

> Right now things still suck pretty hard, depending on what you are
> using.
>
Indeed.

Owen

Attachments:

smime.p7s (2.06 KB)

owen at delong

Oct 25, 2009, 8:52 PM

Post #53 of 57 (93 views)
Permalink

Re: ingress filtering and multiple Internet conenctions [In reply to]

On Oct 25, 2009, at 4:58 PM, Joe Greco wrote:

>> Joe Greco wrote:
>>> There's a problem: I can validly emit a variety of other
>>> addresses, in
>>> particular any address in 206.55.64.0/20 and some other networks.
>>> I am
>>> not "forging" packets if I emit 206.55.64.0/20-sourced addresses
>>> down a
>>> Comcast pipe.
>>>
>>> How many people realistically have this problem? Well, potentially,
>>> lots. Anyone who uses a VPN could have a legitimate IP address on
>>> their
>>> machine; because of BCP38 (and other security policy) it is common
>>> for a VPN setup to forward Internet-bound traffic back to the VPN
>>> server rather than directly out the Internet. In some cases, one
>>> could
>>> reasonably argue that this is undesirable.
>>
>> I would like to take the opportunity to urge vendors of routers and
>> firewalls to take extra special care and attention to make sure
>> that The
>> Right Thing can always happen whenever multiple egress services are
>> employed.
>>
>> This means that policy routing for network AND ALL locally generated
>> traffic should be available and work as the operator intends it to.
>>
>> Right now things still suck pretty hard, depending on what you are
>> using.
>
> Who defines what "The Right Thing" is?
>
> Allowing (what are to the service provider) random IP's inbound, even
> if there's some mechanism to limit it, means that the ISP now has some
> additional responsibilities to be able to transport packets for space
> that isn't theirs; a transit upstream or peer might filter, especially
> for smaller service providers.
>
> Basically, allowing this dooms BCP38.
>
Allowing the operator the configuration OPTION in all cases is good.
Rational defaults in favor of BCP-38 are acceptable. The inability to
override those defaults is bad.

Owen

Attachments:

smime.p7s (2.06 KB)

nanog-post at rsuc

Oct 26, 2009, 3:03 AM

Post #54 of 57 (85 views)
Permalink

Re: ISP port blocking practice [In reply to]

[tangent of interst for the archives]

On Sat, Oct 24, 2009 at 02:07:42PM -0500, Joe Greco wrote:
[snip]
> If I'm assigned 24.1.2.3 by Comcast, and Comcast filters my ingress to
> prevent me from emitting other addresses, you claim that's fine because
> it's BCP38.
>
> There's a problem: I can validly emit a variety of other addresses, in
> particular any address in 206.55.64.0/20 and some other networks. I am
> not "forging" packets if I emit 206.55.64.0/20-sourced addresses down a
> Comcast pipe.

Only in your service agreement allows this. Most folks realized both
- the bad guys figured out this 'triangle routing' ages ago (was common
to send bulk abuse traffic down broadband and receive the ack stream
on dialup Back In The Day) and specificlly disallow it.
- such hacks to attempt multihoming without BGP fail in spectacular
ways nd can't be reled on for any real traffic.

So while you may have an allocation and therefore not be 'forging' by
strict definitions, you are injecting martian traffic as far as the
resi broadband provider is concerned and it should be dropped.

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

rbonica at juniper

Nov 3, 2009, 12:21 PM

Post #55 of 57 (55 views)
Permalink

Re: ISP port blocking practice [In reply to]

Folks,

I would love to see the IETF OPSEC WG publish a Best Common Practices
document on ISP Port filtering. The document would capture information
similar to that offered by Justin.

Would anybody on this list be willing to author an Internet Draft?

Ron
(co-director IETF O&M Area)

Justin Shore wrote:
> Zhiyun Qian wrote:
>> Hi all,
>>
>> What is the common practice for enforcing port blocking policy (or what
>> is the common practice for you and your ISP)? More specifically, when
>> ISPs try to block certain outgoing port (port 25 for instance), they
>> could do two rules:
>> 1). For any outgoing traffic, if the destination port is 25, then drop
>> the packets.
>> 2). For any incoming traffic, if the source port is 25, then drop the
>> packets.
>
> I block on both generally. I block inbound and outbound for residential
> customers in dynamic pools. I block inbound only for residential with
> statically-assigned IPs. That way a customer can request (and pay for)
> a static IP and be able to get around out outbound SMTP block. Few
> companies use the MSP port (tcp/587). I'm not sure why more don't make
> the effort but most don't. To make up for that we allow static
> residential customers to evade that filter with a static IP. We still
> block inbound though. We also allow them to use our SMTP servers and
> SmartHosts if they want with no requirements on source domains (like
> some providers require, essentially requiring the customer to advertise
> for you). The inbound block isn't really all that useful as you elude
> to. However I use it more often than not to look for people scanning
> out ranges for open relays. I use that data for feed my RTBH trigger
> router and drop the spammer's traffic on the floor (or the poor,
> unfortunate owner of the compromised PC that's been 0wned.
>
> We block several other things too. Netbios traffic gets dropped both
> ways. MS-SQL traffic gets dropped both ways (a few users have
> complained about this but very few stick to their guns when you point
> out that their traffic is traversing the web completely unencrypted). I
> block default and common proxy ports such as 3128, 7212, and 6588 in
> both directions. Squid is too easy to misconfigure (done it myself).
> GhostSurf and WinGate have both been abusable as open proxies in various
> releases. I also block 8000, 8080 and 8081 towards the customers.
> These are some of our most commonly scanned ports (usually all 3 at once
> plus some or all of the 80xx ones). I've encountered many compromised
> residential CPEs that the users either enabled themselves or were
> enabled by default. I don't block those 3 ports on outbound flows
> though; too many false positives.
>
> And finally we also block several different types of ICMPs. First off
> we block ICMP fragments. Then we permit echo, echo-reply,
> packet-too-big, and time-exceeded. The rest get explicitly dropped.
> IPv6 will change this list dramatically. I haven't had time to research
> ICMPv6 thoroughly enough to say any more than that.
>
> Basically I just pick out some of the really bad ports and block them.
> This gives me a wealth of data with which to null-route compromised PCs
> scanning my networks.
>
>> Also, is it common that the rules are based on tcp flags (e.g. SYN,
>> SYN-ACK)? One would think block SYN packet is good enough.
>
> I don't get that deep into it. Forged packets of types other than SYN
> can still reek havoc on existing flows. I think it's better to block
> all and move on.
>
> Justin
>
>
> .
>

mark at edgewire

Nov 3, 2009, 5:51 PM

Post #56 of 57 (54 views)
Permalink

Re: ISP port blocking practice [In reply to]

Hi all,

Just out of curiosity for those whom may manage Hotel Wifi networks (I
know I know, not really ISP level but since we're on the topic of port
blocking). Does anyone actually make an effort to be blocking port
443? I've had that experience at a few Hotels in Philippines and I
can't think of a valid reason as to why those ports would be dropping
traffic. Would like to hear from anyone whom has had this experience.

Best regards,

Mark

On 04-Nov-2009, at 4:21 AM, Ron Bonica wrote:

> Folks,
>
> I would love to see the IETF OPSEC WG publish a Best Common Practices
> document on ISP Port filtering. The document would capture information
> similar to that offered by Justin.
>
> Would anybody on this list be willing to author an Internet Draft?
>
> Ron
> (co-director IETF O&M Area)
>
> Justin Shore wrote:
>> Zhiyun Qian wrote:
>>> Hi all,
>>>
>>> What is the common practice for enforcing port blocking policy (or
>>> what
>>> is the common practice for you and your ISP)? More specifically,
>>> when
>>> ISPs try to block certain outgoing port (port 25 for instance), they
>>> could do two rules:
>>> 1). For any outgoing traffic, if the destination port is 25, then
>>> drop
>>> the packets.
>>> 2). For any incoming traffic, if the source port is 25, then drop
>>> the
>>> packets.
>>
>> I block on both generally. I block inbound and outbound for
>> residential
>> customers in dynamic pools. I block inbound only for residential
>> with
>> statically-assigned IPs. That way a customer can request (and pay
>> for)
>> a static IP and be able to get around out outbound SMTP block. Few
>> companies use the MSP port (tcp/587). I'm not sure why more don't
>> make
>> the effort but most don't. To make up for that we allow static
>> residential customers to evade that filter with a static IP. We
>> still
>> block inbound though. We also allow them to use our SMTP servers and
>> SmartHosts if they want with no requirements on source domains (like
>> some providers require, essentially requiring the customer to
>> advertise
>> for you). The inbound block isn't really all that useful as you
>> elude
>> to. However I use it more often than not to look for people scanning
>> out ranges for open relays. I use that data for feed my RTBH trigger
>> router and drop the spammer's traffic on the floor (or the poor,
>> unfortunate owner of the compromised PC that's been 0wned.
>>
>> We block several other things too. Netbios traffic gets dropped both
>> ways. MS-SQL traffic gets dropped both ways (a few users have
>> complained about this but very few stick to their guns when you point
>> out that their traffic is traversing the web completely
>> unencrypted). I
>> block default and common proxy ports such as 3128, 7212, and 6588 in
>> both directions. Squid is too easy to misconfigure (done it myself).
>> GhostSurf and WinGate have both been abusable as open proxies in
>> various
>> releases. I also block 8000, 8080 and 8081 towards the customers.
>> These are some of our most commonly scanned ports (usually all 3 at
>> once
>> plus some or all of the 80xx ones). I've encountered many
>> compromised
>> residential CPEs that the users either enabled themselves or were
>> enabled by default. I don't block those 3 ports on outbound flows
>> though; too many false positives.
>>
>> And finally we also block several different types of ICMPs. First
>> off
>> we block ICMP fragments. Then we permit echo, echo-reply,
>> packet-too-big, and time-exceeded. The rest get explicitly dropped.
>> IPv6 will change this list dramatically. I haven't had time to
>> research
>> ICMPv6 thoroughly enough to say any more than that.
>>
>> Basically I just pick out some of the really bad ports and block
>> them.
>> This gives me a wealth of data with which to null-route compromised
>> PCs
>> scanning my networks.
>>
>>> Also, is it common that the rules are based on tcp flags (e.g. SYN,
>>> SYN-ACK)? One would think block SYN packet is good enough.
>>
>> I don't get that deep into it. Forged packets of types other than
>> SYN
>> can still reek havoc on existing flows. I think it's better to block
>> all and move on.
>>
>> Justin
>>
>>
>> .
>>
>

jared at puck

Nov 3, 2009, 6:13 PM

Post #57 of 57 (54 views)
Permalink

Re: ISP port blocking practice [In reply to]

On Nov 3, 2009, at 8:51 PM, mark [at] edgewire wrote:

> Hi all,
>
> Just out of curiosity for those whom may manage Hotel Wifi networks
> (I know I know, not really ISP level but since we're on the topic of
> port blocking). Does anyone actually make an effort to be blocking
> port 443? I've had that experience at a few Hotels in Philippines
> and I can't think of a valid reason as to why those ports would be
> dropping traffic. Would like to hear from anyone whom has had this
> experience.

I've found that some public (eg: Hospital) networks have very
draconian security policies on their guest wireless. The University
of Michigan hospitals block IMAP over SSL (tcp/993), SMTP-Submit (tcp/
587) and all the vpn software I had at my disposal.

This blocking is becoming more common to force people to HTTP/HTTPS
ONLY based systems. They make utilizing these networks from a mobile
device hard, and quickly forget your mac authentication quickly and
are overall poorly run (no feedback loop to get things unblocked that
are legit).

I have found that I am having to vpn-out more often from these 'guest'
networks to obtain "real" internet access. I recommend running a few
gateways (eg: pptp, ipsec, openvpn) to get around these issues.

(I have found some well run hotel networks that intercept tcp/3128 and
send it to a local squid cache).

- Jared

1 2 3

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com