Stuff I'm Up To

Technical Ramblings

SMB Insecurely Configured Service — August 17, 2017

SMB Insecurely Configured Service

For the first time today I ran into Nessus plugin ID 44676.

It highlighted an “insecurely configured Windows service”. This related to a Service Discretionary Access Control List (DACL), which is a whole bag of new to me.

The guidance shows how you can use the command line to show the DACL for the service it reported the issue with.

The following service has insecure group permissions:

Bacway Windows Service (BacwayService) :
– Authenticated Users: DC

More information is given here: https://support.microsoft.com/en-us/help/914392/best-practices-and-guidance-for-writers-of-service-discretionary-acces

Continue reading

Advertisements
Windows Update KB4034681 (August Monthly Rollup) — August 9, 2017

Windows Update KB4034681 (August Monthly Rollup)

Four hours of swearing at servers, kicking switches and rebooting printers and terminals and all because of a Windows Update.

Our entire network uses 802.1X authentication with certificates and this morning I arrived in the office to find all the Teradici terminals and network printers were failing to authenticate properly.

We hadn’t changed anything in the NPS policies so has a certificate expired? The errors in the event logs were constant

Event ID 36887 – A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 42.

Continue reading

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

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