Re: [j-nsp] Changing SSH port on EX switches, M routers
From: Stefan Fouant sfou...@shortestpathfirst.net Date: Sun, 3 Apr 2011 21:27:06 -0400 -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- boun...@puck.nether.net] On Behalf Of Kevin Oberman Sent: Sunday, April 03, 2011 7:50 PM 1. Limit access to the ssh port to trusted hosts, preferably tightly controlled hosts that are dedicated to acting a bastions. No extra services running that might open vulnerabilities! 2. No passwords! Even if rules for 'good' passwords are followed, passwords are not nearly as strong as good cyrpto keys. (yes, I know about the Debian issue! That was so incredibly stupid that it still boggles my mind! I doubt that any Unix distro will ever do anything so incomprehensibly stupid again, but it's unwise to assume stupidity is growing less common. If in doubt, run openssh directly from openssh.org. they KNOW what they are doing! 3. Require two factor systems to further control access. We use SmartCard tokens to create and store the private keys. When working properly, it is not possible to get the private key off of the token and modern openssh contains support for PKCS11 which will work with SmartCards, though finding tokens that work with Unix in the US is a problem. This sort of control is vastly superior to playing games with the ssh port by which smart hackers will only be mildly disturbed. While I completely agree with all of the points, there is such a thing as taking things too far... to the point where security actually becomes an encumbrance and hinders normal operations... I once worked for an employer that had the most bizarre and overly complex process for accessing devices - they required everyone to log into a VPN Concentrator (regardless of being remote or at the corporate location). From there they required SSHing into jumphosts, and then finally from the jumphost you could SSH into your given device. The VPN, jumphosts, and the end-devices were all using two-factor authentication (SecureID). While this represented probably one of the most secure environments I've ever worked in, logging into multiple devices during firedrills was a real PITA to say the least... As with any security system, you need to trade off the benefits versus the costs. Aside from procurement and training costs, theer are on-going maintenance costs and loss of productivity due to the implementation. FWIW, the system we use is quite straight-forward. It does require a login to a bastion host with the SmartCard token followed by access to the routing asset, also via SSH. IT really means: $ ssh bastion1.es.net (not a real node name) $ ssh chicago-router-1 You better have more than one bastion host and they need to be as diversely located as possible in your network footprint. The most common key-based attacks depend on stealing a private key, usually with the pass-phrase. With the tokens, this simply odes not work, making public key access pretty strong. We have been using this system for over two years with minimal operational impact and no cases where access was unavailable except when tokens were physically damaged or forgotten. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Changing SSH port on EX switches, M routers
On 03/04/11 02:13, Jesus Alvarez wrote: It should be trivial to implement a configurable SSH port in the Junos True. firmware and this would help in securing the router. Practically all I doubt it. scanners attempt SSH logins when port 22 is available but very few check all available ports. It is surprising that Juniper does not provide a way to change the SSH port. In my experience if you change the port all that happens is the really simple scans go away, but anything the least bit smart is still there. The way to stop SSH being an issue is: 1. If possible firewall the port to allow known management traffic only. Obviously most networks need to leave a few bounce hosts for emergencies, but these can be *nix hosts that can run fail2ban or similar 2. Disable root auth (*especially* with JunOS, I find I need a root [not super-user] shell roughly once a year, and start shell; su takes care of that) 3. Disable password auth. As long as you don't trust any known compromised keys (Debian SSL bug bites again) this stops everything. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Changing SSH port on EX switches, M routers
the normal approach is to have the control plane policing policy limit where you can ssh from rather than obfiscating the port number. From my vantage point the ability to forward traffic up to the control plane is the problem not which port it happens to be pointed. while you could rate limit it with a policer that seems like it's missing the point. On 4/1/11 5:23 PM, Jesus Alvarez wrote: Hi, Is there a way to change the SSH port for managing the EX switches and M routers? We normally avoid using the standard port 22. Thanks! ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Changing SSH port on EX switches, M routers
And last, but not least:
ssh {
root-login deny;
protocol-version v2;
rate-limit 3;
}
Rate limit it in the [system services] stanza. 3 unsuccessful tries and the IP
is ignored.
- Chris.
P.S. the 'ssh' services port is defined in /etc/services. Unsure if you adjust
the line, that it may move the listening port. Might be worth a try; but
naturally this would be a Juniper-unsupported configuration and will probably
be overwritten on a software upgrade. It may also affect your firewall filters
in the [from] stanza. YMMV.
chrisk@fw02.miller start shell
% grep ssh /etc/services
ssh 22/tcp#Secure Shell Login
ssh 22/udp#Secure Shell Login
On 2011-04-02, at 11:23 AM, Jesus Alvarez wrote:
Hi,
Is there a way to change the SSH port for managing the EX switches and M
routers? We normally avoid using the standard port 22.
Thanks!
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Changing SSH port on EX switches, M routers
-Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- boun...@puck.nether.net] On Behalf Of Chris Kawchuk Sent: Sunday, April 03, 2011 4:48 PM P.S. the 'ssh' services port is defined in /etc/services. Unsure if you adjust the line, that it may move the listening port. Might be worth a try; but naturally this would be a Juniper-unsupported configuration and will probably be overwritten on a software upgrade. It may also affect your firewall filters in the [from] stanza. YMMV. I'm surprised by how many people on this list still think that 'Security through Obscurity' is an effective means of securing devices. Nmap or any other suitable scanner could isolate the SSH port in relatively no time at all. As a matter of practice I think that isolating the allowed IPs which might avail of the SSH port or any other management service for that matter is a much better overall solution. Stefan Fouant, CISSP, JNCIEx2 www.shortestpathfirst.net GPG Key ID: 0xB4C956EC ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Changing SSH port on EX switches, M routers
Agreed. A proper [firewall family inet] restricting ssh access with a packet filter is a far better solution. I assume that lo0.0 loopback filters finally work on an EX-series as of 10.4 (I think I saw that in the release notes for 10.4R3x). - Chris. On 2011-04-04, at 7:02 AM, Stefan Fouant wrote: I'm surprised by how many people on this list still think that 'Security through Obscurity' is an effective means of securing devices. Nmap or any other suitable scanner could isolate the SSH port in relatively no time at all. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Changing SSH port on EX switches, M routers
Ok, it may appear that I was advocating security by obscurity, hence here's
an example of a 'correct' way of doing things: =)
policy-options {
/* Put your known IPs here to allow them through */
prefix-list management-ips {
1.2.3.4/32;
2.3.4.5/32;
3.4.5.6/32;
}
}
firewall {
family inet {
filter protect-management {
term allow-my-ips {
from {
source-prefix-list {
management-ips;
}
protocol tcp;
destination-port 22;
tcp-initial;
}
then accept;
}
term deny-all-other-ips {
from {
protocol tcp;
destination-port 22;
tcp-initial;
}
then {
discard;
}
}
term allow-all-other-control-plane-traffic {
then accept;
}
}
}
}
interfaces {
lo0 {
unit 0 {
family inet {
filter {
input protect-management;
}
address 4.3.2.1/32;
}
}
}
}
Hope this helps
- Chris.
On 2011-04-04, at 7:02 AM, Stefan Fouant wrote:
-Original Message-
From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
boun...@puck.nether.net] On Behalf Of Chris Kawchuk
Sent: Sunday, April 03, 2011 4:48 PM
P.S. the 'ssh' services port is defined in /etc/services. Unsure if you
adjust the line, that it may move the listening port. Might be worth a
try; but naturally this would be a Juniper-unsupported configuration
and will probably be overwritten on a software upgrade. It may also
affect your firewall filters in the [from] stanza. YMMV.
I'm surprised by how many people on this list still think that 'Security
through Obscurity' is an effective means of securing devices. Nmap or any
other suitable scanner could isolate the SSH port in relatively no time at
all.
As a matter of practice I think that isolating the allowed IPs which might
avail of the SSH port or any other management service for that matter is a
much better overall solution.
Stefan Fouant, CISSP, JNCIEx2
www.shortestpathfirst.net
GPG Key ID: 0xB4C956EC
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Changing SSH port on EX switches, M routers
-Original Message-
From: Chris Kawchuk [mailto:juniperd...@gmail.com]
Sent: Sunday, April 03, 2011 5:41 PM
To: Jesus Alvarez
Cc: juniper-nsp; Stefan Fouant
Subject: Re: [j-nsp] Changing SSH port on EX switches, M routers
Ok, it may appear that I was advocating security by obscurity, hence
here's an example of a 'correct' way of doing things: =)
policy-options {
/* Put your known IPs here to allow them through */
prefix-list management-ips {
1.2.3.4/32;
2.3.4.5/32;
3.4.5.6/32;
}
}
Thanks for inclusion of the inbound-prefix ACLs for completeness of the
discussion.
For the record, the comment wasn't directed at you, but rather the direction
of the thread.
Stefan Fouant, CISSP, JNCIEx2
www.shortestpathfirst.net
GPG Key ID: 0xB4C956EC
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Changing SSH port on EX switches, M routers
Date: Sun, 03 Apr 2011 13:12:54 -0700 From: Joel Jaeggli joe...@bogus.com Sender: juniper-nsp-boun...@puck.nether.net the normal approach is to have the control plane policing policy limit where you can ssh from rather than obfiscating the port number. From my vantage point the ability to forward traffic up to the control plane is the problem not which port it happens to be pointed. while you could rate limit it with a policer that seems like it's missing the point. +1 1. Limit access to the ssh port to trusted hosts, preferably tightly controlled hosts that are dedicated to acting a bastions. No extra services running that might open vulnerabilities! 2. No passwords! Even if rules for 'good' passwords are followed, passwords are not nearly as strong as good cyrpto keys. (yes, I know about the Debian issue! That was so incredibly stupid that it still boggles my mind! I doubt that any Unix distro will ever do anything so incomprehensibly stupid again, but it's unwise to assume stupidity is growing less common. If in doubt, run openssh directly from openssh.org. they KNOW what they are doing! 3. Require two factor systems to further control access. We use SmartCard tokens to create and store the private keys. When working properly, it is not possible to get the private key off of the token and modern openssh contains support for PKCS11 which will work with SmartCards, though finding tokens that work with Unix in the US is a problem. This sort of control is vastly superior to playing games with the ssh port by which smart hackers will only be mildly disturbed. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Changing SSH port on EX switches, M routers
-Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- boun...@puck.nether.net] On Behalf Of Kevin Oberman Sent: Sunday, April 03, 2011 7:50 PM 1. Limit access to the ssh port to trusted hosts, preferably tightly controlled hosts that are dedicated to acting a bastions. No extra services running that might open vulnerabilities! 2. No passwords! Even if rules for 'good' passwords are followed, passwords are not nearly as strong as good cyrpto keys. (yes, I know about the Debian issue! That was so incredibly stupid that it still boggles my mind! I doubt that any Unix distro will ever do anything so incomprehensibly stupid again, but it's unwise to assume stupidity is growing less common. If in doubt, run openssh directly from openssh.org. they KNOW what they are doing! 3. Require two factor systems to further control access. We use SmartCard tokens to create and store the private keys. When working properly, it is not possible to get the private key off of the token and modern openssh contains support for PKCS11 which will work with SmartCards, though finding tokens that work with Unix in the US is a problem. This sort of control is vastly superior to playing games with the ssh port by which smart hackers will only be mildly disturbed. While I completely agree with all of the points, there is such a thing as taking things too far... to the point where security actually becomes an encumbrance and hinders normal operations... I once worked for an employer that had the most bizarre and overly complex process for accessing devices - they required everyone to log into a VPN Concentrator (regardless of being remote or at the corporate location). From there they required SSHing into jumphosts, and then finally from the jumphost you could SSH into your given device. The VPN, jumphosts, and the end-devices were all using two-factor authentication (SecureID). While this represented probably one of the most secure environments I've ever worked in, logging into multiple devices during firedrills was a real PITA to say the least... Stefan Fouant, CISSP, JNCIEx2 www.shortestpathfirst.net GPG Key ID: 0xB4C956EC ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Changing SSH port on EX switches, M routers
Date: Sun, 03 Apr 2011 13:12:54 -0700 From: Joel Jaeggli joe...@bogus.com Sender: juniper-nsp-boun...@puck.nether.net the normal approach is to have the control plane policing policy limit where you can ssh from rather than obfiscating the port number. From my vantage point the ability to forward traffic up to the control plane is the problem not which port it happens to be pointed. while you could rate limit it with a policer that seems like it's missing the point. +1 1. Limit access to the ssh port to trusted hosts, preferably tightly controlled hosts that are dedicated to acting a bastions. No extra services running that might open vulnerabilities! 2. No passwords! Even if rules for 'good' passwords are followed, passwords are not nearly as strong as good cyrpto keys. (yes, I know about the Debian issue! That was so incredibly stupid that it still boggles my mind! I doubt that any Unix distro will ever do anything so incomprehensibly stupid again, but it's unwise to assume stupidity is growing less common. If in doubt, run openssh directly from openssh.org. they KNOW what they are doing! 3. Require two factor systems to further control access. We use SmartCard tokens to create and store the private keys. When working properly, it is not possible to get the private key off of the token and modern openssh contains support for PKCS11 which will work with SmartCards, though finding tokens that work with Unix in the US is a problem. This sort of control is vastly superior to playing games with the ssh port by which smart hackers will only be mildly disturbed. There are a number of script kiddy tools that only check port 22 for ssh. Moving to a different port is an effective tool aginst that threat. The tools are basicly drive by hacking. Send a port with user id bob with password egale1 to port 22, wait a bit and try something else. Not being on port 22 helps with the odds a great deal and since any password guessing is based on random odds, anything you do to increase those odds helps a great deal. If something is listening on port 22, then a high port is less liekly to get hit so its the odds game and if you have something listening on 22 that will log attempts, you have an early warning system that something is playing games that should not have happened. As far as keys vs passwords, keys have resulted in far more high value compromised systems than passwords from what I've seen. I figure this is mostly a result of openSSH not having the option to require both keys and a password (which is not the same as a password protected key). Every tool that guesses ssh passwords and does anything once it logs in also has a payload to hunt for other hosts via keys too and many of them can try passphrases on protected keys which they can do much faster than trying remote systems. If your using keys, make sure they are password protected but keep in mind that if someone is far enough into a bastions host that has keys to your router, there is a good chance they can install a keylogger to grab passwords too. -tim ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Changing SSH port on EX switches, M routers
On Fri, Apr 01, 2011 at 08:23:31PM -0400, Jesus Alvarez wrote: Is there a way to change the SSH port for managing the EX switches and M routers? We normally avoid using the standard port 22. No. I've been asking for that feature since... hm, around 2003 or so. Probably no customer demand. :-) Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Changing SSH port on EX switches, M routers
On Sat, Apr 02, 2011 at 02:14:12PM +0200, Daniel Roesen wrote: On Fri, Apr 01, 2011 at 08:23:31PM -0400, Jesus Alvarez wrote: Is there a way to change the SSH port for managing the EX switches and M routers? We normally avoid using the standard port 22. No. I've been asking for that feature since... hm, around 2003 or so. Probably no customer demand. :-) I wonder if you could create an /etc/ssh/sshd_config file and set the port number in there... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Changing SSH port on EX switches, M routers
On 02.04.2011 14:22, Chuck Anderson wrote: I wonder if you could create an /etc/ssh/sshd_config file and set the port number in there... Not exactly, because the sshd is started by inetd - you can as root change that file - but you have to ensure it doesn't get changed by mgd. So a cron script checking for what is in there once an hour does the trick.. Tom ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Changing SSH port on EX switches, M routers
No, I've been asking for this feature. :) Thanks for your answer. It should be trivial to implement a configurable SSH port in the Junos firmware and this would help in securing the router. Practically all scanners attempt SSH logins when port 22 is available but very few check all available ports. It is surprising that Juniper does not provide a way to change the SSH port. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Changing SSH port on EX switches, M routers
Not exactly, because the sshd is started by inetd - you can as root change that file - but you have to ensure it doesn't get changed by mgd. So a cron script checking for what is in there once an hour does the trick.. Thanks for your answer. That sounds like a clever workaround. Are the sshd_config options the same as in OpenSSH? On Junos 10.2R3.10 there is no /etc/ssh/sshd_config. Can I just create a file with a single line to change the port (leaving all other options as defaults)? e.g. something like Port x Could you share the portion of your cron script that replaces sshd_config and restarts sshd when required? I guess port 22 would still be available between the time mgd changes the ssh_config and the time the cron script restarts sshd. How frequently do you see mgd changing the sshd_config? The SSH port should be configurable in the Junos config but this may be a reasonable way to get it implemented. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Changing SSH port on EX switches, M routers
You should probably think about doing IP-based filtering on your management networks. It's going to guarantee a drop in random port scans/login attempts vs obfuscating the listen port of ssh. Scott On Sat, Apr 2, 2011 at 11:13 AM, Jesus Alvarez jalva...@prw.net wrote: No, I've been asking for this feature. :) Thanks for your answer. It should be trivial to implement a configurable SSH port in the Junos firmware and this would help in securing the router. Practically all scanners attempt SSH logins when port 22 is available but very few check all available ports. It is surprising that Juniper does not provide a way to change the SSH port. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Changing SSH port on EX switches, M routers
On Fri, Apr 01, 2011 at 08:23:31PM -0400, Jesus Alvarez wrote: Hi, Is there a way to change the SSH port for managing the EX switches and M routers? We normally avoid using the standard port 22. No, I've been asking for this feature. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Changing SSH port on EX switches, M routers
Hmm. Maybe you could do a nat policy, or maybe just hack a ssh tunnel to map the port. Does the built in ssh client support tunnels? If so you could restrict ssh access to the local host and get the result you need. Of course you'd have to start the tunnel redirect with a script. Will O'Brien On Apr 1, 2011, at 8:07 PM, Richard A Steenbergen r...@e-gerbil.net wrote: On Fri, Apr 01, 2011 at 08:23:31PM -0400, Jesus Alvarez wrote: Hi, Is there a way to change the SSH port for managing the EX switches and M routers? We normally avoid using the standard port 22. No, I've been asking for this feature. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
