Inconsistencies on muting alarms
I have the Gold Firewalla, and very happy with it.
Something that bugs me though is how inconsistent Alarm Muting is for various types of Alarms. Here are a few examples:
SSH Password Guessing is apparently not an incident which you can neither block nor mute, it just "is"... ?
I would expect Firewalla to automatically block SSH Password guessing (for a time period), but there's no indication that it does that. And a 'Mute' which does allow me to mute the IP in question if it just happens to be me mistyping my password a lot ;-) (Really just about consistency here, I don't really do that)
Other access to the same device, same port (22/SSH) are blocked automatically. Probably in a different list (list of known bad IPs/regions, what have you), but the access is identical, it's an attack on your SSH service.
Large Bandwidth Usage has a muted option, but it's unclear what you are really muting here.
It just says "Mute Device: No more alarms on device XXXX". Wait a minute! I do want other alarms for that device, it's not an all or nothing choice! Also, what about large consumption towards a specific location? I mean, my NAS will often spew out lots of data, but if hits specific regions I'm not in, I would like to know!
Compare that to the muting of a gaming alarm for example:
Here the "all" option correctly specifies "Mute gaming activity: Apply to device XXXX only", and I have the option to mute it against a specific site or all sites.
Alas, Large Bandwidth mute should read "Mute large bandwidth usage: Apply to device XXXX only".
Other alarms only allow me to mute a target/site for all devices, not a specific device.
Abnormal Upload is such an alarm. My vacuum cleaner will often "phone home" with map updates etc, and I expect that, so I would like to mute the "Adnormal Upload" alarm for it. However, if my other devices start uploading to the same sites, something is afoot. Please allow us to mute abnormal uploads for only a specific device:
And some mutes for the exact same incident type results in different mute options. Above the Abnormal Upload for the xiaomi.com domain gives me to mute at any subdomain level, while for googleapis.com, it doesn't. Why the difference?
Only one option here "translate.googleapis.com", no "googleapis.com"?
(Not that I really needed it in this case, it's just another example of the mutes being inconsistent.)
That's all for now!
Great product, just some nitpicking really :)
Thanks!
-
@Mstormo
Thanks for your feedback.
Some of the inconsistencies you’ve mentioned do appear to be App bugs, I’ve forwarded to the team.
In general, the mute/block options are designed to be different for different types of alarms. For example, the security related alarms can only be mute on all devices, because If you decide to trust a site accessing one of your device, you might as well trust it on all your devices.
However, we’ve received many feedbacks recently, regarding the alarm options, the current design seems to be not sufficient for many use cases. So we are now actively working on a new version of the alarm options, to make it more flexible and able to cover various cases.
Before the new version comes out, there are some workarounds:
- Alarm settings. If you tap the “tuning” icon on the top right corner of the alarm list, you can manually configure almost any type alarms you’d like to mute, either globally or on a specific device.
- Web Interface. On the Firewalla web interface (my.firewalla.com), we do provide more options for mute/block alarms. While the web interface is in beta testing, it releases new things faster than the mobile App.
Hope it is helpful.
-
I’m excited to hear about the idea of improving alarms!
“For example, the security related alarms can only be mute on all devices, because If you decide to trust a site accessing one of your device, you might as well trust it on all your devices.”
yes, I agree the current capability is insufficient. just to add to the use case, I may trust a certain device, Group, or vlan with certain access (e.g. because of port forwarding etc.) that I would not trust to other devices, groups or vlans.
Thanks, Mstormo!
-
If I may jump in on this thread:
YES dealing with alarms gets quickly annoying and can become conter-productive for less technocentric mindsets. it needs to improve.
Few Suggestions:
- Fundamentally, for any alarm triggered because of "pattern" from "source" to "destination" should provide a way to quickly enable a matching block/allow rule
for instance, I would like to block "pattern=suspicious" access from "source=internet" to "destination=intranet" (currently that's not possible for all use cases) - "pattern" needs to be explained in particular: "heavy bandwith, large upload, suspicious activity,..."
- "source" needs to better quantified, checking in Taleos is quite a bit confusing, I would think there should be ways to maybe categorize the level of risk from a known compromized bot, to ISP IPs which get randomly allocated and got matched as a potential spammer once,...
- "source" should be able to support complex logical patterns (ie: all internet - 123.4.5.0/24 ) similar to wireshark filters plus one where the IP is based on a DNS names adhering to a TTL to support DDNS... for instance I might want to block completely port 21 from the internet except from an IP matching my laptop foo.domain.com which is actually maintained dynamically.
- "source & destination" should support name_aliases for convenience (ie mylaptops=192.168.0.15 and192.168.0.19 and not 192.168.0.40-255)... maybe have firewalla ship with pre-built known offenders and/or well-known safe ranges (aws/azure/google...)
- "known rules" in the same way firewalla has already gone through the trouble of detecting "streaming " patterns, and you already have the ability to detect an AMAZON MAC address... it would be a good idea when you detect an amazon device streaming, to offer the user to: enable a rule which puts all the amazon MAC under an "amazon_devices" group and enable a rule to "ALLOW" "pattern=Streaming" from "source=amazon_devices" to "internet"...
Then later on, as you detect more streaming initiated from smart TV's TCL MAC addresses, suggest to modify the rule from "source=amazon_devices" to "source=amazon_devices and TCL_devices"... etc... - "crowdsourcing" as discussed in a separate thread, allow people to "publish/share" rules so firewalla can share and suggest other users how to deal with an already known issue. Don't decide for them, just inform them that 70% of users are allowing streaming from devices using an amazon MAC address, 10% are blocking, the rest are just ignoring it... etc...
- Fundamentally, for any alarm triggered because of "pattern" from "source" to "destination" should provide a way to quickly enable a matching block/allow rule
-
@FF,
Thanks a lot for your feedback. We'll try to write more docs for different alarm types and how they can be triggered.
As for the definition of Source, Firewalla continuously updates the risk level of IPs from various databases.
The known rule is a good idea. Instead of generating block or allow rules when matching a specific streaming pattern, we will try our best to provide suggestions and let the users make their own decision, unless the activity is determined to be dangerous. The feature of "crowdsourcing" is also on our roadmap.
We are unlikely to support the complex logical patterns in the near future, however, you can use block internet, allow 123.4.5.0/24 to achieve that.
Regards.
-
Adding an example that really puzzles me. Looking at alarms this morning, I see some like watching video that I can only mute on the device that it occurred on.but mute alarm can only be muted on all devices.
this is exactly the opposite of what I want in this case. I want to allow the video from this site on any device and I want to mute the upload on just the one device (these happened to be different devices by the way.)
im not sure this would always be the case, but the current app stops me from being able to decide what to mute in a useful way.
-
I just wanted to chime in here. I do find that the ability to mute alarms is somewhat idiosyncratic—sometimes I can mute for all devices, sometimes I can't; sometimes the choices aren't granular enough. But the only one that is a consistent bother is SSH Password Guessing (for GitHub specifically).
Unfortunately, something that I do on a regular basis in my workflow is causing the SSH Password Guessing alarm to come up several times a day. I think it might be Atlassian SourceTree, but I'm not certain. I do a lot of work with GitHub using both the command line and SourceTree, and I do a lot of building of Kubernetes applications hosted on Git repositories. I also have some IT-installed security monitoring software on my computer too, so that might have something to do with it.
My point is this: I do need to mute this alarm. I understand why this is one that people ought to be aware of, but I do think I have hit on a case where this is a legitimate use case.
-
@firewalla one more thought on this important topic. Alerts should be informed by the rules set up by the administrator. By default don't alert on things that a rule allows. (I'm not positive but I think I have seen examples where that doesn't seem true right now.)
Also, like alerts, users should have the option of using "rule like" behavior to silence (IP, IP range, Port, for source and destination, etc.)
Please sign in to leave a comment.
Comments
13 comments