Archive for the ‘UNIX’ Category

h1

Rsyslog quick configuration

October 6, 2015

Hi there,

Rsyslog provides a logging daemon on our Linux system to catch different events in a organized manner as well providing a way to send/receive these logs to/from a remote machine which can be used for example for logs aggregation on our network.

Rsyslog provides a number of “facilities” (types of programs with a common functionality) that can be classified into the following categories:

syslog_facilities

The localX facilities can be used in case we write/use any application that does not use the common facilities.

Each of these facilities, will generate different entries on the logs depending on the severity of the action that triggered the log entry:

severity_logging

The main configuration file for rsyslog is normally located (tested on a Ubuntu machine) in:

/etc/rsyslog.conf

Here we can set up a number of interesting directives such as:

#UDP log reception
#$ModLoad imudp
#$UDPServerRun 514

#TCP log reception
#$ModLoad imtcp
#$InputTCPServerRun 514

#RELP log reception
#$ModLoad imrelp
#$InputTCPServerRun 2514

It may be surprising that “RELP” protocol for you. RELP is basically a protocol designed for reliable log messages transport between different entities. By means of some wrappers it can be used along with TLS which will provide and reliable and encrypted communication channel for logs.

If we want to restrict which nodes can send logs to our server we can use the following directive:
$AllowedSender UDP, 192.168.1.100, 192.168.1.101, myhost.mydomain.net

We can also allow by TCP. Beware of IP spoofing attacks here.

There are other interesting directives to for example give certain rights to the logs, which is important if we don’t want non-privileged users to access the log files. Check “man rsyslog.conf” for more details about this.

The important directives to configure the logging have the following appearance:
facility.priority

Where the variables used are the ones from the tables above. If we want for example to log all the authentication messages we will add an entry like:
auth.* -/var/log/auth.log
auth.warn -/var/log/auth_warn.log

If we specify a severity level (like warn in the example) all the events with severity from “emerg” to “kern” will be captured into this log. If we want just one certain level we have to use = operator:
auth.=warn -/var/log/auth_warnonly.log

If we want to catch messages from several (or all) facilities but to restrict some we can use the “.none” modifier after a “;” to specify which ones:
*.critical;auth,kern.none -/var/log/all_noauthkern.log

To use the “local” facilities, it follows the same pattern than before:
local0.* -/var/log/myapplocal0.log

If we want to send logs (messages, events…) to a remote machine (a log aggregator for example) we can use the following:
*.* @192.168.1.1 #this uses UDP
*.* @@192.168.1.1 #this uses TCP
*.* :omrelp:192.168.1.1:2514 #this uses RELP (port 2514)

Security factors to take into consideration:

  • If we allow remote logs reception, make sure your daemon is running on a limited partion under a chroot environment or something similar to avoid a disk fill-up
  • Unless some sort of VPN/SSL/TLS, etc is used, our logs will travel unencripted over the network, therefore we are susceptible to suffer a MiTM attack.
  • Only the hosts (or sensors) that will generate logs should be able to send logs over the network, therefore our networking devices should filter any traffic not belonging to these addresses by means of ACL, Iptables or similar. This do not protect from IP spoofing, so if we need are in an untrusted enviroment we should somehow authenticate this traffic.

This gives you few basics to start with syslog. There are other interesting topics such as templates (custom log entries), users restriction, filters (to filter out only information we need), database connection, etc.

Good luck!

Advertisements
h1

Changing screen resolution on VirtualBox (Linux Debian)

October 13, 2010

Hi after … more than a year!!!

These are the necessary steps that you’ve to follow if you want to change your screen’s resolution using VirtualBox (By the way, this app rocks!) on a Debian virtual machine (Also is applicable to the most of the Linux distros):

  1. Install “build-essential” package. In debian is enough typing apt-get install build-essential
  2. On the VirtualBox menu while the VM is running, press Devices and “Install Guest Additions”. This will mount a cd drive on the system
  3. cd /media/cdrom and sh autorun.sh
  4. Log as root and edit the next file: /etc/X11/xorg.conf
  5. At the end of the file there’s a section called “Screen”. Probably you’ll see “Dept 24”. Open a new line and write the next “Modes “1366×768″ …” And the custom resolution that you need to your machine
  6. Reboot the VM with a shutdown -r now

That’s all, now you’re ready to work with the desired resolution

Cheers

h1

Preventing ctrol+alt+del rebooting in our machine

May 1, 2009

Edit the /etc/inittab file as root

There’s a line like this in the file

ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

Just comment it, or replace it with something like this
ca:12345:ctrlaltdel:echo "Use the "shutdown -r now" command if you want to reboot the system"

Also you should read the shutdown manual. This is a part of this that I think is important if we want to lock the rebooting system.
ACCESS CONTROL
shutdown can be called from init(8) when the magic keys CTRL-ALT-DEL are pressed, by creating an appro-
priate entry in /etc/inittab. This means that everyone who has physical access to the console keyboard
can shut the system down. To prevent this, shutdown can check to see if an authorized user is logged in
on one of the virtual consoles. If shutdown is called with the -a argument (add this to the invocation
of shutdown in /etc/inittab), it checks to see if the file /etc/shutdown.allow is present. It then
compares the login names in that file with the list of people that are logged in on a virtual console
(from /var/run/utmp). Only if one of those authorized users or root is logged in, it will proceed. Oth-
erwise it will write the message

shutdown: no authorized users logged in

to the (physical) system console. The format of /etc/shutdown.allow is one user name per line. Empty
lines and comment lines (prefixed by a #) are allowed. Currently there is a limit of 32 users in this
file.

In some distros like Fedora, you must look for the /etc/event.d/control-alt-delete file to modify this event

Cheers

h1

Which distro version am I using?

April 18, 2009

Maybe you have asked yourself sometimes about this. There are some ways:
This shows a text like the uname -a command output
cat /proc/version
This is another way which should works in practically all *NIX systems
cat /etc/issue
And this is valid for Debian and Debian based distros
cat /etc/debian_version

h1

How to: Recovering your Debian/FreeBSD root password

November 1, 2008

Hi there again.

Probably, you’ve lost your root password at least one time in your life (yea, you are not the only one 😉 )… There’s no problem, I’m gonna show you a easy way to fix it.

  • For Debian (Using GRUB, anyway, this will work in any boot loader)
  1. In the line where is our Debian installation, press “e”
  2. Now a kind of editor will be opened. Type the following command after the current commands: “init=/bin/bash”
  3. Press enter
  4. Now you would be back in the first step. Just press de “b” key, to boot the system with the new parameters
  5. Now the system prompt would be a root session. But if you try to use “passwd” command, the system will deny the operation. To fix this, type “mount -o remount,rw /dev/[your_drive]“. Usally your drive will be sda1, hda1 or similar.
  6. Now use the passwd root command to change.
  7. Reboot and your computer and use your new root password 😛
  • For FreeBSD
  1. In the boot menu, choose the option 4 “FreeBSD in single mode user”
  2. Now a message like “Enter fill pathname of shell or RETURN for /bin/sh” will be shown. Just press ENTER
  3. The next step is typing “mount -t ufs -a“. This will mount every file system found in /etc/fstab
  4. Now just use the passwd root command
  5. Reboot the system
h1

Adding quotas support on FreeBSD

November 1, 2008

I followed these steps to add the QUOTA module in the kernel. Moreover, the new kernel will has the generic freebsd kernel options.

First, log in the system as root and type the following commands

  • cd /sys/i386/conf
  • vi QUOTAS_SUPPORT        You can write the file name you want
  • In the file type:

include GENERIC
options QUOTA

  • config CUOTAS_SUPPORT         Be sure that you type the file name you typed
  • cd ../compile/CUOTAS_SUPPORT
  • make cleandepend && make depend && make && make install

That’s all. You can also edit the /sys/i386/GENERIC or DEFAULTS file, but it is highly not recommended because you would lost the default kernel configuration.

h1

Some useful *NIX commands

March 12, 2008

This is a collection of some *NIX commands (i’m using it on a FreeBSD  6.2), to manage some system process and signals.

wait -> It restore the second plane of the terminal until the process is running. You can type new commands, but it will be executed when the process ends.

[command] > /dev/null & -> This will not show the messages that the command print in the screen.

nice -> This command sets the priority of a process. The priority range goes from -20 to +20. To use it, type “nice +15 [process]”. You can also add a rule to a user or group using the “-g” and “-u” modifiers.

time -> This command allows you to watch how much time a process needs to execute.