Hello H&M,

sorry for my late response, the last few days have been very stressful for me.

Hi Stefan,

I do hope this time my e-mail reaches you...

I've accumulated some experience with Guardian, but my main experience is with Snort, snort used in different SIEMs.

Here are my recomandations for IPS/Guardian

Thanks for testing and providing your feedback, I really don't know why your messages are not accepted by the mailing list. I've send a copy of my answer, via CC to the development mailing list.

Recommendation 1: Please add to the ignore list the ability to add a comment to that IP being ignored. Reason: I do want to know why I've ignored all Snort alerts from that IP. (instead of doing a nice snort tuning and modify threshold.conf from snort for a specific list of SIDs).

Accepted, I will schedule this for guardian 2.1.

Note: for the record : ignoring an IP in Guardian does NOT reduce the load on CPU. Snort will continue to trigger alerts and log them. If IPFire is designed to work for small resource systems, I do recommend to move the ignore rule at snort level. I can provide snort logic for accomplishing that.

Sadly this is not possible, because the brute-force detection mechanisms are not provided by snort.

Recommendation 2: As a best practice before unblocking an IP (an offender) I do following steps that require additional data (data that will be nice to be provided by IPFire WUI / guardian-2.0-010 somehow). I am talking about information related to the IP that I want to unblock:

1. What was the reason in the first place for IP being blocked. Recommendation: please add back to guardian.log as much as possible from the information generated in snort/alert file. Currently (guardian-2.0-010) the message in guardian.log is not helping in that direction

Current guardian-2.0-010 guardian.log message:

Wed Feb 18 22:46:17 2015: Blocking 222.186.31.208: An active snort rule has matched and gained an alert. Wed Feb 18 23:18:15 2015: Blocking 123.249.24.160: An active snort rule has matched and gained an alert.

Old Guardian (based on perl) logging style was much better, please use the old logging style if possible:

Wed Feb 18 22:15:34 2015: 123.249.24.160 [1:2403344:1577] ET CINS Active Threat Intelligence Poor Reputation IP TCP group 23 Wed Feb 18 22:18:55 2015: 218.77.79.43 [1:2402000:3604] ET DROP Dshield Block Listed Source group 1 Wed Feb 18 22:23:32 2015: expiring block of 141.212.121.203 Wed Feb 18 22:26:31 2015: 61.240.144.66 [1:2402000:3604] ET DROP Dshield Block Listed Source group 1

Accepted, I will include this really important suggestion into the next testing version.

2. If the reason is is a Policy EXE or DLL download this means that probably one of my laptops/desktops got spearfished and a malware is starting to bring additional files to the victim. Or, is just me downloading the new version of AdobleFlash. No matter the case, before unblocking the IP, I do check if the IP blocked by Guardian „kind of” safe. For that I do use / rely on following tools, tools that can be easily added to the Guardian status window as links. Here are the links format that can be added near each blocked IP:

a. Virustotal. The format of the link is : https://www.virustotal.com/en/ip-address/a.b.c.d/information/ where a.b.c.d is the IP from GUARDIAN iptables chain. Example: https://www.virustotal.com/en/ip-address/61.240.144.66/information/ . Yes, even the mighty Akamai is listed as distributing malware. b. IPVOID (collection of RBL databases – most important one are related to TROJAN monitoring – like ZeusTracker). Format of the link is http://www.ipvoid.com/scan/a.b.c.d/ where a.b.c.d is the IP from GUARDIAN iptables chain. Example: http://www.ipvoid.com/scan/61.240.144.66/

3. Another awesome tool (but also heavy one!) I use before unblocking an offender is the DNS blacklist aggregator from http://multirbl.valli.org/. This tools checks the IP in a whopping 228 RBL databases! Yes, lots of false positives… but when you see the IP in more than 50% of the RBL databases you start to reconsider unblocking it. The format of the link is http://multirbl.valli.org/lookup/a.b.c.d.html where a.b.c.d is the IP from GUARDIAN iptables chain..Example http://multirbl.valli.org/lookup/61.240.144.66.html
4. Another tool I use to check for Phishing sites (IPs) is http://blog.gmane.org/gmane.comp.security.phishings . Here is one example of a site that steals PayPals credentials, site that is also listed in VirusTotal but is not clear what the site is doing (the phishing part): Quaery: http://search.gmane.org/?query=218.208.237.174&group=gmane.comp.security...

From my experience, allowing a user to unblock/flush the GUARDIAN is bad because people do not posses so much knowledge about the reason embedded in the ET rules, rules that were used to trigger alerts and therefore Guardian block action. Giving to the user links to sites like VirusTotal & IPVoid will probably make them wonder themselves why the links are there (in the WUI) and use them before clearing an IP from the offenders list. Second: the links will help them to better understand the ET Rule and why in the first place snort triggered an alert.

Another use case for the links for above sites, but this times for the IPs listed in Status - Connection: if a user sees tons of traffic to suspect sites it is good to be able to check the IPs to a collection of public available tools. I saw in last few months articles about legit sites being injected with redirect codes – see Forbes being attacked last year. Such attacks takes place daily - and unfortunately are successful. An advanced used will take a peak to the active connection and will check why his machines are opening so many connections and will try to see if some of them are legit (using any of the available sites listed above)

Bottom line: if the IP that a user wants to unblock is listed on one of the above sites as distributing malware/Trojan, doing phishing, or having +20000 Domains attached to it (yes, I’ve saw one with more than 20000 domain attached to the IP!), maybe they will leave that IP blocked.

I've seen your feature request on the bugtracker and your posts in the forum thread. I thinks your suggestion would be a nice and handy feature, but I don't agree in putting the icons and links into the "Currently blocked Hosts" section inside the "guardian.cgi".

I'm considering in extending the "ipinfo.cgi" and locating the icons + links to the external sources on that page. The "ipinfo.cgi" is linked from various logging pages, so this would offers the ability to use those information services also for firewall hits, snort alerts etc.

Recommendation 3:

As I wrote in the forum - please allow a user to unblock an IP for a limited period of time. The old guardian did that. The reason is this: I do prefer a limited hole in my security rather than a permanent one. Here is the use case: all of us does downloads/out machines does tons of downloads (Adobe- so many, Antivirus, Windows updates, XUbuntu updates, etc). Snort will block them for various reasons: there are so mane RT rules for that. Me, as user, I do need that download, so I will be forced to add the IP to the ignore list.

This is so bad: for a single time download (one update!) I've created a permanent hole in my IPS. And this holeis most of the time toward an IP that is a local cache (local mirror)! And the local cache provider does reutilize that Ip for so many domains: I've checked that! Many domains being dynamic, or listed in different blacklists. But if I've ignored all alerts for that IP...I am somehow working against my IPS.

And, as I said above, the domains behind one IP can be thousands, IPs are reutilized (See Dynamic cloud servers services - like Amazon, 1&1, or even the provider IpFire Uses) - all these providers reutilize IPs for so many sites...

Bottom line: a permanent hole is totally against IPS concept in my opinion. I rather allow the traffic for a limited time, but after that IPS should block any further attempts for doing traffic with that IP if snort triggers alerts for IT.

Accepted, I will add an option for this in guardian 2.1.

============================================================================================================ Errors - how to replicate them

I’ve managed to replicate Blago’s error like this: create 2 guardian processes in memory. If this is happening, I get same error message:

[root@dmx ~]#/etc/init.d/guardian status guardian is running with Process ID(s) 2928 2299. [root@dmx ~]# /etc/init.d/guardian stop /etc/init.d/guardian: line 33: [: 2928: binary operator expected

Here is a solution to have 2 guardian processes in memory:

[root@dmx ~]#guardian status

There is an executable file named guardian besides the /etc/init.d/script. Making a call to that generates 2 guardian processes in memory. This has nothing to do with an old guardian version on IPFire. Is the same guardian...

Here are the 2 processes:

[root@dmx ~]#ps aux |grep guard root 2299 0.9 0.0 9296 3216 ? S 20:31 0:01 /usr/bin/perl /usr/bin/guardian root 2928 0.0 0.0 10864 3328 pts/0 S 20:33 0:00 /usr/bin/perl /usr/bin/guardian status

After this, /etc/init.d/guardian fails to stop the guardian processes. Other impact observed: the WUI works OK and display as PID number the one from the line with “status” (= 2928), but Currently blocked hosts list is empty. [root@dmx ~]# cat /run/guardian.pid 2928

========================================================================================

Note: updating to 2.17 core 87 somehow put down my guardian. I need some time to rebuild it - the Web interface looks funny - lot of missing elements. Including the Guardian menu! (but the cgi is still on the disk and can be accessed manually).

Best, H&M

Best regards,

-Stefan

-----Original Message----- From: Stefan Schantl [Masked] [mailto:FWD_eRROOjHG@opayq.com] Sent: 28 februarie 2015 15:51 To: 64f853bf@opayq.com Subject: Guardian 2.0 Testversion 011

Hello followers,

at first I have to thanks to all of you which have joined the guardian 2.0 testing team. I've got a lot of positive feedback but also has been noticed about several tiny issues.

I've uploaded an updated test version to http://people.ipfire.org/~stevee/guardian-2.0/.

The installation / update works in the same way as described in the planet post: http://planet.ipfire.org/post/introducing-guardian-2-0-for-ipfire

IMPORTANT: Please create a backup of your files stored in "/var/ipfire/guardian/", otherwise the will be overwritten by the update!

Changelog:

• Matthias Fischer detected some small problems in the "guardian.cgi"

and provided some patches for them. http://git.ipfire.org/?p=people/stevee/ipfire-2.x.git;a=commit;h=19d6abcce57... http://git.ipfire.org/?p=people/stevee/ipfire-2.x.git;a=commit;h=0a6c3cb8964... http://git.ipfire.org/?p=people/stevee/ipfire-2.x.git;a=commit;h=82208c83c70...

• Blago Culjak informed me about problems on starting guardian and displaying it's status in the web interface. This behaviour only happens when the legacy version of guardian has been un-installed and not just replaced by the guardian. In the updated version contains the required file which is used by various IPFire scripts to detect if an addon is installed or not.

• The CLI switch "-d" called "debug mode" has been replaced by "-f" to launch guardian and run it in the foreground.

http://git.ipfire.org/?p=people/stevee/ipfire-2.x.git;a=commit;h=a58bd674863...

• Some new code has been added to prevent from starting multiple instances of guardian.

http://git.ipfire.org/?p=people/stevee/ipfire-2.x.git;a=commit;h=9d44c0d9952...

Best regards,

-Stefan