Network Security Memorandum

Monday, February 2, 2015

CVE-2015-0235: GHOST - A Critical Vulnerability in the Glibc Library

GHOST is a 'buffer overflow' bug affecting the gethostbyname() and gethostbyname2() function calls in the glibc library. If a remote attacker can make an application call to gethostbyname() or gethostbyname2(), this vulnerability allows the remote attacker to execute arbitrary code with the permissions of the user running the application.

GHOST was originally published by Red Hat as CVE-2015-0235: https://access.redhat.com/articles/1332213

1. Check Point Response to CVE-2015-0235 (glibc - GHOST)

Solution ID: sk104443
Severity: Low

IPS Protection:

Check Point released "GNU C Library gethostbyname Buffer Overflow" IPS protection that protects customer environments.
This protection is part of the Recommended_Protection profile. It enables organizations to add a layer of protection to their network while updating their systems with vendor-provided patches.

OS Level Protection:

IPSO OS is not vulnerable.
While Check Point Gaia and SecurePlatform operating systems may be susceptible to CVE-2015-0235, there are no known exploits to Check Point software.

Hotfix Packages

Hotfix packages are available for R77.20, R77.10, R77, R76, and R75.47

	R77.20	R77.10	R77	R76	R75.47
Gaia
SecurePlatform

2. Juniper: 2015-01 Out of Cycle Security Bulletin: GHOST glibc gethostbyname() buffer overflow vulnerability (CVE-2015-0235)

Vulnerable Products

Junos Space
CTPView
CTP
IDP-SA
SRC
NSM Appliance
JSA and STRM Series

SOLUTION:

Junos Space: PR 1060102 has been logged to resolve this issue.
IDP-SA: PR 1060071 has been logged to resolve this issue in IDP-OS.
CTPView: PR 1060060 has been logged to resolve this issue in CTPView.
CTP: PR 1060352 has been logged to resolve this issue in CTP-OS.
SRC: PR 1060350 has been logged to resolve this issue.
NSM Appliance: PR 1059948 has been logged to resolve this issue.
QFabric Director: gethostbyname() functions are used internally, but DNS name resolution is not supplied as a service on external ports.
Firefly Host/vGW: The C/C++ based daemon running on the vGW/FFH Security VM agent is not exploitable. Also, the vGW/FFH management system (SD VM) is Java based (Apache Java application server) is not applicable.
JSA and STRM: A fix is pending release.
IDP Anomaly: The IDP anomaly SMTP:OVERFLOW:COMMAND-LINE should cover the known SMTP variant of this vulnerability. For easy attack lookup, the Signatures team has linked CVE-2015-0235 as a reference to this anomaly and also made it part of the recommended policy. All these changes will be reflected in the next signature pack which is scheduled to release on 29-Jan-2015 at 12:00 PST.

WORKAROUND: General Mitigation:

The affected gethostbyname() functions are primarily called in response to references to DNS host names and addresses from the CLI or via services listening on the device. Apply and maintain good security best current practices (BCPs) to limit the exploitable attack surface of critical infrastructure networking equipment. Use access lists or firewall filters to limit access to networking equipment only from trusted, administrative networks or hosts. This reduces the risk of remote malicious exploitation of the GHOST vulnerability.

3. Cisco : GNU glibc gethostbyname Function Buffer Overflow Vulnerability

Advisory ID: cisco-sa-20150128-ghost:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20150128-ghost

Workarounds:

There are currently no network-based mitigations for this vulnerability or any mitigations that can be performed directly on affected systems.

Tuesday, January 20, 2015

Build NTP Windows Server for Network Devices (not Win32Time)

Based on Cisco Document (ID108076) Troubelshoot Network Time Protocol (NTP), Cisco devices are not able to Sync NTP to W32 Based Time Service.

"Windows W32Time shows that it is an SNTP implementation inside (rather claiming itself NTP). Cisco IOS-NTP, which tries to sync with W32Time, gets its own root-dispersion value that it sends to the W32Time and this proves costly for Cisco IOS-NTP to synchronize. Because the root-dispersion value of Cisco IOS-NTP goes higher than 1000 ms, it unsynchronizes itself (clock-select procedure). Since the Cisco IOS based routers run the full RFC implementation of NTP they do not sync to an SNTP server. In this case the output of the show ntp associations detail command shows that the server is flagged as insane, invalid. The root dispersion value is in excess of 1000 ms, which causes the Cisco IOS NTP implementation to reject the association. Routers that run Cisco IOS can be unable to synchronize to an NTP server if it is a Windows system that runs the W32Time service. If the server is not synchronized, the routers are not able to transmit to and receive packets from the server."

Afroz Ahmad has a post in his blog show How to Setup Windows as NTP Server for Cisco Devices. Basically what you need is a 3rd party NTP software from Meinberg which helps us out.

Download from this link. (http://www.meinbergglobal.com/download/ntp/windows/ntp-4.2.6p5@spider-man-win32-setup.exe)

Installation procedure is quite straightforward.

Problem:

Unfortunately, I got some small problems while trying to create a new account to start this service:

Solution:

What I did is to use a existing account within administrators group to replace NTP service account configured in the Network Time Protocol Daemon.

Another thing I want to mention is how to enable a time server to synchronize in the configuration file (C:\Program Files\NTP\etc\ntp.conf) after the installation, which is basically to remove the # sign from server 127.127.1.0, and add one internal server from your environment, just like shows in the following configuration.

# NTP Network Time Protocol
# **** ATTENTION ****: *You have to restart the NTP service when you change this file to activate the changes*
# PLEASE CHECK THIS FILE CAREFULLY AND MODIFY IT IF REQUIRED
# Configuration File created by Windows Binary Distribution Installer Rev.: 1.28 mbg
# please check http://www.ntp.org for additional documentation and background information

# The following restrict statements prevent that someone can abuse NTP as a traffic amplification tool by
# ignoring mode 6 and mode 7 packets. Especially the monlist feature has a big potential to be abused for this.
# See http://news.meinberg.de/244 for further information.
restrict default nomodify notrap nopeer noquery
# But allow local tools like ntpq full access:
restrict 127.0.0.1
# if you are not using IPv6 on this machine, please comment out the following line:
restrict -6 ::1

# Use drift file
driftfile "C:\Program Files\NTP\etc\ntp.drift"

# your local system clock, should be used as a backup
# (this is only useful if you need to distribute time no matter how good or bad it is)
server 127.127.1.0
# but it operates at a high stratum level to let the clients know and force them to
# use any other timesource they may have.
fudge 127.127.1.0 stratum 12

# Use a NTP server from the ntp pool project (see http://www.pool.ntp.org)
# Please note that you need at least four different servers to be at least protected against
# one falseticker. If you only rely on internet time, it is highly recommended to add
# additional servers here.
# The 'iburst' keyword speeds up initial synchronization, please check the documentation for more details!
server 0.north-america.pool.ntp.org iburst
server 1.north-america.pool.ntp.org iburst
server 2.north-america.pool.ntp.org iburst
server 0.us.pool.ntp.org iburst
server 2.us.pool.ntp.org iburst

# Use specific NTP servers
server 192.168.2.6 iburst

# End of generated ntp.conf --- Please edit this to suite your needs

Reference:

http://www.satsignal.eu/ntp/setup.html

Monday, January 19, 2015

Configuration DHCP Relay in routing instance on Juniper SRX Devices

I was having DHCP Relay configured on SRX 240H Cluster devices, it was quite straightforward experience, and Juniper KB 15755 covered all points when I first configured it. It was working fine at JUNOS version from 11.x to 12.1x44-D40.2 in cluster environment and related interfaces are in different Routing instance.

Basic topology looks like as below: DHCP Server 10.9.1.50 is in routing instance v_i on Reth2.0 interface. Three DHCP Client networks are in different routing instances, v_t and v_Def.

Global DHCP Relay configuration looks like following:

forwarding-options {
helpers {
traceoptions {
file helplog;
level all;
flag bootp;
}
bootp {
relay-agent-option;
description DHCP-Relay-to-DHCP-server-10.9.1.50;
server 10.9.1.50 routing-instance vr_i;
maximum-hop-count 10;
minimum-wait-time 300;
client-response-ttl 20;
interface {
reth2.0;
reth10.90;
reth10.94;
reth7.24;
}
}
}
}

Although based on KB25925, DHCP is not supported on J and SRX series devices in the chassis cluster before Junos 12.1X46. The above configuration did work on my cluster environment before. Also no firewall rules are needed to allow traffic between different zones and DHCP server 10.9.1.50, which was required in KB15755.

The problem comes up when I upgraded SRX240H to SRX1400 platform. DHCP Relay completely not working.

KB 28642[SRX] Example: Configuring DHCP relay server on SRX where relay agent interface and DHCP server interfaces are in different routing-instances explained why and KB28641 [SRX] Configuring the JDHCP relay agent in Custom Routing instance provides additional set up for this feature on server side.

All steps are listed as below:

1. Forwarding Option Configuration on all related DHCP Client Routing Instance

In my environment, there are three Reth interfaces used for DHCP Clients , which is reth7.24, reth10.90 and reth10.94. Reth 7.24 is in routing instance vr_t. Both reht10.90 and reth10.94 are in routing intstance vr_def.

vr_t {
instance-type virtual-router;
interface reth7.24;
routing-options {
instance-import from_all_to_vr_t;
}
forwarding-options {
dhcp-relay {
server-group {
DHCPSVR {
10.9.1.50;
}
}
active-server-group DHCPSVR;
group relay-in-vr {
interface reth7.24;
}
}
}
}
vr_def {
instance-type virtual-router;
interface reth10.90;
interface reth10.94;
routing-options {
instance-import from_all_to_vr_def;
}
forwarding-options {
dhcp-relay {
server-group {
DHCPSVR {
10.9.1.50;
}
}
active-server-group DHCPSVR;
group relay-in-vr {
interface reth10.90;
interface reth10.94;
}
}
}
}

2. Forward option configuration at DHCP Server Routing Instance

DHCP server 10.9.1.50 is in routing instance vr_i.

vr_i{
instance-type virtual-router;
interface reth2.0;
routing-options {
instance-import [ from_all_to_vr_i ];
}
forwarding-options {
dhcp-relay {
server-group {
dummy-config;
}
}
}
}

3. Make sure each client routing instance (vr_t and vr_def) has routes to vr_i.

Also vr_i routing instance has routes to vr_t and vr_def. That is above instance-import configuration used for in above configuration.

Policy-statement configuration is under the policy-options:

policy-statement from_all_to_vr_t {
term term5 {
from instance vr_i;
then accept;
}
}
policy-statement from_all_to_vr_def {
term term5 {
from instance vr_i;
then accept;
}
}
policy-statement from_all_to_vr_i {
term term4 {
from instance vr_t;
then accept;
}
term term5 {
from instance vr_def;
then accept;
}
}

4. No firewall policy will be needed. But both services bootp and dhcp have to be allowed on all DHCP client interface's host-inbound-traffic. Bootp will be needed on server side.

interfaces {
reth2.0 {
host-inbound-traffic {
system-services {
bootp;
}
}
}
}
interfaces {
reth10.90 {
host-inbound-traffic {
system-services {
bootp;
dhcp;
}
}
}
}
interfaces {
reth10.94{
host-inbound-traffic {
system-services {
bootp;
dhcp;
}
}
}
}
interfaces {
reth7.24 {
host-inbound-traffic {
system-services {
bootp;
dhcp;
}
}
}
}

Reference:

Friday, January 16, 2015

Using PKI Build Route-Based IPSec VPN between Juniper SRX

There was a task to change IPSec authentication method from Pre-share key to PKI Certification based. It used on SRX240H and SRX1400 firewalls. This post records the steps and troubleshooting the errors I met during the configuration.

1. On both firewalls generate Public/Private key pair:

{primary:node0}root@fw-1> request security pki generate-key-pair certificate-id PRO size 2048

node0:

--------------------------------------------------------------------------
Generated key pair PRO, key size 2048 bits

2. Generating cert request from the key pair

{primary:node0}root@fw-1> request security pki generate-certificate-request certificate-id PRO subject "CN=Admin,CN=m.test.com,OU=IT,O=test,L=M,ST=ON,C=CA" email admin@test.com filename ms-cert-req

node0:

--------------------------------------------------------------------------Generated certificate request

----- BEGIN CERTIFICATE REQUEST-----MIIC7TCCAdUCAQAwdjERMA8GA1UEAxMISm9obiBZYWxGjAYBgNVBAMTEW1hcmtYW0uZ2ktZGUuY29tMQswCQYDVQQLEwJJVDEMMAoGA1UEChMDRyZEwDgYDVQQEwdNYXJraGFtMQswCQYDVQQIEwJPTjELMAkGA1UEBhMC0EwggEiMA0GCSqGSIbDQEBAQUAA4IBDwAwggEKAoIBAQDEoahBD7RjFBZacquplzFudJ3k+jf1EBcCxxkdDWJVeZEDzFMN6kQbMPKFBvSHhSZU/o+AnkqOzQgTh9Uy/ttdc3r23ZWFu1t/9B79kvoRdxCt43iYHNtTyKk4xN1/Nd2XJ1qV6iXB0OAYAQWnKYsNAz5rY9SRnH5/VU90WRvu5s/wXu+9GEoysI1sjm91Qq1FM5HDtH9ROxDzbtEb8hJ2SmfY/VPctlSI/Ql3ZRyxCexOG2Q93hvhMRKbCNLxj1muSHbnveQI3gM+4nT9PmslUEB3dx5389LH5viCio01039LEWjfydd4HsAdsgD5ZXtihn49BPZNfCIYyDAgMBAAGgMjAwBgkhkiG9w0BCQ4xIzAhMB8GA1UdEQQYMBaBFCJqb2huLnlhbkBnaS1kZS5jb20iMA0CSqGSIb3DQEBBQUAA4IBAQAoRv0I1C5kklU2sRDGB4XCVnnJ/T34+Yn4ekIcGHADuB5kKbr+qc1xTVyelX09EqmGtCrREYSv/meseuco0+jMw9b9EogCfE7eZAw2EWltzA+NTjwcOexvTFYWhjD3YWPXwM/F/rKnS9vtCaaNJB+rpzjyjbJNRSPvFkYgRUsy3xnIJ7K76Jp03r5rD27KW2kaCCD2wXkr6vK97Nf+dgyM8sLBLy1FdUfeO2H5JnhxbodUD6FFGz50s8rqy2a4aUOCD1zCgOiMw/mjq3caFbS+WB2sb+09Kia19y9y2fOzG++v2Kud5luXYKMPuf4qEGSb6k1npNd8qadQf+

-----END CERTIFICATE REQUEST-----

Fingerprint:c7:dd:83:11:d1:8a:54:6c:5c:1e:7e:cd:79:73:c0:71:b0:ba:a5:fc (sha1)f6:10:e3:1f:c0:07:3e:dc:5c:e5:8e:b5:51:2b:9a:1e (md5)

3. Submit Cert Request to the CA and Retrieve Certs

4. Copying the Local Cert, CA Cert to local firewall

You can either use ftp to transfer file to local devices or using vi to copy/paste cert into local folder just like it shows below:

root@fw-1% cd /var/tmp
root@fw-1% vi cert.cer
-----BEGIN CERTIFICATE-----
MIIFAjCCA+qgAwIBAgIQLW8DBB6T4el6zXWK6UDm2zANBgkqhkiG90BAQsFADB+
MQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAd
BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxLzAtBgNVBAMTJlN5bWFudGVj
IENsYXNzIDMgU2VjdXJlIFNlcnZlciBDQSAtIEc0MB4XDTE1MDEwOTAwMDAwMFoX
DTE4MDQwNTIzNTk1OVowgYwxCzAJBgNVBAYTAkNBMRAwDgYDVQQIDAdPbnRhcmlv
MRAwDgYDVQQHDAdNYXJraGFtMS8wLQYDVQQKDCZHaWVzZWNrZSAmIERldnJpZW50
IFN5c3RlbXMgQ2FuYWRhIEluYzELMAkGA1UECwwCSVQxGzAZBNVBAMMEm1vbnRy
ZWFsLmdpLWRlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ2W
x3bDZiXD7Fhh7smdgq7W3ib/UOixoM7NDxryWVaff0mq3oioXUxpClvwkadJ5Js7
3+QOJH0j/jJLwJ6mN/8Me64Caxy3fHkp43NNTz1aOEr2QwOLuY4Z6rvNUgBdqLWo
OpI8OAYTMlBWMT++aKK35PAtDKLxCyKz6iqeR3tbqsxDnfJO5YafyDf8AtRmNJPg
1ms1yV0lKZBtq4weAKHLeSe0+SYu5CIgKHDhUbZ9SjQHyaNpSSY0agtm7gwppcYU
BPtkSTFyyxAVxMQrZrOMPSF2ND1qgwtQkv4ypAx70oLSP2FjWYxXS8eZCaBXRWzp
+2Q0gEbcQ85NG9DZCuMCAwEAAaOCAWswggFnMB0GA1UdEQQWMBSCEm1vbnRyZWFs
LmdpLWRlLmNvbTAJBgNVHRMEAjAAMA4GA1UdDwEB/wQEAwIFoDArBgNVHR8EJDAi
MCCgHqAchhpodHRwOi8vc3Muc3ltY2IuY29tL3NzLmNybDBlBgNHSAEXjBcMFoG
CmCGSAGG+EUBBzYwTDAjBggrBgEFBQcCARYXaHR0cHM6Ly9kLnN5bWNiLmNvbS9j
cHMwJQYIKwYBBQUHAgIwGQwXaHR0cHM6Ly9kLnN5bWNiLmNvbS9ycGEwHQYDVR0l
BBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMB8GA1UdIwQYMaAFF9gz2GQVd+EQxSK
YCqy9Xr0QxjvMFcGCCsGAQUFBwEBBEswSTAfBggrBgEFBQcwAYYTaHR0cDovL3Nz
LnN5bWNkLmNvbTAmBggrBgEFBQcwAoYaaHR0cDovL3NzLnN5bWNiLmNvbS9zcy5j
cnQwDQYJKoZIhvcNAQELBQADggEBAGSmIK5nDbs0e1aryWxbrCp9vMC7dTiJYP9
7VlUZsP63WXTWmOs1CBcyxv1NiO2Ub+CgiynAjnBKzDjPM8EesaTLlHnFqjRD65d
jXwa5UnlQnuZLzdadThp2qmhQbTeGBmT/y4c3rSwHnXwjB0aMQzz7QrKEmNrv13o
2eYEMp2tvZVSemPWpABj265tu6RcD6If3oTxKJy10/pKA/YU3xRLL9XB3NvU5NUO
Ej7ubdQsBTTBeJIE8/C5coDLEZbxYpQVSnqDBrOXLG5R2pNi0hIebXFaVDG36gy
NCGfTTNr8Elo7RYMspaZZhyQRZzXefzCxJwqxu39MwTNRJAhTPA=
-----END CERTIFICATE-----

root@fw-1% vi root.cer
-----BEGIN CERTIFICATE-----
MIIFODCCBCCgAwIBAgIQUT+5dDhwtzRAQY0wkwaZ/zANBgkqhkiG9w0BAQsFADCB
yjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJp
U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW
ZXJpU2lnbiBDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzUwHhcNMTMxMDMxMDAwMDAwWhcNMjMxMDMwMjM1OTU5WjB+MQsw
CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNV
BAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxLzAtBgNVBAMTJlN5bWFudGVjIENs
YXNzIDMgU2VjdXJlIFNlcnZlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAstgFyhx0LbUXVjnFSlIJluhL2AzxaJ+aQihiw6UwU35VEYJb
A3oNL+F5BMm0lncZgQGUWfm893qZJ4Itt4PdWid/sgN6nFMl6UgfRk/InSn4vnlW
9vf92Tpo2otLgjNBEsPIPMzWlnqEIRoiBAMnF4scaGGTDw5RgDMdtLXO637QYqzu
s3sBdO9pNevK1T2p7peYyo2qRA4lmUoVlqTObQJUHypqJuIGOmNIrLRM0XWTUP8T
L9ba4cYY9Z/JJV3zADreJk20KQnNDz0jbxZKgRb78oMQw7jW2FUyPfG9D72MUpVK
Fpd6UiFjdS8W+cRmvvW1Cdj/JwDNRHxvSz+w9wIDAQABo4IBYzCCAV8wEgYDVR0T
AQH/BAgwBgEB/wIBADAwBgNVHR8EKTAnMCWgI6Ahhh9odHRwOi8vczEuc3ltY2Iu
Y29tL3BjYTMtZzUuY3JsMA4GA1UdDwEB/wQEAwIBBjAvBggrBgEFBQcBAQQjMCEw
HwYIKwYBBQUHMAGGE2h0dHA6Ly9zMi5zeW1jYi5jb20wawYDVR0gBGQwYjBgBgpg
hkgBhvhFAQc2MFIwJgYIKwYBBQUHAgEWGmh0dHA6Ly93d3cuc3ltYXV0aC5jb20v
Y3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vcnBhMCkG
A1UdEQQiMCCkHjAcMRowGAYDVQQDExFTeW1hbnRlY1BLSS0xLTUzNDAdBgNVHQ4E
FgQUX2DPYZBV34RDFIpgKrL1evRDGO8wHwYDVR0jBBgwFoAUf9Nlp8Ld7LvwMAnz
Qzn6Aq8zMTMwDQYJKoZIhvcNAQELBQADggEBAF6UVkndji1l9cE2UbYD49qecxny
H1mrWH5sJgUs+oHXXCMXIiw3k/eG7IXmsKP9H+IyqEVv4dn7ua/ScKAyQmW/hP4W
Ko8/xabWo5N9Q+l0IZE1KPRj6S7t9/Vcf0uatSDpCr3gRRAMFJSaXaXjS5HoJJtG
QGX0InLNmfiIEfXzf+YzguaoxX7+0AjiJVgIcWjmzaLmFN5OUiQt/eV5E1PnXi8t
TRttQBVSK/eHiXgSgW7ZTaoteNTCLD0IX4eRnh8OsN4wUmSGiaqdZpwOdgyA8nTY
Kvi4Os7X1g8RvmurFPW9QaAiY4nxug9vKWNmLT+sjHLF+8fk1A/yO0+MKcc=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIE0DCCBDmgAwIBAgIQJQzo4DBhLp8rifcFTXz4/TANBgkqhkiG9w0BAQUFADBf
MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsT
LkNsYXNzIDMgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw
HhcNMDYxMTA4MDAwMDAwWhcNMjExMTA3MjM1OTU5WjCByjELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJpU2lnbiwgSW5jLiAtIEZv
ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAz
IFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzUwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvJAgIKXo1nmAMqudLO07cfLw8
RRy7K+D+KQL5VwijZIUVJ/XxrcgxiV0i6CqqpkKzj/i5Vbext0uz/o9+B1fs70Pb
ZmIVYc9gDaTY3vjgw2IIPVQT60nKWVSFJuUrjxuf6/WhkcIzSdhDY2pSS9KP6HBR
TdGJaXvHcPaz3BJ023tdS1bTlr8Vd6Gw9KIl8q8ckmcY5fQGBO+QueQA5N06tRn/
Arr0PO7gi+s3i+z016zy9vA9r911kTMZHRxAy3QkGSGT2RT+rCpSx4/VBEnkjWNH
iDxpg8v+R70rfk/Fla4OndTRQ8Bnc+MUCH7lP59zuDMKz10/NIeWiu5T6CUVAgMB
AAGjggGbMIIBlzAPBgNVHRMBAf8EBTADAQH/MDEGA1UdHwQqMCgwJqAkoCKGIGh0
dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTMuY3JsMA4GA1UdDwEB/wQEAwIBBjA9
BgNVHSAENjA0MDIGBFUdIAAwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVy
aXNpZ24uY29tL2NwczAdBgNVHQ4EFgQUf9Nlp8Ld7LvwMAnzQzn6Aq8zMTMwbQYI
KwYBBQUHAQwEYTBfoV2gWzBZMFcwVRYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQU
j+XTGoasjY5rw8+AatRIGCx7GS4wJRYjaHR0cDovL2xvZ28udmVyaXNpZ24uY29t
L3ZzbG9nby5naWYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8v
b2NzcC52ZXJpc2lnbi5jb20wPgYDVR0lBDcwNQYIKwYBBQUHAwEGCCsGAQUFBwMC
BggrBgEFBQcDAwYJYIZIAYb4QgQBBgpghkgBhvhFAQgBMA0GCSqGSIb3DQEBBQUA
A4GBABMC3fjohgDyWvj4IAxZiGIHzs73Tvm7WaGY5eE43U68ZhjTresY8g3JbT5K
lCDDPLq9ZVTGr0SzEK0saz6r1we2uIFjxfleLuUqZ87NMwwq14lWAyMfs77oOghZ
tOxFNfeKW/9mz1Cvxm1XjRl4t7mi0VfqH5pLr7rJjhJ+xr3/
-----END CERTIFICATE-----

5. Creating a Trusted CA Profile and load local certificate and CA Certificate

ca-profile rootverisign {
ca-identity test.com;
revocation-check {
disable;
}
administrator {
email-address "admin@test.com";
}
}

{primary:node0}root@fw-1> request security pki local-certificate load certificate-id PRO filename /var/tmp/cert.cer
node0:
--------------------------------------------------------------------------
Local certificate loaded successfully

{primary:node0}root@fw-1> request security pki ca-certificate load ca-profile rootverisign filename /var/tmp/root.cer
node0:
--------------------------------------------------------------------------
error: Command aborted as CA certificate already exists. Retry after clearing the existing CA certificate

This error is relating to existing CA certificate. We will clear it first by following command:

{primary:node0}
root@fw-1> clear security pki ca-certificate ca-profile rootverisign

or You can directly go into cert folder to delete it.

root@fw-1> request security pki ca-certificate load ca-profile Montreal-PRO filename /var/tmp/root.cer
node0:
--------------------------------------------------------------------------
Fingerprint:
44:f4:34:20:3e:fa:be:7e:9e:c5:82:94:e3:b2:36:0b:4c:c5:c0:c0 (sha1)
1a:3e:85:80:2b:c7:57:86:c2:44:66:ff:89:ad:1e:c8 (md5)
error: Failed to write the CA certificate to local store

This error message usaully caused by unrecognized certificate file format. Actually, Juniper SRX does not take this kind of CA certification which has two certifications inside one file. We have to manually split this Certification to two parts then separately import different CA Profile, such as G4 and G5 we created below.

pki {
ca-profile G4 {
ca-identity gi-de.com;
revocation-check {
disable;
}
administrator {
email-address "admin@test.com";
}
}
ca-profile G5 {
ca-identity gi-de.com;
revocation-check {
disable;
}
administrator {
email-address "admin@test.com";
}
}
traceoptions {
file PKITRACE size 1m;
flag all;
}
}

root@fw-1> request security pki ca-certificate load ca-profile G4 filename /var/tmp/g4.cer
node0:
--------------------------------------------------------------------------
Fingerprint:
ff:67:36:7c:5c:d4:de:4a:e1:8b:cc:e1:d7:0f:da:bd:7c:86:61:35 (sha1)
23:d5:85:8e:bc:89:86:10:7c:b7:ac:1e:17:f7:26:c5 (md5)
CA certificate for profile G4 loaded successfully

{primary:node0}
root@fw-1> request security pki ca-certificate load ca-profile G5 filename /var/tmp/g5.cer
node0:
--------------------------------------------------------------------------
Fingerprint:
32:f3:08:82:62:2b:87:cf:88:56:c6:3d:b8:73:df:08:53:b4:dd:27 (sha1)
f9:1f:fe:e6:a3:6b:99:88:41:d4:67:dd:e5:f8:97:7a (md5)
CA certificate for profile G5 loaded successfully

6. Using the Cert in IPsec VPN Configuration

ike {
inactive: traceoptions {
file IKELOG size 1m;
flag policy-manager;
flag ike;
flag routing-socket;
flag certificates;
}
proposal P1-AES_1_1_1 {
authentication-method rsa-signatures;
dh-group group2;
authentication-algorithm sha1;
encryption-algorithm aes-128-cbc;
lifetime-seconds 86400;
}
policy ike-pol-Myvpn {
mode main;
proposals P1-AES_1_1_1;
certificate {
local-certificate Mark-PRO;
peer-certificate-type x509-signature;
}
inactive: pre-shared-key ascii-text "$9$4xZGjqmT3nCHqp01IcSs2g4Uj"; ## SECRET-DATA
}
gateway gw-TheirGateway {
ike-policy ike-pol-Myvpn;
address 10.9.1.1;
local-identity hostname mark.test.com;
remote-identity hostname mont.test.com;
external-interface reth9.0;
local-address 10.4.1.1;
}
}
ipsec {
proposal P2-AES_1 {
description group2;
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm aes-128-cbc;
lifetime-seconds 3600;
}
policy ipsec-pol-1 {
perfect-forward-secrecy {
keys group2;
}
proposals P2-AES_1;
}
vpn vpn-ToThem {
bind-interface st0.0;
ike {
gateway gw-TheirGateway;
idle-time 1800;
ipsec-policy ipsec-pol-1;
}
}

}

Some Other Configuration for Route-Based IPSec VPN

Interfaces {
st0 {
unit 0 {
family inet;
}
}
}

admin@fw-trn1-2> show configuration routing-instances
vr_SRX2{
instance-type virtual-router;
interface reth9.0;
interface st0.0;
routing-options {
static {
route 1.1.1.0/24 next-hop 10.4.1.2;
route 10.9.0.0/16 next-hop st0.0;
route 10.9.1.1/32 next-hop 10.4.1.2;
}
aggregate {
route 10.94.0.0/16 {
preference 2;
}
route 192.168.0.0/16 {
preference 2;
}
}
instance-import from_all_to_SRXl;
}

Reference:

1. Commands to clear pki related files

clear security pki key-pair certificate-id Markham-PRO

clear security pki local-certificate certificate-id Markham-PRO

clear security pki key-pair certificate-id Markham-PRO

clear security pki ca-certificate ca-profile Markham-PRO

clear security pki certificate-request certificate-id Markham-PRO

2. J Series / SRX Series IPSec VPN with PKI Certificates Primer
3. Example: Configuring the PKI in Junos OS
4. Certificate based IPSEC VPN in SRX
5. Juniper SRX - PKI - Certificate-based VPNs - Part 02 - SRX Configuration & Certificate Signings

Notes:

The following will setup your installed SSL certificate on fe-0/0/0.0 You need to assign this to the
externally facing interface. The interface should be set to accept HTTPS.

set security zones security-zone untrust interfaces fe-0/0/0.0 host-inbound-traffic systemservices https
set system services web-management https pki-local-certificate PRO interface fe-0/0/0.0

Thursday, January 15, 2015

Monitoring Juniper SRX Firewall CPU, Memory and Flow Session Information from PRTG

While using PRTG to monitor our firewalls, we found by default it could not poll Juniper SRX's CPU and flow information with auto discovery method. From command line, we are able to use following SNMP Mib to get CPU, Memory and Flow Session information, but not directly from PRTG.

PRTG is powerful network monitoring tools for enterprise with following features I likes :

Easy to deployment, as it said it can be installed in 2 minutes
Auto discovery methods to find monitoring elements.
Support distribution implementation. You could install agents it in multiple location.
Support Multiple protocols, such as SNMP, WMI, Netflow, jflow and sFlow etc.
Web Interface is quite intuitionistic
Email function
etc

This post will show how to manually add some sensors which not be able to use through auto discovery method.

1. SRX 240 SPU Mib Information

admin@fw-srx-1> show chassis hardware

node0:--------------------------------------------------------------------------Hardware inventory:Item Version Part number Serial number DescriptionChassis AG1912110058 SRX240HRouting Engine REV 51 750-021793 AAEP4868 RE-SRX240HFPC 0 FPC PIC 0 16x GE Base PICPower Supply 0
node1:--------------------------------------------------------------------------Hardware inventory:Item Version Part number Serial number DescriptionChassis AG0912110078 SRX240HRouting Engine REV 50 750-021793 AAEK3334 RE-SRX240HFPC 0 FPC PIC 0 16x GE Base PICPower Supply 0

admin@fw-srx-1> show security monitoring fpc 0

node0:--------------------------------------------------------------------------FPC 0 PIC 0 CPU utilization : 2 % Memory utilization : 78 % Current flow session : 191 Current flow session IPv4: 191 Current flow session IPv6: 0 Max flow session : 65536Total Session Creation Per Second (for last 96 seconds on average): 25IPv4 Session Creation Per Second (for last 96 seconds on average): 25IPv6 Session Creation Per Second (for last 96 seconds on average): 0
node1:--------------------------------------------------------------------------FPC 0 PIC 0 CPU utilization : 0 % Memory utilization : 77 % Current flow session : 135 Current flow session IPv4: 135 Current flow session IPv6: 0 Max flow session : 65536Total Session Creation Per Second (for last 96 seconds on average): 1IPv4 Session Creation Per Second (for last 96 seconds on average): 1IPv6 Session Creation Per Second (for last 96 seconds on average): 0

admin@fw-srx-1> show snmp mib get 1.3.6.1.4.1.2636.3.39.1.12.1.1.1.4.0 jnxJsSPUMonitoringCPUUsage.0 = 0

admin@fw-srx-1> show snmp mib get 1.3.6.1.4.1.2636.3.39.1.12.1.1.1.5.0 jnxJsSPUMonitoringMemoryUsage.0 = 78

admin@fw-srx-1> show snmp mib get 1.3.6.1.4.1.2636.3.39.1.12.1.1.1.6.0 jnxJsSPUMonitoringCurrentFlowSession.0 = 175

admin@fw-srx-1> show snmp mib get 1.3.6.1.4.1.2636.3.39.1.12.1.1.1.7.0 jnxJsSPUMonitoringMaxFlowSession.0 = 65536

2. Add sensors into PRTG

Since we already have MIB information in the SRX, here is the manual way to add those information into PRTG.

3. SRX1400 Mib Information

For SRX1400, SPU is in the different slot, you will just need to change slot number from 0 to 1.

{primary:node0}
admin@fw-1400-1> show chassis hardware node0:--------------------------------------------------------------------------Hardware inventory:Item Version Part number Serial number DescriptionChassis BH1114AJ0027 SRX 1400Midplane REV 11 711-111012 ACDN7611 SRX1k BackplanePEM 0 rev 11 740-112015 J027MY002311P AC Power SupplyPEM 1 rev 11 740-112015 J027MW001S11P AC Power SupplyCB 0 REV 12 750-112544 ACDL8977 SRX1K-RE-12-10 Routing Engine BUILTIN BUILTIN Routing Engine CPP BUILTIN BUILTIN Central PFE Processor Mezz REV 09 710-021115 ACDM9055 SRX HD Mezzanine CardFPC 0 REV 19 750-111019 ACDL1005 SRX1k 10GE SYSIO PIC 0 BUILTIN BUILTIN 6x 1GE RJ45 3x 1GE SFP 3x 10GE SFP+ Xcvr 6 NON-JNPR 00000MTC1131006V SFP-T Xcvr 7 NON-JNPR JUR1835GCWP SFP+-10G-SR Xcvr 8 Yrod NON-JNPR JUR1835G6WY SFP+-10G-SR Xcvr 9 NON-JNPR JUR1835GU90 SFP+-10G-SRFPC 1 REV 12 750-112543 ACDJ6935 SRX1k Dual Wide NPC+SPC Support Card PIC 0 BUILTIN BUILTIN SPU Cp-FlowFPC 3 REV 19 710-017865 ACDR5442 BUILTIN NPC PIC 0 BUILTIN BUILTIN NPC PICFan Tray -N/A- -N/A- -N/A- SRX 1400 Fan Tray
node1:--------------------------------------------------------------------------Hardware inventory:Item Version Part number Serial number DescriptionChassis BH1114AJ0011 SRX 1400Midplane REV 11 711-111012 ACDM5607 SRX1k BackplanePEM 0 rev 11 740-112015 J027MY004011P AC Power SupplyPEM 1 rev 11 740-112015 J027LS004011P AC Power SupplyCB 0 REV 12 750-112544 ACDL8984 SRX1K-RE-12-10 Routing Engine BUILTIN BUILTIN Routing Engine CPP BUILTIN BUILTIN Central PFE Processor Mezz REV 09 710-021115 ACDM9054 SRX HD Mezzanine CardFPC 0 REV 19 750-111019 ACDM8051 SRX1k 10GE SYSIO PIC 0 BUILTIN BUILTIN 6x 1GE RJ45 3x 1GE SFP 3x 10GE SFP+ Xcvr 6 NON-JNPR 00000MTC123511UD SFP-T Xcvr 7 Vo NON-JNPR JUR1835GB6J SFP+-10G-SR Xcvr 8 NON-JNPR JUR1835GCWT SFP+-10G-SR Xcvr 9 NON-JNPR JUR1833GMZN SFP+-10G-SRFPC 1 REV 12 750-112543 ACDJ6938 SRX1k Dual Wide NPC+SPC Support Card PIC 0 BUILTIN BUILTIN SPU Cp-FlowFPC 3 REV 19 710-017865 ACDS1404 BUILTIN NPC PIC 0 BUILTIN BUILTIN NPC PICFan Tray -N/A- -N/A- -N/A- SRX 1400 Fan Tray
admin@fw-1400-1> show security monitoring fpc 1
node0:--------------------------------------------------------------------------FPC 1 PIC 0 CPU utilization : 2 % Memory utilization : 72 % Current flow session : 2085 Current flow session IPv4: 2085 Current flow session IPv6: 0 Max flow session : 1048576 Current CP session : 1914 Current CP session IPv4: 1914 Current CP session IPv6: 0 Max CP session : 1048576Total Session Creation Per Second (for last 96 seconds on average): 34IPv4 Session Creation Per Second (for last 96 seconds on average): 34IPv6 Session Creation Per Second (for last 96 seconds on average): 0
node1:--------------------------------------------------------------------------FPC 1 PIC 0 CPU utilization : 0 % Memory utilization : 70 % Current flow session : 1844 Current flow session IPv4: 1844 Current flow session IPv6: 0 Max flow session : 1048576 Current CP session : 1844 Current CP session IPv4: 1844 Current CP session IPv6: 0 Max CP session : 1048576Total Session Creation Per Second (for last 96 seconds on average): 0IPv4 Session Creation Per Second (for last 96 seconds on average): 0IPv6 Session Creation Per Second (for last 96 seconds on average): 0

{primary:node0}
admin@fw-1400-1> show snmp mib get 1.3.6.1.4.1.2636.3.39.1.12.1.1.1.4.1
jnxJsSPUMonitoringCPUUsage.1 = 1
{primary:node0}
admin@fw-1400-1> show snmp mib get 1.3.6.1.4.1.2636.3.39.1.12.1.1.1.5.1 jnxJsSPUMonitoringMemoryUsage.1 = 72

{primary:node0}
admin@fw-1400-1> show snmp mib get 1.3.6.1.4.1.2636.3.39.1.12.1.1.1.6.1 jnxJsSPUMonitoringCurrentFlowSession.1 = 2245
{primary:node0}
admin@fw-1400-1> show snmp mib get 1.3.6.1.4.1.2636.3.39.1.12.1.1.1.7.1 jnxJsSPUMonitoringMaxFlowSession.1 = 1048576

4. CPU for Routing Engine

SRX branch also have a SPU (Service Processing Unit). Considering SRX branch doesn't have a dedicated SPU chip, but due to it's muticore infrasture, it will use one logical core act as RE, and other logical core act as SPU, this SPU always sit in FPC0.

The following MIB is for Routing Engine CPU Poll.

{primary:node0}
admin@fw-srx-1> show snmp mib walk 1.3.6.1.4.1.2636.3.1.13.1.5 jnxOperatingDescr.1.1.0.0 = node0 midplanejnxOperatingDescr.1.2.0.0 = node1 midplanejnxOperatingDescr.2.1.0.0 = node0 PEM 0jnxOperatingDescr.2.2.0.0 = node1 PEM 0jnxOperatingDescr.4.1.0.0 = node0 SRX240 PowerSupply fan 1jnxOperatingDescr.4.2.0.0 = node0 SRX240 PowerSupply fan 2jnxOperatingDescr.4.3.0.0 = node0 SRX240 CPU fan 1jnxOperatingDescr.4.4.0.0 = node0 SRX240 CPU fan 2jnxOperatingDescr.4.5.0.0 = node0 SRX240 IO fan 1jnxOperatingDescr.4.6.0.0 = node0 SRX240 IO fan 2jnxOperatingDescr.4.7.0.0 = node1 SRX240 PowerSupply fan 1jnxOperatingDescr.4.8.0.0 = node1 SRX240 PowerSupply fan 2jnxOperatingDescr.4.9.0.0 = node1 SRX240 CPU fan 1jnxOperatingDescr.4.10.0.0 = node1 SRX240 CPU fan 2jnxOperatingDescr.4.11.0.0 = node1 SRX240 IO fan 1jnxOperatingDescr.4.12.0.0 = node1 SRX240 IO fan 2jnxOperatingDescr.7.1.0.0 = node0 FPC: FPC @ 0/*/*jnxOperatingDescr.7.6.0.0 = node1 FPC: FPC @ 0/*/*jnxOperatingDescr.8.1.1.0 = node0 PIC: 16x GE Base PIC @ 0/0/*jnxOperatingDescr.8.6.1.0 = node1 PIC: 16x GE Base PIC @ 0/0/*jnxOperatingDescr.9.1.0.0 = node0 Routing EnginejnxOperatingDescr.9.1.1.0 = node0 USB HubjnxOperatingDescr.9.2.0.0 = node1 Routing EnginejnxOperatingDescr.9.2.1.0 = node1 USB Hub
{primary:node0}

admin@fw-srx-1> show snmp mib walk 1.3.6.1.4.1.2636.3.1.13.1.8 jnxOperatingCPU.1.1.0.0 = 0jnxOperatingCPU.1.2.0.0 = 0jnxOperatingCPU.2.1.0.0 = 0jnxOperatingCPU.2.2.0.0 = 0jnxOperatingCPU.4.1.0.0 = 0jnxOperatingCPU.4.2.0.0 = 0jnxOperatingCPU.4.3.0.0 = 0jnxOperatingCPU.4.4.0.0 = 0jnxOperatingCPU.4.5.0.0 = 0jnxOperatingCPU.4.6.0.0 = 0jnxOperatingCPU.4.7.0.0 = 0jnxOperatingCPU.4.8.0.0 = 0jnxOperatingCPU.4.9.0.0 = 0jnxOperatingCPU.4.10.0.0 = 0jnxOperatingCPU.4.11.0.0 = 0jnxOperatingCPU.4.12.0.0 = 0jnxOperatingCPU.7.1.0.0 = 0jnxOperatingCPU.7.6.0.0 = 0jnxOperatingCPU.8.1.1.0 = 0jnxOperatingCPU.8.6.1.0 = 0jnxOperatingCPU.9.1.0.0 = 19jnxOperatingCPU.9.1.1.0 = 0jnxOperatingCPU.9.2.0.0 = 8jnxOperatingCPU.9.2.1.0 = 0

admin@fw-srx-1> show snmp mib get 1.3.6.1.4.1.2636.3.1.13.1.8.9.1.0.0 jnxOperatingCPU.9.1.0.0 = 19
{primary:node0}
admin@fw-srx-1> show chassis routing-engine | find "CPU utilization"

Pages

Monday, February 2, 2015

CVE-2015-0235: GHOST - A Critical Vulnerability in the Glibc Library

1. Check Point Response to CVE-2015-0235 (glibc - GHOST)

IPS Protection:

OS Level Protection:

Hotfix Packages

2. Juniper: 2015-01 Out of Cycle Security Bulletin: GHOST glibc gethostbyname() buffer overflow vulnerability (CVE-2015-0235)

Vulnerable Products

SOLUTION:

WORKAROUND: General Mitigation:

3. Cisco : GNU glibc gethostbyname Function Buffer Overflow Vulnerability

Workarounds:

Tuesday, January 20, 2015

Build NTP Windows Server for Network Devices (not Win32Time)

Problem:

Solution:

Reference:

Monday, January 19, 2015

Configuration DHCP Relay in routing instance on Juniper SRX Devices

1. Forwarding Option Configuration on all related DHCP Client Routing Instance

2. Forward option configuration at DHCP Server Routing Instance

3. Make sure each client routing instance (vr_t and vr_def) has routes to vr_i.

4. No firewall policy will be needed. But both services bootp and dhcp have to be allowed on all DHCP client interface's host-inbound-traffic. Bootp will be needed on server side.

Reference:

Friday, January 16, 2015

Using PKI Build Route-Based IPSec VPN between Juniper SRX

1. On both firewalls generate Public/Private key pair:

2. Generating cert request from the key pair

3. Submit Cert Request to the CA and Retrieve Certs

4. Copying the Local Cert, CA Cert to local firewall

5. Creating a Trusted CA Profile and load local certificate and CA Certificate

6. Using the Cert in IPsec VPN Configuration

Reference:

Notes:

Thursday, January 15, 2015

Monitoring Juniper SRX Firewall CPU, Memory and Flow Session Information from PRTG

1. SRX 240 SPU Mib Information

2. Add sensors into PRTG

3. SRX1400 Mib Information

4. CPU for Routing Engine

Reference