Development March 2015

development@lists.ipfire.org

14 participants
22 discussions

Start a nNew thread

Update monit addon to 5.12
by Dirk Wagner 22 Mar '15

22 Mar '15

pz pull from http://git.ipfire.org/?p=people/glotzi/ipfire-2.x.git;a=commit;h=04ad584f35…

2 1

Traffic Accounting based on iptables
by Benjamin Schweikert 18 Mar '15

18 Mar '15

Dear all, I am thinking about different options to do a traffic accounting for each ip adress in my network consisting of green, blue and orange. The next try shall be a traffic accounting based on iptables. That is what I want to try: iptables -N INET_OUT iptables -N INET_IN iptables -I FORWARD -j INET_IN iptables -I FORWARD -j INET_OUT iptables -I INET_OUT -s "$ip" iptables -I INET_IN -d "$ip" My question is, what is the correct "Forward" chain which directs the whole (external) traffic to device red0? Best regards Ben

1 0

Testing GeoIP based firewall
by Blago Culjak 17 Mar '15

17 Mar '15

Hello, been testing whole day, but I'm having some major trouble while doing so. 1. After enabling GeoIP, don't even select any country, apply rules, I can't connect to WUI or SSH from RED. At what position are GeoIP rules? Are they overriding rules made by Incoming Firewall Access? 2. Can the quick rules made in Firewall -> GeoIP block be visible in Firewall->Firewall Rules, so we can get a hang of it? 3. Seems that ping is working from RED, so you do not block ICMP in quick rules made in Firewall -> GeoIP?

2 3

merge request for #10671
by IT Superhack 11 Mar '15

11 Mar '15

Dear IPFire-Developers, could you please integrate the attachment (patched global.conf) from the bug #10671 into IPFire? Thanks in advance, Timmothy Wilson

2 1

Re: Guardian 2.0 Testversion 011
by Stefan Schantl 05 Mar '15

05 Mar '15

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.ph… > > 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(a)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=19d6abcce5… http://git.ipfire.org/?p=people/stevee/ipfire-2.x.git;a=commit;h=0a6c3cb896… http://git.ipfire.org/?p=people/stevee/ipfire-2.x.git;a=commit;h=82208c83c7… > > * 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=a58bd67486… > > * 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=9d44c0d995… > > Best regards, > > -Stefan > > > >

1 0

logrotate
by Olaf Albrecht 05 Mar '15

05 Mar '15

Is it true that IPFire has a small logrotate bug? I have seen that my /var/log/messages has a size of 1,3 GB. When I start logrotate manually it says that the /etc/logrotate.d is missing. After creating that folder logrotate is starting without problems. Maybe I deleted that folder but I don't think so. Olaf Ferdinand Lusch GmbH & Co. KG Im Brocke 11 33649 Bielefeld Tel: +49 (521) 9417 0 Fax: +49 (521) 9417 228 info(a)lusch.de www.lusch.de Zweigwerk Buke: Industriestrasse 21 33184 Altenbeken-Buke Tel: +49 (5255) 98890 0 Fax: +49 (5255) 98890 50 Kommanditgesellschaft, Sitz u. Reg.-Ger. Bielefeld HRA 10273 Komplementaer: LUBRA Verwaltungsgesellschaft mbH, Sitz u. Reg.-Ger. Bielefeld HRB 30 488 Geschaeftsfuehrer: Katharina Lusch, Wolfgang Exner

2 1

merge request owncloud 7.03
by Daniel Weismüller 04 Mar '15

04 Mar '15

Hello Michael Could you please megre my branch owncloud-7.03 Thanks for that ;-) - Daniel

2 3

SHA1/MD5 in IPFire
by IT Superhack 03 Mar '15

03 Mar '15

Hello Development-List, hi, it's me again. In the past, some ciphers and algorithms were broken, such as MD5, RC4, DES and recently SHA1. Because those are either weak or insecure, most experts recommend to avoid them. But nothing big happend, near all websites still support RC4 or MD5, some certificates are still signed with SHA1 and so on. Even in IPFire those are sill used in several categories: 1. On downloads.ipfire.org, the checksums use SHA1. 2. Until 2.17, the HTTPS certificate IPFire generated was signed with SHA1. During the last ten minutes, I tried to set up an IPSec connection and noticed that some of the used cryptographic technologies are weak/insecure, such as: 1. The root certificate is RSA-2048 (RSA-4096 is better) and is signed with SHA1. 2. Road-Warrior-Certificates are RSA-1024 (insecure) and signed with MD5, which is also insecure. 3. SHA1 and MD5 are allowed for authenticating (see: advanced settings). Since those endanger secure communication, it would be nice if MD5 & co. could be avoided in IPFire. Many thanks in advance, Timmothy Wilson P.S.: The Bug ID is #10763

2 1

Guardian 2.0 Testversion 011
by Matthias Fischer 02 Mar '15

02 Mar '15

Hi, Feedback: As far I can see, no problems here. Great! ;-) I did several - personal - enhancements, perhaps you could think of it: I altered the Logs menu, showing '/var/log/guardian/guardian.log', with a *very* simple '/srv/web/ipfire/cgi-bin/logs.cgi/guardian_log.dat', and a new entry in '/var/ipfire/menu.d/70-log.menu': ... $sublogs->{'51.guardian'} = {'caption' => $Lang::tr{'guardian log'}, 'uri' => '/cgi-bin/logs.cgi/guardian_log.dat', 'title' => "$Lang::tr{'guardian log'}", 'enabled' => 1 }; ... I did the same some time ago with 'squid', so I thought of no problems and it works. The underlying CGI is *really* simple, no comfort, but its doing its job. Second, I compiled 'guardianctrl.c' to REJECT, not to DROP and its working either. Feature request: User switch on GUI, to switch between REJECT and DROP. ;-) Regards Matthias -- tails, linux, USB, CD, secure desktop, IRC, truecrypt, tor, onion

2 3

Guardian 2.0 - Testing - 2.0-011
by Jim Becher 02 Mar '15

02 Mar '15

Hi all, Great work on adding Guardian. Here is my feedback on testing. System usage / process seems to be running well with not that much overhead. In looking at the log vs the web interface I have some feedback regarding web interface: Possible Bug: I was unable to delete a host from the web interface - screen cast is here showing the last Host not being removed when selecting the delete option: http://screencast.com/t/ccl8eGNlxcj Suggestion: Would it be valuable to add the Date / time stamp in addition to the IP address. Question: Will the list of blocked IP address paginate after a specific number Have been running for 24 hours and hit near 19 blocked hosts. This feature may already be there but I may not have enough blocked hosts. Running Guardian 2.0-011 and IPFire 2.17 (i586) - Core Update 87 Thanks Jim

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

Development March 2015