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] JUNOS and MS RPC
Thanks for the feedback. Is this common for firewall vendors, where the full dynamic range needs to be opened to support RPC, or is this a failing of JUNOS? I've only dealt with ScreenOS and JUNOS. I'm looking for more information to take back to the governance folks. The other options, I suppose, are to go through all of our DC's and define static RPC ports in the registry or setup IPSec sessions between the servers. Glenn From: Scott T. Cameron routeh...@gmail.commailto:routeh...@gmail.com Date: Sat, 2 Apr 2011 15:38:22 -0600 To: Glenn Krutsinger gkrutsin...@compassion.commailto:gkrutsin...@compassion.com Cc: juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net Subject: Re: [j-nsp] JUNOS and MS RPC I've got two sets of SRX3400 clusters, and the ALGs should come with: caveat emptor. Nice on paper and very similar to Linux conntrack modules, but in reality the rule of thumb is it's better to have them disabled. In the case of Microsoft, their technical papers will say your firewall should allow 1024-65535 open. In my datacenters, the only place where I find this to be necessary is to domain controllers. Most other MS software can happily run off a specific TCP port. YMMV. Scott On Sat, Apr 2, 2011 at 4:33 PM, Glenn Krutsinger gkrutsin...@compassion.commailto:gkrutsin...@compassion.com wrote: Hello all, Is anyone running MS products through SRX firewalls? How are you getting RPC to work? According to engineering, the ScreenOS ms-rpc-any isn't included in JUNOS, although, I do see the ALG catching the info based off of endpoint mapper sessions. Add to that the fact that MS changed their port range for RPC with Server 2008 has given me some real fun conversations with our server team. Thanks, Glenn ___ juniper-nsp mailing list juniper-nsp@puck.nether.netmailto: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
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
