comments abour outgoing SSH blocking

Hello,

I am looking for comments and suggestions here. In an academic
institution, the guy responsible for firewall has blocked all outgoing
aSSH connections. Their claim is that this prevents anybody from tried
to hack into remote systems. I have never heard any such thing before,
since if anybody tried to do so, the SSH attempts would leave a trail.
If they blocked telnet, I would understand. But SSH? Does this policy
make sense? Or am I missing something here?

My first thoughts about this policy was that the IT guys there are
incompetent and do not want to do their home work to secure their
systems and want to take the easy way out. But I figured I should ask
others first in case I do not see all the subtle things.

And, if that policy is wrong, the more tricky part, how do I start to
convince them that outgoing SSH should be allowed ... which is going to
be very uphill task. But since I find this policy huge pain in the neck
(can't use rsync over ssh, can't use plain rsync even!), I am going to
give it my best shot.

thanks,
->HS

H.S. wrote:
>
> ... the guy responsible for firewall has blocked all outgoing
> aSSH connections. Their claim is that this prevents anybody from tried
> to hack into remote systems. I have never heard any such thing before,
> since if anybody tried to do so, the SSH attempts would leave a trail.
> If they blocked telnet, I would understand. But SSH? Does this policy
> make sense? Or am I missing something here?
>
> [snip]

You're missing something.

telnet leaves as much, or as little, a trail as ssh.

If you run an ssh server on the Internet, you quickly learn that there
are loads of dictionary-based, script-kiddie tools to try to break in
to ssh servers.

ssh can be secured better than telnet through better authentication
(public key), but most sites just run ssh like it's encrypted telnet.
Run that way, ssh is no better than telnet for defending against brute
force attacks against passwords.

Allen Kistler wrote:
> H.S. wrote:
>> ... the guy responsible for firewall has blocked all outgoing
>> aSSH connections. Their claim is that this prevents anybody from tried
>> to hack into remote systems. I have never heard any such thing before,
>> since if anybody tried to do so, the SSH attempts would leave a trail.
>> If they blocked telnet, I would understand. But SSH? Does this policy
>> make sense? Or am I missing something here?
>>
>> [snip]
>
> You're missing something.
>
> telnet leaves as much, or as little, a trail as ssh.
>
> If you run an ssh server on the Internet, you quickly learn that there
> are loads of dictionary-based, script-kiddie tools to try to break in
> to ssh servers.
>
> ssh can be secured better than telnet through better authentication
> (public key), but most sites just run ssh like it's encrypted telnet.
> Run that way, ssh is no better than telnet for defending against brute
> force attacks against passwords.

Hmm ... here at my university we have no such restrictions. I do not
recall anyone being reported for abusing ssh. Come to think of this, I
do not know of any academic institution, except the one I mentioned
earlier, that does this.

The dictionary attacks are pretty common. I give you that. But shutting
off outgoing ssh just because of them en mass doesn't look reasonably to me.

Could I not exploit port 80 for vulnerabilities? I am sure one can find
poorly setup and maintained servers. By the above token, access to port
80 should also be stopped.

Or perhaps port 80 is not easily exploitable as is port 22 for a script
kiddie or even a serious cracker?

->HS

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

,--- H S writes:
| Hello,

Hi,

[...]

| And, if that policy is wrong, the more tricky part, how do I start to
| convince them that outgoing SSH should be allowed ... which is going to
| be very uphill task. But since I find this policy huge pain in the neck
| (can't use rsync over ssh, can't use plain rsync even!), I am going to
| give it my best shot.


You can secure SSH, by, allowing only public key authentications from
external world, by using things like denyhosts[1] (which require
tcp_wrappers support in sshd), or running SSH on different port
(security by obscurity) . In OpenSSH 2.5p1 and later they've
introduced a "Match" block, where you can customize SSH configuration
on some criteria, for more information check out sshd_config(5) .

References:
[1] - http://denyhosts.sourceforge.net/

| thanks,
| -> HS

HTH
- --
Ashish Shukla आशीष श�क�ल http://wahjava.wordpress.com/
·-- ·- ···· ·--- ·- ···- ·- ·--·-· --· -- ·- ·· ·-·· ·-·-·- -·-· --- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHQyRJHy+EEHYuXnQRAiLHAJsE5xLqpkDQmvm919iJEo ajn+NuagCg5nd8
HM0WgqW94T0IOiMayNApbsY=
=uoVg
-----END PGP SIGNATURE-----

On Nov 20, 4:51 pm, "H.S." <hs.saDELETEME...@gmail.com> wrote:
> Hello,
>
> I am looking for comments and suggestions here. In an academic
> institution, the guy responsible for firewall has blocked all outgoing
> aSSH connections. Their claim is that this prevents anybody from tried
> to hack into remote systems. I have never heard any such thing before,
> since if anybody tried to do so, the SSH attempts would leave a trail.
> If they blocked telnet, I would understand. But SSH? Does this policy
> make sense? Or am I missing something here?
>
> My first thoughts about this policy was that the IT guys there are
> incompetent and do not want to do their home work to secure their
> systems and want to take the easy way out. But I figured I should ask
> others first in case I do not see all the subtle things.
>
> And, if that policy is wrong, the more tricky part, how do I start to
> convince them that outgoing SSH should be allowed ... which is going to
> be very uphill task. But since I find this policy huge pain in the neck
> (can't use rsync over ssh, can't use plain rsync even!), I am going to
> give it my best shot.
>
> thanks,
> ->HS


http://elsiddik.blogspot.com/2007/10/secure-ssh.html

zaher el siddik

elsiddik wrote:
> On Nov 20, 4:51 pm, "H.S." <hs.saDELETEME...@gmail.com> wrote:
>> Hello,
>>
>> I am looking for comments and suggestions here. In an academic
>> institution, the guy responsible for firewall has blocked all outgoing
>> aSSH connections. Their claim is that this prevents anybody from tried
>> to hack into remote systems. I have never heard any such thing before,
>> since if anybody tried to do so, the SSH attempts would leave a trail.
>> If they blocked telnet, I would understand. But SSH? Does this policy
>> make sense? Or am I missing something here?
>>
>> My first thoughts about this policy was that the IT guys there are
>> incompetent and do not want to do their home work to secure their
>> systems and want to take the easy way out. But I figured I should ask
>> others first in case I do not see all the subtle things.
>>
>> And, if that policy is wrong, the more tricky part, how do I start to
>> convince them that outgoing SSH should be allowed ... which is going to
>> be very uphill task. But since I find this policy huge pain in the neck
>> (can't use rsync over ssh, can't use plain rsync even!), I am going to
>> give it my best shot.
>>
>> thanks,
>> ->HS
>
>
> http://elsiddik.blogspot.com/2007/10/secure-ssh.html
>
> zaher el siddik


Thanks for the site. But I don't see why *outgoing* SSH should be
blocked "for security purposes." Is there no method which can mitigate
the claimed security problems in this?

->HS

On Nov 20, 7:52 pm, "H.S." <hs.sa...@gmail.com> wrote:
> elsiddik wrote:
> > On Nov 20, 4:51 pm, "H.S." <hs.saDELETEME...@gmail.com> wrote:
> >> Hello,
>
> >> I am looking for comments and suggestions here. In an academic
> >> institution, the guy responsible for firewall has blocked all outgoing
> >> aSSH connections. Their claim is that this prevents anybody from tried
> >> to hack into remote systems. I have never heard any such thing before,
> >> since if anybody tried to do so, the SSH attempts would leave a trail.
> >> If they blocked telnet, I would understand. But SSH? Does this policy
> >> make sense? Or am I missing something here?
>
> >> My first thoughts about this policy was that the IT guys there are
> >> incompetent and do not want to do their home work to secure their
> >> systems and want to take the easy way out. But I figured I should ask
> >> others first in case I do not see all the subtle things.
>
> >> And, if that policy is wrong, the more tricky part, how do I start to
> >> convince them that outgoing SSH should be allowed ... which is going to
> >> be very uphill task. But since I find this policy huge pain in the neck
> >> (can't use rsync over ssh, can't use plain rsync even!), I am going to
> >> give it my best shot.
>
> >> thanks,
> >> ->HS
>
> >http://elsiddik.blogspot.com/2007/10/secure-ssh.html
>
> > zaher el siddik
>
> Thanks for the site. But I don't see why *outgoing* SSH should be
> blocked "for security purposes." Is there no method which can mitigate
> the claimed security problems in this?
>
> ->HS

Well blocking outgoing ssh saves your admin alot of work - i guess he
managed to take the easy way.
SSH is secure but it is most flexible and secure if you use public-key
authentication. Trusted-host and password.
to use public keys with an ssh server you need to gnerate a public
private key pair - by launching this command : ssh-keygen -t rsa or -t
dsa for dsa keys.


good luck,
zaher el siddik

H.S. wrote:
> Allen Kistler wrote:
>> H.S. wrote:
>>> ... the guy responsible for firewall has blocked all outgoing
>>> aSSH connections. Their claim is that this prevents anybody from tried
>>> to hack into remote systems. I have never heard any such thing before,
>>> since if anybody tried to do so, the SSH attempts would leave a trail.
>>> If they blocked telnet, I would understand. But SSH? Does this policy
>>> make sense? Or am I missing something here?
>>>
>>> [snip]
>> You're missing something.
>>
>> telnet leaves as much, or as little, a trail as ssh.
>>
>> If you run an ssh server on the Internet, you quickly learn that there
>> are loads of dictionary-based, script-kiddie tools to try to break in
>> to ssh servers.
>>
>> ssh can be secured better than telnet through better authentication
>> (public key), but most sites just run ssh like it's encrypted telnet.
>> Run that way, ssh is no better than telnet for defending against brute
>> force attacks against passwords.
>
> Hmm ... here at my university we have no such restrictions. I do not
> recall anyone being reported for abusing ssh. Come to think of this, I
> do not know of any academic institution, except the one I mentioned
> earlier, that does this.
>
> The dictionary attacks are pretty common. I give you that. But shutting
> off outgoing ssh just because of them en mass doesn't look reasonably to me.
>
> Could I not exploit port 80 for vulnerabilities? I am sure one can find
> poorly setup and maintained servers. By the above token, access to port
> 80 should also be stopped.
>
> Or perhaps port 80 is not easily exploitable as is port 22 for a script
> kiddie or even a serious cracker?
>
> ->HS

Most web access is anonymous. It was designed to be anonymous.
There's little opportunity for password cracking.
What opportunity there is doesn't grant the cracker access to the OS.

Running services with known vulnerabilities is a separate topic.
Yes, any service can have known, unpatched vulnerabilities.
kiddie-scripts that go looking for web servers really go looking for
unpatched vulnerabilities or unconfigured extras.

telnet and ssh running perfectly and pristinely still give OS access
using, potentially, only username and password.

If an admin chooses not to have his network be the source of cracking
attempts against other organizations, he can usually get the support of
his bosses and lawyers to impose whatever restrictions he wants that
don't impede the business.

In comp.os.linux.networking H.S. <(E-Mail Removed)>:
> Hello,

> I am looking for comments and suggestions here. In an academic
> institution, the guy responsible for firewall has blocked all outgoing
> aSSH connections. Their claim is that this prevents anybody from tried
> to hack into remote systems. I have never heard any such thing before,
> since if anybody tried to do so, the SSH attempts would leave a trail.
> If they blocked telnet, I would understand. But SSH? Does this policy
> make sense? Or am I missing something here?

It is a good baseline security policy to simply deny anything at
first, then explicit allow things that are needed. Despite
preventing outgoing ssh crack attempts through infected systems
inside, it prevents to establish a connection from outside the
network back inside tunneled through an already open outside
connection.

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo (E-Mail Removed) | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 328: Fiber optics caused gas main leak

"H.S." <(E-Mail Removed)> writes:

> Hello,
>
> I am looking for comments and suggestions here. In an academic
> institution, the guy responsible for firewall has blocked all outgoing
> aSSH connections. Their claim is that this prevents anybody from tried
> to hack into remote systems. I have never heard any such thing before,
> since if anybody tried to do so, the SSH attempts would leave a trail.
> If they blocked telnet, I would understand. But SSH? Does this policy
> make sense? Or am I missing something here?

That's insane at best. Your users can be trying to hack into outside
systems using ftp, http, or anything else that the remote sites are
running.

> My first thoughts about this policy was that the IT guys there are
> incompetent and do not want to do their home work to secure their
> systems and want to take the easy way out. But I figured I should ask
> others first in case I do not see all the subtle things.

It's past that. He's taking responsibility on himself for protecting
the whole rest of the internet from users at the university. That's
not his job.

> And, if that policy is wrong, the more tricky part, how do I start to
> convince them that outgoing SSH should be allowed ... which is going to
> be very uphill task. But since I find this policy huge pain in the neck
> (can't use rsync over ssh, can't use plain rsync even!), I am going to
> give it my best shot.

Somebody at that level of incompetence... I can't imagine.