Stuff I'm Up To

Technical Ramblings

Monitor Security Flow — November 15, 2017

Monitor Security Flow

We stream the Juniper SRX logs out to our syslog server and that seems to work quite well. It is reliant upon us having the relevant log setting in the rules.

So for rules where we allow we can log the data at session-close

...
    then {
        permit;
        log {
            session-close;
        }
    }

But in our Deny All rules we log the session-init – because a denied session never gets closed (it’s never opened). So the session-init just logs the attempt.

...
    then {
        deny;
        log {
            session-init;
        }
    }

But what if we’re missing some rule logging, or are a bit unsure if packets coming in are actually coming in or not? That where monitor security flow comes in handy.

At the cli on the SRX you need to setup and activate the security flow, the filters to apply and the file to log to. In this example we’re going to capture packets from a specific ip address on a particular interface.

Create a named filter called ‘myfilter’ and then create a file to log into.

> monitor security flow filter interface reth0 source-prefix 192.168.56.10 myfilter
> monitor security flow file size 10240 securityflow.log

Then you can start and stop the monitor as you need. Then look at the content of the file.

> monitor security flow start
> monitor security flow stop
> show log securityflow.log

View the current status of your monitor

> show monitor security flow

Monitor security flow session status: Active
Monitor security flow trace file: /var/log/securityflow.log
Monitor security flow filters: 1
  Name: myfilter
    Status: Active
    Source: 192.168.56.10/32 (port 0~65535)
    Destination: 0.0.0.0/0 (port 0~65535)
    Logical system: root-logical-system
    Interface: reth0.0

Copy the log file to another system if you want to analyse it further

> file copy /var/log/securityflow.log scp://user@server.domain.local:~/

After stopping your monitor, you can then tidy up removing your file and filter using

> file delete /var/log/securityflow.log
> clear monitor security flow filter myfilter

 

Advertisements
JunOS static-nat and proxy-arp — October 31, 2017

JunOS static-nat and proxy-arp

I’m still relatively new to this JunOS, even though it’s been installed for several months now. Today’s problem was not passing traffic through a new static-nat that I’d setup. I checked the config for static-nats that already existed and couldn’t see the problem.

I needed to look at how the static-nat gets presented on the interface. It’s no good having a NAT rule if you don’t actively acknowledge that you are active on that IP address on an interface. No proxy-arp means nothing gets passed to NAT because the IP doesn’t exist on the network.

To do this make sure you add a proxy-arp address on the interface that you want to access the IP address.

eg.

set security proxy-arp interface reth1.99 address 192.168.99.99/32

Then you’ll have a related rule entry in your security nat static rule-set stanza to handle the translation.

eg.

show rule MyRule   
match {
    destination-address 192.168.99.99/32;
}
then {
    static-nat {
        prefix {
            192.168.0.99/32;
        }
    }
}

 

Teradici PCoIP Zero Client Firmware v5.5.1 — August 9, 2017

Teradici PCoIP Zero Client Firmware v5.5.1

After downloading the PCoIP firmware update to deploy to our terminals I uploaded it to a test station using the “Admin Web Interface” (AWI) – the built in web GUI on the terminal, not from the central management console.

It seemed to go OK, but when it reset the PCoIP processor, effectively a reboot, it came up with a dialog showing the message:

Warning : Multilanguage font pack not found !
Defaulting to English only : Please update firmware to enable multilanguage support

I tried re-uploading the file and still received the same result.

Continue reading

Old School FTP — August 7, 2017

Old School FTP

Having recently replaced the firewall we found one of the external sites used for FTP file transfers was failing periodically. Turns out this was a simple problem. We just weren’t allowing enough of a range for the FTP data ports needed. We’d allocated a range of 1,000 ports, but looks like they use more.

So how did we find this out? I could have trawled the firewall logs, but was just easier to see what the FTP log file was telling me.

The log file generated the error “425 Unable to open the data connection”. After looking at the previous passive mode response I decoded the port that it required.

ftp> 227 Entering Passive Mode (192,168,0,250,109,116)

It’s a simple calculation. The first four numbers are the remote servers IP address and the last two specify the TCP data port required. In order to determine the port take the 5th number and multiply by 256 then add the 6th number.

eg.

109 x 256 + 116 = 28020

So now I’ve extended the allowed port range to include 28000-28999 to make the connection.

Ideally it would be best to get the remote server administrator to tell you what range they require. But if you have to resort to guessing at least you know how to calculate their requirement.

 

References: https://www.ietf.org/rfc/rfc959.txt

SRX SSH Ciphers, Algorithms & Key Exchange — July 31, 2017

SRX SSH Ciphers, Algorithms & Key Exchange

When doing a Nessus scan for the first time on the new SRX320 cluster it highlighted some weaknesses in the SSH protocol. This was due to arcfour, cbc and hmac being enabled by default.

So to remedy this we need to set the acceptable levels of ciphers etc.

Using the CLI a simple change to the config for the SSH service is required, under system services ssh.

# edit system services ssh
# set ciphers [ aes256-ctr "aes256-gcm@openssh.com" "chacha20-poly1305@openssh.com" ];
# set macs [ hmac-sha2-256 "hmac-sha2-256-etm@openssh.com" hmac-sha2-512 "hmac-sha2-512-etm@openssh.com" ];
# set key-exchange [ curve25519-sha256 ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521 group-exchange-sha2 ]

Commit the changes and rescan and all is good.

Continue reading

Disaster Recovery Site and VRRP —

Disaster Recovery Site and VRRP

We’re currently working at putting in a new SIP based phone system that is externally hosted. As we already have a disaster recovery (DR) site with a network that routes out to it we figured we’d host the backup link for the phone system out there too.

The phone provider has installed 2 routers for us, one locally and the other at the DR site. They’ve then configured their routers to handle failovers using some active technology like BGP or VRRP. We don’t know the specifics and that really doesn’t matter to us. As long as we can route traffic out to them to their gateway address, then the rest is up to us to handle.

Continue reading

JunOS SRX too clever for it’s own good! — July 28, 2017

JunOS SRX too clever for it’s own good!

Today the planned migration from a Juniper ScreenOS SSG to a JunOS SRX didn’t quite go as smoothly as I’d have liked.

We spent many hours last night and this morning trying to figure out why numerous services that worked fine through the SSG firewall failed through the SRX. This despite me having triple checked the rule sets matched exactly from one system to the other.

We ended up making changes to connected systems to resolve the problems as workarounds but this was far from ideal. The eventual culprit turned out to be a default feature that is enabled on the SRX within the default application junos-dns-udp.

Continue reading

Squid3 changes for Debian Jessie — July 21, 2017
Juniper HA Woes — July 6, 2017

Juniper HA Woes

I spent quite some time messing around with a pair of Juniper SRX320’s trying to get the HA clustering setup. The documentation seems pretty straight forward, but I kept tripping over one fatal flaw.

Initially I configured HA using the J-Web interface and it configured successfully. I made some changes, set things up to test and then decided I didn’t like the direction I was taking and wanted to factory reset the devices.

The reset seemed pretty straight forward but then everything went wrong when I tried to follow the Command Line instructions for setting up an Active/Passive configuration. Every time I put the two systems into cluster mode and set the cluster ID and node the secondary node (node 1) always showed as lost and disabled.

Continue reading

OpenVPN DNS — July 4, 2017

OpenVPN DNS

Using OpenDNS on a Linux system that uses resolv.conf requires that the OpenVPN script is able to update the DNS servers sent by the remote dhcp options. To do this you must amend your OpenVPN config file to include the following lines.

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Then when you establish your connection your DNS search domain and servers will be added successfully.

References: https://airvpn.org/topic/9608-how-to-accept-dns-push-on-linux-systems-with-resolvconf/

Wrong Certificate! — June 15, 2017

Wrong Certificate!

“Your connection is not private!”

This was a game over message that was the result of installing the wrong type of certificate onto our new printers. We’re still working on getting the template right, but put simply we enabled a User certificate as the HTTPS management certificate. This caused any browser to throw up a serious security alert, serious enough that it doesn’t give you the option to continue to the management interface.

Even trying a factory reset on the printer didn’t take us back to factory settings for the management interface – that’s another bridge we have to cross.

Thankfully, within Google Chrome there is a secret instruction that allows us to continue even though we really shouldn’t.

So don’t use this carte blanche. It’s a get out of jail free card for a specific failure of our own making. If your browser is stopping you from getting to a web site, it’s usually doing so for a very good reason.

One the page where you are prevented access click anywhere inside the browser page and type “badidea“. As if by magic you are now able to visit the page and now we were able to correct our misconfiguration and change the HTTPS certificate back to a valid Web Server type.

If you find “badidea” doesn’t work try using “danger” instead.

 

References: https://www.quora.com/How-do-you-fix-the-privacy-error-in-Chrome-Your-connection-is-not-private

 

Unable to Logon as admin — June 5, 2017

Unable to Logon as admin

I managed to bork one of our test switches today. I was in the process of enabling “netlogin” using RADIUS as the authentication method, when I must have inadvertently enabled RADIUS authentication for the management interface instead of just for “netlogin”.

Using the Extreme documentation as a clue to resolve this kind of issue, but for a forgotten admin password, I was able to modify the instructions slightly to achieve a logon without resorting to a factory reset.

Continue reading