Messages

Do you know whether there are any issues with Macs, when it comes to the serial connection? Like MBP with an USB->USBc converter? (have seen the info on the page about macOS, just asking for experience)

I found it worked more smoothly than expected, a contrast with trying to work a serial connection to a Hunsn box. I used the cable which comes with the Deciso with an Apple USB A->C converter (A1632) but other converters should work. There are various apps on the app store. My preference after trying three is SerialTools. You can save a configuration document and start that. I think Apple's screen in Terminal works too.

My wife raised that she could not reach a NZ web site, miwoollies.com, with whom we have dealt occasionally over many years. I found I could, then realised I was still on the VPN so obviously Qfeeds was stopping her, which proved true. The address in question is 192.200.160.14 which threat lookup shows to be Bigcommerce Inc. This is the same site, different IP,  I raised a few days ago when she was trying to reach the Australian luxury goods site Oroton, although the problem was less important then. The relevant list is James Brine Bruteforce IPs feed

As we discussed before, bigcommerce is used by both legitimate and non-legitimate players. Is the solution to whitelist selected IPs as they arise, in floating rules? If I install a VPN on her machine she will probably wind up leaving it on, bypassing Qfeeds. Is the bigcommerce listing open to refinement?

Coincidentally I have this evening (my time) received an alert from haveibeenpwned about an aggregated list from Synthient last April, in which list an email and password appear. Given that list gathers previous material the alert probably repeats previous rather than being new. In any case, without knowing the breach source there is really nothing to do if passwords are strong and never reused. Criminals are not going to expend centuries trying to brute-force long random strings and state actors would not be interested in me.

This is still in the vein of saying of course my e-mail is known, and in some cases they can see the lock (hashed password) but breaking it is another matter so why jump on hearing someone else knows my email and a singular lock? If it were to something critical then I will hear from the organisation and can act as a precaution, though all critical assets have 2FA anyway.

While other people may have a different view, I am not seeing credential monitoring as worth the investment unless it can tell me precisely on which site the breach occurred.

Edit to add: I am my own e-mail provider, and have for many years kept anything important out of e-mail unless the message itself has strong encryption.

Can you tell me which one you have? I am thinking about to upgrade my old Zyxel.

How many ports? SFP or copper?

I am another one who uses Mikrotiks behind Opnsense. My switches comprise two CRS304 4 x 10Gb (+ 1Gb management port) in different places as the principal backbone and a CRS310 with 8 x 2.5Gb + 2 x SFP+ in the "server room" aka workshop. They are excellent switches, all running ROS, though I took advice and replaced the factory fan in the CRS310 with a Noctua for a quieter life.

Knowing my e-mail addresses have been leaked is not interesting unless I always know the specific site from which it was leaked.

My working security assumptions are that the world already knows my name, address, phone number, e-mail addresses and probabilistically I am more likely to have been born on a particular one among my many dates of birth. haveibeenpwned confirms the e-mail aspect.

Therefore, if I know of the specific site of a new leak then I can change that password from abundant caution. Otherwise, I really do not care, my security being in heaps of entropy, 2FA where available, and tossing phishers into spam.

Thus, the marginal price I might pay would be zero without that feature of original loss site, little chance of more with it. Small businesses can lose data without anyone really noticing except your information turns up on the web, and losses from large businesses appear in the news.

That wasn't very promising, sorry. I would consider it if it were made available.

Regarding the brand choice alone, a year ago I switched from Hunsn to a Deciso box, the 697 with 4 x 2.5Gb suiting my needs. Additional to your caution about where it was made my two principal reasons were firstly the best assurance I could get that new versions of Opnsense would run without having to worry about device compatibility, and secondly it was a handy way to support Deciso/Opnsense beyond donations. Having used it a year, I will stick with Deciso gear when I need to change.

Not as prior distinctions but from experience, I have found its thermal performance to be excellent and as a strawberry on the cake they are also aesthetically quite neat.

Good move for temperature sensing. I use a progressively staged fan that kicks in when ambient rises, having a cupboard rather than a proper cabinet for the router and primary switches. You have scope to do that with your microcontroller.

I meant to mention that your discrepancy is much higher than I see. On different boxes I have seen more like 3-15 degree differences between measurement methods, the Deciso 697 being the closest and an N100 4 x 2.5G the worse. I wonder whether the Chinese boxes are simply thermally inferior; as some sort of analogy, they have good capacity to shed heat from the box which is a mass of finned metal, but not at the same rate from the CPU location. It could make sense.

As I have probably written in another related thread, assuming your router sits in plain air, measure the ambient air temperature. If it is within specification then you ought to be able to trust the designers. However, it is well known that manufacturers of CWWK boxes can be careless about applying thermal paste properly so if sysctl dev.cpu | fgrep temperature reports high figures on such a box then check it. If it is not high then trust the ambient.

GUI temperature is a guide to changes with activity.

To wrap up the curiosity item I raised, one of those addresses is bam.nr-data.net which is a gathering point for browser activity tracking, while the other is bigcommerce.com related to shopfront checkouts and again probably about activity data collection given purchases were not affected. Calls originated from Apple Safari, not Mullvad, although it is not excluded that that is coincidence.

While they are more about privacy than security, nothing has broken with them being blocked.

Misunderstanding something. The internal router stopped it. The edge router can never see what is not passed to it in the first place.

I have no further such contacts. I have organised to track their app source if one turns up again.

interesting to see that you experience outbound connections to it

That "interesting" could be carrying a lot of freight. The attempted connections were for a short period then ceased. The machine which sourced them has Sophos Premium running on it and no open ports. The router which trapped them is internal, not at the edge, looking only at outgoing traffic, Community key for Q-feeds. The Plus key is on the edge so it saw nothing of this.

I tried the threat lookups again. They worked in Safari, not in Mullvad (Firefox), "network error". Everything is latest versions.

I am curious to know what to make of this.

I saw in event logs that a string of outgoing connections were attempted from one machine. The first set was to 63.141.128.3 and the second to 162.247.243.29. I tried to look up each of these in TIP (Plus licence) to receive the reply "An error occurred while searching. Please try again or contact support if the problem persists." which it did.

dig showed NXDOMAIN of course. At virustotal.com each of these addresses was flagged by the SOCRadar Abusix list as malware but clean in the other 94 analyses shown by virustotal.

Is the likely source for these a pixel in a spam message or some web page? I have spam fairly heavily controlled so such a message rarely becomes visible to execute.

Why does the threat lookup so rarely respond with information, this not being the first time it has simply said there was an error?

since we don't collect any telemetry data, we can't display your hits in the TIP. This is a deliberate choice, we prefer not to gather any data from your firewalls.

Something appreciated by this user, for one.

@leony, I formerly had pretty much what you are discussing, with three LAN ports and some physical switches. Rules are pretty straightforward and it all worked.

My current setup is more complex, yet can still be implemented comfortably with or without VLANS (mine is without). It depends what suits if or when your system grows. There is nothing wrong with your starting point, especially if it can re-use existing equipment effectively.

I had an emerging problem where my mail server ceased to be able to access or be found outside its sub-net. I found that crowdsec was marked as blocking those messages so switched it off after which normal service was restored. Q-Feeds is still running on the WAN side. My public IP is not listed as an IOC in TIP.

In the course of this, I looked at the firewall log to find these (sample, abbreviated, unmatched, fake internal) entries, all TCP:

Source: 10.68.166.221:443
Dest: 177.36.61.165:42577
Action: block
Label: Block access to private nets

Source: 177.36.56.101:14851
Dest: 10.68.166.221:443
Action: pass
Label: let out anything from firewall

Should not the first be a pass and the second a block?
The 177.x.x.x addresses are not found in TIP IOC. Nor are they found by dig -x so it is understandable that they should be blocked, except it then seems the messaging is wrong.

Has something inverted here, or have I misunderstood it? I have made no changes to my firewall rules in ages other than adding the WAN floating rule for Q-Feeds.