A Broadband and ADSL forum. BroadbanterBanter

Welcome to BroadbanterBanter.

You are currently viewing as a guest which gives you limited access to view most discussions and other FREE features. By joining our free community you will have access to post topics, communicate privately with other members (PM), respond to polls, upload your own photos and access many other special features. Registration is fast, simple and absolutely free so please, join our community today.

Go Back   Home » BroadbanterBanter forum » Newsgroup Discussions » uk.telecom.broadband (UK broadband)
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

uk.telecom.broadband (UK broadband) (uk.telecom.broadband) Discussion of broadband services, technology and equipment as provided in the UK. Discussions of specific services based on ADSL, cable modems or other broadband technology are also on-topic. Advertising is not allowed.

Zen internet shocker



 
 
Thread Tools Display Modes
  #1  
Old December 13th 07, 05:56 PM posted to uk.telecom.broadband
Hog
external usenet poster
 
Posts: 27
Default 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 ****ing MAC code you worthless amateur ****s 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 ****ing thing
ever invented?*

--
Hog


  #2  
Old December 13th 07, 06:00 PM posted to uk.telecom.broadband
tony h
external usenet poster
 
Posts: 233
Default Zen internet shocker


"Hog" wrote in message
...
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 ****ing thing
ever invented?*

--
Hog


entanet, does what it says on the tin!


  #3  
Old December 13th 07, 06:09 PM posted to uk.telecom.broadband
Bob Eager
external usenet poster
 
Posts: 2,472
Default Zen internet shocker

On Thu, 13 Dec 2007 17:56:57 UTC, "Hog"
wrote:

*So can anyone recommend a business broadband provider that would rather
commit hari kiri than block port 135, 25 relay or any other ****ing 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. ]
  #4  
Old December 13th 07, 06:12 PM posted to uk.telecom.broadband
The Natural Philosopher
external usenet poster
 
Posts: 1,000
Default Zen internet shocker

tony h wrote:
"Hog" wrote in message
...
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 ****ing thing
ever invented?*

--
Hog


entanet, does what it says on the tin!


ditto claranet AFAICT
  #5  
Old December 13th 07, 06:36 PM posted to uk.telecom.broadband
Gordon Henderson
external usenet poster
 
Posts: 797
Default Zen internet shocker

In article , tony h wrote:

"Hog" wrote in message
...
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 ****ing 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)
  #6  
Old December 13th 07, 08:01 PM posted to uk.telecom.broadband
[email protected]
external usenet poster
 
Posts: 51
Default Zen internet shocker

On 13 Dec, 17:56, "Hog" 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
  #7  
Old December 13th 07, 08:12 PM posted to uk.telecom.broadband
Eeyore
external usenet poster
 
Posts: 3,222
Default Zen internet shocker



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 ****ing MAC code you worthless amateur ****s 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 ****ing 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

  #8  
Old December 14th 07, 06:36 AM posted to uk.telecom.broadband
Mugwump
external usenet poster
 
Posts: 50
Default Zen internet shocker

In article b7ea3d39-97d7-4718-8b27-bdcce1b62929
@e6g2000prf.googlegroups.com, says...
On 13 Dec, 17:56, "Hog" 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.
  #9  
Old December 14th 07, 09:18 AM posted to uk.telecom.broadband
JamesB
external usenet poster
 
Posts: 8
Default Zen internet shocker


"Hog" wrote in message
...
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 ****ing MAC code you worthless amateur ****s 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 ****ing thing
ever invented?*

--
Hog


  #10  
Old December 14th 07, 09:25 AM posted to uk.telecom.broadband
JamesB
external usenet poster
 
Posts: 8
Default Zen internet shocker


"Hog" wrote in message
...
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 ****ing MAC code you worthless amateur ****s 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 ****ing 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.


 




Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Internet Connection and internet tv nickbrace uk.telecom.broadband (UK broadband) 1 February 24th 06 11:11 AM
Internet Gateway device created in Network Connections when I removed Internet Connection Sharing Martin Underwood uk.comp.home-networking (UK home networking) 2 April 7th 05 01:56 PM
Internet anking and internet security Furby uk.telecom.broadband (UK broadband) 12 January 31st 05 08:08 AM
Gio Internet Brent Murray uk.telecom.broadband (UK broadband) 0 February 28th 04 08:31 AM


All times are GMT +1. The time now is 03:59 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.Content Relevant URLs by vBSEO 2.4.0
Copyright 2004-2020 BroadbanterBanter.
The comments are property of their posters.