Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

connectivity issues



Frankly, SSH is not the kind of thing anyone worries about.  The most
common practice is to run it on 2222 instead of 22.  Anyone who would need
to log into your machine with SSH could simply be told how to do it.

You might be able to send network probes out using an artifically low TTL
to see how far you can get, something like traceroute except that you
would have to send synthetic TCP frames instead of ICMP frames.  This
would be fairly simple to write in Perl, I would think.  My guess is that
the border routers -- the ones which sit at the interface between your ISP
and the rest of the world -- are where the critical firewalling takes
place, and your chances of getting this changed are rather small.

You might also get someone outside the network to port scan you, using a
tool such as NMAP.  The results might be interesting if unhelpful.

Most ISPs try to be fairly unrestrictive.  The most commonly blocked ports
are 137-139 as a courtesy to Windows users.  Next is probably port 25,
which prohibits customers from sending spam directly.  The free ISPs tend
to be the most restrictive, and NetZero blocks their customers from using
most mail-related protocols with foreign servers.  However, unlike a
corporate firewall where anything not specifically allowed is prohibited,
ISPs generally want to prevent customers from doing a small number of
harmful things and otherwise leave them alone.  ISPs do not want to block
IRC or RTSP or MMS or IM, since customers will complain.

In other words, ISPs usually block ports because they think it is for your
own good.  In the vast majority of cases, all people really want is the
ability to browse the web and exchange e-mail.  ISPs by and large do not
care if you run a web server, as long as you do not run a porn site and
are never mentioned on Slashdot.  What gives ISPs nightmares are protocols
such as Napster and Gnutella, and I have personally yanked cables out of
jacks to shut off customers who had their lines pegged continuously for
hours at 100% utilization because of Gnutella.

-- Mike


On 2001-08-13 at 09:43 -0400, Kent Borg wrote:

> On Mon, Aug 13, 2001 at 06:36:28AM -0400, Michael Bilow wrote:
> > Speaking as someone who configures routers for ISPs and has participated
> > in policy drafting on such matters...
> 
> Ooow!  Maybe you could help me with something.
> 
> I use Galaxy DSL for my home connection.  The NATing router in my
> basement is under their control, but I finally managed to get them to
> open up the firewall so I can play with various protocols.  The
> problem, however, is that there are still blocked ports.  The tech
> support folks don't know where the blocking might be coming from, and
> the pattern is more complicated than my model router is capable of
> implementing.
> 
> So something upstream of my router is blocking things.  Any suggestion
> on how I might navigate my ISP to get the ports opened?
> 
> The DSL circuit is from NAS, they are the ones who actually munge with
> the router, so they are possibly the ones who are doing the other
> blocking.
> 
> The way I got as far as I have was to read the router manual, point
> the Galaxy DSL folks to the precise page number for what I wanted
> done, and have them point the NAS people the the exact page number in
> the manual...I think I even faxed the pages to Galaxy DSL and they
> faxed the pages to NAS.  If I am going to get my ports opened, I think
> I am going to have to be as explicit this time.  Ideas on how to do
> this?
> 
> 
> Thanks,
> 
> -kb, the Kent who types this mail on an ssh session to port 19 because
> his port 22 is blocked.

-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org