[j-nsp] cgnat routing architecture
My customers are currently in a vrf for internet access. they all have public ip addresses. I'm running low on IP's and I'm planning a CGNat deployment. Call my current vrf "one" I'm planning on creating a new inside nat domain, and throwing customers into that new vrf. Call the new vrf "three" I'm currently testing a Juniper MX104 with MS-MIC-16G and it seems to be working nicely thus far. (actually I'm testing redundant cgn nodes, the other one is a cisco asr9k w/vsm-500) On the juniper cgn node I have .. ms-1/0/0.2 - vrf "one" - service-domain outside ms-1/0/0.1 - vrf "three" - service-domain inside My current way of getting traffic towards the nat's is via static routes and thus being advertised into vrf "three" where remote pe's learn about those dual default routes and it all works good... but. static routes always scare me when not tied to some other logic. My concerns are that if the wan (nat outside, ms-1/0/0/2, vrf "one") side of the nat node dies, then I don't want traffic arriving at that nat node and being dropped/blackholed. What are the best ways to conditionally advertise a few routes based on some external reachability info ? I've recently learned about rib-groups and doing inter-vrf route leaking.. I wonder if I should learn the vrf "one" default route and leak it into vrf "three" across the control plane of those dual nat nodes. I've recently learned about conditionally generated routes and wonder if there's a nice solution there. I welcome any and all suggestions. Thanks y'all Aaron ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX480BASE3-AC - whats inside bundle
Hi Rob, last time I ordered a MX480-PREMIUM3-AC bundle (Mid/2015) I got the following parts: 1x MX480-PREMIUM3-AC 1x FANTRAY-MX480-HC-BB 4x PWR-MX480-2520-AC-BB 4x CBL-M-PWR-RA-EU 1x CHAS-MX480 1x CRAFT-MX480-S 2x RE-S-1800X4-32G-BB 2x SCBE2-MX-BB SCBE2-MX-BB was a (relatively cheap) extra, default is SCBE-MX-BB. Keep in mind, according to Juniper price list RE-S-X6-64G-B requires Junos 15.1F3. Best regards, Theo Voss -Ursprüngliche Nachricht- Von: juniper-nsp im Auftrag von Matthew Crocker Datum: Dienstag, 5. April 2016 um 15:35 An: Robert Hass Cc: "juniper-nsp@puck.nether.net" Betreff: Re: [j-nsp] MX480BASE3-AC - whats inside bundle Not exactly the same but I’m looking at a quote for a MX480-PREMIUM3-DC - MX480 Premium Bundle with redundant components, DC Power and it includes: JS-IPV6 JS-IPV6 IPv6 License — included FFANTRAY-MX480-HC-BB FFANTRAY-MX480-HC-BBMX480 High Capacity Fantray, Base Bundle — included PWR-MX480-2400-DC-BB PWR-MX480-2400-DC-BBMX480/MX240 2400W DC P/S, Base Bundle — included RE-S-X6-64G-BBRE-S-X6-64G-BB Routing Engine - 6 Core 2.0GHz with 64G Memory, Base Bundle, for MX240/MX480/MX960 —included SCBE2-MX-BB SCBE2-MX-BB Enhanced MX Switch Control Board, Base Bundle — extra but cheap — Matthew Crocker President - Crocker Communications, Inc. Managing Partner - Crocker Telecommunications, LLC E: matt...@corp.crocker.com E: matt...@crocker.com > On Apr 4, 2016, at 4:43 AM, Robert Hass wrote: > > On Mon, Apr 4, 2016 at 4:42 AM, Chen Jiang wrote: > >> The only difference between "3" and non-"3" model is the enhanced midplane >> to support new 500G line card. The old non-"3" chassis midplane could >> support about 300Gbps bandwidth per slot. >> >> Is it delivered with old SCB or with latest SCBE2 ? > > Rob > ___ > 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] protect ssh and telnet
❦ 5 avril 2016 11:58 -0400, Phil Shafer : > Apologies. I shot my mouth off. JUNOS does not currently support > this. And RADIUS, being cleartext, is not suitable. > > LDAP (w/ SSL) would be a better solution, using something like: > > https://github.com/AndriiGrytsenko/openssh-ldap-publickey > > which plugs into openssh using the "AuthorizedKeysCommand" sshd_config > statement. But JUNOS doesn't ship openldap, so the only way to > make this work would be an external web server can proxies requests > into LDAP. The AuthorizedKeysCommand would be a script that makes > the HTTP request and formats the results. The above LPK script > could be put inside a perl web framework like Mojolicious. Are we allowed to modify manually the /var/etc/sshd_conf file? Moreover, I suppose it could be rewritten on each commit by mgd. -- Nothing so needs reforming as other people's habits. -- Mark Twain ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] protect ssh and telnet
On 5 April 2016 at 21:10, Tom Storey wrote: Hey Tom, > Wouldnt that assume that you always access your REs inband, therefore > only ever connecting to the master? What if you access them out of > band via their ethernet ports. Each RE then needs its own unique key? I don't use on-band MGMT ethernets, I think they are actively harmful (not JNPR specific statement). But my recallection seems to be, that they do share state, so em0/fxp0 is always one specific port on active RE, and that you cannot SSH into the backup em07/fxp0. But take that with boatload of salt. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] protect ssh and telnet
Thinking out loud. Wouldnt that assume that you always access your REs inband, therefore only ever connecting to the master? What if you access them out of band via their ethernet ports. Each RE then needs its own unique key? I mean, in theory they probably dont (is there anything to stop multiple machines sharing the same key?), but it would make sense that each RE has its own unique "identity"? Or maybe that becomes a knob, shared identity with key in config or unique stored on disk? Or perhaps you store master and slave RE keys in config so they switch during failover, at least then you have a maximum of two keys to expect for any given box, which is better than n keys depending on how many REs you go through? Or some combination of both of these? On 5 April 2016 at 17:34, Saku Ytti wrote: > On 5 April 2016 at 19:18, Tore Anderson wrote: > > Hey, > >> Speaking only for myself, I'd accept server key change only if it's a >> device that is known to have been recently replaced/zeroized/etc. I'd >> *never* accept a key changing without that being expected for some >> reason known in advance. > > Depending on scale of network and position in the organisation this > may work. But if network has 100 tacacs account, thousands or tens of > thousands of devices, it may not be realistic to expect everyone of > the 100 user has good grasp when device is being replaced. Maybe 5 of > those even understand what SSH keys mean. > I think secret-in-config is fast remedy to hard problem. People who > are able to do something smart should be able to disable it, but it > seems safest default way to work. But it might be too late now for > that, as everyone has learned to ignore keys and many people have > toolised the key verification out. > >> That's not really true even if you blindly accept any changed/unknown >> SSH key, because telnet will leak information like login credentials in >> cleartext to any passive listener while mounting a successful attack on >> SSH requires MitM capability. That's more difficult to pull off. Also, >> if you're using SSH keys your login credentials won't leak even if you >> are successfully MitMed. > > I don't really have statistics on how often you are able to passively > listen but not inject, but logically it does make sense that passive > listen is more common, but by which margin, I don't know. From > security point of view I consider SSH Telnet equal when SSH keys are > not verified. But I still prefer SSH in this scenario, because it's > easier to mechanise with SSH via exec() channels etc. > > -- > ++ytti > ___ > 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] protect ssh and telnet
On 5 April 2016 at 19:18, Tore Anderson wrote: Hey, > Speaking only for myself, I'd accept server key change only if it's a > device that is known to have been recently replaced/zeroized/etc. I'd > *never* accept a key changing without that being expected for some > reason known in advance. Depending on scale of network and position in the organisation this may work. But if network has 100 tacacs account, thousands or tens of thousands of devices, it may not be realistic to expect everyone of the 100 user has good grasp when device is being replaced. Maybe 5 of those even understand what SSH keys mean. I think secret-in-config is fast remedy to hard problem. People who are able to do something smart should be able to disable it, but it seems safest default way to work. But it might be too late now for that, as everyone has learned to ignore keys and many people have toolised the key verification out. > That's not really true even if you blindly accept any changed/unknown > SSH key, because telnet will leak information like login credentials in > cleartext to any passive listener while mounting a successful attack on > SSH requires MitM capability. That's more difficult to pull off. Also, > if you're using SSH keys your login credentials won't leak even if you > are successfully MitMed. I don't really have statistics on how often you are able to passively listen but not inject, but logically it does make sense that passive listen is more common, but by which margin, I don't know. From security point of view I consider SSH Telnet equal when SSH keys are not verified. But I still prefer SSH in this scenario, because it's easier to mechanise with SSH via exec() channels etc. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] protect ssh and telnet
* Saku Ytti > If you want to do this right today, the correct way is to extract > public key in secure manner (What is secure? OOB not really, but maybe > human on-site) and store them in your jump box for user-wide > consumption, and raise alarm if host keys have changed. So who ever is > physically installing RE, should also make sure hostkeys are updated > securely in centralised location. > > I'm sure someone out there does this, but I'm going to say that at > least 99% of user-base (All vendors) just accept any key always. Speaking only for myself, I'd accept server key change only if it's a device that is known to have been recently replaced/zeroized/etc. I'd *never* accept a key changing without that being expected for some reason known in advance. I'll also accept unknown keys when accessing devices recently added to the network. These corner cases both give a small opportunity for a successful MitM attack, but I must admit I sleep well at night anyway. > Making SSH really no safer than Telnet. That's not really true even if you blindly accept any changed/unknown SSH key, because telnet will leak information like login credentials in cleartext to any passive listener while mounting a successful attack on SSH requires MitM capability. That's more difficult to pull off. Also, if you're using SSH keys your login credentials won't leak even if you are successfully MitMed. Tore ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] protect ssh and telnet
Vincent Bernat writes: >On which attribute can SSH keys be served? Apologies. I shot my mouth off. JUNOS does not currently support this. And RADIUS, being cleartext, is not suitable. LDAP (w/ SSL) would be a better solution, using something like: https://github.com/AndriiGrytsenko/openssh-ldap-publickey which plugs into openssh using the "AuthorizedKeysCommand" sshd_config statement. But JUNOS doesn't ship openldap, so the only way to make this work would be an external web server can proxies requests into LDAP. The AuthorizedKeysCommand would be a script that makes the HTTP request and formats the results. The above LPK script could be put inside a perl web framework like Mojolicious. It's a bit of rough plumbing, but until we can ship openldap (or you run the non-veriexec JUNOS), that's likely the best answer. Thanks, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] protect ssh and telnet
On 5 April 2016 at 16:53, Patrick Okui wrote: > I personally take an event that changes the host key the same as having a > new host (irrespective of platform). Usually those events have a human doing > the changes in the similar way that deploying a new one would. > > I therefore apply the same policy I would as if it was new kit. Tedious I > know, but SSH wasn’t really designed to make it easy to verify keys via > third parties. > > I’ve currently taken to maintaining SSHFP DNS records (rfc4255) and this > seems to work pretty well for me (in signed zones of course). Damn 1 percenters! Seriously this is the right solution today, but in practice it's too hard to most and those would benefit from the compromise of carrying secret in config. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] protect ssh and telnet
On 5 Apr 2016, at 14:14 EAT, Saku Ytti wrote: On 5 April 2016 at 13:52, Richard Hartmann wrote: This still sounds as if your CMDB would need to detect that, raise a flag, and then push out new config after being updated; in case of planned maintenance, you could even add that info before the swap. I don't think you can push secret key, not in supported way at least. You can jump to shell and replace the host keys in unixy way, of course. But how do you jump to the box when you don't know its keys? If you do know, then there is no point jumping to replace them, innit? If you want to do this right today, the correct way is to extract public key in secure manner (What is secure? OOB not really, but maybe human on-site) and store them in your jump box for user-wide consumption, and raise alarm if host keys have changed. So who ever is physically installing RE, should also make sure hostkeys are updated securely in centralised location. I personally take an event that changes the host key the same as having a new host (irrespective of platform). Usually those events have a human doing the changes in the similar way that deploying a new one would. I therefore apply the same policy I would as if it was new kit. Tedious I know, but SSH wasn’t really designed to make it easy to verify keys via third parties. I’ve currently taken to maintaining SSHFP DNS records (rfc4255) and this seems to work pretty well for me (in signed zones of course). -- patrick ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX480BASE3-AC - whats inside bundle
Not exactly the same but I’m looking at a quote for a MX480-PREMIUM3-DC - MX480 Premium Bundle with redundant components, DC Power and it includes: JS-IPV6 JS-IPV6 IPv6 License — included FFANTRAY-MX480-HC-BB FFANTRAY-MX480-HC-BBMX480 High Capacity Fantray, Base Bundle — included PWR-MX480-2400-DC-BB PWR-MX480-2400-DC-BBMX480/MX240 2400W DC P/S, Base Bundle — included RE-S-X6-64G-BBRE-S-X6-64G-BB Routing Engine - 6 Core 2.0GHz with 64G Memory, Base Bundle, for MX240/MX480/MX960 —included SCBE2-MX-BB SCBE2-MX-BB Enhanced MX Switch Control Board, Base Bundle — extra but cheap — Matthew Crocker President - Crocker Communications, Inc. Managing Partner - Crocker Telecommunications, LLC E: matt...@corp.crocker.com E: matt...@crocker.com > On Apr 4, 2016, at 4:43 AM, Robert Hass wrote: > > On Mon, Apr 4, 2016 at 4:42 AM, Chen Jiang wrote: > >> The only difference between "3" and non-"3" model is the enhanced midplane >> to support new 500G line card. The old non-"3" chassis midplane could >> support about 300Gbps bandwidth per slot. >> >> Is it delivered with old SCB or with latest SCBE2 ? > > Rob > ___ > 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] protect ssh and telnet
On 5 April 2016 at 14:32, Nathan Ward wrote: Hey, > I agree with you that putting these in the config is probably a solution - > though, backing them up to a RANCID server or whatever might not be ideal? > Not too sure, I’d have to think some more about this. I’d also be worried > about people using the same host key on many routers because they copied the > whole config over. By no means perfect solution, few are But easily deployable today without changes to processes or people and immediate security benefits. > Thinking of other solutions, can the router report in to a management system > and drop off it’s public key I wonder - perhaps the outbound-ssh service > could help establish the initial comms if you have the ability to get a > trusted, common config on to your boxes. I don’t know if outbound-ssh lets > you get a non-netconf SSH connection back in, and I’m not exactly sure of > what the mechanics would be of all that anyway.. it might make it worse. I'm thinking that if some protocol (probably not SSH, but does not matter now) could refresh devices publickey in central location and this protocol would rely on constant/static credentials in configuration templates, then it seem like ultimately it is same solution as just storing secret key in configs? Anyone with access to configs can update publickey to match newly generated secret key? Perhaps if all devices would have something like Cisco CMP (ETH OOB), which would add some identity in as DHCP option, and you could query from Cisco via RESTFUL HTTPS with this hash secret+identity+customerID+orderID if it's device Cisco shipped you and what is the CMP device's initial ssh fingerprint. Then you could programmatically give lease, if HTTPS proves success, programmatically with ssh push keys to the actual management plane. Secret would have been previously set on Cisco order pages. Something to that note might work. But would take long to deploy, would take forever to be ubiquitous. Where as secret in config is trivially implementable by all vendors rapidly. I know I could produce that DHCP server in working day, but how many organisation could not? > What happens in an RE failover if you’ve got a master only address? Does each > RE have it’s own key? I haven’t been the person on the ground for one of > those for years so can’t remember! REs maintain same key. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] protect ssh and telnet
On 5 April 2016 at 13:52, Richard Hartmann wrote: > This still sounds as if your CMDB would need to detect that, raise a > flag, and then push out new config after being updated; in case of > planned maintenance, you could even add that info before the swap. I don't think you can push secret key, not in supported way at least. You can jump to shell and replace the host keys in unixy way, of course. But how do you jump to the box when you don't know its keys? If you do know, then there is no point jumping to replace them, innit? If you want to do this right today, the correct way is to extract public key in secure manner (What is secure? OOB not really, but maybe human on-site) and store them in your jump box for user-wide consumption, and raise alarm if host keys have changed. So who ever is physically installing RE, should also make sure hostkeys are updated securely in centralised location. I'm sure someone out there does this, but I'm going to say that at least 99% of user-base (All vendors) just accept any key always. Making SSH really no safer than Telnet. This is pretty classic example where demanding good security (not exposing secret keys) destroys whole security model. Compromise of putting the secret keys in config would make secure much, much better for 99% of users. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] protect ssh and telnet
Sorry, I assumed a dual-RE setup, not one where you physically swap the RE. This still sounds as if your CMDB would need to detect that, raise a flag, and then push out new config after being updated; in case of planned maintenance, you could even add that info before the swap. Richard ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] protect ssh and telnet
On 5 April 2016 at 13:02, Richard Hartmann wrote: > Isn't a list of valid pubkeys enough? You can toss that into > known_hosts or your equivalent automagically and be done with it. But the keys changes on the router when RE is swapped. So you no longer know it's the same device you've connected before. In all networks I've worked with, this is 'solved' by not caring about key changes. Which makes ssh pretty much same as telnet. I would rather trust that configuration is secure and my employees aren't going to MITM me and just keeps secret keys in config, so that router can always use same keys and I could treat key changes as alerts. It's not best possible solution, but it's very much superior to not caring about key changes. And it's easy solution to deploy. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] protect ssh and telnet
On Tue, Apr 5, 2016 at 11:45 AM, Saku Ytti wrote: > I wish we could make the compromise and have secret keys > stored in config, so that they would survive RE changes. Isn't a list of valid pubkeys enough? You can toss that into known_hosts or your equivalent automagically and be done with it. Richard ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] protect ssh and telnet
On 5 April 2016 at 05:23, Phil Shafer wrote: Hey Phil, > Me, I don't even like allowing passwords. JUNOS now supports the > "system services ssh no-passwords" knob to force the use of ssh > keys over text passwords. And your radius server will happily serve > ssh keys. Force the move away from passwords. I do generally agree on the notion of no password, but isn't radius cleartext, so middle-man could send their own publickeys and then use their secret key to login. So doesn't this rely on assumption that radius is in secure network without middle-man possibility. In which case telnet would be equally safe? Another thing that grinds my gears (not JNPR specific) is that because routers own secret key is not in config, it changes when our control-planes break down and we switch them. This makes it standard practice for vast majority of the network to just ignore key changes completely. Which in turn again makes ssh pretty much as good as telnet. I wish we could make the compromise and have secret keys stored in config, so that they would survive RE changes. People who already have some way of handling this situation securely, wouldn't need to enable this. But people who now just blindly delete and trust any host keys, could turn this on and start verifying keys having much better security than just ignoring them. (How many who run rancid, oxidized or equivalent let them fail on key failures?). -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] protect ssh and telnet
On 5 Apr 2016, at 5:23 EAT, Phil Shafer wrote: > Aaron writes: >> I'm new to Juniper. and I'm looking to protect ssh/telnet on all interfaces >> on my juniper ACX5048's. > > First comment is: if you want security, don't allow telnet. > Force the use of ssh. > > Me, I don't even like allowing passwords. JUNOS now supports the "system > services ssh no-passwords" knob to force the use of ssh keys over text > passwords. And your radius server will happily serve ssh keys. Force the > move away from passwords. Do you have documentation on how to do this? I have looked through the cymru docs and they don’t say how to serve the SSH key from radius. -- patrick signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
