Re: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?
Michael, got it, thanks. Lee, the README of your repository provides an excellent introduction to RE filtering. Based on your filters, I moved the processing of the IP Options from edge filters to RE filters: https://gist.github.com/tonusoo/efd9ab4fcf2bb5a45d34d5af5e3f3e0c#file-junos-re-filters-L574:L585 Martin ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?
Hi.
Thanks for the feedback and remarks. I have updated the RE filters:
https://gist.github.com/tonusoo/efd9ab4fcf2bb5a45d34d5af5e3f3e0c
Few comments:
* I used the ephemeral range of 49160 - 65535 based on "sysctl
net.inet.ip.portrange.first" and "sysctl net.inet.ip.portrange.last"
on FreeBSD shell
* the "router-v4" was carried over from inet6 filters as I wanted to
keep the v4 and v6 rules as identical as possible. It also helps to
filter malformed packets addressed
to multicast. For example TCP SYN packets addressed to dport 179 with
destination IP set to 224.0.0.6
Michael,
regarding the GTSM for BGP and related filters. Do you group the BGP
neighbors into different prefix lists based on the expected TTL?
Something like this:
root@vmx1> show configuration firewall family inet filter accept-bgp-v4
term accept-bgp-ttl-255-v4 {
from {
source-prefix-list {
/* adjacent BGP neighbors with TTL set to 255 */
bgp-neighbors-ttl-255-v4;
}
destination-prefix-list {
router-v4;
}
protocol tcp;
ttl 255;
destination-port bgp;
}
then {
count accept-bgp-ttl-255-v4;
accept;
}
}
term accept-bgp-v4 {
from {
source-prefix-list {
/* rest of the BGP neighbors */
bgp-neighbors-v4;
}
destination-prefix-list {
router-v4;
}
protocol tcp;
destination-port bgp;
}
then {
count accept-bgp-v4;
accept;
}
}
root@vmx1>
Martin
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?
Hi. > In practical life IOS-XR control-plane is better protected than JunOS, > as configuring JunOS securely is very involved, considering that MX > book gets it wrong, offering horrible lo0 filter as does Cymru, what > chance the rest of us have? I recently worked on a RE protection filter based on the examples given in the "Juniper MX Series" book: https://gist.github.com/tonusoo/efd9ab4fcf2bb5a45d34d5af5e3f3e0c It's a tight filter for a simple network, e.g MPLS is not in use and thus there are no filters for signaling protocols or MPLS LSP ping/traceroute, routing instances are not in use, authentication for VRRPv3 or OSPF is not in use, etc. Few differences compared to filters in the MX book: * "ttl-except 1" in "accept-icmp" filter was avoided by simply moving the traceroute related filters in front of "accept-icmp" filter * "discard-extension-headers" filter in the book discards certain Next Header values and allows the rest. I changed it in a way that only specified Next Header values are accepted and rest are discarded. Idea is to discard unneeded extension headers as early as possible. * in term "neighbor-discovery-accept" in filter "accept-icmp6-misc" only the packets with Hop Limit value of 255 should be accepted * the "accept-bgp-v6" filter or any other IPv6 related RE filter in the book does not allow the router to initiate BGP sessions with other routers. I added a term named "accept-established-bgp-v6" in filter "accept-established-v6" which addresses this issue. * for the sake of readability and simplicity, I used names instead of numbers if possible. For example "icmp-type router-solicit" instead of "icmp-type 133". * in all occurrences, if it was not possible to match on the source IP address, then I strictly policed the traffic * traffic from management networks is not sharing policers with traffic from untrusted networks The overall structure of the RE filters in "Juniper MX Series" book is in my opinion very good. List of small filters which accept specific traffic and finally discard all the rest. Reason for having separate v4 and v6 prefix-lists is a Junos property to ignore the prefix-list altogether if it's used in a family inet filter while the prefix-list contains only the inet6 networks. Same is true if the prefix-list is used in family inet6 filter and the prefix-list contains only inet networks. For example, if only IPv4 name servers addresses are defined under [edit system name-server] and prefix-list with apply-path "system name-server <*>" is used as a source prefix-list in some family inet6 filter, then actually no source address related restrictions apply. This can be checked with "show filter index program" on a PFE CLI. Martin ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP OIDs for Yellow/Red Alarm on MX204
Hi.
As a workaround,
https://gist.github.com/tonusoo/2f95c1d377bf658dcf5c8b7c9dba5f57 could
be used. Few examples:
$ snmpwalk -v 2c -c public mx204 .1.3.6.1.4.1.2636.3.4
JUNIPER-ALARM-MIB::jnxYellowAlarmState.0 = INTEGER: off(2)
JUNIPER-ALARM-MIB::jnxYellowAlarmCount.0 = Gauge32: 0
JUNIPER-ALARM-MIB::jnxRedAlarmState.0 = INTEGER: off(2)
JUNIPER-ALARM-MIB::jnxRedAlarmCount.0 = Gauge32: 0
$
$ snmpwalk -v 2c -c public mx204 jnxYellowAlarmCount.0
JUNIPER-ALARM-MIB::jnxYellowAlarmCount.0 = Gauge32: 0
$
$ snmpwalk -v 2c -c public mx204 jnxYellowAlarmCount
JUNIPER-ALARM-MIB::jnxYellowAlarmCount.0 = Gauge32: 0
$
$ snmpget -v 2c -c public mx204 jnxRedAlarmState.0
JUNIPER-ALARM-MIB::jnxRedAlarmState.0 = INTEGER: off(2)
$
Installation:
root@mx204> file list /var/db/scripts/snmp/
/var/db/scripts/snmp/:
mx204_yellow_and_red_alarm.slax
root@mx204> show configuration system scripts snmp | display
inheritance no-comments
/* jnxYellowAlarmState, jnxYellowAlarmCount, jnxRedAlarmState and
jnxRedAlarmCount support */
file mx204_yellow_and_red_alarm.slax {
oid .1.3.6.1.4.1.2636.3.4.2.2.1;
oid .1.3.6.1.4.1.2636.3.4.2.2.2;
oid .1.3.6.1.4.1.2636.3.4.2.3.1;
oid .1.3.6.1.4.1.2636.3.4.2.3.2;
checksum sha-256
bbe81079f38d18c85cf6d8799a7fa459ce3418c5582f746cf743b00a73e0ab91;
}
root@mx204>
The script looks for "Major" or "Minor" alarms in the output of RPCs
for both the "show system alarms" and "show chassis alarms". This
means that alarms listed in both outputs are counted twice for
jnxRedAlarmCount and jnxYellowAlarmCount.
Based on my experience the chassis alarms are a subset of system
alarms, but I'm not sure. It seems to work in a way that certain alarm
types(seen in the XML output) like "ETHER" or "Chassis" are seen in
the output of "show chassis alarms" while all the alarm types are
listed in the output on "show system alarms". On the other hand, the
https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/command/show-chassis-alarms.html
states that:
"In Junos, the chassis alarms are different from the system alarms
(viewed by using the show system alarms command)."
Perhaps someone from Juniper could clarify this.
Martin
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RPD coring today?
> > What does this show: > > > > show system core-dump core-file-info /path/to/corefile > > gdb was removed from junos somewhere around 16. This unfortunately > doesn't work anymore. It was quite handy. While it's obviously not that convenient, then one can prepare a VM with necessary shared libraries from Junos and use gdb there. For example, here is the backtrace of the rpd core dump from Junos 17.3R3-S11.4 opened in gdb 11.2 for FreeBSD: (gdb) bt #0 0xc9c24b7a in __sys_thr_kill () from /root/libs/lib/libc.so.7 #1 0xc9c24a64 in raise () from /root/libs/lib/libc.so.7 #2 0xc9c23690 in abort () from /root/libs/lib/libc.so.7 #3 0xc9c06815 in __assert () from /root/libs/lib/libc.so.7 #4 0x0166549f in tag_unlock_tag_label_elm () #5 0x01661592 in tag_gw_unlock_tag_label_elm () #6 0x0153024a in rt_nexthops_free () #7 0x01544b1a in rt_change_parms () #8 0x0155243f in rt_change_ribgroup_import () #9 0x00a3d01f in bgp_ribgroup_change_rt () #10 0x00a051fe in bgp_sync_cb () #11 0x015593bf in rt_nh_change_cb () #12 0x015537f9 in rt_nh_change_immediate_cb () #13 0x01555cc9 in rt_nh_resolve_change () #14 0x00a041e8 in bgp_rt_cnh_resolve_change () #15 0x00a0581f in bgp_sync_rt_change () #16 0x00a56401 in bgp_rt_change () #17 0x00a58c45 in bgp_rcv_nlri () #18 0x00a5a8da in bgp_read_v4_update () #19 0x009df4ec in bgp_handle_update () #20 0x00a1d6c1 in bgp_read_resp_process_internal () #21 0x00a1db18 in bgp_read_resp_process () #22 0x016f001c in task_job_run_common () #23 0x016f1480 in task_job_bg_dispatch () #24 0x01708625 in task_scheduler_internal () #25 0x01709261 in task_scheduler () #26 0x007223ff in main () (gdb) As seen above, the shared object libraries from Junos were placed under the /root/libs. Gdbinit was configured with "set sysroot /root/libs". With the stack frame number and the function name it's possible to dig even deeper using disassemblers like radare2. Perhaps it's useful for somebody in the future. Martin ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
