Updated openSUSE Package: lynis 1.2.9

I’m pleased to announce a new Version of our Package lynis. Now we have the Version 1.2.9. The Package is reachable in the openSUSE:Factory:Contrib Repository. This release adds several fixes and improvements for Squid, a few new tests, and improved logging and reporting.

Updated Package for openSUSE: bleachbit 0.7.2

I’m pleased to announce my updated bleachbit Package for openSUSE.

What’s new?

The following changes have been made since 0.7.1:

  • Fix deleting Firefox version 3 passwords.
  • Add new menu option to show system information useful for reporting bugs. Click Help – System Information.
  • Specific to Linux
    • Clean Konqueror cache, history, and cookies.
    • Fix bug launching BleachBit as Administrator on Ubuntu and Debian.
    • Improve the completion notification: do not show if the BleachBit application window is in focus, and if it is not, automatically remove the notification after 10 seconds.

This Package is committed to openSUSE:Factory:Contrib Repo.

Updated Package for openSUSE: rkhunter 1.3.6

I’m pleased to announce the new rkhunter Package for openSUSE.

What’s new in this package? The Project says:

This release offers more ease of use by adding more end-user configuration options and aids detection by adding and improving rootkit and malware checks.

The change log lists 29 additions including 9 configuration options and details for 12 rootkits, 29 changes including improvements for 15 rootkit checks and 22 bugfixes. Naming a few:

  • New IGNORE_PRELINK_DEP_ERR configuration option in case of persistent prelink dependency errors.
  • New USER_FILEPROP_FILES_DIRS configuration option to add files and directories to the file properties check.
  • New COPY_LOG_ON_ERROR configuration option to copy the log file if any errors or warnings have occurred.
  • New WEBCMD configuration option to specify the command used to download data file updates from the Internet.
  • Rkhunter will look for configuration options in the main configuration file, and then in the local configuration file if it exists.
  • New SHARED_LIB_WHITELIST configuration option for whitelisting preloaded shared libraries.
  • New WARN_ON_OS_CHANGE configuration option. If unset then no warnings will be shown.
  • New UPDT_ON_OS_CHANGE configuration option. If set and the O/S has changed then rkhunter will automatically update properties (‚rkhunter –propupd‘).
  • Added support for hash functions SHA224, SHA256, SHA384 and SHA512 using CPAN perl modules Digest-SHA-PurePerl or SHA256.
  • New UPDATE_LANG configuration option.
  • New ALLOWPROMISCIF configuration option.
  • New PKGMGR_NO_VRFY configuration option for fine-grained package manager verification process control.
  • Rootkit checks added: Adore Rootkit (aka strings.o aka Dextenea) cb, CX, Fu, iLLogiC, ld-linuxv.so.1, ‚Spanish‘, trNkit, Xzibit, ZK.
  • Updated rootkit / malware checks: Ambient (ark), beX2, BOBkit, Dica-kit, Dreams, Enye LKM, evil strings test, Fleakit, FreeBSD, Phalanx2, SHV4, Universal (URK).

This Package is now available in openSUSE:Factory:Contrib.

Cyber Security Tip ST04-014: Avoiding Social Engineering and Phishing Attacks

Cyber Security Tip ST04-014
Avoiding Social Engineering and Phishing Attacks

Do not give sensitive information to anyone unless you are sure that they
are indeed who they claim to be and that they should have access to the

What is a social engineering attack?

In a social engineering attack, an attacker uses human interaction (social
skills) to obtain or compromise information about an organization or its
computer systems. An attacker may seem unassuming and respectable, possibly
claiming  to  be a new employee, repair person, or researcher and even
offering credentials to support that identity. However, by asking questions,
he or she may be able to piece together enough information to infiltrate an
organization’s  network.  If  an attacker is not able to gather enough
information from one source, he or she may contact another source within the
same organization and rely on the information from the first source to add
to his or her credibility.

What is a phishing attack?

Phishing is a form of social engineering. Phishing attacks use email or
malicious  websites  to  solicit  personal  information by posing as a
trustworthy organization. For example, an attacker may send email seemingly
from a reputable credit card company or financial institution that requests
account information, often suggesting that there is a problem. When users
respond with the requested information, attackers can use it to gain access
to the accounts.

Phishing attacks may also appear to come from other types of organizations,
such as charities. Attackers often take advantage of current events and
certain times of the year, such as
* natural disasters (e.g., Hurricane Katrina, Indonesian tsunami)
* epidemics and health scares (e.g., H1N1)
* economic concerns (e.g., IRS scams)
* major political elections
* holidays

How do you avoid being a victim?

* Be suspicious of unsolicited phone calls, visits, or email messages from
individuals asking about employees or other internal information. If an
unknown individual claims to be from a legitimate organization, try to
verify his or her identity directly with the company.
* Do  not  provide  personal  information  or information about your
organization,  including its structure or networks, unless you are
certain of a person’s authority to have the information.
* Do not reveal personal or financial information in email, and do not
respond to email solicitations for this information. This includes
following links sent in email.
* Don’t send sensitive information over the Internet before checking a
website’s security (see Protecting Your Privacy for more information).
* Pay attention to the URL of a website. Malicious websites may look
identical to a legitimate site, but the URL may use a variation in
spelling or a different domain (e.g., .com vs. .net).
* If you are unsure whether an email request is legitimate, try to verify
it by contacting the company directly. Do not use contact information
provided on a website connected to the request; instead, check previous
statements for contact information. Information about known phishing
attacks is also available online from groups such as the Anti-Phishing
Working Group (http://www.antiphishing.org).
* Install and maintain anti-virus software, firewalls, and email filters
to  reduce  some  of  this  traffic  (see Understanding Firewalls,
Understanding  Anti-Virus  Software,  and  Reducing  Spam for more
* Take advantage of any anti-phishing features offered by your email
client and web browser.

What do you do if you think you are a victim?

* If you believe you might have revealed sensitive information about your
organization,  report  it  to  the  appropriate  people within the
organization, including network administrators. They can be alert for
any suspicious or unusual activity.
* If you believe your financial accounts may be compromised, contact your
financial institution immediately and close any accounts that may have
been compromised. Watch for any unexplainable charges to your account.
* Immediately change any passwords you might have revealed. If you used
the same password for multiple resources, make sure to change it for
each account, and do not use that password in the future.
* Watch for other signs of identity theft (see Preventing and Responding
to Identity Theft for more information).
* Consider reporting the attack to the police, and file a report with the
Federal Trade Commission (http://www.ftc.gov/).

Author: Mindi McDowell

Produced 2004 by US-CERT, a government organization.

Note: This tip was previously published and is being re-distributed to increase awareness.

Terms of use


This document can also be found at


For instructions on subscribing to or unsubscribing from this mailing list, visit

Setup: Secure Nagios Server

Today i’ve found an interesting Article about setting up Nagios. This Webbased Monitor can observed through an Website on an Apache Server. Earlier i thought, that setting up an Nagios Server is difficult. But i’ve seen, that it is easy. I think i try it out.

(Author: Bill Keys via http://www.linuxsecurity.com; Thanks)


Nagios is a monitoring software designed to let you know about problems on your hosts and networks quickly. You can configure it to be used on any network. Setting up a Nagios server on any Linux distribution is a very quick process however to make it a secure setup it takes some work. This article will not show you how to install Nagios since there are tons of them out there but it will show you in detail ways to improve your Nagios security.

You may be wondering why should I need to think about securing my Nagios server? Well, think about the amount of information the attacker can get if they compromise it.

All the examples below assumes you are using Ubuntu. However these examples will help any user running a Nagios server to make it more secure since the concepts will still apply.

Web interface

If you installed Nagios with one of the quick start guides out there, chances are that you setup the web interface. Since Nagios uses Apache to display it there are many security options.

Below is an example of apache configuration for a Nagios web interface:

Options ExecCGI
AllowOverride None
Order allow,deny
Allow from all
AuthName „Nagios Access“
AuthType Basic
AuthUserFile /usr/local/nagios/etc/htpasswd.users
Require valid-user

The ‚Allow from‘ option is used to provide access to only a certain IP address and/or network. The above example allows any IP address to access the web interface. The other security options are used for authentication. ‚AuthType‘ defines the type of authentication being used. There are two types you can choose from Basic or Digest. Basic authentication will transmit your passwords and username as clear text. However using Digest the passwords are transmitted as MD5 digests which is more secure then in clear text.

After making some security improvement we get the below.

Options ExecCGI
AllowOverride None
Order allow,deny
Allow from 192.168.4.
AuthName „Nagios Access“
AuthType Digest
AuthDigestFile /usr/local/nagios/etc/htpasswd.users
Require valid-user

Now only computers on the network can have access to the web interface. Also we are now using Digest authentication instead of the insecure method of Basic authentication.

Now we need to add users and passwords to allow accesses to the web interface. To add a new user using digest authentication use the below command:

# htdigest -c /usr/local/nagios/etc/htpasswd.users realm username

Digest is more secure then Basic authentication but the best way keep your username and passwords safe is to use SSL.

Make sure that you restart apache if you make any configuration changes.

# /etc/init.d/apache2 restart

Best Practices

This sections lists some of the best security practices when setting up an Nagios server.

  • Don’t Run Nagios As Root
  • There should be an normal user called nagios. If Nagios is running as root then if Nagios gets compromised then the attacker can do anything they want to your system.

  • Lock Down The Check Result Directory
  • Make sure that only nagios has read/write access to the check result directory otherwise an attacker can send fake host and service checks. This directory is normal at /usr/local/nagios/var/spool/checkresults

  • Use Full Paths In Command Definitions
  • When defining commands, make sure to specify the full path and not the relative one to any scripts or binaries you’re executing.

  • Secure Remote Agents
  • Some example are NRPE, NSClient, and SNMP. Below we will look at steps to secure the NRPE remote agent.

Secure Remote agents

This sections we will look at ways you can make NRPE more secure. This remote agent is used to execute programs on an remote host for doing checks like the load or disk usage. Since we don’t want any programs or users being able to execute commands on our remote machines it’s important to spend some time to make NRPE more secure.

Since NRPE come with support for TCP wrappers we can define which hosts have access to it.

Example /etc/hosts.allow


This will allow only to be able to use this remote agent on this host. You should replace this with the IP address of your Nagios client. Note this should be used on both your Nagios server and client.

NRPE should never run as root or any other superusers it should only be run as a nagios user in the group nagios. In /etc/nagios/nrpe.cfg you can check weather or not it’s running as nagios.

Example part of /etc/nagios/nrpe.cfg


Another part of NRPE that can be a security hole is allowing command arguments. We don’t want attacks to send malicious arguments that can compromise our system. Some times we need to allow Nagios to send command arguments but if you don’t need it to be enable which most times they are not needed then you should definitely disable them.

To disable them edit /etc/nagios/nrpe.cfg and make sure that you have the below line:


Make user you restart nrpe to if you make any changes to nrpe.cfg. For more information on how to secure NRPE please read the file called SECURITY in the packages source file.

Secure Communication channels

Any time you communicate over a network you should be thinking about how can I make this more secure. This is where SSL is needed.

NRPE allows you to enable it to use SSL but your package must have configured it with the –enable-ssl option. If NRPE is configured to use SSL note, both the client and the server instance must have it enabled to work.

Next we should also configure SSL so that we don’t send our web interfaces passwords in clear text.

# openssl genrsa -des3 -out server.3des-key 1024
# openssl rsa -in server.3des-key -out server.key
# openssl req -new -key server.key -x509 -out server.crt -days 365
# chmod 600 server.key
# rm server.3des-key
# mv server.crt /etc/ssl/
# mv server.key /etc/ssl/private/

Now that we have generated our certificate we need to tell Apache to use them.

In your Apache configuration you will need to add the SSLRequireSSL options for example:

Options ExecCGI
AllowOverride None
Order allow,deny
Allow from 192.168.4.
AuthName „Nagios Access“
AuthType Digest
AuthDigestFile /usr/local/nagios/etc/htpasswd.users
Require valid-user

Remember to restart Apache.

# /etc/init.d/apache2 restart

Where to go from here?

Now you should feel confident that your Nagios server is more secure from attack. The next step is to just install security updates when they are released.


Updated package: kpassgen 0.5

Updated Package: kpassgen
Version: 0.5
Repository: KDE:KDE4:Community

New Package: kpassgen

Today i’ve released the kpassgen Package in KDE:KDE4:Community. It is planned to publish in Contrib too. Mehr von diesem Beitrag lesen