Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes: >"H.S." <hs.saDELETEMEmix@gmail.com> 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. I agree that it is insane. ssh is the one secure remote login facility and in an academic setting security should be important. Their justification may be that there are a huge number of ssh hack scripts out there, which try to break into remote linux/unix machines by trying passwords. Most are launched from Windows machines, but they may be trying to stop that kind of attack. Of course there are better ways of doing it, but that may provide the justification. >> 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. They cannot "secure their systems" since academic users are very jealous of their own systems and do not allow the sysadmins to secure their machines. This of course makes their machines ripe for takeover and used as spambots, sshbots, etc. >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. Sure, that is part of his job. Why are you defining 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. You are at an academic institution. Talk to the profs. They have far more clout than do the students. using ssh to go out to other machines is the ONLY way that it should work, and academics are one of th eprime groups to use logging in to other machines. It may of course be that there are "student" networks which are blocked and "faculty" nets which are not. c

Hi, Nikos Chantziaras <realnc@arcor.de> wrote: > H.S. 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. > > That made me laugh ^^ > > >> I have never heard any such thing before, >> since if anybody tried to do so, the SSH attempts would leave a trail. > > Usually, incoming attacks leave a trail. Outgoing attempts are harder > to spot because you must explicitly look for them (they don't leave > logs). That means, one has to monitor such attempts. > > The easy way is to block it. That's a good solution if the admins don't > know how to monitor it. > > >> If they blocked telnet, I would understand. But SSH? Does this policy >> make sense? Or am I missing something here? > > It doesn't make sense, really. It *does* make sense when it's a > temporary block; until a real solution is set up. But shutting outgoing > SSH down forever is just ridiculous. > > >> 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. > > It's not about them securing their systems. Outgoing SSH is not part of > system security; incoming SSH is. By blocking outgoing SSH you are > trying to secure other systems from your own. Keep in mind, that outgoing ssh can easily be used to set up a tunnel, which probably will open your network for everyone. It is only a few commands and all the blocking of incoming ssh is in vain. I agree, that it is rather stupid to argue the way they do: preventing other networks and systems from attacks -- but in fact they secure their own systems. And they are obviously stupid enough, not to argue that way. So, from a security point of view, it really makes sense to block outgoing ssh connections from *every* workstation, but you can imagine a more secure scenario by having one dedicated machine, you can give outgoing ssh access and that you can control and audit much better. Again - imagine the following scenario: assume galileo is the inside host: georg@galileo[~]$ uname -a OpenBSD galileo.XXXXXXX.net X.X GENERIC georg@galileo[~]$ and he connects to the remote host outsite with the following command; georg@galileo[~]$ ssh -R 5022:localhost:22 bsd5 Password: .... [georg@bsd5] ~> uname -a FreeBSD bsd5.XXXXXXXX.net [georg@bsd5] ~> netstat -an | grep 5022 tcp4 0 0 127.0.0.1.5022 *.* LISTEN tcp6 0 0 ::1.5022 *.* LISTEN [georg@bsd5] ~> Now, you have a tunneled ssh daemon listening on port 5022 on the remote outside machine, that can be used to connect from the outside into your internal network. [georg@bsd5] ~> ssh -p 5022 localhost georg@localhost.XXXXXXX.net's password: Last login: Tue Nov 27 18:47:39 2007 from ......... OpenBSD ..... done - and no firewall will be able to block that incoming traffic. So, it is not a bad idea to block outgoing ssh traffic, because it opens you network to possibly nearly everyone -- and you should find a way, to do it in a more secure, controlled and audited manner. Best, gk