Continuing the topic about perimeter services. As I mentioned earlier, I don’t think that the external perimeter services should be considered as a fully functional replacement for custom Vulnerability Management processes. I would rather see their results as an additional feed showing the problems your current VM process has. Recently I tested the Detectify’s Asset Inventory (Monitoring) solution, which provides such feed by automatically detecting the issues with your second, third (and more) leveled domains and related web services. Here's what they provide, and my basic API usage examples.

I don’t know if you heard, but we have a huge IT scandal here in Russia. In a nutshell: 15 years ago, one smart guy worked as a system administrator in a large Russian Internet company (kind of Russian Yahoo) and in his spare time he was developing an open source web server. Now this web server is the most widely used in the world, and the company behind it, created by this guy 8 years ago, was recently bought by F5 Networks for $670 million. Everything looked fine until yesterday, when police raided the office of Nginx Inc. in Moscow, and this guy sysadmin/founder/developer Igor Sysoev was interrogated and can now spend 6 years in prison. This happened because the company where he worked for 10 years (Nov 2000 – May 2011), Rambler, somehow claims the rights to #nginx. Despite the fact that Sysoev worked on it in his spare time, the project is open source and he was a system administrator there, not a software developer. How do you like it?

So why am I so angry about this situation and can't ignore it. Well, I never met Igor and didn't even use Nginx a lot. Of course, Nginx is one of the most successful open source projects created in Russia (the only comparable is Postgres). But it is much more than that!

You know, there is not much joy in the life of an IT professional. And one of the greatest pleasures is to KNOW that after 8-9-10 hours of full time work, you can work on your OWN pet project and DREAM that someday it can develop into something valuable. What Rambler is doing now is an attack on what is sacred to many IT professionals: midnight coding with red eyes, the right to do whatever you want with your own creation (even release it for free under BSD license), the dream about a better life.

Different countries have different laws regulating the intellectual property of things created by man in his free time. Thanks to the Russian Labor Code, developers have all the intellectual rights in such situations by default. But if this particular case will show that it does not mean anything, and the former employer can claim the rights to any of your further successful projects (most of startupers had once worked full time), this will really cause enormous damage to the country. This will kill people’s passion for creating something new, this will make investment in Russian companies much more risky, and emigration among qualified IT professionals will certainly increase.

So please support Nginx, this is important. I see the following actions that everyone can do quite safely and easily:

- spread the message, show your attitude;
- tell your PR team that now is a good time to demonstrate that YOUR company is friendly to open source and developers, and not at all like Rambler;
- tell your HR/recruiting team that now is a good time to attract good technical experts from #Rambler;
- if you work in Rambler and don't like the situation, perhaps you may consider changing the job (if you are a security guy, contact me if you need help with this) or at least ask to increase your salary. 😉

The idea is to show that such actions are not only very harmful for PR, but also destroy the HR brand.

A small update on #Zbrunk. First of all, I created a new API call that returns a list of object types in the database and number of this types for a certain period of time. Without it, debugging was rather inconvenient.

$ curl -k https://127.0.0.1:8088/services/searcher -d '{"get_types":"True", "search": {"time":{"from":"1471613579","to":"1471613580"}}, "output_mode": "json", "max_count":"10000000", "auth_token":"8DEE8A67-7700-4BA7-8CBF-4B917CE23512"}'

{"results": ["test_event"], "results_count": 1, "all_results_count": 0, "text": "Types found", "code": 0}

I also added some examples of working with Zbrunk http API from #python3. Rewriting them from pure curl was not so trivial. 😅 Flask is rather moody, so I had to abandon the idea of making requests exactly the same as in Splunk. 😓 But the differences are cosmetic. It is now assumed that events will be passed to collector in valid json (not as a file with json events separated by '\n'). I also send all params of requests as json, not data. But for the compatibility reasons previous curl examples will also work. 😉

Lol, #Rapid7 released an album with short infosec versions of Christmas songs. It's even better than last year. My favourite are:

"You better control
You better comply
You better safeguard
We're telling you why
Auditors are coming to town"

and

"Do you want to build a plugin?
C'mon, let's code away
Old apps won't cut it anymore
They're such a bore
Let's automate today"

😁 #haxmas
https://www.rapid7.com/info/haxmas

The problem exists with regular expressions in this file:

# ls -al /opt/splunk/etc/datetime.xml
-r--r--r--. 1 splunk splunk 8178 Jan 25 2018 /opt/splunk/etc/datetime.xml

You can check that the file is buggy like this (based on the changes mentioned in the article):

# cat /opt/splunk/etc/datetime.xml | grep "\\d|\[901\]"
<text><![CDATA[(20\d\d|19\d\d|[901]\d(?!\d))]]></text>

To fix this, you can upgrade Splunk to the latest version, but IMHO it's safer and easierto update only datetime.xml. Take datetime.zip file and upload it to the server:

$ scp datetime.zip user@splunk:/home/user/datetime.zip

Replace the file on the server:

# unzip datetime.zip 
Archive:  datetime.zip
  inflating: cfg/datetime.xml 
# cp /home/user/cfg/datetime.xml /opt/splunk/etc/datetime.xml

The output of

# cat /opt/splunk/etc/datetime.xml | grep "\\d|\[901\]"

should be empty.

Don't forget to restart the server:
# systemctl stop splunk.service
# systemctl start splunk.service