Re: [j-nsp] protect ssh and telnet

[Krasimir Avramski]

Hey Aaron,


file show /var/db/scripts/commit/ifl-addr.slax


version 1.0;

ns junos = "http://xml.juniper.net/junos/*/junos";;
ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";;
ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";;

import "../import/junos.xsl";

match configuration {
var $toplevel = .;
var $vrf = "one"; /* name of routing instance */
var $direct = 0; /* set this to 1 for building  "direct" prefixes, default
is "local"" */

 {
 {
 {
 "ifl-addr-v4";
for-each ($toplevel/routing-instances/instance[name =
$vrf]/interface) {
var $ifd = substring-before(name, ".");
var $unit = substring-after(name, ".");
for-each ($toplevel/interfaces/interface[name =
$ifd]/unit[name = $unit]/family/inet/address) {
  var $addr = jcs:parse-ip(name);
if ($direct) {
{
 $addr[4]_"/"_$addr[3];
   }
}
else {
 {
 $addr[1];
}
}
}
}
 }
 }
 }
}

Best Regards,
Krasi


On 15 April 2016 at 23:12, Aaron  wrote:

> Right, that’s what I saw recently when working through a case with JTAC…
>
>
>
> I need a solution that will…
>
> 1 – apply to ONLY my direct/local actual ip addresses on my ACX5048
>
> 2 – apply to ONLY routing-instance vrf “one”
>
>
>
>
>
> agould@eng-lab-acx5048-1
> #
> show policy-options prefix-list all-internet | display inheritance
> ##
> ## apply-path was expanded to:
> ## 10.101.14.124/30;
> ## 10.101.14.108/30;
> ## 1.2.3.64/28;
> ## 10.95.255.0/26;
> ## 10.101.12.245/32;
> ##
> apply-path "interfaces <*> unit <*> family inet address <*>";
>
>
>
>
>
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] protect ssh and telnet

[Aaron]

Right, that’s what I saw recently when working through a case with JTAC…

 

I need a solution that will…

1 – apply to ONLY my direct/local actual ip addresses on my ACX5048

2 – apply to ONLY routing-instance vrf “one”

 

 

 

 agould@eng-lab-acx5048-1# show policy-options prefix-list all-internet | 
display inheritance
##
## apply-path was expanded to:
## 10.101.14.124/30;
## 10.101.14.108/30;
## 1.2.3.64/28;
## 10.95.255.0/26;
## 10.101.12.245/32;
##
apply-path "interfaces <*> unit <*> family inet address <*>";

 

 

 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] protect ssh and telnet

[Krasimir Avramski]

Hi Aaron,

Currently script is building list of all configured ifls (except
logical-systems defined). You can tag the the vrf "one" addresses through
"apply-macro" and modify script to add address based on that condition.

Sample ifl tag:
set interfaces xe-0/0/0 unit 0 family inet address 3.3.3.3/24 apply-macro
vrf-one

Best Regards,
Krasi




On 15 April 2016 at 19:10, Aaron  wrote:

> Thanks Krasi, Hmmm, this looks very interesting, I want to try it in my
> lab… also, please let me know if this will ONLY work for my
> routing-instance vrf “one” interfaces…
>
>
>
> My vrf “one” is where my public/vulnerable ip’s live…
>
>
>
> I don’t need to protect my default core vrf which is all 10.x.x.x and that
> domain is behing a mgmt. net firewall boundary
>
>
>
> Aaron
>
>
>
> *From:* Krasimir Avramski [mailto:kr...@smartcom.bg]
> *Sent:* Friday, April 15, 2016 6:51 AM
> *To:* Aaron 
> *Cc:* Chris Jones ; Juniper-Nsp <
> juniper-nsp@puck.nether.net>
>
> *Subject:* Re: [j-nsp] protect ssh and telnet
>
>
>
> Hi Aaron,
>
>
>
> Below is commit script which is building dynamic prefix list (containing
> local IPv4 addresses) you could reference in FTF:
>
>
>
> krasi# show system scripts commit
>
> allow-transients;
>
> file ifl-addr-v4.slax;
>
>
>
>
>
>
>
>
>
> krasi# run file show /var/db/scripts/commit/ifl-addr-v4.slax
>
> version 1.0;
>
>
>
> ns junos = "http://xml.juniper.net/junos/*/junos";;
>
> ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";;
>
> ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";;
>
>
>
> import "../import/junos.xsl";
>
>
>
> match configuration {
>
>  {
>
>  {
>
>  {
>
>  "ifl-addr-v4";
>
>   for-each (interfaces/interface/unit/family/inet/address)
> {
>
> var $address = substring-before(name, "/");
>
>  {
>
>$address;
>
>}
>
>   }
>
>  }
>
>  }
>
>  }
>
> }
>
>
>
>
>
>
>
> krasi# show policy-options |display inheritance |display commit-scripts
>
> prefix-list ifl-addr-v4 {
>
> 1.1.1.1/32;
>
> 10.10.111.1/32;
>
> }
>
>
>
>
>
> krasi# set interfaces xe-0/0/0 unit 0 family inet address 2.2.2.2/30
>
>
>
> [edit]
>
> root# commit
>
> commit complete
>
>
>
> [edit]
>
> root# show policy-options |display inheritance |display commit-scripts
>
> prefix-list ifl-addr-v4 {
>
> 1.1.1.1/32;
>
> 2.2.2.2/32;
>
> 10.10.111.1/32;
>
>  }
>
>
>
>
>
> Best Regards,
>
> Krasi
>
>
>
> On 13 April 2016 at 23:43, Aaron  wrote:
>
> Thanks Chris, but apparently the Juniper ACX5048 is an exception to the
> lo0 rule…  see link
>
>
>
> http://kb.juniper.net/InfoCenter/index?page=content <
> http://kb.juniper.net/InfoCenter/index?page=content&id=KB28893&actp=search&viewlocale=en_US&searchid=1305252358192>
> &id=KB28893&actp=search&viewlocale=en_US&searchid=1305252358192
>
>
>
> I’ve been able to accomplish protecting telnet/ssh on my ACX5048 like this…
>
>
>
> set routing-instances one forwarding-options family inet filter input
> protect-5048
>
> set firewall family inet filter protect-5048 term 1 from
> destination-address 1.1.1.1/32
>
> set firewall family inet filter protect-5048 term 1 from protocol tcp
>
> set firewall family inet filter protect-5048 term 1 from destination-port
> telnet
>
> set firewall family inet filter protect-5048 term 1 from destination-port
> ssh
>
> set firewall family inet filter protect-5048 term 1 then count
> protect-5048-counter
>
> set firewall family inet filter protect-5048 term 1 then discard
>
> set firewall family inet filter protect-5048 term 2 then accept
>
>
>
> 1.1.1.0/24 is a subnet on an interface in vrf “one” on my acx5048…
>
>
>
> The only thing is that I will need to make it a policy with my colleagues
> that if/when we churn public address space or add new interfaces on our
> acx5048’s, part of the process will be to add a line to our firewall acl…
>
>
>
> set firewall family inet filter protect-5048 term 1 from
> destination-address 1.1.2.1/32
>
> set firewall family inet filter protect-5048 term 1 from
> destination-address 1.1.3.1/32
>
> etc
>
>
>
> QUESTION – does any

Re: [j-nsp] protect ssh and telnet

[Krasimir Avramski]

Hi Roberto,

The script is building only /32 "local" prefixes.
Your suggestion is building "direct" prefixes (cisco "connected" networks)
and when matching at the FTF level (note that is NOT lo0 filter)  depending
on the filter action you can achieve "undesired" results.

Best Regards,
Krasi

On 15 April 2016 at 19:39, Roberto Bertó  wrote:

> What's difference between your junos script and this apply-path?
>
> set policy-options prefix-list router-ipv4 apply-path "interfaces <*> unit
> <*> family inet address <*>"
>
>
> 2016-04-15 13:10 GMT-03:00 Aaron :
>
>> Thanks Krasi, Hmmm, this looks very interesting, I want to try it in my
>> lab… also, please let me know if this will ONLY work for my
>> routing-instance vrf “one” interfaces…
>>
>>
>>
>> My vrf “one” is where my public/vulnerable ip’s live…
>>
>>
>>
>> I don’t need to protect my default core vrf which is all 10.x.x.x and
>> that domain is behing a mgmt. net firewall boundary
>>
>>
>>
>> Aaron
>>
>>
>>
>> From: Krasimir Avramski [mailto:kr...@smartcom.bg]
>> Sent: Friday, April 15, 2016 6:51 AM
>> To: Aaron 
>> Cc: Chris Jones ; Juniper-Nsp <
>> juniper-nsp@puck.nether.net>
>> Subject: Re: [j-nsp] protect ssh and telnet
>>
>>
>>
>> Hi Aaron,
>>
>>
>>
>> Below is commit script which is building dynamic prefix list (containing
>> local IPv4 addresses) you could reference in FTF:
>>
>>
>>
>> krasi# show system scripts commit
>>
>> allow-transients;
>>
>> file ifl-addr-v4.slax;
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> krasi# run file show /var/db/scripts/commit/ifl-addr-v4.slax
>>
>> version 1.0;
>>
>>
>>
>> ns junos = "http://xml.juniper.net/junos/*/junos";;
>>
>> ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";;
>>
>> ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";;
>>
>>
>>
>> import "../import/junos.xsl";
>>
>>
>>
>> match configuration {
>>
>>  {
>>
>>  {
>>
>>  {
>>
>>  "ifl-addr-v4";
>>
>>   for-each
>> (interfaces/interface/unit/family/inet/address) {
>>
>> var $address = substring-before(name, "/");
>>
>>  {
>>
>>$address;
>>
>>}
>>
>>   }
>>
>>  }
>>
>>  }
>>
>>  }
>>
>> }
>>
>>
>>
>>
>>
>>
>>
>> krasi# show policy-options |display inheritance |display commit-scripts
>>
>> prefix-list ifl-addr-v4 {
>>
>> 1.1.1.1/32 <http://1.1.1.1/32> ;
>>
>> 10.10.111.1/32 <http://10.10.111.1/32> ;
>>
>> }
>>
>>
>>
>>
>>
>> krasi# set interfaces xe-0/0/0 unit 0 family inet address 2.2.2.2/30 <
>> http://2.2.2.2/30>
>>
>>
>>
>> [edit]
>>
>> root# commit
>>
>> commit complete
>>
>>
>>
>> [edit]
>>
>> root# show policy-options |display inheritance |display commit-scripts
>>
>> prefix-list ifl-addr-v4 {
>>
>> 1.1.1.1/32 <http://1.1.1.1/32> ;
>>
>> 2.2.2.2/32 <http://2.2.2.2/32> ;
>>
>> 10.10.111.1/32 <http://10.10.111.1/32> ;
>>
>>  }
>>
>>
>>
>>
>>
>> Best Regards,
>>
>> Krasi
>>
>>
>>
>> On 13 April 2016 at 23:43, Aaron mailto:aar...@gvtc.com>
>> > wrote:
>>
>> Thanks Chris, but apparently the Juniper ACX5048 is an exception to the
>> lo0 rule…  see link
>>
>>
>>
>> http://kb.juniper.net/InfoCenter/index?page=content <
>> http://kb.juniper.net/InfoCenter/index?page=content <
>> http://kb.juniper.net/InfoCenter/index?page=content&id=KB28893&actp=search&viewlocale=en_US&searchid=1305252358192>
>> &id=KB28893&actp=search&viewlocale=en_US&searchid=1305252358192>
>> &id=KB28893&actp=search&viewlocale=en_US&searchid=1305252358192
>>
>>
>>
>> I’ve been able to accomplish protecting telnet/ssh on my ACX5048 like
>> this…
>>
>>
>>
&g

Re: [j-nsp] protect ssh and telnet

[Roberto Bertó]

What's difference between your junos script and this apply-path?

set policy-options prefix-list router-ipv4 apply-path "interfaces <*> unit
<*> family inet address <*>"


2016-04-15 13:10 GMT-03:00 Aaron :

> Thanks Krasi, Hmmm, this looks very interesting, I want to try it in my
> lab… also, please let me know if this will ONLY work for my
> routing-instance vrf “one” interfaces…
>
>
>
> My vrf “one” is where my public/vulnerable ip’s live…
>
>
>
> I don’t need to protect my default core vrf which is all 10.x.x.x and that
> domain is behing a mgmt. net firewall boundary
>
>
>
> Aaron
>
>
>
> From: Krasimir Avramski [mailto:kr...@smartcom.bg]
> Sent: Friday, April 15, 2016 6:51 AM
> To: Aaron 
> Cc: Chris Jones ; Juniper-Nsp <
> juniper-nsp@puck.nether.net>
> Subject: Re: [j-nsp] protect ssh and telnet
>
>
>
> Hi Aaron,
>
>
>
> Below is commit script which is building dynamic prefix list (containing
> local IPv4 addresses) you could reference in FTF:
>
>
>
> krasi# show system scripts commit
>
> allow-transients;
>
> file ifl-addr-v4.slax;
>
>
>
>
>
>
>
>
>
> krasi# run file show /var/db/scripts/commit/ifl-addr-v4.slax
>
> version 1.0;
>
>
>
> ns junos = "http://xml.juniper.net/junos/*/junos";;
>
> ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";;
>
> ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";;
>
>
>
> import "../import/junos.xsl";
>
>
>
> match configuration {
>
>  {
>
>  {
>
>  {
>
>  "ifl-addr-v4";
>
>   for-each (interfaces/interface/unit/family/inet/address)
> {
>
> var $address = substring-before(name, "/");
>
>  {
>
>$address;
>
>}
>
>   }
>
>  }
>
>  }
>
>  }
>
> }
>
>
>
>
>
>
>
> krasi# show policy-options |display inheritance |display commit-scripts
>
> prefix-list ifl-addr-v4 {
>
> 1.1.1.1/32 <http://1.1.1.1/32> ;
>
> 10.10.111.1/32 <http://10.10.111.1/32> ;
>
> }
>
>
>
>
>
> krasi# set interfaces xe-0/0/0 unit 0 family inet address 2.2.2.2/30 <
> http://2.2.2.2/30>
>
>
>
> [edit]
>
> root# commit
>
> commit complete
>
>
>
> [edit]
>
> root# show policy-options |display inheritance |display commit-scripts
>
> prefix-list ifl-addr-v4 {
>
> 1.1.1.1/32 <http://1.1.1.1/32> ;
>
> 2.2.2.2/32 <http://2.2.2.2/32> ;
>
> 10.10.111.1/32 <http://10.10.111.1/32> ;
>
>  }
>
>
>
>
>
> Best Regards,
>
> Krasi
>
>
>
> On 13 April 2016 at 23:43, Aaron mailto:aar...@gvtc.com>
> > wrote:
>
> Thanks Chris, but apparently the Juniper ACX5048 is an exception to the
> lo0 rule…  see link
>
>
>
> http://kb.juniper.net/InfoCenter/index?page=content <
> http://kb.juniper.net/InfoCenter/index?page=content <
> http://kb.juniper.net/InfoCenter/index?page=content&id=KB28893&actp=search&viewlocale=en_US&searchid=1305252358192>
> &id=KB28893&actp=search&viewlocale=en_US&searchid=1305252358192>
> &id=KB28893&actp=search&viewlocale=en_US&searchid=1305252358192
>
>
>
> I’ve been able to accomplish protecting telnet/ssh on my ACX5048 like this…
>
>
>
> set routing-instances one forwarding-options family inet filter input
> protect-5048
>
> set firewall family inet filter protect-5048 term 1 from
> destination-address 1.1.1.1/32 <http://1.1.1.1/32>
>
> set firewall family inet filter protect-5048 term 1 from protocol tcp
>
> set firewall family inet filter protect-5048 term 1 from destination-port
> telnet
>
> set firewall family inet filter protect-5048 term 1 from destination-port
> ssh
>
> set firewall family inet filter protect-5048 term 1 then count
> protect-5048-counter
>
> set firewall family inet filter protect-5048 term 1 then discard
>
> set firewall family inet filter protect-5048 term 2 then accept
>
>
>
> 1.1.1.0/24 <http://1.1.1.0/24>  is a subnet on an interface in vrf “one”
> on my acx5048…
>
>
>
> The only thing is that I will need to make it a policy with my colleagues
> that if/when we churn public address space or add new interfaces on our
> acx5048’s, part of the process will be to add a line to our firewall acl…
>
>
>
> set f

Re: [j-nsp] protect ssh and telnet

[Aaron]

Thanks Krasi, Hmmm, this looks very interesting, I want to try it in my lab… 
also, please let me know if this will ONLY work for my routing-instance vrf 
“one” interfaces… 

 

My vrf “one” is where my public/vulnerable ip’s live…

 

I don’t need to protect my default core vrf which is all 10.x.x.x and that 
domain is behing a mgmt. net firewall boundary

 

Aaron

 

From: Krasimir Avramski [mailto:kr...@smartcom.bg] 
Sent: Friday, April 15, 2016 6:51 AM
To: Aaron 
Cc: Chris Jones ; Juniper-Nsp 

Subject: Re: [j-nsp] protect ssh and telnet

 

Hi Aaron,

 

Below is commit script which is building dynamic prefix list (containing local 
IPv4 addresses) you could reference in FTF:

 

krasi# show system scripts commit

allow-transients;

file ifl-addr-v4.slax;

 

 

 

 

krasi# run file show /var/db/scripts/commit/ifl-addr-v4.slax

version 1.0;

 

ns junos = "http://xml.juniper.net/junos/*/junos";;

ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";;

ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";;

 

import "../import/junos.xsl";

 

match configuration {

 {

 {

 {

 "ifl-addr-v4";

  for-each (interfaces/interface/unit/family/inet/address) {

var $address = substring-before(name, "/");

 {

   $address;

   }

  }

 }

 }

 }

}

 

 

 

krasi# show policy-options |display inheritance |display commit-scripts

prefix-list ifl-addr-v4 {

1.1.1.1/32 <http://1.1.1.1/32> ;

10.10.111.1/32 <http://10.10.111.1/32> ;

}

 

 

krasi# set interfaces xe-0/0/0 unit 0 family inet address 2.2.2.2/30 
<http://2.2.2.2/30> 

 

[edit]

root# commit

commit complete

 

[edit]

root# show policy-options |display inheritance |display commit-scripts

prefix-list ifl-addr-v4 {

1.1.1.1/32 <http://1.1.1.1/32> ;

2.2.2.2/32 <http://2.2.2.2/32> ;

10.10.111.1/32 <http://10.10.111.1/32> ;

 }

 

 

Best Regards,

Krasi

 

On 13 April 2016 at 23:43, Aaron mailto:aar...@gvtc.com> > 
wrote:

Thanks Chris, but apparently the Juniper ACX5048 is an exception to the lo0 
rule…  see link



http://kb.juniper.net/InfoCenter/index?page=content 
<http://kb.juniper.net/InfoCenter/index?page=content 
<http://kb.juniper.net/InfoCenter/index?page=content&id=KB28893&actp=search&viewlocale=en_US&searchid=1305252358192>
 &id=KB28893&actp=search&viewlocale=en_US&searchid=1305252358192> 
&id=KB28893&actp=search&viewlocale=en_US&searchid=1305252358192



I’ve been able to accomplish protecting telnet/ssh on my ACX5048 like this…



set routing-instances one forwarding-options family inet filter input 
protect-5048

set firewall family inet filter protect-5048 term 1 from destination-address 
1.1.1.1/32 <http://1.1.1.1/32> 

set firewall family inet filter protect-5048 term 1 from protocol tcp

set firewall family inet filter protect-5048 term 1 from destination-port telnet

set firewall family inet filter protect-5048 term 1 from destination-port ssh

set firewall family inet filter protect-5048 term 1 then count 
protect-5048-counter

set firewall family inet filter protect-5048 term 1 then discard

set firewall family inet filter protect-5048 term 2 then accept



1.1.1.0/24 <http://1.1.1.0/24>  is a subnet on an interface in vrf “one” on my 
acx5048…



The only thing is that I will need to make it a policy with my colleagues that 
if/when we churn public address space or add new interfaces on our acx5048’s, 
part of the process will be to add a line to our firewall acl…



set firewall family inet filter protect-5048 term 1 from destination-address 
1.1.2.1/32 <http://1.1.2.1/32> 

set firewall family inet filter protect-5048 term 1 from destination-address 
1.1.3.1/32 <http://1.1.3.1/32> 

etc



QUESTION – does anyone know how to make this firewall acl or include a 
confition or policy somehow to apply the firewall policy to ONLY LOCAL ROUTES 
(/32’s) ?  that would be nice , so that I would never have to add/subtract 
specific ip addresses in this firewall policy.



Aaron







From: Chris Jones [mailto:ipv6fre...@gmail.com <mailto:ipv6fre...@gmail.com> ]
Sent: Wednesday, April 13, 2016 10:05 AM
To: Aaron mailto:aar...@gvtc.com> >
Cc: juniper-nsp@puck.nether.net <mailto:juniper-nsp@puck.nether.net> 
Subject: Re: [j-nsp] protect ssh and telnet



To answer OPs actual question:



What you're looking for is an RE filter, applied to lo0. A great resource 
explaining them and some best practices, etc. check out Doug Hank's Day One 
book: 
http://www.juniper.net/us/en/training/jnbooks/day-one/fundamentals-series/securing-routing-engine/



On Tue, Mar 29, 2016 at 10:26 PM, Aaron mailto:aar...

Re: [j-nsp] protect ssh and telnet

[Krasimir Avramski]

Hi Aaron,

Below is commit script which is building dynamic prefix list (containing
local IPv4 addresses) you could reference in FTF:

krasi# show system scripts commit
allow-transients;
file ifl-addr-v4.slax;




krasi# run file show /var/db/scripts/commit/ifl-addr-v4.slax
version 1.0;

ns junos = "http://xml.juniper.net/junos/*/junos";;
ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";;
ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";;

import "../import/junos.xsl";

match configuration {
 {
 {
 {
 "ifl-addr-v4";
  for-each (interfaces/interface/unit/family/inet/address) {
var $address = substring-before(name, "/");
 {
   $address;
   }
  }
 }
 }
 }
}



krasi# show policy-options |display inheritance |display commit-scripts
prefix-list ifl-addr-v4 {
1.1.1.1/32;
10.10.111.1/32;
}


krasi# set interfaces xe-0/0/0 unit 0 family inet address 2.2.2.2/30

[edit]
root# commit
commit complete

[edit]
root# show policy-options |display inheritance |display commit-scripts
prefix-list ifl-addr-v4 {
1.1.1.1/32;
2.2.2.2/32;
10.10.111.1/32;
 }


Best Regards,
Krasi

On 13 April 2016 at 23:43, Aaron  wrote:

> Thanks Chris, but apparently the Juniper ACX5048 is an exception to the
> lo0 rule…  see link
>
>
>
> http://kb.juniper.net/InfoCenter/index?page=content <
> http://kb.juniper.net/InfoCenter/index?page=content&id=KB28893&actp=search&viewlocale=en_US&searchid=1305252358192>
> &id=KB28893&actp=search&viewlocale=en_US&searchid=1305252358192
>
>
>
> I’ve been able to accomplish protecting telnet/ssh on my ACX5048 like this…
>
>
>
> set routing-instances one forwarding-options family inet filter input
> protect-5048
>
> set firewall family inet filter protect-5048 term 1 from
> destination-address 1.1.1.1/32
>
> set firewall family inet filter protect-5048 term 1 from protocol tcp
>
> set firewall family inet filter protect-5048 term 1 from destination-port
> telnet
>
> set firewall family inet filter protect-5048 term 1 from destination-port
> ssh
>
> set firewall family inet filter protect-5048 term 1 then count
> protect-5048-counter
>
> set firewall family inet filter protect-5048 term 1 then discard
>
> set firewall family inet filter protect-5048 term 2 then accept
>
>
>
> 1.1.1.0/24 is a subnet on an interface in vrf “one” on my acx5048…
>
>
>
> The only thing is that I will need to make it a policy with my colleagues
> that if/when we churn public address space or add new interfaces on our
> acx5048’s, part of the process will be to add a line to our firewall acl…
>
>
>
> set firewall family inet filter protect-5048 term 1 from
> destination-address 1.1.2.1/32
>
> set firewall family inet filter protect-5048 term 1 from
> destination-address 1.1.3.1/32
>
> etc
>
>
>
> QUESTION – does anyone know how to make this firewall acl or include a
> confition or policy somehow to apply the firewall policy to ONLY LOCAL
> ROUTES (/32’s) ?  that would be nice , so that I would never have to
> add/subtract specific ip addresses in this firewall policy.
>
>
>
> Aaron
>
>
>
>
>
>
>
> From: Chris Jones [mailto:ipv6fre...@gmail.com]
> Sent: Wednesday, April 13, 2016 10:05 AM
> To: Aaron 
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] protect ssh and telnet
>
>
>
> To answer OPs actual question:
>
>
>
> What you're looking for is an RE filter, applied to lo0. A great resource
> explaining them and some best practices, etc. check out Doug Hank's Day One
> book:
> http://www.juniper.net/us/en/training/jnbooks/day-one/fundamentals-series/securing-routing-engine/
>
>
>
> On Tue, Mar 29, 2016 at 10:26 PM, Aaron  aar...@gvtc.com> > wrote:
>
> I'm new to Juniper. and I'm looking to protect ssh/telnet on all interfaces
> on my juniper ACX5048's.
>
>
>
> In Cisco you can protect the virtual interface (vty) with a acl
> (access-class) so that any remote login attempts (ssh or telnet) or
> protected.
>
>
>
> How do I protect ssh and telnet globally in Junos ?  I only want to allow
> ssh and telnet from certain trusted management subnets.
>
>
>
> Aaron
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net  juniper-nsp@puck.nether.net>
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>
>
>
>
>
> --
>
> Chris Jones
> JNCIE-ENT #272
> CCIE# 25655 (R&S)
>
> ___
> 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

[Aaron]

Thanks Chris, but apparently the Juniper ACX5048 is an exception to the lo0 
rule…  see link

 

http://kb.juniper.net/InfoCenter/index?page=content 
<http://kb.juniper.net/InfoCenter/index?page=content&id=KB28893&actp=search&viewlocale=en_US&searchid=1305252358192>
 &id=KB28893&actp=search&viewlocale=en_US&searchid=1305252358192

 

I’ve been able to accomplish protecting telnet/ssh on my ACX5048 like this…

 

set routing-instances one forwarding-options family inet filter input 
protect-5048

set firewall family inet filter protect-5048 term 1 from destination-address 
1.1.1.1/32

set firewall family inet filter protect-5048 term 1 from protocol tcp

set firewall family inet filter protect-5048 term 1 from destination-port telnet

set firewall family inet filter protect-5048 term 1 from destination-port ssh

set firewall family inet filter protect-5048 term 1 then count 
protect-5048-counter

set firewall family inet filter protect-5048 term 1 then discard

set firewall family inet filter protect-5048 term 2 then accept

 

1.1.1.0/24 is a subnet on an interface in vrf “one” on my acx5048…

 

The only thing is that I will need to make it a policy with my colleagues that 
if/when we churn public address space or add new interfaces on our acx5048’s, 
part of the process will be to add a line to our firewall acl…

 

set firewall family inet filter protect-5048 term 1 from destination-address 
1.1.2.1/32

set firewall family inet filter protect-5048 term 1 from destination-address 
1.1.3.1/32

etc

 

QUESTION – does anyone know how to make this firewall acl or include a 
confition or policy somehow to apply the firewall policy to ONLY LOCAL ROUTES 
(/32’s) ?  that would be nice , so that I would never have to add/subtract 
specific ip addresses in this firewall policy.

 

Aaron

 

 

 

From: Chris Jones [mailto:ipv6fre...@gmail.com] 
Sent: Wednesday, April 13, 2016 10:05 AM
To: Aaron 
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] protect ssh and telnet

 

To answer OPs actual question:

 

What you're looking for is an RE filter, applied to lo0. A great resource 
explaining them and some best practices, etc. check out Doug Hank's Day One 
book: 
http://www.juniper.net/us/en/training/jnbooks/day-one/fundamentals-series/securing-routing-engine/

 

On Tue, Mar 29, 2016 at 10:26 PM, Aaron mailto:aar...@gvtc.com> > wrote:

I'm new to Juniper. and I'm looking to protect ssh/telnet on all interfaces
on my juniper ACX5048's.



In Cisco you can protect the virtual interface (vty) with a acl
(access-class) so that any remote login attempts (ssh or telnet) or
protected.



How do I protect ssh and telnet globally in Junos ?  I only want to allow
ssh and telnet from certain trusted management subnets.



Aaron

___
juniper-nsp mailing list juniper-nsp@puck.nether.net 
<mailto:juniper-nsp@puck.nether.net> 
https://puck.nether.net/mailman/listinfo/juniper-nsp





 

-- 

Chris Jones
JNCIE-ENT #272
CCIE# 25655 (R&S)

___
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]

 ❦  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

[Saku Ytti]

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

[Tom Storey]

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

[Saku Ytti]

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

[Tore Anderson]

* 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

[Phil Shafer]

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

[Saku Ytti]

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

[Patrick Okui]

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] protect ssh and telnet

[Saku Ytti]

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

[Saku Ytti]

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

[Richard Hartmann]

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

[Saku Ytti]

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

[Richard Hartmann]

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

[Saku Ytti]

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

[Patrick Okui]

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

Re: [j-nsp] protect ssh and telnet

[Vincent Bernat]

 ❦  4 avril 2016 22:23 -0400, Phil Shafer  :

> 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.

On which attribute can SSH keys be served?
-- 
Choose variable names that won't be confused.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] protect ssh and telnet

[Tim Jackson]

Sadly, you guys messed up ACX5k lo0 filtering.. Even though it's a
QFX5100/EX4600 inside..

--
Tim

On Mon, Apr 4, 2016 at 9:23 PM, 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.
>
> The "lo0" filter covers traffic to the routing engine.  Any filter
> applied to lo0 will block/allow only that traffic.
>
> More generally, take a look at the "secure junos template" from
> Team Cymru:
>
> http://www.team-cymru.org/templates.html
>
> Thanks,
>  Phil
> ___
> 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

[Phil Shafer]

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.

The "lo0" filter covers traffic to the routing engine.  Any filter
applied to lo0 will block/allow only that traffic.

More generally, take a look at the "secure junos template" from
Team Cymru:

http://www.team-cymru.org/templates.html

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] protect ssh and telnet

[Aaron]

I'm new to Juniper. and I'm looking to protect ssh/telnet on all interfaces
on my juniper ACX5048's.

 

In Cisco you can protect the virtual interface (vty) with a acl
(access-class) so that any remote login attempts (ssh or telnet) or
protected.

 

How do I protect ssh and telnet globally in Junos ?  I only want to allow
ssh and telnet from certain trusted management subnets.

 

Aaron

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp