Mailing List Archive: NANOG: users

Customer-facing ACLs

1 2 3

View All

Index | Next | Previous | View Threaded

joelja at bogus

Mar 7, 2008, 9:40 PM

Post #26 of 69 (1914 views)
Permalink

Re: Customer-facing ACLs [In reply to]

Frank Bulk wrote:
> The last few spam incidents I measured an outflow of about 2 messages per
> second. Does anyone know how aggressive Telnet and SSH scanning is? Even
> if it was greater, it's my guess there are many more hosts spewing spam than
> there are running abusive telnet and SSH scans.

Judging by the hits on my firewall there's a fair amount of variation
between the scanners that are doing a couple login attempts per hour,
and the bot that's making thousands of login attempts with 4 or 5
connection attempts going at a time. We don't filter them till they hit
a threshold.

I don't even bother to log telnet attempts anymore so I can't say much
about that.

> Frank
>
> -----Original Message-----
> From: owner-nanog [at] merit [mailto:owner-nanog [at] merit] On Behalf Of Mark
> Foster
> Sent: Friday, March 07, 2008 10:02 PM
> To: Dave Pooser
> Cc: nanog [at] merit
> Subject: Re: Customer-facing ACLs
>
>
>> Blocking port 25 outbound for dynamic users until they specifically
> request
>> it be unblocked seems to me to meet the "no undue burden" test; so would
>> port 22 and 23. Beyond that, I'd probably be hesitant until I either
> started
>> getting a significant number of abuse reports about a certain flavor of
>> traffic that I had reason to believe was used by only a tiny minority of
> my
>> own users.
>>
>
> Sorry, I must've missed something.
> Port 25 outbound (excepting ISP SMTP server) seems entirely logical to me.
>
> Port 22 outbound? And 23? Telnet and SSH _outbound_ cause that much of a
> concern? I can only assume it's to stop clients exploited boxen being used
> to anonymise further telnet/ssh attempts - but have to admit this
> discussion is the first i've heard of it being done 'en masse'.
>
> It'd frustrate me if I jacked into a friends Internet in order to do some
> legitimate SSH based server administration, I imagine...
>
> Is this not 'reaching' or is there a genuine benefit in blocking these
> ports as well?
>
> Mark.
>
>
>
>

dave.nanog at alfordmedia

Mar 7, 2008, 10:59 PM

Post #27 of 69 (1912 views)
Permalink

Re: Customer-facing ACLs [In reply to]

> Port 22 outbound? And 23? Telnet and SSH _outbound_ cause that much of a
> concern? I can only assume it's to stop clients exploited boxen being used
> to anonymise further telnet/ssh attempts - but have to admit this
> discussion is the first i've heard of it being done 'en masse'.

On one test machine that I leave SSH unfirewalled on, I'll see 200-4000 SSH
login attempts per day, trying to brute force it. Lets see, this morning in
an eight-minute span from one IP in Aruba 100 attempts for root; other
usernames attempted include admin, staff, sales, office, alias, stud (!),
trash, guest, test, oracle, a few personal names, apache, svn, iraf, swsoft,
gast, sirsi and nagios. And this is a relatively slow day.

Telnet I wouldn't know about, but I'm told bots will try to force it as
well.
--
Dave Pooser, ACSA
Manager of Information Services
Alford Media http://www.alfordmedia.com

blakjak at blakjak

Mar 7, 2008, 11:44 PM

Post #28 of 69 (1898 views)
Permalink

Re: Customer-facing ACLs [In reply to]

On Sat, 8 Mar 2008, Dave Pooser wrote:

>
>> Port 22 outbound? And 23? Telnet and SSH _outbound_ cause that much of a
>> concern? I can only assume it's to stop clients exploited boxen being used
>> to anonymise further telnet/ssh attempts - but have to admit this
>> discussion is the first i've heard of it being done 'en masse'.
>
> On one test machine that I leave SSH unfirewalled on, I'll see 200-4000 SSH
> login attempts per day, trying to brute force it. Lets see, this morning in
> an eight-minute span from one IP in Aruba 100 attempts for root; other
> usernames attempted include admin, staff, sales, office, alias, stud (!),
> trash, guest, test, oracle, a few personal names, apache, svn, iraf, swsoft,
> gast, sirsi and nagios. And this is a relatively slow day.
>
> Telnet I wouldn't know about, but I'm told bots will try to force it as
> well.

Oh, there's plenty of names in one of my server logs too... looks almost
like they've gone through a name-choosing handbook.

I can understand the logic of dropping the port, but theres some
additional thought involved when looking at Port 22 - maybe i'm not
well-read enough, but the bots I've seen that are doing SSH scans, etc,
are not usually on Windows systems. I can figure them working on Linux,
MacOS systems - but surely the vast majority of 'vulnerable' hosts are
those running OS's coming from our favourite megacorp? Which typically
don't come shipped with neither SSH server nor SSH client... ?

To me, at least half the users likely to be running either Linux or Mac
are going to be the same users who're going to request they be allowed
outbound SSH.... is the blocking of outbound SSH considered to be
sufficiently useful that we're advocating it these days?

(Aren't we all just moving SSH to non-standard ports within our
networks anyway?)

... Mark.

dave.nanog at alfordmedia

Mar 8, 2008, 12:10 AM

Post #29 of 69 (1911 views)
Permalink

Re: Customer-facing ACLs [In reply to]

> I can understand the logic of dropping the port, but theres some
> additional thought involved when looking at Port 22 - maybe i'm not
> well-read enough, but the bots I've seen that are doing SSH scans, etc,
> are not usually on Windows systems. I can figure them working on Linux,
> MacOS systems - but surely the vast majority of 'vulnerable' hosts are
> those running OS's coming from our favourite megacorp? Which typically
> don't come shipped with neither SSH server nor SSH client... ?

They typically don't ship with an SMTP server either. Considering that my
preferred SSH client for Windows weighs in as a single 412k .exe, I'd
imagine that bot designers are just writing their own SSH clients for
brute-forcing.

> To me, at least half the users likely to be running either Linux or Mac
> are going to be the same users who're going to request they be allowed
> outbound SSH.... is the blocking of outbound SSH considered to be
> sufficiently useful that we're advocating it these days?

Half the Mac users? You think? I know a dozen or so sysadmins who use Macs,
and about a hundred users who wouldn't know SSH from PCP; I think that's
probably a slightly skewed sample considering I'm a Mac geek who hangs
around with Mac geeks, and I'd guess the consumer users are a larger
percentage of the real-life population. I'd expect the number of folks who
want SSH unblocked to be under 1% of a consumer broadband network, and
probably closer to 0.1% or so. And again, it ought to be trivial to let your
users unblock the system, either via phone call or via self-service Web page
(though in the latter case you'd better use a captcha or something so the
bot doesn't automatically unblock itself).
--
Dave Pooser, ACSA
Manager of Information Services
Alford Media http://www.alfordmedia.com

adrian at creative

Mar 8, 2008, 12:28 AM

Post #30 of 69 (1911 views)
Permalink

Re: Customer-facing ACLs [In reply to]

On Sat, Mar 08, 2008, Mark Foster wrote:
>

> To me, at least half the users likely to be running either Linux or Mac
> are going to be the same users who're going to request they be allowed
> outbound SSH.... is the blocking of outbound SSH considered to be
> sufficiently useful that we're advocating it these days?
>
> (Aren't we all just moving SSH to non-standard ports within our
> networks anyway?)

.. I'm surprised botnets aren't big enough right now to do surreptitious port
scans of machines (there's 'only' 64k ports nowdays!) over timeframes measured
in weeks, from arbitrary bots (ie, not a single IP) to get a scanning footprint
to later submit in the "crack" queue.

Makes me think about Google, to be honest.

Who has more machines, botnets, or google? :)

Adrian

frnkblk at iname

Mar 8, 2008, 10:10 AM

Post #31 of 69 (1912 views)
Permalink

RE: Customer-facing ACLs [In reply to]

Sorry if I wasn't more clear, but I'm not asking about inbound attempts, I'm
asking about the number of outbound attempts a host would perform.

Frank

-----Original Message-----
From: Joel Jaeggli [mailto:joelja [at] bogus]
Sent: Friday, March 07, 2008 11:41 PM
To: frnkblk [at] iname
Cc: 'Mark Foster'; Dave Pooser; nanog [at] merit
Subject: Re: Customer-facing ACLs

Frank Bulk wrote:
> The last few spam incidents I measured an outflow of about 2 messages per
> second. Does anyone know how aggressive Telnet and SSH scanning is? Even
> if it was greater, it's my guess there are many more hosts spewing spam
than
> there are running abusive telnet and SSH scans.

Judging by the hits on my firewall there's a fair amount of variation
between the scanners that are doing a couple login attempts per hour,
and the bot that's making thousands of login attempts with 4 or 5
connection attempts going at a time. We don't filter them till they hit
a threshold.

I don't even bother to log telnet attempts anymore so I can't say much
about that.

> Frank
>
> -----Original Message-----
> From: owner-nanog [at] merit [mailto:owner-nanog [at] merit] On Behalf Of
Mark
> Foster
> Sent: Friday, March 07, 2008 10:02 PM
> To: Dave Pooser
> Cc: nanog [at] merit
> Subject: Re: Customer-facing ACLs
>
>
>> Blocking port 25 outbound for dynamic users until they specifically
> request
>> it be unblocked seems to me to meet the "no undue burden" test; so would
>> port 22 and 23. Beyond that, I'd probably be hesitant until I either
> started
>> getting a significant number of abuse reports about a certain flavor of
>> traffic that I had reason to believe was used by only a tiny minority of
> my
>> own users.
>>
>
> Sorry, I must've missed something.
> Port 25 outbound (excepting ISP SMTP server) seems entirely logical to me.
>
> Port 22 outbound? And 23? Telnet and SSH _outbound_ cause that much of a
> concern? I can only assume it's to stop clients exploited boxen being used
> to anonymise further telnet/ssh attempts - but have to admit this
> discussion is the first i've heard of it being done 'en masse'.
>
> It'd frustrate me if I jacked into a friends Internet in order to do some
> legitimate SSH based server administration, I imagine...
>
> Is this not 'reaching' or is there a genuine benefit in blocking these
> ports as well?
>
> Mark.
>
>
>
>

justin at justinshore

Mar 8, 2008, 10:17 AM

Post #32 of 69 (1903 views)
Permalink

Re: Customer-facing ACLs [In reply to]

Mark Foster wrote:
>
> Port 22 outbound? And 23? Telnet and SSH _outbound_ cause that much of
> a concern? I can only assume it's to stop clients exploited boxen being
> used to anonymise further telnet/ssh attempts - but have to admit this
> discussion is the first i've heard of it being done 'en masse'.

I don't think there's much to be gained from blocking ingress 22 from
customers. I don't see any SSH scans originating from my customers
(though there is always the potential). I wouldn't have any issues with
blocking outbound telnet though but I can't really justify it either
since I don't see a real big problem with that kind of traffic
originating on my network either.

Now inbound SSH and Telnet (destined for my customers) should be blocked
IMHO. Doing a little prodding around our netspace I've found most SSH
installs to be of a known vulnerable version or at least an old version
yet to have any vulnerabilities found in. Nothing positive could come
from letting them get compromised. We would of course offer a way for
users to get around the block. Our current approach is to have them
sign up for a static IP (another $5/month). The fee keeps everyone from
automatically signing up for is as "free stuff" but still gives the
legit users an inexpensive way to get what they need.

> It'd frustrate me if I jacked into a friends Internet in order to do
> some legitimate SSH based server administration, I imagine...

Agreed but remember that people like you, I and the rest of the readers
of NANOG are a teeny tiny minority on the Internet. I could pick a
couple thousand of my users at random and not find one that knows what
SSH is.

> Is this not 'reaching' or is there a genuine benefit in blocking these
> ports as well?

I don't think there's much to be gained from blocking telnet & SSH from
the customers to the Internet. Blocking SMTP in the same direction is
critical IMHO. Blocking the same 3 ports back to the customer makes
sense to me though. I think there is a real and tangible benefit to the
exercise.

Justin

justin at justinshore

Mar 8, 2008, 10:27 AM

Post #33 of 69 (1904 views)
Permalink

Re: Customer-facing ACLs [In reply to]

It varies widely. I see some extremely slow scans (1 SYN every 2-5
minutes). This is what someone on the SANS ISC page mentioned I believe.

I've also seen scans last for up to 10 minutes. The consistency of the
speeds made me think that perhaps the scanning computer was on a slow link.

The worst scans are the ones that last a second or two and hit us with a
SYN for every IP in our allocations. That kind of scan and its flood of
packets is the one that I don't think I can stop without some sort of QoS.

I've seen coordinated scans with everything from 2 to about a dozen
different hosts scanning seemingly random IPs across our network. I
know it's coordinated though because together they hit every IP but
never hit the same IP by more than one scanner.

I've seen scans that clearly learn where the accessible SSH daemons are,
that then feed this info back to the puppet master so he can command a
different compromised host (or hosts) to then handle the attacks. I've
also see a scanner first scan our network and then immediately start
pounding on the accessible daemons. Finally I've see the scanner stop
its scan in mid-stream, pound on an accessible daemon for a while with a
pre-defined set of userids and then continue on with the scans.

Clearly there's some variation in the scanning methods.

Justin

Frank Bulk wrote:
> The last few spam incidents I measured an outflow of about 2 messages per
> second. Does anyone know how aggressive Telnet and SSH scanning is? Even
> if it was greater, it's my guess there are many more hosts spewing spam than
> there are running abusive telnet and SSH scans.

frnkblk at iname

Mar 8, 2008, 11:54 AM

Post #34 of 69 (1900 views)
Permalink

RE: Customer-facing ACLs [In reply to]

While I don't do flow monitoring today, when monitoring for outbound spam
with Wirekshark I have seen hosts systematically check all the hosts in the
block for an open SMTP port. I'm sure a lot more is going on that I don't
know. The patterns are obvious to the human observer -- too bad that such
logic isn't built into the firewall. I know there are some enterprise
security admins that subscribe to the approach that all inbound and outbound
traffic is blocked by defacto, with a few ports opened up in either
direction for known applications. Of course, port 80 becomes the port of
choice for all the undesired apps.

Frank

-----Original Message-----
From: Justin Shore [mailto:justin [at] justinshore]
Sent: Saturday, March 08, 2008 12:28 PM
To: frnkblk [at] iname
Cc: 'Mark Foster'; Dave Pooser; nanog [at] merit
Subject: Re: Customer-facing ACLs

It varies widely. I see some extremely slow scans (1 SYN every 2-5
minutes). This is what someone on the SANS ISC page mentioned I believe.

I've also seen scans last for up to 10 minutes. The consistency of the
speeds made me think that perhaps the scanning computer was on a slow link.

The worst scans are the ones that last a second or two and hit us with a
SYN for every IP in our allocations. That kind of scan and its flood of
packets is the one that I don't think I can stop without some sort of QoS.

I've seen coordinated scans with everything from 2 to about a dozen
different hosts scanning seemingly random IPs across our network. I
know it's coordinated though because together they hit every IP but
never hit the same IP by more than one scanner.

I've seen scans that clearly learn where the accessible SSH daemons are,
that then feed this info back to the puppet master so he can command a
different compromised host (or hosts) to then handle the attacks. I've
also see a scanner first scan our network and then immediately start
pounding on the accessible daemons. Finally I've see the scanner stop
its scan in mid-stream, pound on an accessible daemon for a while with a
pre-defined set of userids and then continue on with the scans.

Clearly there's some variation in the scanning methods.

Justin

Frank Bulk wrote:
> The last few spam incidents I measured an outflow of about 2 messages per
> second. Does anyone know how aggressive Telnet and SSH scanning is? Even
> if it was greater, it's my guess there are many more hosts spewing spam
than
> there are running abusive telnet and SSH scans.

jay at west

Mar 8, 2008, 12:58 PM

Post #35 of 69 (1903 views)
Permalink

Re: Customer-facing ACLs [In reply to]

Dave Pooser wrote:

> Half the Mac users? You think? I know a dozen or so sysadmins who use Macs,

[raises hand...]

> and about a hundred users who wouldn't know SSH from PCP; I think that's
> probably a slightly skewed sample considering I'm a Mac geek who hangs
> around with Mac geeks, and I'd guess the consumer users are a larger
> percentage of the real-life population.

I was quite surprised to see the large number of Mac laptops at NANOG
42. I didn't do a formal count but it seemed like about 1/4 to 1/3 of
the laptops in use were Macs.

> I'd expect the number of folks who
> want SSH unblocked to be under 1% of a consumer broadband network, and
> probably closer to 0.1% or so. And again, it ought to be trivial to let your
> users unblock the system, either via phone call or via self-service Web page
> (though in the latter case you'd better use a captcha or something so the
> bot doesn't automatically unblock itself).

I'm against the slippery slope of blocking ports by default, with the
possible exception of SMTP if the provider offers a well-publicized
local SMTP server.

Servers that must leave ssh open to the Internet can and should consider
using some form of time-out script like this one:
http://www.pettingers.org/code/SSHBlack.html

--
Jay Hennigan - CCIE #7880 - Network Engineering - jay [at] impulse
Impulse Internet Service - http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

bill.norton at gmail

Mar 8, 2008, 2:40 PM

Post #36 of 69 (1915 views)
Permalink

Re: Customer-facing ACLs [In reply to]

>
> I was quite surprised to see the large number of Mac laptops at
> NANOG 42. I didn't do a formal count but it seemed like about 1/4
> to 1/3 of the laptops in use were Macs.

...You know, now that you mention it, I was also quite impressed with
how many macbook pros there were in room as well. That would be good
to informally track I think :

what tools(laptops) do NANOG folk tend to use?

as this data might help SW dev types to target their netTools
distributions to mac platforms more quickly.

In the good ole days it seemed like 99% were PCs & maybe a couple were
reinstalled with some form of unix, and the rare and incompatible
couple of macs in the room were driven by freaks speaking a different
language (appletalk) and hitting weirder clover keys than the rest of
us.

Now, Apple seems to be the neteng laptop of choice, what the cool kids
drive.

Bill

mtinka at globaltransit

Mar 8, 2008, 7:24 PM

Post #37 of 69 (1918 views)
Permalink

Re: Customer-facing ACLs [In reply to]

On Saturday 08 March 2008, Justin Shore wrote:

> What kind of customer-facing filtering do you do (ingress
> and egress)? This of course is dependent on the type of
> customer, so lets assume we're talking about an average
> residential customer.

We supply to mid-to-small ISP's mostly, and sizeable
enterprise customers; so the degree to which we can filter
is limited.

That said, at the edge, we run uRPF on all customer-facing
ports (loose or strict, depending on the deployment).

In addition, on each edge router's core-facing uplinks, we
run egress ACL's matching RFC 1918 and RFC 3330 (yes, with
uRPF downstream to the customers, this might seem
redundant, but we've actually seen some 'catches', so it
appears to help us solidify our filtering implementation).

In the core, we don't filter or run uRPF, for obvious
reasons.

On our border routers, we deploy ingress filters, again,
cutting off RFC 1918 and RFC 3330.

On peering routers (private peering and exchange points), we
run uRPF on our peering interface (taking care to run loose
mode in case private peers also peer at the public exchange
point). Again, upstream ACL's are implemented on
core-facing uplinks to "double-check".

As you can tell, we don't filter
protocols/ports/applications. We leave that to the
customer, and insist on it.

All the above goes for IPv6 as well, as appropriate.

We are also quite picky about NLRI filtering (BGP), but
that's beyond this scope :-).

Hope this helps.

Cheers,

Mark.

Attachments:

signature.asc (0.81 KB)

justin at justinshore

Mar 9, 2008, 3:56 PM

Post #38 of 69 (1900 views)
Permalink

Re: Customer-facing ACLs [In reply to]

Dave Pooser wrote:
>> I can understand the logic of dropping the port, but theres some
>> additional thought involved when looking at Port 22 - maybe i'm not
>> well-read enough, but the bots I've seen that are doing SSH scans, etc,
>> are not usually on Windows systems. I can figure them working on Linux,
>> MacOS systems - but surely the vast majority of 'vulnerable' hosts are
>> those running OS's coming from our favourite megacorp? Which typically
>> don't come shipped with neither SSH server nor SSH client... ?
>
> They typically don't ship with an SMTP server either. Considering that my
> preferred SSH client for Windows weighs in as a single 412k .exe, I'd
> imagine that bot designers are just writing their own SSH clients for
> brute-forcing.

Or are simply writing a bot that sens TCP SYNs to port 22 and are
reporting those hosts that responds with a SYN ACK back to the C&C.
Then the C&C can direct other compromised hosts with a more complete
rootkit (or compromised *nix host) to do brute-force userid/password
guessing.

> Half the Mac users? You think? I know a dozen or so sysadmins who use Macs,
> and about a hundred users who wouldn't know SSH from PCP; I think that's
> probably a slightly skewed sample considering I'm a Mac geek who hangs
> around with Mac geeks, and I'd guess the consumer users are a larger
> percentage of the real-life population. I'd expect the number of folks who
> want SSH unblocked to be under 1% of a consumer broadband network, and
> probably closer to 0.1% or so. And again, it ought to be trivial to let your
> users unblock the system, either via phone call or via self-service Web page
> (though in the latter case you'd better use a captcha or something so the
> bot doesn't automatically unblock itself).

Agreed. I don't think the end-user's OS makes them more or less likely
to be using SSH unless the OS is a BSD or Linux (then I suspect you'd
get a disproportionate # of SSH users compared to the other more simple
OSs).

Justin

cmarlatt at rxsec

Mar 10, 2008, 7:10 AM

Post #39 of 69 (1899 views)
Permalink

Re: Customer-facing ACLs [In reply to]

Dave Pooser wrote:
>
> Do bots try brute force attacks on Telnet and FTP? All I see at my firewall
> are SSH attacks and spam. But sure, if there's a lot of Telnet abuse block
> 23 too; I think it's used about as rarely by "normal" customers as SSH is.
>

Depending on the ip space I find FTP brute force attacks 10 times more
common than SSH attacks. There really isn't a blanket rule you can impose.

On a different note, unless you clearly advertise that you're offering
filtered services I don't really find the practice ethical - and no a
tiny line in the TOS doesn't really cut it IMHO.

That doesn't mean it can't be done, simply spin the imposed ACL as a
value-add and that your customers are now on a "safer internet".

Regards,

Chris

adrian at creative

Mar 10, 2008, 7:53 AM

Post #40 of 69 (1898 views)
Permalink

Re: Customer-facing ACLs [In reply to]

> >Do bots try brute force attacks on Telnet and FTP? All I see at my firewall
> >are SSH attacks and spam. But sure, if there's a lot of Telnet abuse block
> >23 too; I think it's used about as rarely by "normal" customers as SSH is.
> >
>
> Depending on the ip space I find FTP brute force attacks 10 times more
> common than SSH attacks. There really isn't a blanket rule you can impose.
>
> On a different note, unless you clearly advertise that you're offering
> filtered services I don't really find the practice ethical - and no a
> tiny line in the TOS doesn't really cut it IMHO.
>
> That doesn't mean it can't be done, simply spin the imposed ACL as a
> value-add and that your customers are now on a "safer internet".

Does anyone have any handy links to actual raw data and papers about this?

I'm sure we've all got our own personal datapoints to support automated
network probes but I'd prefer to stuff something slightly more concrete
and official(!) into the Wiki.

Adrian

justin at justinshore

Mar 10, 2008, 8:23 AM

Post #41 of 69 (1898 views)
Permalink

Re: Customer-facing ACLs [In reply to]

Adrian Chadd wrote:
> Does anyone have any handy links to actual raw data and papers about this?
>
> I'm sure we've all got our own personal datapoints to support automated
> network probes but I'd prefer to stuff something slightly more concrete
> and official(!) into the Wiki.

SANS ISC might have some useful reports. I see a few links in this article:

http://www.incidents.org/diary.html?storyid=4045

Justin

sean at donelan

Mar 10, 2008, 9:57 AM

Post #42 of 69 (1902 views)
Permalink

Re: Customer-facing ACLs [In reply to]

On Fri, 7 Mar 2008, Scott Weeks wrote:
>> To me there is no question of whether or not you filter traffic for
>> residential broadband customers.
>
> SBC in my area (Dallas) went from wide open to outbound 25 blocked by
> default/opened on request. I think doing the same thing with port 22 would
> hardly be an undue burden on users, and would help keep botnets in check.
> ------------------------------------------------
>
> Might as well do TCP 20, 21 and 23, too. Woah, that slope's getting slippery!

Depends on how you ask the questions.

How about: Should a statefull firewall be provided for casual broadband
dynamic Internet access connections by default? Users may change the
default settings of the stateful firewall as they choose.
1. Unsolicited inbound (to user LAN) traffic

Are there LAN-only protocols and other data packets which shouldn't be
accepted on WAN Internet access links without prior coordination (if
ever)?
1. Anti-spoofing controls of source addresses
2. Proxy/gratitious ARP, ICMP redirects, DHCP server->client, RIP?
3. "Local" multicast data and broadcasts
4. "Sanity" checks of IP headers (i.e. source==destination,
loopback, etc) which should never appear on the wire
5. Layer 2 non-Internet (non-IP, non-IPv6, non-ARP, non-PPPOE)

Are there some protocols that should have prior coordination when using
some Internet access types, e.g. dynamic or unauthenticated connections?
1. outbound to off-net SMTP (port 25) instead of MSA (port 587)
2. NetBios over TCP, the exploding Microsoft protocol?

surfer at mauigateway

Mar 10, 2008, 11:53 AM

Post #43 of 69 (1901 views)
Permalink

Re: Customer-facing ACLs [In reply to]

Long response with answers inline...

--- sean [at] donelan wrote:---------------------------
> Might as well do TCP 20, 21 and 23, too. Woah, that slope's getting slippery!

Depends on how you ask the questions.

How about: Should a statefull firewall be provided for casual broadband
dynamic Internet access connections by default? Users may change the
default settings of the stateful firewall as they choose.
1. Unsolicited inbound (to user LAN) traffic
-----------------------------------------------------

The ultimate answer is: It depends. :-) As you know, it depends on your network and who your users are. My experiences are with a global network of cold potato routing for high-end enterprises, a 10,000 person university and, currently, a state-wide ILEC. In these networks no, internet access should not be closed partially by default and then allowed to be opened by a user.

Little tutus out in Hana are not going to be able to figure it out when trying to use things their keiki on the mainland are telling them to use that're not on port 80. College students are just going to open everything so they don't have to worry blockages of the newest, kewlest thing to start up that they want to try. Enterprises want to be in as complete control of their services as possible, so perhaps there, if they all have technically adept network folks.

-----------------------------------------------------
Are there LAN-only protocols and other data packets which shouldn't be
accepted on WAN Internet access links without prior coordination (if
ever)?
1. Anti-spoofing controls of source addresses
2. Proxy/gratitious ARP, ICMP redirects, DHCP server->client, RIP?
3. "Local" multicast data and broadcasts
4. "Sanity" checks of IP headers (i.e. source==destination,
loopback, etc) which should never appear on the wire
5. Layer 2 non-Internet (non-IP, non-IPv6, non-ARP, non-PPPOE)

Are there some protocols that should have prior coordination when using
some Internet access types, e.g. dynamic or unauthenticated connections?
1. outbound to off-net SMTP (port 25) instead of MSA (port 587)
2. NetBios over TCP, the exploding Microsoft protocol?
------------------------------------------------------

The first 1-5...OK, possibly, but that isn't what the person was speaking about.

The second 1-2, no, unless it's VERY clear to your customers upfront. I used to be of the 'second 1-2' opnion, but I've since changed my mind on the kind of networks I help operate. It's funny (in a sick kind of way) how much stuff you can break when you filter unless you have the time to do a *very complete* traffic analysis over an extended time period. Folks do all sorts of crazy crap that I think they shouldn't do (off-LAN Micro$loth file sharing, for example), but are doing and some have done for a long time.

The hard part is I now always take over networks that have been in operation a long time and enabling these policies can be very painful after the fact. Establishing them when the network is new is a different story.

scott

sean at donelan

Mar 10, 2008, 12:30 PM

Post #44 of 69 (1909 views)
Permalink

Re: Customer-facing ACLs [In reply to]

On Mon, 10 Mar 2008, Scott Weeks wrote:
> The hard part is I now always take over networks that have been in
> operation a long time and enabling these policies can be very painful
> after the fact. Establishing them when the network is new is a
> different story.

Whatever you decide, whether you know what the policies are or not, there
are always have a set of default network policies.

The question is do you explain to you customers just as carefully what
your default policy doesn't do, as well as what it does. Do you take
just as much time to carefully explain the risks and what may break to
your customers of allowing that traffic as you would of not allowing that
traffic.

It seems to be very painful whatever decision is made.

surfer at mauigateway

Mar 10, 2008, 1:05 PM

Post #45 of 69 (1896 views)
Permalink

Re: Customer-facing ACLs [In reply to]

---------- sean [at] donelan wrote: ----------
On Mon, 10 Mar 2008, Scott Weeks wrote:

> The hard part is I now always take over networks that have been in
> operation a long time and enabling these policies can be very painful
> after the fact. Establishing them when the network is new is a
> different story.

Whatever you decide, whether you know what the policies are or not, there
are always have a set of default network policies.

The question is do you explain to you customers just as carefully what
your default policy doesn't do, as well as what it does. Do you take
just as much time to carefully explain the risks and what may break to
your customers of allowing that traffic as you would of not allowing that
traffic.

It seems to be very painful whatever decision is made.
-------------------------------------------------

The default policy is we allow eveything. It takes no explaining.

I understand the port 25 issue and am reconsidering it for dynamic addresses on outbound traffic, but at least one person on NANOG showed me a use of that. Like network engineers at many other companies, I'm spread so thin that it's hard to find the time to do work like this and I keep putting it on the back burner. VZ had it completely open and I have followed that as we seperated this network from their network, as I can't take on the extra work of fixing brokenness that would result from applying the filter.

scott

mailinglist at bangky

Mar 10, 2008, 4:58 PM

Post #46 of 69 (1902 views)
Permalink

Customer-facing ACLs [In reply to]

Hi Justin (and all others on-list)

I understand your grounds for blocking outbound SMTP for your customers
(especially those on dynamic IP connections).
It probably will do good to block infected customers that are spewing
spam all over the world.

However, considering the number of mobile workers out there who send
email via their laptops to corporate SMTP servers, won't blocking
outbound SMTP affect them?

Since these corporate types (I'm guessing here) are probably unaware of
how to change their email client's SMTP configurations, chances are that
blocking outbound SMTP will probably cause quite a lot of pain.

After all, there are also those who frequently move from place to place
so they're going to have to keep changing SMTP servers every time they
go to a new place that's on a different ISP.

Cheers
--
ANG Kah Yik (bangky)

andy at xecu

Mar 10, 2008, 5:12 PM

Post #47 of 69 (1906 views)
Permalink

Re: Customer-facing ACLs [In reply to]

On Tue, 11 Mar 2008, Ang Kah Yik wrote:

>
> Hi Justin (and all others on-list)
>
> I understand your grounds for blocking outbound SMTP for your customers
> (especially those on dynamic IP connections).
> It probably will do good to block infected customers that are spewing spam all
> over the world.
>
> However, considering the number of mobile workers out there who send email via
> their laptops to corporate SMTP servers, won't blocking outbound SMTP affect
> them?
>
> Since these corporate types (I'm guessing here) are probably unaware of how to
> change their email client's SMTP configurations, chances are that blocking
> outbound SMTP will probably cause quite a lot of pain.
>
> After all, there are also those who frequently move from place to place so
> they're going to have to keep changing SMTP servers every time they go to a
> new place that's on a different ISP.

For what it's worth, that's what port 587 was created for.

And wouldn't those corporate types require VPN to access the network?

On top of that, most who "block" 25 don't block it but direct it to
internal mail servers where it can be subjected to limits and filtering.

Andy

---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---

mailinglist at bangky

Mar 10, 2008, 5:40 PM

Post #48 of 69 (1897 views)
Permalink

Re: Customer-facing ACLs [In reply to]

Hi Andy (and all who responded),

Thanks for the heads-up on the redirection on SMTP traffic. I've yet to
see an implementation of it but I agree that it's a possible solution.

As for the issue I raised previously, perhaps corporate users isn't a
good example but what about users of email services such as Gmail and
the like?
Some users do use the SMTP service instead of the web interface. But
redirection should do the trick.

And thanks to all who remind me about rfc 2476 - I'm not a mail admin so
I'm not familiar with it but I'll read up on it.

Andy Dills wrote:
> And wouldn't those corporate types require VPN to access the network?
>
> On top of that, most who "block" 25 don't block it but direct it to
> internal mail servers where it can be subjected to limits and filtering.
>
> Andy
>
> ---
> Andy Dills
> Xecunet, Inc.
> www.xecu.net
> 301-682-9972
> ---
>
> For what it's worth, that's what port 587 was created for.

mack at exchange

Mar 10, 2008, 5:49 PM

Post #49 of 69 (1900 views)
Permalink

Customer-facing ACLs [In reply to]

> ------------------------------
>
> Date: Tue, 11 Mar 2008 07:58:01 +0800
> From: Ang Kah Yik <mailinglist [at] bangky>
> Subject: Customer-facing ACLs
>
> Hi Justin (and all others on-list)
>
> I understand your grounds for blocking outbound SMTP for your customers
> (especially those on dynamic IP connections).
> It probably will do good to block infected customers that are spewing
> spam all over the world.
>
> However, considering the number of mobile workers out there who send
> email via their laptops to corporate SMTP servers, won't blocking
> outbound SMTP affect them?
>
> Since these corporate types (I'm guessing here) are probably unaware of
> how to change their email client's SMTP configurations, chances are
> that
> blocking outbound SMTP will probably cause quite a lot of pain.
>
> After all, there are also those who frequently move from place to place
> so they're going to have to keep changing SMTP servers every time they
> go to a new place that's on a different ISP.
>
> Cheers
> - --
> ANG Kah Yik (bangky)
>
> ------------------------------

One would hope mobile commuters are using something more secure
than just raw SMTP to send e-mail if their network admins have
any sense. The usual combination requires a POP connection first
or uses a port other than 25 to send. As a customer my home DSL
service provider (SBC) blocks port 25 by default. Many firewalls can
be programmed to allow 'related' connections. Ie. if a POP connection
is opened then allow the SMTP connection.

The real solution is to move to imap or msa (port 587) or the latest
MS exchange protocol (whatever it is).

As for blocking FTP and SSH, it would depend A LOT on your customer base.

As a content provider we do not allow raw NetBios into our network.
Anyone that wants to use remote file sharing to work on their windows server
is encouraged (Whips and Chains if necessary) to use a VPN tunnel.

If you are going to block something, block port 135 both directions.

--
LR Mack McBride
Network Administrator
Alpha Red, Inc.

sean at donelan

Mar 10, 2008, 6:52 PM

Post #50 of 69 (1909 views)
Permalink

Re: Customer-facing ACLs [In reply to]

On Mon, 10 Mar 2008, Scott Weeks wrote:
> The default policy is we allow eveything. It takes no explaining.

If you don't bother to explain to the same customers who you believe
couldn't figure out how to change the default settings, what the
risks and how to protect their computers on the Internet, is it any
wonder that normal user's have such a difficult time being safe on the
Internet?

> I understand the port 25 issue and am reconsidering it for dynamic
> addresses on outbound traffic, but at least one person on NANOG showed
> me a use of that. Like network engineers at many other companies, I'm
> spread so thin that it's hard to find the time to do work like this and
> I keep putting it on the back burner. VZ had it completely open and I
> have followed that as we seperated this network from their network, as
> I can't take on the extra work of fixing brokenness that would result
> from applying the filter.

Like I said, there is always a default policy whether you know what
that policy is or not. You probably end up spending the resources on
the front-end or on the back-end.

Implementing source address verification can take years, but if you
never start, you will never finish.

Implementing sanity checks for IP headers can take years, but if you
never start, you will never finish.

Implementing unsolicited/unwanted traffic controls can take years, but
if you never start, you will never finish.

Do you think caller-id/call-blocking/harrassing-call-trace were easy, or
rather they took years of hard work. Although the technology may change,
people seem to stay the same. And people seem to be adept at doing the
same stuff with new technology to other people.

1 2 3

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads