Country origin: Identified country origin of this host (Unknown of unidentified)

Last destination IP: Last event destination IP

Last protocol: Last event protocol

Last source port: Last event source port

Last destination port: Last event destination port

Last service: Last event network service name (Unknown if non IANA reserved port)

Reporting server: Last event reporting server for this host

6. Last connections denied stats:

Major stats about last connection denied in Realtime 24 hours time window mode:

Client IP: IP of the last denied connection

Event Time: Date and hour of last connection denied

Interface: Logical interface name reported by Iptables

Country origin: Identified country origin of this host (Unknown of unidentified)

Destination IP: Destination IP of this event

Protocol: Protocol reported of this event

Source port: Source connection port

Destination port: Destination connection port

Service: Network service name (Unknown if non IANA reserved port)

Reporting server: Reporting server for this connection

Iptables Activity Overview Dashboard (Realtime/Timerange):

Dashboard details

1. Timerange overview:

Span Time value:

The span time value is dynamically defined using a Macro to get the best chart granularity, this is being used in chart command using "span=$Span$"

In Realtime mode, this is statically defined to 1 minute, in Timerange mode the range value can be automatically set from 5 minutes to several hours depending of the time range width.

Begin Time Analysis: Date and hour of the begining of the selected time range

End Time Analysis: Date and hour ot the end of the selected time range

2. Activity Summary:

This section presents various stats about more important informations of Iptables activity:

Number of connections denied: Total number of connections denied within the time range

Top offenser: Client IP with the highest number of connections denied

Denied for Top offenser: Total number of connections denied for the Top offenser host

Country origin for Top Offenser: Country origin for this host, Unknown if can't be identified

Top Protocol: Protocol most often attempted within the selected time range

Top Source port: Source port most often attempted

Top Destination port: Destination port most often attempted

Top Identified network service: Network service most often attempted

Top Destination IP: Destination IP most often reported

Top Country origin: Identified country most often reported

Top Reporting Host: Iptables host with the highest number of denied connections

3. Alert trend chart and peak load identification:

This sections shows:

- Alert trend by Iptables reporting host:

For Realtime, the span value (eg. span=) is statically defined in the XML hard code

For Timerange, the span value is dynamically defined by a macro (see Macro.conf) depending on the width of the time range itself, the goal here is to get the better chart granularity possible

- Peak load identification:

We identify here the peak load within the selected time range, how many connections were refused (drop and deny) and when.

Then this is being represented inside inside a gauge where the range (green, yellow, red range) will dynamically be defnied by a subsearch inside the global query.

These gauge range values will depend on the arithmetical mean result of denied connections for past 48 hours, the goal is to represent a potentil abnormal Iptables activity. (eg. being under attack)

The analysis result here should always equivalent between the chart and peak load. (both are cumulated results for all reporting hosts)

4. Last Events:

Last 100 events represented by major type of data, click on show result to export them or change the request.

4. TOP Source IP and Country Origin:

- Top 10 pie chart and Top 100 data client IP with country origin identification

- Top 10 pie chart and Top 100 country origin of denied connections

5. TOP Network Services and Destination Port:

Data is being represented by:

- Top 10 pie chart and Top 100 data Network Services attempted:

Network services are identified whenever they are destination port known as reserved (for most of theme IANA ports reserved) using a csv input lookup.

See props.conf and transform.conf, Networking services are automatically defined for any event under the field called "Service", when the destination port is not known as reserved or standard port, the service name will defined under the value "Unknown".

- Top 10 pie chart and Top 100 destination port attempted with Network Service name identification

Please note that this application intends to analyse denied or dropped connections, any event containing following pattern will not be analysed by Splunk:

- "ACCEPT" OR "Accept" OR "ALLOW" OR "Allow"

Even if indexed by Splunk, if an event contains one of these patterns, it will be expected to be tagged as an accepted connection. If you need to adapt this general configuration to your own situation, please create a local Macro.conf containing the macro customized to your needs:

If you need custom settings, create your local Macro.conf:

$SPLUNK_HOME/etc/apps/iptables/local/Macro.conf:

### Iptables sourcetype

[iptables_src]

definition = sourcetype="iptables_source" NOT "ACCEPT" OR "Accept" OR "ALLOW" OR "Allow"

iseval = 0

Save your local/Macro.conf file and restart Splunk.

Installation and configuration will be done in a few steps:

SUMMARY OF STEPS:

Iptables / Syslog Configurations steps:

1. Set each Iptables reporting host to log events using SYSLOG

2. Configure SYSLOG to trap these events and put them in a dedicated log file of your choice

7. Open Splunk for Iptables and observe the magical power of Splunk ^^

Part 1 : Configuration of Iptables and Syslog1. Set each Iptables reporting host to log dropped or rejected packetsConfiguring Iptables is far away from the scope of this guide, the only thing required is to configure Iptables to log inbound dropped and rejected packets. (by default, Iptables logs its events to Syslog)Iptables shall use a prefix pattern to log, this will be used first to manually recognize Iptables events in main syslog file, and then it shall be used to catched these events into a dedicated log file. (not obligatory but recommended)Part 2 : Configuration of Syslog

In 2 steps:

- if you want to manage different Iptables reporting hosts servers from Splunk, then read the Multiple Iptables client configuration note- If you just have one host to manage (Iptables and Splunk are installed in the same host), then just follow the common configuration sectionMULTIPLE IPTABLES CLIENT CONFIGURATION NOTE: Remote and centralized Syslog configuration:Configuring Syslog to send events from a Syslog host to a a remote Syslog server is out of the scope of this guide.Therefore, if you want to send Iptables events of different hosts, you can choose between different solutions, as:- Sending events using Syslog to a remote centralized Syslog- Sending events from local log file using Splunk forwarder module- Others (homemade scripts...)I would recommend using "Rsyslog" (Enhanced Syslog version that comes with many modern Linux OS) to achieve this, which is indeed easy enough.Here is in 2 steps a quick syslog centralized configuration: (remember to restart rsyslog after each modification)1. In client rsyslog host, modify "/etc/rsyslog.conf" and add a section to send any events to your Syslog server: (adapt the example IP)

*.* @192.168.1.254:514

2. In syslog server configuration, create a configuration file that will catch any remote client Syslog events and put them into a dedicated per host log file:Ensure your configuration name will be read after the iptables syslog config file. (see above, use numbered prefix)Create "/etc/rsyslog.d/10-remotehosts.conf" with the following content: (Note: The iptables config we will create after will be called 08 to be read before this and intercept messages

Finally, achieve the rest to the configuration above to be able to intercept remote Syslog client events containing the iptables event tag and put them in a dedicated log file for all hosts.COMMON CONFIGURATION for Single and Multiple Iptables installations: 1. Set Syslog to trap iptables events to a dedicated logfile

This configuration part will depend on your system and needs, i recommend the use of "rsyslog"The goal is to configure syslog to trap any event containing a key word set as the iptables prefix into a dedicated log fileFor example, with UFW you will have "[UFW BLOCK]" as a prefix.If you set manually configure Iptables, just choose and report your log prefix. (eg. example "DROP(wan)"In Debian/Ubuntu systems for example, create an rsyslog configuration file, example:Create "/etc/rsyslog.d/08-iptables.conf" with the following content: (adapt with your log prefix)

:msg, contains, "DROP(wan)" /var/log/iptables.log
& ~

Restart rsyslog to take effect.Part 3 : Configuration of Splunk (the easy part!)Configure input file using Splunk Manager interface:Go to "manager", "Data Input", and configure MANUALLY a new input file pointing to your iptables log file.With settings by part configuration:Host:You can let the default settings, it does not mind as we don't use it to recognize the iptables reporting server.Source type:- Set the source Type: Manual- Source type: iptables_sourceIndex:- Set the destination Index: iptables_index

Configure input manually:

You can also add your input file manually, create a new file in "${APP_HOME}/local/inputs.conf" with the following content: (adapt to your case)

This is absolutely optional, but you could think about getting a qualified domain name to access to your home network. (a domain costs very few per year, and your can dynamically associate it with your public IP)

In many cases, when you connect from secure places (such as your company site), trying to access to a web site using its public IP will be prohibited by internals web proxies and firewalls.

By using a fqdn to associate your public IP to a real Internal domain name, your site is as official as any Internet company web site :-)

As an alternative to buy your own domain name, you can also use dynamic free domain name services such as no-ip.org, but most of company proxy will also block them.

And finally, this is just clean and beautiful ^^

In this post, i will assume for the example purpose that your domaine name is "myowndomain.com". (still the fqdn is optional)

Step 2: Manage your SSL certificate

Off course, we will want to secure our Web traffic using an SSL certificate, there is 2 ways to achieve this:

1. Generating an "auto-signed" SSL certificate

You can very easily generate an auto-signed SSL certificate, you will have exactly the same security and encrypting level than any official certificate but this certificate won't be officially recognized over the Internet.

That means that when connecting to your site, your Web browser will warn you about the impossibility to guaranty your security connecting to this site, and you have to accept this.

I personally prefer having an official SSL certificate :-)

2. Buy and generate an Officially signed SSL certificate

You can also buy an official SSL certificate for very few, in this case your browser will automatically recognize your certificate as valid and you won't get any warn.

There is some places where you can get a free official SSL certificate for personal use. (look for "startssl")

Friday, January 18, 2013

The Goal:

With Observium associated with Unix agent check_mk the goal will be to monitor any available indicator (CPU, Mem, Traffic interface...) and most of all, specific Raspberry Pi main indicators dynamically allocated when running Overclocked with Turbo mode:

I recommend to install Observium and Mysql into a central server which will request our Rpi to generate graphs and so on.

We will use an additional agent called "check_mk" to request the Rpi, system load generated by snmp and Unix agent are very limited which is very great, the Rpi is a small power device and you don't want monitoring to generate high system load!

One time you have Observium up and running, follow this guide to integrate any Raspberry Pi you want to monitor :-)