Changelog for 8.3.5 (v8-devel)

Version 8.3.5 [v8-devel] 2014-08-05omprog:

  • emit error message via syslog() if loading binary fails
    This happens after forking, so omprog has no longer access to rsyslog’s regular error reporting functions. Previously, this meant any error message was lost. Now it is emitted via regular syslog (which may end up in a different instance, if multiple instances run…)
  • couple of patches imported from v7-stable (7.6.4)

Masking data in logs and RSYSLOG

As a mobile payments company, we at SumUp are obligated to follow many industry regulations, one of them being PCI DSS. Restricting access to credit card numbers is a clear need and this implies ensuring they are not part of the logs which are used for various purposes and have bigger audience, not restricted to the authorized list of employees who have access to sensitive data.

PAN or primary account number is used by card issuers as card number which is unique and brings information about the issuer and also in majority of the cases can be validated with Luhn algorithm. This is the number on you credit or debit card and it should be kept secret by us.

One widely used approach is to have quality assurance of the logs all over the development and deployment cycle. This is a needed and valuable attitude however first it takes a lot of human resources and second it is kind of reactive approach in terms of dealing with production systems. So we want something better, something mandatory which can leave us on the safe side if we got human error somewhere in the chain. This is very important in our case where we need to put logging management system out of PCI scope. From four ways which are offered by PCI DSS, Requirement 3.4:

3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs)
by using any of the following approaches:

  •  One-way hashes based on strong cryptography, (hash must be of the entire PAN).
  • Truncation (hashing cannot be used to replace the truncated segment of PAN).
  •  Index tokens and pads (pads must be securely stored).
  • Strong cryptography with associated key-management processes and procedures.

our natural choice for log messages is truncation. We want to truncate PAN data if it’s present in the logs for some reason in example in situation when temporary the log level is increased for investigation. While we have centralized log storage which is in PCI scope we want to transfer the logs  in real-time in some external location, accessible for developers and BI where they can find and use the information they need.

Since we are using rsyslog for logging daemon our next step was to get in touch with Adiscon – the company behind this brilliant piece of software. They were very interested when I explained the idea and the work started. A little bit later we got new message modification module called mmexternal. It sends the message to some external binary and expects an input. More on the implementation here.

Let me give you an example with a code snippet from rsyslog config and an example of python script which is doing a regular expression to catch and replace i.e. VISA, MasterCard and AMEX cards. You may find a lot of useful regular expressions here:

rsyslog.conf

module(load=”mmexternal”)
action(type=”mmexternal”
binary=”/usr/local/bin/external_python_cards_replace.py”
interface.input=”msg” )

external_python_cards_replace.py

Please note that the above snippets are only examples. With using regular expressions you are going to have many false positives but in general this won’t be an issue. Also note that you can modify completely different parts of the logs and also you are not limited to any language or technique for doing so.

With the following example we have negligible resource consumption on the server where log modification is done. Synthetic test which not claim for accuracy shows around 5% CPU usage on single core 2.5GHz virtual CPU for 100 messages/s.

This is how we are doing it. All comments and suggestions are welcome!

rsyslog 8.3.4 (v8-devel) released

We have just released 8.3.4 of the v8-devel branch.

This is a somewhat unexpected new 8.3 devel version: thanks to some sponsor, we could work on providing better parsers for Cisco IOS devices as well as some improvements to the general date parser. As we want to integrate this into 8.4, we have decided to release another 8.3 version. Please note that 8.4 stable is still immanent. This version also includes a number of bug fixes.

ChangeLog:

http://www.rsyslog.com/changelog-for-8-3-4-v8-devel/

Download:

http://www.rsyslog.com/download-v8-devel/

As always, feedback is appreciated.

Best regards,
Florian Riedl

Changelog for 8.3.4 (v8-devel)

Version 8.3.4 [v8-devel] 2014-07-11

  • new pmciscoios parser supporting various Cisco IOS formats
  • RFC3164 timestamp parser now accepts timezones and subsecond resolution
    … at least for some common formats and where we could do so without running risk of breaking proper formats (or introducing regressions)
  • new parser config object — permits to define custom parser definitions
  • new tzinfo config object — permits to define time zone offsets
    This is a utility object that currently is being used by some parsers.
  • bugfix: mishandling of input modules not supporting new input instances
    If they did not support this, accidently the output module part of the module union was written, leading to unpredictable results. Note: all core modules do support this interface, but some contributed or very old ones do not.
  • bugfix: double-free when ruleset() parser parameters were used
    While unlikely, this could cause stability issues even after the config phase.

Upcoming new v8-stable

A new rsyslog v8-stable is coming up soon. It will not just be the next iteration of 8.2, instead it will be a new feature release based on the current 8.3 devel. So be prepared to welcome 8.4. Frequent followers may wonder why 8.4 is ready. Originally, we planned to release it after the summer break. The reason is simple: its ready to come up, albeit with a little less functionality than originally anticipated.

We were (and are) busy working on the rsyslog Windows Agent, which gets a fresh brush up of its engine. It’ll be even better (and faster) as before, but that also meant that we had less time to spent on Linux rsyslog. It turned out that we are primarily doing maintenance and bug fixing on v8-devel the past couple of weeks, just as it normally happens before a new stable branch comes up. So the code has matured. At the same time, we get very good feedback for 8.2 in general, which really makes us believe that v8 fully replaces v7. The bad news is that 8.3 is currently missing the promised non-C support for input modules. However, it’s easy to do this via the regular syslog() API, so this doesn’t look like it’s overly important. In short, this means 8.3 is ready for prime time and we won’t defer it for longer than really required. Just think about how many folks have asked about non-C actions or the ability to clear out dynafiles after an inactivity timeout.

We released 8.3.3 last week, and it is scheduled to be the last 8.3 version (if nothing really important comes up). We are still working on some rough edges, which we hopefully can smoothen within the next couple of days. If possible, we’ll move them into 8.4.0. We hope to be able to release 8.4.0 next week or the week thereafter, so we get a shiny new stable before the summer break.

Also, we will finally officially drop community development support for v7. This will probably even happen this week. As usual, that doesn’t mean v7 is put into the waste bin. We’ll continue to apply patches to it, and we expect that distros will carry it for a while. Even new v7 releases may happen from time to time. But it’s no longer a version that you can expect to receive community support on (of course, rsyslog support contract customers will also be supported on outdated versions, so relax if that is you – but that’s a different story).

We hope you are looking forward to 8.4. If you can, please also help with testing 8.3.3.

rsyslog 8.3.3 (v8-devel) released

We have just released 8.3.3 of the v8-devel branch.

This provides the capability to automatically close files (including dynafiles) after some inactivity timeout. It also makes some of the more exotic modules build under v8, which now supports the same set of output modules as v7 did.

ChangeLog:

http://www.rsyslog.com/changelog-for-8-3-3-v8-devel/

Download:

http://www.rsyslog.com/download-v8-devel/

As always, feedback is appreciated.

Best regards,
Florian Riedl

Changelog for 8.3.3 (v8-devel)

Version 8.3.3 [v8-devel] 2014-05-26
  • unify input object naming
    imudp now supports “name” paramter, as other inputs do. “inputname” has been deprecated, but can still be used. Same applies to “appendport” subparamter”. Thanks to “Nick Syslog” for the suggestion.
  • made the missing (contributed) modules build under v8 [import from 8.2.2]
    Modules:

    • * mmrfc5424addhmac
    •   * omrabbitmq
    •   * omgssapi
    •   * omhdfs
    •   * omzmq3
  • added a cleanup process (janitor); permits to close omfile files after a timeout
  • make omgssapi build under v8.3 [import vom v8.2]
    note that we could do this to the stable, because there is NO regression chance at all: only omgssapi was changed, and this module did NOT work previously.
  • removed obsolete –disable-fsstnd configure option
    Thanks to Thomas D. for alerting us.
    Closes: https://github.com/rsyslog/rsyslog/issues/72

RSyslog Windows Agent 2.3 Released

Adiscon is proud to announce the 2.3 release of RSyslog Windows Agent.

This is the maintenance release and contains mainly bugfixes.

Most notably, this version includes OpenSSL library 1.0.1h. This fixes all security issues from the OpenSSL Security Advisory (2014-06-05).

Detailed information can be found in the version history below.

Build-IDs: Service 2.3.119, Client 2.3.145

Features

  • Updated embedded OpenSSL library to 1.0.1h

Bugfixes

  • SETP Protocoll: Fixed a bug in zlib decompression.
  • RELP Action: The RELP Action failed when no other network related Actions/services was configured.
  • Configuration Client: Fixed minor bugs in the configuration client.

 

Version 2.3 is a free download. Customers with existing 1.x keys can contact our Sales department for upgrade prices. If you have a valid Upgrade Insurance ID, you can request a free new key by sending your Upgrade Insurance ID to sales@adiscon.com. Please note that the download enables the free 30-day trial version if used without a key – so you can right now go ahead and evaluate it.

rsyslog 8.2.2 (v8-stable) released

We have just released 8.2.2 of the v8-stable branch.

This release allows to build the missing (contributed) modules under v8. Please note, that most of these modules did not yet receive real testing as we don’t have the necessary environments. We depend on users submitting error reports and helping out to iron out any issues that may arise.

Additionaly, the separated documentation is available as a tarball download on the download page.

ChangeLog:

http://www.rsyslog.com/changelog-for-8-2-2-v8-stable/

Download:

http://www.rsyslog.com/downloads/download-v8-stable/

As always, feedback is appreciated.

Best regards,
Florian Riedl

Changelog for 8.2.2 (v8-stable)

Version 8.2.2 [v8-stable] 2014-06-02

  • made the missing (contributed) modules build under v8
    Note that we could do this to the stable, because there is NO regression chance at all: only the modules themselves were changed, and they did NOT work at all previously. Please also note that most of these modules did not yet receive real testing. As we don’t have the necessary environments (easily enough available), we depend on users submitting error reports and helping to iron out any issues that may arise.
    Modules:

    • mmrfc5424addhmac
    • omrabbitmq
    • omgssapi
    • omhdfs
    • omzmq3
Scroll to top