Very Computer

by **General Schvantzkop** » Fri, 17 Mar 2006 11:58:19

I have an ssh server which I use to distribute code to my customers. I
have the port set to a number in the 2000s rather than the standard port
22.

My problem is that I have several customers at large corporations which
have firewalls that block outgoing access to my machine. Is anything there
I can do to make it possible for them the access my machine, moving to
another port. Is there anything that they can do? I'm open to suggestions?

Thanks,

by **Gran** » Fri, 17 Mar 2006 12:07:16

>My problem is that I have several customers at large corporations which
>have firewalls that block outgoing access to my machine. Is anything there
>I can do to make it possible for them the access my machine, moving to
>another port. Is there anything that they can do? I'm open to suggestions?

Stay on standard ports, perhaps try https -- going to non-standard ports
may give one an illusion of security, but it is still the old 'security
by obscurity' -- non-viable as you have seen. You're lumped in with the
copyright breakers and evil file sharers on strange ports...

Grant.
--
Memory fault -- brain fried

by **David Schwart** » Fri, 17 Mar 2006 19:01:13

> On Wed, 15 Mar 2006 21:58:19 -0500, General Schvantzkoph

>>My problem is that I have several customers at large corporations which
>>have firewalls that block outgoing access to my machine. Is anything there
>>I can do to make it possible for them the access my machine, moving to
>>another port. Is there anything that they can do? I'm open to suggestions?
> Stay on standard ports, perhaps try https -- going to non-standard ports
> may give one an illusion of security, but it is still the old 'security
> by obscurity' -- non-viable as you have seen. You're lumped in with the
> copyright breakers and evil file sharers on strange ports...

I would recommend that you create a web page explaining exactly what
type of access is required (that it's over TCP, the port, destination
IP/host, and so on) and why. Tell your customers to show that web page to
their firewall administrators. Make sure the page clearly explains what data
is exchanged and what service you are providing.

When customers experience an access problem, advise them to show that
page to their network administrator. Perhaps send them an email they can
easily forward.

Don't give their network administrator *any* legitimate reason to say
no. That way you stay on the up and up, being honest and forthcoming. If
they say "no", there's nothing you can do -- they own their network and get
to decide what traffic goes on it.

DS

by **General Schvantzkop** » Fri, 17 Mar 2006 20:56:34

> On Wed, 15 Mar 2006 21:58:19 -0500, General Schvantzkoph

>>My problem is that I have several customers at large corporations which
>>have firewalls that block outgoing access to my machine. Is anything
>>there I can do to make it possible for them the access my machine, moving
>>to another port. Is there anything that they can do? I'm open to
>>suggestions?

> Stay on standard ports, perhaps try https -- going to non-standard ports
> may give one an illusion of security, but it is still the old 'security by
> obscurity' -- non-viable as you have seen. You're lumped in with the
> copyright breakers and evil file sharers on strange ports...

> Grant.

I already have port 22 in use by another machine so I have to use another
port for this machine. The security by obscurity issue really works. The
machine on port 22 gets multiple attacks a day by password guessing
scanners (I have password authorization disabled so these attacks should
be futile but they are scary any way). The machine on the high port has
never had an attack. I could try using a well know port for another
service, the FTP port for example.

by **Moe Tr** » Sat, 18 Mar 2006 05:12:35

On Thu, 16 Mar 2006, in the Usenet newsgroup comp.os.linux.networking, in

>>>My problem is that I have several customers at large corporations which
>>>have firewalls that block outgoing access to my machine. Is anything
>>>there I can do to make it possible for them the access my machine, moving
>>>to another port. Is there anything that they can do? I'm open to
>>>suggestions?

>> Stay on standard ports, perhaps try https

There are quite a number of "secure" ports that could be used - see
http://www.iana.org/assignments/port-numbers. But there are several other
problems.

Quote:>> going to non-standard ports may give one an illusion of security, but
>> it is still the old 'security by obscurity' -- non-viable as you have seen.

It does have it's advantages, but then to - so does firewalling by IP
address. Restricting access to the server based on the (should be) known
address block of the customer may be an option

Quote:>> You're lumped in with the copyright breakers and evil file sharers on
>> strange ports...

We don't _automatically_ block based on that, but we do look at any traffic
that is going to "non-standard" ports. If the traffic is encrypted, it's
more work for us to investigate it, and this isn't going to put us into the
best humor.

Quote:>I already have port 22 in use by another machine so I have to use another
>port for this machine.

Which suggests the use of a single address for everything - perhaps a
residential network with a generic PTR (if it has one at all) record.
That's not going to win friends and influence network security admins.

Quote:>The security by obscurity issue really works.

I don't dispute that. The thing is that "I" expect a business to have the
port adequately secured, and I _don't_ expect a business to be using the
non-standard port. This also ties in to that PTR record.

Quote:>The machine on port 22 gets multiple attacks a day by password guessing
>scanners (I have password authorization disabled so these attacks should
>be futile but they are scary any way). The machine on the high port has
>never had an attack.

Most of the attacks are zombies or skript kiddiez who are trying a limited
number of usernames, with somewhat predictable passwords. You can use a
less obvious username - such as the serial number of the product they are
trying to get support for - or the product name itself. You can also
configure your server to tar-pit bad logins (delays increase with the
number of failed attempts from a specific address), or even TEMPORARILY
blackhole the address after so-many failed attempts. You can also use the
firewall to limit access to addresses where the customers are located
rather than accepting everyone from everywhere.

Quote:>I could try using a well know port for another service, the FTP port for
>example.

Again, watch giving the appearance of not being on the up-and-up. Our users
are not supposed to be using the network for personal use, so we do watch
where the traffic is going. Traffic to a non-obvious address is at least
noticed. Traffic to addresses that don't resolve, or that resolve to a
non-business/education address get looked at. If it's encrypted, there
will be questions asked. If it's encrypted, AND not going to a well known
port, it's going to raise more flags.

Old guy

by **General Schvantzkop** » Sat, 18 Mar 2006 08:43:08

Let me clarify my situation and maybe someone will have a suggestion that
will allow me provide a release server that's accessible to my large
company clients.

I have a small company (3 man) that provides IP for FPGAs and ASICs. Our
customers are all over the world and range from startups to fortune 500
corporations.

We have home offices. I have a business DSL line with a single static IP
and a registered domain. I have a half dozen Linux machines which I use
for development and as file servers.

I have two dedicated servers that connect to the Internet though ssh. One
server, on port 22, is our CVS server. That server is accessed by my
partners and me and is used to collaborate on development. The only
machines that are authorized to connect to it (I use RSA authorization,
passwords are disabled) belong to me and my partners. The other machine is
my release server, which has ssh mapped to a high port number.

Each customer has a user account on the release server. I place code
releases for them in their accounts. The only networking service on this
machine is ssh, there are no legacy servers installed and all of the other
machines on my network have this machine in their hosts.deny file and none
of them permit ssh access from it (I can ssh to it from all of my
machines). I've also set the privileges on all accounts to 700 so that no
customer can see the content of any other customer's directory.

For the startups this setup works fine. For the big companies this doesn't
work because their firewalls don't permit them to access my server. The
work around so far is that my customers at these companies have used their
home machines to access the server. I've tried moving the port to 20 (FTP)
figuring that a company is unlikely to block FTP, but that didn't work.

Does anyone have any suggestions about a means for providing access to
releases to customers at big companies? My requirements are 1) Reasonably
straight forward access for my customers. 2) Good security for me. 3) Runs
on Linux.

by **Medgy** » Sat, 18 Mar 2006 11:35:24

Hi General,

I think your best bet will be to get another global IP address for your
release server. Then your customers would be able to connect using the
standard port and everybody is happy. You could do that in a number of
ways, of course. One would just be to ask your ISP to delegate a larger
block of static IP addresses. You obviously have a legitimate need, so
in exchange for a few dollars per month the ISP should oblige. Another
idea would be to move your release server to a data center and get a
static address there.

Both of these solutions would be very clean and seem to present the
simplest possible path. There are less clean solutions that could let
you differentiate traffic to the same standard port, but why complicate
things? As for the security of sshd on the standard port, random
usernames and good passwords are a good first stp. You could do more,
but it depends on the sophistication of your users, or maybe you could
factor that out by building the update function into the software
itself? Just some thoughts.

Medgya

by **Moe Tr** » Sat, 18 Mar 2006 11:54:25

On Thu, 16 Mar 2006, in the Usenet newsgroup comp.os.linux.networking, in

Quote:>We have home offices. I have a business DSL line with a single static IP
>and a registered domain. I have a half dozen Linux machines which I use
>for development and as file servers.

OK - look at the address you are using on that domain. If you do a DNS
lookup of the domain name, you get an IP address. If you then do a second
lookup - this time of the IP address, does it return your hostname, or
some generic stuff (generic defined as a hostname that contains the IP
address in some form such as 192.0.2.22 -> dsl-192-000-002-022.provider.com
or similar). Second, look up the IP address in the various RBL lists -
one way being http://www.TQMcube.com/rblcheck.htm (uses tables) and see
that the provider is clean. We've null-routed quite a number of providers
because of spam problems - some of them being quite large. In a couple of
cases, we've had to cut holes to "whitelist" some entity that has chosen
a poor provider. I know you can't get a direct assignment from an RIR, but
see if your provider will SWIP the address to you, or at least list you
on their rwhois server. That builds confidence not only in network
security types, but also mail administrators.

Quote:>I have two dedicated servers that connect to the Internet though ssh. One
>server, on port 22, is our CVS server. That server is accessed by my
>partners and me and is used to collaborate on development. The only
>machines that are authorized to connect to it (I use RSA authorization,
>passwords are disabled) belong to me and my partners.

OK, with a single address, I can see your problem.

Quote:>The other machine is my release server, which has ssh mapped to a high
>port number.

>Each customer has a user account on the release server. I place code
>releases for them in their accounts.

I don't know what your threat model is, yada, yada, yada. You want to
separate the two SSH servers - that's fine. If all your customers can do
is download AND NOTHING ELSE, I'd suggest having a strong username and
password setup for each, set permissions so that they can't do anything
except download, and then leave it on 22. I'd have the CVS server using
the non-standard port number, as your people would be minimally
inconvenienced. That would appear more on the "up-and-up" to the paranoid
net security types.

The bit about "strong username" - do your customers have a frequent need
to be connecting? Would writing down the username and password be something
normal (mainly because of infrequent use)? If so, consider generating
usernames the way we _used_ to generate initial passwords. Either
'head -2 /dev/random | uuencode /dev/stdout' or 'head -2 /dev/random |
mimencode' and in either case, select a string that begins with a letter
consisting of letters and numbers only. Using mixed case would increase
security and is permitted by most systems, but probably should be avoided
to prevent confusing the users. While you're at it - there is also the
password a little further into the string.

Quote:>I've also set the privileges on all accounts to 700 so that no
>customer can see the content of any other customer's directory.

Do they _need_ to be writable by the customers?

Quote:>For the startups this setup works fine. For the big companies this doesn't
>work because their firewalls don't permit them to access my server. The
>work around so far is that my customers at these companies have used their
>home machines to access the server.

That doesn't work here - we don't allow _any_ access to the home systems
from our network. I can't say much more than that.

Quote:>I've tried moving the port to 20 (FTP) figuring that a company is unlikely
>to block FTP, but that didn't work.

You'd have to ask them why, but depending on your provider, I can't see
any reason why that wouldn't work. Of course if your address is in the
middle of SpammersRus.com, there would be problems.

Quote:>Does anyone have any suggestions about a means for providing access to
>releases to customers at big companies? My requirements are 1) Reasonably
>straight forward access for my customers. 2) Good security for me. 3) Runs
>on Linux.

From my view, clean address, resolves both ways, and a known port would
_probably_ get the best results. Security for you comes from having good
usernames. and running on up-to-date Linux (or similar).

Old guy

by **General Schvantzkop** » Sat, 18 Mar 2006 13:10:24

> On Thu, 16 Mar 2006, in the Usenet newsgroup comp.os.linux.networking, in

>>We have home offices. I have a business DSL line with a single static IP
>>and a registered domain. I have a half dozen Linux machines which I use
>>for development and as file servers.

> OK - look at the address you are using on that domain. If you do a DNS
> lookup of the domain name, you get an IP address. If you then do a second
> lookup - this time of the IP address, does it return your hostname, or
> some generic stuff (generic defined as a hostname that contains the IP
> address in some form such as 192.0.2.22 ->
> dsl-192-000-002-022.provider.com or similar). Second, look up the IP
> address in the various RBL lists - one way being
> http://www.TQMcube.com/rblcheck.htm (uses tables) and see that the
> provider is clean. We've null-routed quite a number of providers because
> of spam problems - some of them being quite large. In a couple of cases,
> we've had to cut holes to "whitelist" some entity that has chosen a poor
> provider. I know you can't get a direct assignment from an RIR, but see
> if your provider will SWIP the address to you, or at least list you on
> their rwhois server. That builds confidence not only in network security
> types, but also mail administrators.

>>I have two dedicated servers that connect to the Internet though ssh. One
>>server, on port 22, is our CVS server. That server is accessed by my
>>partners and me and is used to collaborate on development. The only
>>machines that are authorized to connect to it (I use RSA authorization,
>>passwords are disabled) belong to me and my partners.

> OK, with a single address, I can see your problem.

>>The other machine is my release server, which has ssh mapped to a high
>>port number.

>>Each customer has a user account on the release server. I place code
>>releases for them in their accounts.

> I don't know what your threat model is, yada, yada, yada. You want to
> separate the two SSH servers - that's fine. If all your customers can do
> is download AND NOTHING ELSE, I'd suggest having a strong username and
> password setup for each, set permissions so that they can't do anything
> except download, and then leave it on 22. I'd have the CVS server using
> the non-standard port number, as your people would be minimally
> inconvenienced. That would appear more on the "up-and-up" to the paranoid
> net security types.

> The bit about "strong username" - do your customers have a frequent need
> to be connecting? Would writing down the username and password be
> something normal (mainly because of infrequent use)? If so, consider
> generating usernames the way we _used_ to generate initial passwords.
> Either 'head -2 /dev/random | uuencode /dev/stdout' or 'head -2
> /dev/random | mimencode' and in either case, select a string that begins
> with a letter consisting of letters and numbers only. Using mixed case
> would increase security and is permitted by most systems, but probably
> should be avoided to prevent confusing the users. While you're at it -
> there is also the password a little further into the string.

>>I've also set the privileges on all accounts to 700 so that no customer
>>can see the content of any other customer's directory.

> Do they _need_ to be writable by the customers?

>>For the startups this setup works fine. For the big companies this
>>doesn't work because their firewalls don't permit them to access my
>>server. The work around so far is that my customers at these companies
>>have used their home machines to access the server.

> That doesn't work here - we don't allow _any_ access to the home systems
> from our network. I can't say much more than that.

>>I've tried moving the port to 20 (FTP) figuring that a company is
>>unlikely to block FTP, but that didn't work.

> You'd have to ask them why, but depending on your provider, I can't see
> any reason why that wouldn't work. Of course if your address is in the
> middle of SpammersRus.com, there would be problems.

>>Does anyone have any suggestions about a means for providing access to
>>releases to customers at big companies? My requirements are 1) Reasonably
>>straight forward access for my customers. 2) Good security for me. 3)
>>Runs on Linux.

> From my view, clean address, resolves both ways, and a known port would
> _probably_ get the best results. Security for you comes from having good
> usernames. and running on up-to-date Linux (or similar).

> Old guy

I checked my IP address using rblcheck and it's clean. I can try swapping
the ports on the two servers and put the release server on 22. Do you
think the problem is due to the fact that I'm using a non-standard port?

by **General Schvantzkop** » Sat, 18 Mar 2006 13:18:29

> Hi General,

> I think your best bet will be to get another global IP address for your
> release server. Then your customers would be able to connect using the
> standard port and everybody is happy. You could do that in a number of
> ways, of course. One would just be to ask your ISP to delegate a larger
> block of static IP addresses. You obviously have a legitimate need, so in
> exchange for a few dollars per month the ISP should oblige. Another idea
> would be to move your release server to a data center and get a static
> address there.

> Both of these solutions would be very clean and seem to present the
> simplest possible path. There are less clean solutions that could let you
> differentiate traffic to the same standard port, but why complicate
> things? As for the security of sshd on the standard port, random usernames
> and good passwords are a good first stp. You could do more, but it depends
> on the sophistication of your users, or maybe you could factor that out by
> building the update function into the software itself? Just some thoughts.

> Medgya

I'm going to try putting my release server on 22 and moving the other
server to a different port.

As for usernames and passwords, I think passwords are a terrible idea,
easy ones can be guessed and *es are a pain in the ass because you
have to write them down somewhere. I use RSA authentication which is much
more secure and also much simpler for the user. No hacker is going to be
able to break a public key system. I suppose there is some chance that the
NSA could break RSA but I'm not worried about that. If the NSA wants my
IP I'd be happy to sell them a license.

by **Medgy** » Sat, 18 Mar 2006 14:50:32

I agree, passwords are a bad idea. Obviously you should use RSA/DSA
internally, but for your customers it may be more problematic, and
depends on their level of sophistication and the tools they have
available. In the best case maybe you could have them upload their
public keys?

Medgya

by **Tauno Voipi** » Sat, 18 Mar 2006 18:53:58

> Let me clarify my situation and maybe someone will have a suggestion that
> will allow me provide a release server that's accessible to my large
> company clients.

> I have a small company (3 man) that provides IP for FPGAs and ASICs. Our
> customers are all over the world and range from startups to fortune 500
> corporations.

> We have home offices. I have a business DSL line with a single static IP
> and a registered domain. I have a half dozen Linux machines which I use
> for development and as file servers.

> I have two dedicated servers that connect to the Internet though ssh. One
> server, on port 22, is our CVS server. That server is accessed by my
> partners and me and is used to collaborate on development. The only
> machines that are authorized to connect to it (I use RSA authorization,
> passwords are disabled) belong to me and my partners. The other machine is
> my release server, which has ssh mapped to a high port number.

> Each customer has a user account on the release server. I place code
> releases for them in their accounts. The only networking service on this
> machine is ssh, there are no legacy servers installed and all of the other
> machines on my network have this machine in their hosts.deny file and none
> of them permit ssh access from it (I can ssh to it from all of my
> machines). I've also set the privileges on all accounts to 700 so that no
> customer can see the content of any other customer's directory.

> For the startups this setup works fine. For the big companies this doesn't
> work because their firewalls don't permit them to access my server. The
> work around so far is that my customers at these companies have used their
> home machines to access the server. I've tried moving the port to 20 (FTP)
> figuring that a company is unlikely to block FTP, but that didn't work.

> Does anyone have any suggestions about a means for providing access to
> releases to customers at big companies? My requirements are 1) Reasonably
> straight forward access for my customers. 2) Good security for me. 3) Runs
> on Linux.

In a similar situation, I had to provide the customer access
via https (TCP/443). The big corporation firewalls usually
have to accept the HTTP/SSL traffic, but they seem to be very
wary on SSH.

--

Tauno Voipio
tauno voipio (at) iki fi

by **General Schvantzkop** » Sat, 18 Mar 2006 21:43:01

> I agree, passwords are a bad idea. Obviously you should use RSA/DSA
> internally, but for your customers it may be more problematic, and depends
> on their level of sophistication and the tools they have available. In the
> best case maybe you could have them upload their public keys?

> Medgya

That's what I do, I have them send me their public keys. All of my
customers are using at least some Linux systems so they already have ssh
available to them. For those that are using Windows I have them install
Cygwin.

by **General Schvantzkop** » Sat, 18 Mar 2006 21:45:59

Quote:> In a similar situation, I had to provide the customer access via https
> (TCP/443). The big corporation firewalls usually have to accept the
> HTTP/SSL traffic, but they seem to be very wary on SSH.

What did you do to provide https access? How do you restrict access to
specific users?

by **Moe Tr** » Sun, 19 Mar 2006 05:10:56

On Thu, 16 Mar 2006, in the Usenet newsgroup comp.os.linux.networking, in

>> From my view, clean address, resolves both ways, and a known port would
>> _probably_ get the best results. Security for you comes from having
>> good usernames. and running on up-to-date Linux (or similar).

When I wrote that, I wasn't aware of your use of their public keys. That
pretty well takes care of the security angle.

Quote:>I checked my IP address using rblcheck and it's clean. I can try swapping
>the ports on the two servers and put the release server on 22. Do you
>think the problem is due to the fact that I'm using a non-standard port?

Not knowing your IP address, I can't say for sure, but I would guess that
to be a strong possibility. A lot is going to depend on the policies and
paranoia level at the customers. I'm at an R&D facility, and we're very
restrictive of what the users are allowed to do with the network. We do
monitor traffic (generally speaking "after the fact"), and we do have
filters on the routers. I mentioned we block access to "home" netblocks
as one example. We also block all protocols except TCP, UDP and ICMP, and
even there we don't allow "everything". I know that (with a few exceptions)
we block outbound connection starts (SYN) to ports over 1024, and (again
with exceptions) inbound connection starts to most ports. The idea is
that our users should be able to initiate "normal" connections to remote
systems that may reasonably be expected to be work related, and that no
Internet visible servers exist in the user segment of the network, so
there would be no reason to allow such inbound connections. (The Internet
visible stuff is in DMZs and separate networks.)

For those customers where you are having problems, a short note to the

mailbox with that name - but try the lower case, and 'postmaster'
addresses if it doesn't work) may elicit some explanation. Whitelisting
generally has to come from inside user requests, and I think someone here
already mentioned having a web page or email form letter that your
customers can use to explain their need to their network/firewall people.

Old guy

Very Computer

Getting around corporate firewalls to access ssh server

Getting around corporate firewalls to access ssh server

Getting around corporate firewalls to access ssh server

Getting around corporate firewalls to access ssh server

Getting around corporate firewalls to access ssh server

Getting around corporate firewalls to access ssh server

Getting around corporate firewalls to access ssh server

Getting around corporate firewalls to access ssh server

Getting around corporate firewalls to access ssh server

Getting around corporate firewalls to access ssh server

Getting around corporate firewalls to access ssh server

Getting around corporate firewalls to access ssh server

Getting around corporate firewalls to access ssh server

Getting around corporate firewalls to access ssh server

Getting around corporate firewalls to access ssh server

Getting around corporate firewalls to access ssh server