Zen internet shocker

I'm gutted. My Idol has feet of clay.

I commissioned a new adsl connection from them, first of several to be
migrated. I checked and double checked that they implemented no port
blocking or traffic management.

Today, day one, I had a problem. THE problem. Accessing our Atlanta based
Exchange Server using Cached Exchange Mode. Checked again with customer and
business level support. "No we don't block any ports".

Spoke to them again an hour ago.

Me "currently I cannot telnet through port 135, 25 is ok"
Zen "we don't port block anything"
Me "ok try it yourself, here is my server IP............"
Zen "long pause"
Zen "hold music"
Zen "uhhhhhh it seems like we might block 135. you see there was this virus
outbreak......"
Me "<unrepeatable>"
Me "so for this account and this fixed IP range please open 135 and anything
else you might have inadvertently blocked"
Zen "uhhhhh it seems we can't do that, or wont"
Zen "is there anything else we can do for you today"

YESSSS get me a fucking MAC code you worthless amateur cunts and stop
calling yourself a business broadband provider

*So can anyone recommend a business broadband provider that would rather
commit hari kiri than block port 135, 25 relay or any other fucking thing
ever invented?*

--
Hog

"Hog" <(E-Mail Removed)> wrote in message
news:fjrrpl$rp0$(E-Mail Removed)...
> I'm gutted. My Idol has feet of clay.

> *So can anyone recommend a business broadband provider that would rather
> commit hari kiri than block port 135, 25 relay or any other fucking thing
> ever invented?*
>
> --
> Hog
>

entanet, does what it says on the tin!

On Thu, 13 Dec 2007 17:56:57 UTC, "Hog" <(E-Mail Removed)>
wrote:

> *So can anyone recommend a business broadband provider that would rather
> commit hari kiri than block port 135, 25 relay or any other fucking thing
> ever invented?*

AAISP - http://aa.nu or http://sod.ms

--
[ 7'ism - a condition by which the sufferer experiences an inability
to give concise answers, express reasoned argument or opinion.
Usually accompanied by silly noises and gestures - incurable, early
euthanasia recommended. ]

tony h wrote:
> "Hog" <(E-Mail Removed)> wrote in message
> news:fjrrpl$rp0$(E-Mail Removed)...
>> I'm gutted. My Idol has feet of clay.
>
>> *So can anyone recommend a business broadband provider that would rather
>> commit hari kiri than block port 135, 25 relay or any other fucking thing
>> ever invented?*
>>
>> --
>> Hog
>>
>
> entanet, does what it says on the tin!
>
>
ditto claranet AFAICT

In article <fjrrvg$4d5$(E-Mail Removed)>, tony h <(E-Mail Removed)> wrote:
>
>"Hog" <(E-Mail Removed)> wrote in message
>news:fjrrpl$rp0$(E-Mail Removed)...
>> I'm gutted. My Idol has feet of clay.
>
>> *So can anyone recommend a business broadband provider that would rather
>> commit hari kiri than block port 135, 25 relay or any other fucking thing
>> ever invented?*
>>
>> --
>> Hog
>>
>
>entanet, does what it says on the tin!

Ditto.. And if you've got a few to do, it might be worth your while (well
beer-money anyway) to become a reseller yourself...

Gordon
(Entanet reseller, but there are dozens to choose from)

On 13 Dec, 17:56, "Hog" <hogS...@freenetCHIPS.co.uk> wrote:

> Today, day one, I had a problem. THE problem. Accessing our Atlanta based
> Exchange Server using Cached Exchange Mode. Checked again with customer and
> business level support. "No we don't block any ports".

Any reason why you are not using RPC over HTTP which means you would
be using port 443 instead and avoiding this issue (which is common and
not just with Zen) this is a very common issue.

If you really want avoid using RPC over HTTP then you simply set up a
site to site VPN. I can understand your frustration as you were told
that no ports were blocked, it would have been a little more helpful
if Zen had explained your alternatives. It makes sense from their
point of view to block 135 due to blaster type worms for the good of
99.999% of their customers, there are always other ways to accomplish
what you want, better, safer ways if you use the above methods.

Kind Regards

Willie MacLeod

Hog wrote:

> I'm gutted. My Idol has feet of clay.
>
> I commissioned a new adsl connection from them, first of several to be
> migrated. I checked and double checked that they implemented no port
> blocking or traffic management.
>
> Today, day one, I had a problem. THE problem. Accessing our Atlanta based
> Exchange Server using Cached Exchange Mode. Checked again with customer and
> business level support. "No we don't block any ports".
>
> Spoke to them again an hour ago.
>
> Me "currently I cannot telnet through port 135, 25 is ok"
> Zen "we don't port block anything"
> Me "ok try it yourself, here is my server IP............"
> Zen "long pause"
> Zen "hold music"
> Zen "uhhhhhh it seems like we might block 135. you see there was this virus
> outbreak......"
> Me "<unrepeatable>"
> Me "so for this account and this fixed IP range please open 135 and anything
> else you might have inadvertently blocked"
> Zen "uhhhhh it seems we can't do that, or wont"
> Zen "is there anything else we can do for you today"
>
> YESSSS get me a fucking MAC code you worthless amateur cunts and stop
> calling yourself a business broadband provider
>
> *So can anyone recommend a business broadband provider that would rather
> commit hari kiri than block port 135, 25 relay or any other fucking thing
> ever invented?*

Idnet.

"IDNet specialise in providing high-performance broadband services for
businesses that require the fastest, most reliable and best supported broadband
connections available. All our business broadband services feature the
following: ......

No Network Contention, No Port Blocking, No Traffic Shaping, No Bandwidth
Throttling"
http://www.idnet.net/solutions/businessbroadband.jsp#

Mind you, after your experience I'd want to double, double check that point for
good measure.

Their pricing (or traffic allowance) is just a tad more competitive than Zen's
too.

Mention me when signing up and we both get a tenner too.


Graham

In article <b7ea3d39-97d7-4718-8b27-bdcce1b62929
@e6g2000prf.googlegroups.com>, (E-Mail Removed) says...
> On 13 Dec, 17:56, "Hog" <hogS...@freenetCHIPS.co.uk> wrote:
>
> > Today, day one, I had a problem. THE problem. Accessing our Atlanta based
> > Exchange Server using Cached Exchange Mode. Checked again with customer and
> > business level support. "No we don't block any ports".
>
> Any reason why you are not using RPC over HTTP which means you would
> be using port 443 instead and avoiding this issue (which is common and
> not just with Zen) this is a very common issue.
>
> If you really want avoid using RPC over HTTP then you simply set up a
> site to site VPN. I can understand your frustration as you were told
> that no ports were blocked, it would have been a little more helpful
> if Zen had explained your alternatives. It makes sense from their
> point of view to block 135 due to blaster type worms for the good of
> 99.999% of their customers, there are always other ways to accomplish
> what you want, better, safer ways if you use the above methods.
>
>
TBH I think quite a few ISPs block port 135 for the reasons above.
However they do not include it in the 'no port blocking' statement for
the simple reason that it has been in force for so long now and was put
in place for protection purposes.

"Hog" <(E-Mail Removed)> wrote in message
news:fjrrpl$rp0$(E-Mail Removed)...
> I'm gutted. My Idol has feet of clay.
>
> I commissioned a new adsl connection from them, first of several to be
> migrated. I checked and double checked that they implemented no port
> blocking or traffic management.
>
> Today, day one, I had a problem. THE problem. Accessing our Atlanta based
> Exchange Server using Cached Exchange Mode. Checked again with customer
> and business level support. "No we don't block any ports".
>
> Spoke to them again an hour ago.
>
> Me "currently I cannot telnet through port 135, 25 is ok"
> Zen "we don't port block anything"
> Me "ok try it yourself, here is my server IP............"
> Zen "long pause"
> Zen "hold music"
> Zen "uhhhhhh it seems like we might block 135. you see there was this
> virus outbreak......"
> Me "<unrepeatable>"
> Me "so for this account and this fixed IP range please open 135 and
> anything else you might have inadvertently blocked"
> Zen "uhhhhh it seems we can't do that, or wont"
> Zen "is there anything else we can do for you today"
>
> YESSSS get me a fucking MAC code you worthless amateur cunts and stop
> calling yourself a business broadband provider
>
> *So can anyone recommend a business broadband provider that would rather
> commit hari kiri than block port 135, 25 relay or any other fucking thing
> ever invented?*
>
> --
> Hog
>

"Hog" <(E-Mail Removed)> wrote in message
news:fjrrpl$rp0$(E-Mail Removed)...
> I'm gutted. My Idol has feet of clay.
>
> I commissioned a new adsl connection from them, first of several to be
> migrated. I checked and double checked that they implemented no port
> blocking or traffic management.
>
> Today, day one, I had a problem. THE problem. Accessing our Atlanta based
> Exchange Server using Cached Exchange Mode. Checked again with customer
> and business level support. "No we don't block any ports".
>
> Spoke to them again an hour ago.
>
> Me "currently I cannot telnet through port 135, 25 is ok"
> Zen "we don't port block anything"
> Me "ok try it yourself, here is my server IP............"
> Zen "long pause"
> Zen "hold music"
> Zen "uhhhhhh it seems like we might block 135. you see there was this
> virus outbreak......"
> Me "<unrepeatable>"
> Me "so for this account and this fixed IP range please open 135 and
> anything else you might have inadvertently blocked"
> Zen "uhhhhh it seems we can't do that, or wont"
> Zen "is there anything else we can do for you today"
>
> YESSSS get me a fucking MAC code you worthless amateur cunts and stop
> calling yourself a business broadband provider
>
> *So can anyone recommend a business broadband provider that would rather
> commit hari kiri than block port 135, 25 relay or any other fucking thing
> ever invented?*
>

I agree that Zen should probably "advertise" this more, but tbh they are
doing something sensible that a lot of ISP's are now doing. I'd certainly
suggest you ask the questions specifically before signing up to someone
else. Also bear in mind there may be routers between your ISP and the
eventual destination that block 135 that you don't have any control over!

As Willie pointed out, there are much better methods you can use to connect
Outlook to Exchange over the net - we have a router to router VPN between
our sites, and this has other advantages too; I can administer remote
machines, copy files to and from the other office and pretty much anything
else I could do on a LAN. There are a lot of good reasons to NOT expose RPC
as detailed on Technet (pasted below for convenience). At the end of the day
of course, you're entitled to set up your connections however you want, and
Zen could have been more helpful by opening up the port for you, but then if
your server was compromised and got used to then attack others everyone
loses out...

James

Technet stuff:
---------------------------------------------
The Danger of Exposing RPC to the Internet

So what is dangerous about disclosing that you are using RPC? We might group
the dangers into four categories:
..

Endpoint Mapper promiscuity,
..

General Denial-of-Service (DoS) by attacking port 135 itself,
..

Service specific attacks based upon information from querying port 135, and
..

Escalation of privilege attacks based upon information from querying port
135.

Let's look at each in turn.

First, the Endpoint Mapper is highly promiscuous. A standard security maxim
is that people should have access only to the information they need, and the
Endpoint Mapper is a prime violator of this maxim. From preceding section we
see that there are tools that allow you unfettered access to information:
..

NETSTAT and easily-available port scanners can show you TCP ports on which
the server is listening.
..

RPCDUMP queries TCP/135 and shows you what RPC-based programs are registered
on the server and the ports they are listening on.

The standard ports, such as TCP/25 (SMTP), TCP/53 (DNS), or TCP/80 (HTTP)
can be shut down if you do not need them, or carefully managed and monitored
if you do need them. If a malicious user runs a port-scanner program against
your server, he will only find out about ports you are intentionally
exposing to the Internet and protecting. However, if he uses a program such
as RPCDUMP, and you expose even one RPC-based program to the Internet, he
will find out about all RPC-based programs on your server whether you intend
to expose them or not. The reason for this is that you have to expose the
RPC Endpoint Mapper (since RPC based programs first access to the RPC
Endpoint Mapper on TCP/135 before accessing their program-specific RPC
port) - as we saw in the previous section, Outlook needs to access TCP/135
to find out where to access its mailbox. Unfortunately, you cannot stop the
Endpoint Mapper answering a question about other RPC services, since it
needs to be able to respond to queries from those clients. Consequently,
allowing access to port TCP/135 for even one service (e.g. Exchange)
divulges much more information (e.g. about Active Directory, SQL Server, or
Systems Management Server) than you should. Traditionally there has been no
way to address this problem.

Second, a hacker might create a generic DoS by attacking port 135 itself. If
you can cause the RPC Endpoint Mapper that is listening on port 135 to fail,
any RPC program that accesses that port first will be unable to determine
what port to use for subsequent communications. Consequently, a successful
attack on port 135 would block all RPC-based services offered by the server.
The RPC Endpoint Mapper has in fact been compromised in the past. For
example, a well-publicized vulnerability of the Windows NT 4.0 RPC was a
flaw that caused it to fail upon receipt of a particular malformed request
(See References: MS01-048). Microsoft rapidly issued a patch to protect
against this exploit, and no similar flaws have been identified since then.
However, from a hacker's point of view, attacking port 135 is highly
profitable as a single-point-of-failure for all RPC services on the server.

Third, there could be service-specific attacks based upon information from
querying port 135. If you expose port 135, a program such as RPCDUMP will
tell you what services are running on the server. A malicious hacker might
then attempt various attacks on the identified services - such as those
offered by Exchange 2000 and SQL Server. This strategy has been exploited in
the past. (For example, see References: MS01-041) As with MS01-048,
Microsoft rapidly issued a patch for the affected servers and services, and
there are no outstanding RPC vulnerabilities. However, given the amount of
information that a general query to the RPC Endpoint Mapper divulges, a
hacker will always probe here with glee.

Finally, since many management tools use RPC to administer the server or
domain, there is also a possibility that someone could try an
escalation-of-privilege attack through one of these ports. The security
literature is rife with people concerned with this. A prevalent
escalation-of-privilege attack was the "sechole" attack: under appropriate
circumstances, a user with merely guest privileges could make himself a
system administrator and have rights over your entire environment. (See
References: SecHole.)The vulnerability was sufficiently well known, and
SECHOLE.EXE sufficiently available, that companies such as Ernst and Young
included a 'sechole' attack as part of their standard toolset when doing
penetration analyses. (See References: Penetration Tools.) As before, a
properly patched server is not vulnerable to any known
escalation-of-privilege attack, but the strategy is there if some
enterprising hacker discovers sechole2.

To drive home the need for concern about RPCs, let's look at one way to
bring down a mail server through an RPC attack. Suppose a buffer overrun
vulnerability on a specific Exchange RPC service was discovered, hacker
mounted an attack on your server before you had a chance to patch it. One
authority on secure coding practices describes the dangers thus:

The buffer overrun is one of the most dangerous and prevalent
vulnerabilities in system code. At its core is an unchecked, externally
provided buffer that causes some form of buffer operation (such as
CopyMemory, strcat, strcpy, wcscpy, and so on) to fail. If you're lucky, the
application will crash with a core dump, segmentation fault, or access
violation. If you're not, an attacker can exploit the buffer overrun by
injecting and executing arbitrary code in your process. Copying a buffer
into a stack-based buffer is the most common cause of exploitable attacks.
(See References: Testing For Buffer Overruns.)

The danger is clear - if you expose RPCs to the Internet, someone might
exploit some relatively well known procedures that compromise your security.