On Jan 14, 2010, AJ Weber wrote: > I don't know if this is a "Feature Request" or whether it's burried somewhere > in the options... > > Can I choose which events trigger an email?
There aren't any granular controls for this yet, but that is a good idea. You can disable email and/or syslog alerts altogether with the ALERTING_METHODS variable, but more specific controls are not currently implemented. > For example, right now, I'd like to only get the notification when fwknopd > receives a knock. I currently get that, and then 30sec later I get a notice > that the fw has been closed-up (right on time, yes, but I kind of trust it > enough that I can assume that is the case). > > Some options I can think of: > - Notify on any Knock > - Notify on (only) invalid/failed Knock-Attempt > - Notify on Timeout Action > - Notify on ALL (what I think is the current functionality) I could envision an ability to apply filtering rules to emails based on a hierarchy of info->warning priorities or something along these lines. > Thanks, > AJ > > PS: And while we're at Feature Requests, a great feature that is only loosely > related, would be to notify on detected port-scans or DoS attempts. Since > you're already sniffing all the traffic on all the ports, you would be able > to detect this quite easily (I think), and you already have the notification > and logging capabilities coded and ready! Implementing port scan detection is beyond the scope of the fwknop project. By default, fwknopd only sniffs one UDP port, and the additional machinery to offer port scan detection would add a level of complexity that is better implemented by other software (such as an IDS or firewall log parser). I do agree that SPA-specific attacks are something that fwknop should look for and send appropriate alerts for though. The replay attack detection functionality fits nicely here for example. I agree that DoS attack detection (as you mentioned above) is something that could be implemented. An example would be applying thresholds to the number of incoming SPA packets - any inline adversary that can intercept an SPA packet could replay it in a loop and modify it at the same time, and fwknopd should build in defenses against this. Of course, an attack of this sort is a simple resource exhaustion attack - there is practically zero risk of real access being granted by an attack of this sort. Further, the upcoming C fwknopd server implementation will most likely offer better performance than the perl version so it should be able to weather DoS attacks more effectively too. Thanks, --Mike > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Fwknop-discuss mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/fwknop-discuss ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Fwknop-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fwknop-discuss
