Stuff I'm Up To

Technical Ramblings

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

Advertisements
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

Squid Kerberos Nightmare — July 25, 2017

Squid Kerberos Nightmare

What a terrible sequence of events we suffered today. Took quite a bit of head scratching, log reading and plenty of Google fu to resolve.

We use Squid with an LDAP and authenticated lookup to establish if a user is a member of an AD group to allow them through the proxy. For some very strange reason the authentication and lookup began failing today.

Continue reading

Fail2ban – Quick Reference — July 20, 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

Broken ARP — April 26, 2017

Broken ARP

Not a fun morning. We spent an hour or two trying to figure out why our GUEST networks was unable to route any packets to the Internet.

For many a GUEST network may be a trivial network, but for us we also us GUEST for unauthenticated devices to access our Virtual Desktop System – primarily including devices that are re-purposed laptops/desktops that no longer require a full Windows PC for domain access and just provide a VMware Horizon Client. So we had a large number of users unable to connect to the back office systems.

The strange thing here was that all other network traffic from the trusted networks worked as expected.

Continue reading

Sophos UTM HA —

Sophos UTM HA

We encountered a few problems with licensing when we looked at moving from the UTM525’s to UTM430’s so we had to delay the project until yesterday. On the one hand it gave us plenty of time to plan for the eventualities like Martians and be confident that the configuration restore testing worked whilst testing.

The one thing we didn’t expect was problem getting the two UTM430’s to configure themselves using High Availability (HA).

Continue reading

Preventing Martians — April 4, 2017

Preventing Martians

In the process of changing firewalls and routers around we encountered the Juniper detecting what it suspected were malicious MAC address changes that no longer match the IP address it last used. Which is understandable as we’re giving the same IP address to new hardware.

This MAC mismatch error triggers some Martian alerts, which results in the IP addresses for the new devices becoming unroutable. To try and prevent this we should try clearing down the IP ARP cache tables for various devices.

Juniper (ScreenOS)

-> clear arp [192.168.0.254]

or

-> clear arp all

Extreme Switches (XOS)

# clear iparp [192.168.0.254]

or

# clear iparp vlan [TRUST]

Martian addresses are host or network addresses about which all routing information is ignored. When received by the routing device, these routes are ignored. They commonly are sent by improperly configured systems on the network and have destination addresses that are obviously invalid.

CVE – Security Vunerability Datasource — March 18, 2017
STIG — March 17, 2017
Oracle Database Patches —
Setting the Killbit for an ActiveX Control — March 7, 2017

Setting the Killbit for an ActiveX Control

Adding a killbit for a control that Nessus says requires one.

https://support.microsoft.com/en-gb/help/240797/how-to-stop-an-activex-control-from-running-in-internet-explorer

In brief you need to find or create the classid in:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility

However, on one I found I first had to hunt the name in HKEY_CLASSES_ROOT\CLSID

eg. Nessus reported

  Class Identifier  : {D63891F1-E026-11D3-A6C3-005004055C6C}
  Filename          : C:\Program Files (x86)\xxxx\Runtime\NCSECW.DLL
  Installed version : 1.6.6.32

But when I search for NCSECW.DLL I got a different Class ID and that was what I needed to use to add a killbit for.