Schnellnavigation: Go to start of page | Go to posts | Go to navigation
In a non-dsitributed architecture (your indexer is also the host receiving the events), you might want to keep Splunk running as a non-privilegied user but still be still receive syslog from remote hosts. You have (mainly) two solutions:
iptables -A PREROUTING -t nat -p udp –dport 514 -j REDIRECT –to-port 1514
iptables -A PREROUTING -t nat -p tcp –dport 514 -j REDIRECT –to-port 1514
Splunk 4.3 is out for a few days, and this new release contains some nice improvements:
And some more new stuff…
Arcsight recently presented their new version of the Logger. Some of the new features are:
The main log management solutions available on the market have different features, and different way of handling the data. This article focus on how ArcSight Logger, Loglogic and Splunk are handling archives, and what are their integrity functionalities.
How the different log management solutions are handling the data archiving ?
ArcSight allocates data by one gigabyte block on the Logger. In case of very low rate of events in a specific data group, the archive will still have a one gigabyte size, even if the original events are less than on gigabyte. If archive are scheduled, this can only by done day per day, for the previous day. However, archiving data does not means that the data is removed from the Logger: instead, the data is marked as ready for being overwritten, based on the retention settings.
Once archived (and overwritten), the data can still be included in the searches if “reloaded” (it is just accessed from the storage location, not copied back locally to the Logger and index is not available anymore).
Read the complete article »
The Juniper VPN SSL solution (Secure Access) is undoubtedly the most advanced of the market today, and I’ve always been satisfied with it. However, a few days ago, one of my customers show me his VPN SSL, for which he enabled the “virtual keyboard“.
I’ve never been really convinced about the security level added by virtual keyboards. Even if it prevents key loggers from capturing sensitive credentials, it is more easy for someone to see the code clicked with a mouse than with a keyboard. And more important, if a malicious software is able to intercept keystrokes, he can take screen-shot when the user is clicking, or sniff the password inside the browser before it is sent to the server (for the worst virtual keyboards ones).
In this case, the Javascript based virtual keyboard just enters the values in the password input form, which is read-only.
So, I’ve wrote a simple Greasemonkey script that modifies the Juniper web pages and allows to enter directly the password in the form instead of using this annoying keyboard: JuniperVpnSslRemoveVirtualKeyboard.
Read the complete article »
As reported by Kaspersky, most browsers (and proxies ?) supports URL with IP addresses in format others than decimal, which can be a good way to bypass network security:
The previous URL are working with both Firefox and Chrome.
You will find below a patch for WAFW00F (a tool used to fingerprint Web Application Firewall) that allows to identify Imperva SecureSphere WAF.
On characteristic of Imperva is to respond with an HTTP/1.0 message, even if the request is made in HTTP/1.1. The other WAF I’ve worked with do not have the same behaviour (but there may be a few false positive).
This was tested with Imperva 6.2 and 7.0 in transparent bridge mode.
The whole wafw00f.py modified can be found here (or an the project issue list) and the diff is below.
Read the complete article »
If the previous version of VMWare Converter for Linux was quite buggy (I had errors when trying to convert virtual machines stored on NFS or mount via SSH/Fuse), the 4.0.1 works well: I installed it on a VM running Ubuntu 9.04, and manage to convert (windows) VM without any problem.
Read the complete article »
So you your boss asked you to secure his new strategic web application which is part of his plan to conquer the world. But that damn developers are used to think that their work is finish when it just works, and debugging their whole code is simply not an option. Here’s the solution: use a web application firewall like ModSecurity2.
ModSecurity can be embedded as a module on your webserver, or you can set up an Apache based reverse web proxy with ModSecurity protecting multiple web sites, without wondering which kind of server they are running.
It can be used in different ways: either to intercept know exploits or suspicious activities, or to simply only allow access to your application web page, parameters, and the kind of characters the value’s parameters are supposed to be… But the last step might require a lot of work, so you may want to combine generic rules with a few rules dedicated to forbid the use of the holes you’ve just found on your brand new web site.
A set of “generic rules” is provided with ModSecurity: the Core Rules. For optimization reasons, the regular expressions (rules are based on regexp) are mixed in a small number of rules and are almost not understandable for most of them. The script used for this task is not yet released, but should be in a “near feature” according to Breach. Update: Yes, it was released here !
You might also pick rules from alternative sources, like gotroot.com.
If you install rules from the tarball found on the website, be sure to remove write permissions on them for everybody (yes, default permissions are -rw-rw-rw- !!!).
Now, let’s try to make a few rules:
You might first want to whitelist an IP address. The following rule can be added to your own file on your core rules directory, or better (especially if you have multiple virtual host), on the virtual host config file:
<IfModule mod_security2.c>SecRule REMOTE_ADDR "^192.168.1.100$" phase:1,nolog,allow,ctl:ruleEngine=DetectionOnly</IfModule>