Protect yourself against future threats.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
===========================================================================
AUSCERT External Security Bulletin Redistribution
ESB-2016.1033
Protect-RE(loopback) Firewall Filter does not discard OSPF
packets from non-permitted prefixes
28 April 2016
===========================================================================
AusCERT Security Bulletin Summary
---------------------------------
Product: Juniper EX4300
Juniper QFX3500
Juniper QFX5100
Publisher: Juniper Networks
Operating System: Juniper
Impact/Access: Reduced Security -- Remote/Unauthenticated
Resolution: Mitigation
Original Bulletin:
http://kb.juniper.net/InfoCenter/index?page=content&id=JSA10748
- --------------------------BEGIN INCLUDED TEXT--------------------
Protect-RE(loopback) Firewall Filter does not discard OSPF packets from
non-permitted prefixes
Categories:
Junos
Switch Products
Junos-EX
QFX3500
EX4300
QFX5100
SIRT Notices
EX4600
Security Advisories ID: JSA10748
Last Updated: 26 Apr 2016
Version: 1.0
Product Affected:
This issue affects the EX4300, EX4600, QFX3500, QFX5100 platforms running
14.1X53-D30.
Problem:
On EX4300, EX4600, QFX3500, QFX5100 platforms, a firewall filter applied on
the lo0 interface may not work as expected. OSPF adjacencies form irrespective
of the source-address. The adjacency should never form using the configuration
below. It should only form if the correct source-address is used in the
OSPF_NEIGHBORS term, in this case, the 192.168.1.x/24 subnet.
This same configuration works on the EX4200 as expected. The adjacency does
not form until the incorrect source-address is replaced with the correct one.
In below example, an incorrect source-address 172.16.1.x/32 subnet is used
intentionally in the OSPF_NEIGHBOR term. The term should not match and it
should go to the next term - DENY_ANY term, where the action is count and
discard. However, the adjacency forms regardless of the source-address in the
OSPF_NEIGHBOR term. It is not discarded or counted by DENY_ANY term as
indicated by the formation of a Full adjacency and DENIED_TRAFFFIC counter.
JTAC Lab setup Details
This limitation is reproduced in the JTAC lab using EX4300.
EX4300-1 - ge-0/0/15 ------------ ge-0/0/15 - EX4300-2
Configuration
{master:0} root@ospf-1> show configuration | display set set version 13.2X51-D37.1 set system host-name ospf-1
set system root-authentication encrypted-password "$1$QKgKM4mj$SjcxtW9i/ILQQYLK2IMzF1"
set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.1/24
set interfaces lo0 unit 0 family inet filter input OSPF_FILTER
set interfaces lo0 unit 0 family inet address 1.1.1.1/32
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR from source-address 172.16.1.2/32
set firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR from protocol ospf
set firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR then log
set firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR then accept
set firewall family inet filter OSPF_FILTER term DENY_ANY then count DENIED_TRAFFIC
set firewall family inet filter OSPF_FILTER term DENY_ANY then discard
{master:0}
root@ospf-2> show configuration | display set
set version 14.1X53-D30.3
set system host-name ospf-2
set system root-authentication encrypted-password "$1$m0KUv05.$jkU1qDmiRaEuW5zTQxNm80"
set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.2/24
set interfaces lo0 unit 0 family inet filter input OSPF_FILTER
set interfaces lo0 unit 0 family inet address 2.2.2.2/32
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR from source-address 172.16.1.1/32
set firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR from protocol ospf
set firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR then log
set firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR then accept
set firewall family inet filter OSPF_FILTER term DENY_ANY then count DENIED_TRAFFIC
set firewall family inet filter OSPF_FILTER term DENY_ANY then discard
Solution:
Root Cause
In a nutshell, EX4200 and EX4300 use different chipsets and hence there are
changes in the way these (multicast destination IP 224.0.0.X) packets are
handled. OSPF packets are making it to CPU due to implicit rule to allow IP
reserved Multicast packets which is placed before last discard term. This is
needed to allow all multicast transit packets to not get discarded. We are
basically running into chipset limitations. To handle limitations/behaviors,
our design expects user to add explicit discard term for the kind of packets
that are not needed to be trapped to CPU. The last discard term discards
regular L3 data packets (except destination IP=224.0.0.x packets) and control
packets which are L3 routed and not explicitly accepted by terms before.
We are basically dealing with below limitations:
Chipset on EX4300, EX4600, QFX3500, QFX5100 platforms sets destination
port as CPU port even for transit multicast packets
EX4300, EX4600, QFX3500, QFX5100 platforms chipset's action resolution
engine, Discard wins over any action and hence in the absence of implicit term
to allow reserved multicast packets, protocol packets would get discarded if
user does not configure explicit term for each and every packet which is not
scalable.
EX4300, EX4600, QFX3500, QFX5100 platforms chipset does not treat TTL
expired packets as routed packets and loopback filter being applied on family
inet, it is expected to act only on L3 routed packets
Solution
To overcome this limitation, it is required to configure explicit discard term
for unwanted OSPF packets as below to overcome specific chipset limitations.
root@ospf-2# show | compare
[edit firewall family inet filter OSPF_FILTER]
term OSPF_NEIGHBOR { ... }
+ term OSPF_tmp {
+ from {
+ source-address {
+ 192.168.1.1/32;
+ }
+ protocol ospf;
+ }
+ then {
+ count intersted_SA;
+ discard; <---------
+ }
+ }
term DENY_ANY { ... }
root@ospf-2> show ospf neighbor
(no output returned)
This is specific to the packets with multicast destination IP 224.0.0.X
address. Since OSPF hello uses 224.0.0.5 address, it requires explicit discard
for unwanted source IP addresses.
Any other terms which do not use this address should not be impacted. For
example, SSH and IPV6 traffic is not affected by this limitation.
Workaround:
See Solution section above.
Implementation:
Related Links:
CVSS Score:
5.3 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N)
Risk Level:
Medium
- --------------------------END INCLUDED TEXT--------------------
You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to auscert@auscert.org.au
and we will forward your request to the appropriate person.
NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members. As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.
NOTE: This is only the original release of the security bulletin. It may
not be updated when updates to the original are made. If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.
Contact information for the authors of the original document is included
in the Security Bulletin above. If you have any questions or need further
information, please contact them directly.
Previous advisories and external security bulletins can be retrieved from:
http://www.auscert.org.au/render.html?cid=1980
===========================================================================
Australian Computer Emergency Response Team
The University of Queensland
Brisbane
Qld 4072
Internet Email: auscert@auscert.org.au
Facsimile: (07) 3365 7031
Telephone: (07) 3365 4417 (International: +61 7 3365 4417)
AusCERT personnel answer during Queensland business hours
which are GMT+10:00 (AEST).
On call after hours for member emergencies only.
===========================================================================
-----BEGIN PGP SIGNATURE-----
Comment: http://www.auscert.org.au/render.html?it=1967
iQIVAwUBVyFswn6ZAP0PgtI9AQJkIBAAg5alYDExtDhHoIfGkbxwSuK0HaA6cFAt
slfkPJ2xcW1EL0WkRC+Bmhl/+PfsOKD0umSUBDDYKXdpUHeLShrDTVqLbaEXxPsK
pkTKj5knIbr6tkqLGuZAEO9LIGjFs/SFyZ4AXPzTxcGIMRwI45PWcsb//EQIAFAF
gjnnALqXH7SN5ObktYj/XeSgIfhjTXXMv3m9lSLO2lq9Wc5HP6ZPxlYeDEAfENfB
xJ2N2ZLp5BmU6lWcWo/lszfpwOVjM1R8qsZDJMNWuOehjDqtSi2ORuwbnszjkirY
KZYQRPSdgHvXtulDK5ISzWPdtlV1TKe8BRj1trjgC3wdWztVyyJds4/a6bZiL8eY
q6FNhW9aAd9wl4OLdbNOsaQQc9W9dmrOGGFCfVrcUYF9J2x1ygUaaqOs+5woQ4uy
u6VJW8BAzbeJNyPZJCbqe8aPPkwMjLWOI86wLmAvmRI3MhTPdAhA6vrxy+TlnAJL
JNyHzxfxCr/9ekKpNvQA7UhFLnPdZrOLNtOY90L3CI5tVe/M+IH1Cz723/qIBOrP
17Tw6Cu14E5Iq22knV1lOO5MZWRbS2GM+OpBc3mpScRv4FsNFsoQeSmqYd76zIVK
1E5FwN7ypjJKuYipTbnXjDNXZfkwd2we0ARKkTtpMmnpBvpfSlRnI5Ac2LMgV+Iv
cDWKp+1Jh/0=
=vKt3
-----END PGP SIGNATURE-----