rev.dennis

One of the most popular internet browsers out there today is Firefox with Chrome being second and Safari next and Internet Explorer consistently falling to last place because of its proprietary features and Microsoft coding. Why is Firefox, Chrome and Safari doing so well. They are built to run on any website not just those websites created with Microsoft FrontPage. Also Firefox and Chrome work on most operating system platforms (Windows, Mac, Linux)... IE only works on windows. So some simple things to do to troubleshoot Firefox. 1. Reset Firefox by typing in the address bar.. about:config 2. Click Reset Firefox Now maybe when you launch firefox it crashes... try and launch it via safe-mode Windows: "C:Program FilesMozilla Firefoxfirefox.exe" -safe-mode Mac: Hold the Option key while launching Firefox Linux: from command line firefox -safe-mode

PART ONE What is installed? (This is for a x86_64 machine) rpm -qa | grep ^jre # jre-1.7.0_40-fcs.x86_64 [dhosang@localhost ~]$ rpm -qa | grep ^jre jre-1.7.0_40-fcs.x86_64 check and download latest and greatest at www.java.com to /usr/java/ At the time of this article the latest is: jre1.7.0_60 [dhosang@localhost ~]$ cd /usr/java [dhosang@localhost ~]$ sudo rpm -Uvh jre-7u60-linux-x64.rpm PART TWO Check which java is set [dhosang@localhost ~]$ sudo /usr/sbin/alternatives --config java password for dhosang: There is 1 program that provides 'java'. Selection Command ----------------------------------------------- *+ 1 /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.3.0.fc20.x86_64/jre/bin/java Check which plugin is set [dhosang@localhost ~]$ sudo /usr/sbin/alternatives --config libjavaplugin.so.x86_64 If /usr/sbin/alternatives shows a wrong item remove it [dhosang@localhost ~]$ sudo /usr/sbin/alternatives --remove libjavaplugin.so.x86_64 /usr/java/jre1.7.0_40/lib/amd64/libnpjp2.so Install the newest one [dhosang@localhost ~]$ sudo /usr/sbin/alternatives --install /usr/lib64/mozilla/plugins/libjavaplugin.so libjavaplugin.so.x86_64 /usr/java/jre1.7.0_60/lib/amd64/libnpjp2.so 1 Note: Remember, you've got to check alternatives --config java and alternatives --config libjavaplugin.so.x86_64 everytime you update java-1.7.0-openjdk and switch it back to java (oracle).

PART ONE What is installed? (This is for a x86_64 machine) rpm -qa | grep ^jre # jre-1.7.0_40-fcs.x86_64 [dhosang@localhost ~]$ rpm -qa | grep ^jre jre-1.7.0_40-fcs.x86_64 check and download latest and greatest at www.java.com to /usr/java/ At the time of this article the latest is: jre1.7.0_60 [dhosang@localhost ~]$ cd /usr/java [dhosang@localhost ~]$ sudo rpm -Uvh jre-7u60-linux-x64.rpm PART TWO Check which java is set [dhosang@localhost ~]$ sudo /usr/sbin/alternatives --config java password for dhosang: There is 1 program that provides 'java'. Selection Command ----------------------------------------------- *+ 1 /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.3.0.fc20.x86_64/jre/bin/java Check which plugin is set [dhosang@localhost ~]$ sudo /usr/sbin/alternatives --config libjavaplugin.so.x86_64 If /usr/sbin/alternatives shows a wrong item remove it [dhosang@localhost ~]$ sudo /usr/sbin/alternatives --remove libjavaplugin.so.x86_64 /usr/java/jre1.7.0_40/lib/amd64/libnpjp2.so Install the newest one [dhosang@localhost ~]$ sudo /usr/sbin/alternatives --install /usr/lib64/mozilla/plugins/libjavaplugin.so libjavaplugin.so.x86_64 /usr/java/jre1.7.0_60/lib/amd64/libnpjp2.so 1 Note: Remember, you've got to check alternatives --config java and alternatives --config libjavaplugin.so.x86_64 everytime you update java-1.7.0-openjdk and switch it back to java (oracle).

Here is a great Perl script thanks to Zed Pobre that lists all groups and what members are in each. #!/usr/bin/perl -T # # Lists members of all groups, or optionally just the group # specified on the command line # # Copyright © 2010-2013 by Zed Pobre ([email protected] or [email protected]) # # Permission to use, copy, modify, and/or distribute this software for any # purpose with or without fee is hereby granted, provided that the above # copyright notice and this permission notice appear in all copies. # use strict; use warnings; $ENV{"PATH"} = "/usr/bin:/bin"; my $wantedgroup = shift; my %groupmembers; my $usertext = `getent passwd`; my @users = $usertext =~ /^(+):/gm; foreach my $userid (@users) { my $usergrouptext = `id -Gn $userid`; my @grouplist = split(' ',$usergrouptext); foreach my $group (@grouplist) { $groupmembers{$group}->{$userid} = 1; } } if($wantedgroup) { print_group_members($wantedgroup); } else { foreach my $group (sort keys %groupmembers) { print "Group ",$group," has the following members:n"; print_group_members($group); print "n"; } } sub print_group_members { my ($group) = @_; return unless $group; foreach my $member (sort keys %{$groupmembers{$group}}) { print $member,"n"; } }

This script is a direct replacement for the basic Nagios emailer. This perl script provides the following features: * Allows you to specify the senders email address * Allows you to specify the destination email address/group * Allows you to differentiate between Host and Service outages * Allows you to connect directly to any SMTP server * Doesn't require any local sendmail configuration * Uses standard Net::SMTP module * Runs within Nagios's embedded perl interpreter * Allows you to format the alert message subject and body * Allows you to send emails to different alert groups based on nagios configuration Configuration steps -------------- I put this in the nagios plugins directory /etc/nagios/libexec but you can put it anywhere. commands.cfg define command{ command_name notify-by-email command_line $USER1$/send_mail.pl -n "$NOTIFICATIONTYPE$" -h "$HOSTNAME$" -s "$HOSTSTATE$" -a "$HOSTADDRESS$" -i "$HOSTOUTPUT$" -d "$LONGDATETIME$" -e "$CONTACTEMAIL$" } define command{ command_name host-notify-by-email command_line $USER1$/send_mail.pl -n "HOST $NOTIFICATIONTYPE$" -h "$HOSTNAME$" -s "$HOSTSTATE$" -a "$HOSTADDRESS$" -i "$HOSTOUTPUT$" -d "$LONGDATETIME$" -e "$CONTACTEMAIL$" } define command{ command_name service-notify-by-email command_line $USER1$/send_mail.pl -n "SERVICE $NOTIFICATIONTYPE$" -h "$HOSTNAME$" -s "$SERVICESTATE$" -a "$HOSTADDRESS$" -i "$SERVICEDESC$ - $SERVICEOUTPUT$ - $SERVICECHECKCOMMAND$" -d "$LONGDATETIME$" -e "$CONTACTEMAIL$" } contacts.cfg define contact{ contact_name contact host_notification_commands host-notify-by-email service_notification_commands service-notify-by-email email [email protected] .... rest of contact details .... } send_mail.pl.txt send_mail.pl.txt

This script is a direct replacement for the basic Nagios emailer. This perl script provides the following features: * Allows you to specify the senders email address * Allows you to specify the destination email address/group * Allows you to differentiate between Host and Service outages * Allows you to connect directly to any SMTP server * Doesn't require any local sendmail configuration * Uses standard Net::SMTP module * Runs within Nagios's embedded perl interpreter * Allows you to format the alert message subject and body * Allows you to send emails to different alert groups based on nagios configuration Configuration steps -------------- I put this in the nagios plugins directory /etc/nagios/libexec but you can put it anywhere. commands.cfg define command{ command_name notify-by-email command_line $USER1$/send_mail.pl -n "$NOTIFICATIONTYPE$" -h "$HOSTNAME$" -s "$HOSTSTATE$" -a "$HOSTADDRESS$" -i "$HOSTOUTPUT$" -d "$LONGDATETIME$" -e "$CONTACTEMAIL$" } define command{ command_name host-notify-by-email command_line $USER1$/send_mail.pl -n "HOST $NOTIFICATIONTYPE$" -h "$HOSTNAME$" -s "$HOSTSTATE$" -a "$HOSTADDRESS$" -i "$HOSTOUTPUT$" -d "$LONGDATETIME$" -e "$CONTACTEMAIL$" } define command{ command_name service-notify-by-email command_line $USER1$/send_mail.pl -n "SERVICE $NOTIFICATIONTYPE$" -h "$HOSTNAME$" -s "$SERVICESTATE$" -a "$HOSTADDRESS$" -i "$SERVICEDESC$ - $SERVICEOUTPUT$ - $SERVICECHECKCOMMAND$" -d "$LONGDATETIME$" -e "$CONTACTEMAIL$" } contacts.cfg define contact{ contact_name contact host_notification_commands host-notify-by-email service_notification_commands service-notify-by-email email [email protected] .... rest of contact details .... } send_mail.pl.txt send_mail.pl.txt

All you need to do is first find installation of Nagios sudo find / -name "htpasswd.users" If the file htpasswd.users was found at /etc/nagios, then add user by running sudo cp /etc/nagios/htpasswd.users /etc/nagios/htpasswd.users.backup sudo htpasswd /etc/nagios/htpasswd.users dhosang Now you must give your newuser permission to do something in Nagios. All permissions are handeled in the cgi.cfg file. I recommend just adding your newuser to the same as a similar user. So find the lines that you want to give similar permission to and add a comma and then your new user. sudo vi /etc/nagios/cgi.cfg

All you need to do is first find installation of Nagios sudo find / -name "htpasswd.users" If the file htpasswd.users was found at /etc/nagios, then add user by running sudo cp /etc/nagios/htpasswd.users /etc/nagios/htpasswd.users.backup sudo htpasswd /etc/nagios/htpasswd.users dhosang Now you must give your newuser permission to do something in Nagios. All permissions are handeled in the cgi.cfg file. I recommend just adding your newuser to the same as a similar user. So find the lines that you want to give similar permission to and add a comma and then your new user. sudo vi /etc/nagios/cgi.cfg

You can see if you have perl installed (you should since it comes on every linux distro I used) by typing perl -v Perl Script #!/usr/bin/perl use strict; use warnings; use Filesys::DiskSpace; my $dir = "/home"; my ($fs_type, $fs_desc, $used, $avail, $fused, $favail) = df $dir; my $df_free = (($avail) / ($avail+$used)) * 100.0; my $out = sprintf("Disk space on $dir: %0.2fn",$df_free); print $out;

List the current running processes $ ps -ef -e (displays all the processes) -f (displays full format listing) List the processes by UID or User using -u $ ps -f -u wwwrun,postfix

List the current running processes $ ps -ef -e (displays all the processes) -f (displays full format listing) List the processes by UID or User using -u $ ps -f -u wwwrun,postfix

Here I am going to keep updating ways to troubleshoot ssh login issues on linux or unix operating systems. Even though there are several different flavors and types of linux, the basis is typically the same. I am currently running/testing these commands on a RH 5.x system SSH Login Records $ cat /var/log/secure SSH Login Attempts $ cat /var/log/auth.log (some helpful filters) $ grep sshd.*Failed /var/log/auth.log | less $ grep sshd.*Did /var/log/auth.log | less .ssh/authorized_keys permissions, compare files checksum Failed Login Attempts $ grep "authentication failure" /var/log/secure | awk '{ print $13 }' | cut -b7- | sort | uniq -c Capture login attempts $ tcpdump -w xpackets.pcap src 138.35.28.202 and port 22 NOTES: $ tcpdump -D (shows available interfaces in the event you want to capture only on one interface with -i eth0) $ tcpdump -r xpackets.pcap (will read the file file you just captured)

Here I am going to keep updating ways to troubleshoot ssh login issues on linux or unix operating systems. Even though there are several different flavors and types of linux, the basis is typically the same. I am currently running/testing these commands on a RH 5.x system SSH Login Records $ cat /var/log/secure SSH Login Attempts $ cat /var/log/auth.log (some helpful filters) $ grep sshd.*Failed /var/log/auth.log | less $ grep sshd.*Did /var/log/auth.log | less .ssh/authorized_keys permissions, compare files checksum Failed Login Attempts $ grep "authentication failure" /var/log/secure | awk '{ print $13 }' | cut -b7- | sort | uniq -c Capture login attempts $ tcpdump -w xpackets.pcap src 138.35.28.202 and port 22 NOTES: $ tcpdump -D (shows available interfaces in the event you want to capture only on one interface with -i eth0) $ tcpdump -r xpackets.pcap (will read the file file you just captured)

Oddly enough the majority of ATM's are all running the easy to hack Windows OS but there are some alternatives. Not sure why its so difficult to find more alternatives for ATM machines. It's pretty simple, Windows is crap and I wouldn't want something as serious as handling money transactions managed by a virus prone operating system. Here are some interesting articles about banks loosing money because of how easy it is to hack a windows anything. http://geek2live.blogspot.com/2009/08/windows-fails-with-atm-machine.html http://www.linkedin.com/groups/Would-Linux-devices-fare-better-65688.S.5824409911932526595 http://techrights.org/2009/10/07/windows-trojan-bank/ https://groups.google.com/forum/#!topic/iitdlug/e7nXyGixNFU http://www.maximumpc.com/article/news/hackers_targeting_windows_xpbased_atm_machines http://www.geek.com/news/atms-infected-with-virus-551684/

Oddly enough the majority of ATM's are all running the easy to hack Windows OS but there are some alternatives. Not sure why its so difficult to find more alternatives for ATM machines. It's pretty simple, Windows is crap and I wouldn't want something as serious as handling money transactions managed by a virus prone operating system. Here are some interesting articles about banks loosing money because of how easy it is to hack a windows anything. http://geek2live.blogspot.com/2009/08/windows-fails-with-atm-machine.html http://www.linkedin.com/groups/Would-Linux-devices-fare-better-65688.S.5824409911932526595 http://techrights.org/2009/10/07/windows-trojan-bank/ https://groups.google.com/forum/#!topic/iitdlug/e7nXyGixNFU http://www.maximumpc.com/article/news/hackers_targeting_windows_xpbased_atm_machines http://www.geek.com/news/atms-infected-with-virus-551684/

Not Enough Memory for Firmware Update I have a TS-412 running firmware 4.0.2 and have been happy with it (No issues). I recently wanted to keep it up to date with the latest firmware (4.0.7) but upon trying to update the TS-412 with the latest version of firmware using Live Update option it fails and states: If I try the manual method under the Firmware Update tab the error is different and states: Total Memory under System Status: 249.7MB Under Resource Monitor - Memory Usage: Physical Used 157.75MB, Free 92.58MB Swap Total: 517.62 MB Swap Used: 34.68 MB Swap Free: 482.93 MB I rebooted the NAS in attempts to clear up any RAM. I shutdown any service I can find to free up memory and still no luck.

Not Enough Memory for Firmware Update I have a TS-412 running firmware 4.0.2 and have been happy with it (No issues). I recently wanted to keep it up to date with the latest firmware (4.0.7) but upon trying to update the TS-412 with the latest version of firmware using Live Update option it fails and states: If I try the manual method under the Firmware Update tab the error is different and states: Total Memory under System Status: 249.7MB Under Resource Monitor - Memory Usage: Physical Used 157.75MB, Free 92.58MB Swap Total: 517.62 MB Swap Used: 34.68 MB Swap Free: 482.93 MB I rebooted the NAS in attempts to clear up any RAM. I shutdown any service I can find to free up memory and still no luck.

Trying to discover hosts in a subnet from a linux box and here is what I came up with so far Using a BASH script: subnet=192.168.2. addr=1 while [ $addr -lt 256 ]; do ping -c 1 -t 1 $subnet$addr > /dev/null && echo Found $subnet$addr let addr=addr+1 done OR this script may work better subnet=192.168.2. for addr in `seq 1 1 255 `; do ( ping -c 1 -t 1 $subnet$addr > /dev/null && echo Found $subnet$addr ) & done OR even ping the broadcast address like this ping -b 192.168.2.255 OR use arp-scan (if loaded) sudo arp-scan -I eth0 192.168.2.0/24 OR utilize nmap (one of my favorite discovery tools) nmap -v -sP 192.168.0.0/16 10.0.0.0/8 OR even another script FOR /L %i IN (1,1,254) DO ping -n 1 10.254.254.%i | FIND /i “Reply”>> ipaddresses.txt

Trying to discover hosts in a subnet from a linux box and here is what I came up with so far Using a BASH script: subnet=192.168.2. addr=1 while [ $addr -lt 256 ]; do ping -c 1 -t 1 $subnet$addr > /dev/null && echo Found $subnet$addr let addr=addr+1 done OR this script may work better subnet=192.168.2. for addr in `seq 1 1 255 `; do ( ping -c 1 -t 1 $subnet$addr > /dev/null && echo Found $subnet$addr ) & done OR even ping the broadcast address like this ping -b 192.168.2.255 OR use arp-scan (if loaded) sudo arp-scan -I eth0 192.168.2.0/24 OR utilize nmap (one of my favorite discovery tools) nmap -v -sP 192.168.0.0/16 10.0.0.0/8 OR even another script FOR /L %i IN (1,1,254) DO ping -n 1 10.254.254.%i | FIND /i “Reply”>> ipaddresses.txt

I would like to establish an LDAP server on a CentOS server but figured I would post this in the General Technology Discussion because LDAP works on all operating systems and I am just confused on everything LDAP but know that everyone uses it. My goal is going to be to utilize this LDAP server for authentication from web servers, switch and router login, and anything else I can find that needs to authenticate a user for access. Could someone help me understand it better? I personally will be using OpenLDAP

I would like to establish an LDAP server on a CentOS server but figured I would post this in the General Technology Discussion because LDAP works on all operating systems and I am just confused on everything LDAP but know that everyone uses it. My goal is going to be to utilize this LDAP server for authentication from web servers, switch and router login, and anything else I can find that needs to authenticate a user for access. Could someone help me understand it better? I personally will be using OpenLDAP

Many times we need to update the serial number on multiple zone files and here is a script that we created for that purpose. It's written in korn shell (ksh).. you can check what shell your default is by typing echo $SHELL ** Downloadable Only as a Subscribed User ** snupdate.ksh.txt snupdate.ksh.txt

Logging your system messages to a remote server is a good security practice. With all servers logging to a central syslog server, it becomes easier to correlate events across your company. It also makes covering up mistakes or malicious activities harder because the purposeful deletion of log files on a server cannot simultaneously occur on your logging server, especially if you restrict the user access to the logging server. syslog-ng can be used to collect local syslog messages & monitor log files on your servers and then forward them to a collector. syslog-ng OSE is an open source alternative to the standard syslog daemon that's commonly found on UNIX and UNIX-like (*nix) systems. It uses the basic syslog protocol, but extends it with content-based filtering, flexible configuration options and adds important features, such as using TCP (as well as TLS), which is much more reliable than UDP. Installation - Using a Package Manager Depending on your Linux distribution you can use yum or APT (do this with root or sudo privileges): # apt-get install syslog-ng You will most likely need to enable Extra Packages for Enterprise Linux (EPEL) # yum install syslog-ng Installing and Starting syslog-ng You can install syslog-ng using standard Linux procedures.The syslog-ng and rsyslog packages cannot be installed at the same time. You have to uninstall one in order for the other to work. Here’s how you can install syslog-ng using RPM package files. Uninstall rsyslog using the rpm command. There are some other RPMs that rely on rsyslog so you will have to do this while ignoring any dependencies with the –nodeps flag. $ rpm -e --nodeps rsyslog Install syslog-ng using yum. $ yum -y install syslog-ng Start the new syslog-ng daemon immediately and make sure it will start on the next reboot. Systems using sysvinit: $ chkconfig syslog-ng on $ service syslog-ng start Starting syslog-ng: [ OK ] $ Systems using systemd: $ systemctl enable syslog-ng.service $ systemctl start syslog-ng.service Starting syslog-ng: [ OK ] $ Your new syslog-ng package is now up and running and ready to go! Configuring syslog-ng Clients Clients logging to the syslog-ng server don't need to have syslog-ng installed on them, a regular syslog client configuration will suffice. If you are running syslog-ng on clients, then you’ll need to modify your configuration file. Let’s look at the below example – Syslog-ng Sample Client Configuration. Syslog-ng Sample Client Configuration source s_sys { file ("/proc/kmsg" log_prefix("kernel: ")); unix-stream ("/dev/log"); internal(); }; destination loghost { udp("loghost.hosangit.com"); }; filter notdebug { level(info...emerg); }; log { source(local); filter(notdebug); destination(loghost); }; The s_sys source comes default in many syslong-ng.conf files, we have just added some additional parameters to make it work. Here the destination syslog logging server is defined as loghost.hosangit.com. We have also added a filter to the log section to make sure only the most urgent messages, info level and above (not debug), get logged to the remote server. After restarting syslong-ng on your client, your syslog server will start receiving messages. Logging your system messages to a remote server is a good security practice. With all servers logging to a central syslog server, it becomes easier to correlate events across your company. It also makes covering up mistakes or malicious activities harder because the purposeful deletion of log files on a server cannot simultaneously occur on your logging server, especially if you restrict the user access to the logging server. syslog-ng can be used to collect local syslog messages & monitor log files on your servers and then forward them to a collector. syslog-ng OSE is an open source alternative to the standard syslog daemon that's commonly found on UNIX and UNIX-like (*nix) systems. It uses the basic syslog protocol, but extends it with content-based filtering, flexible configuration options and adds important features, such as using TCP (as well as TLS), which is much more reliable than UDP. Installation - Using a Package Manager Depending on your Linux distribution you can use yum or APT (do this with root or sudo privileges): # apt-get install syslog-ng You will most likely need to enable Extra Packages for Enterprise Linux (EPEL) # yum install syslog-ng Configure either using our Configure-syslog script or manually. Compiling From Source Download syslog-ng source code & eventlog source code. Install both eventlog & syslog-ng. Eventlog is a generic event logging library developed by Balabit. Once you've unzipped both packages (evenlog_x.x.xx.tar.gz & syslog-ng-x.xx.tar.gz), do this in each of those directories: $ ./configure $ make $ sudo make install Check your syslog-ng version You'll need to know which version of syslog-ng you've got installed. We recommend running on the latest, but at least version 3.2 for best results. Configure syslog-ng The /etc/syslog-ng/syslog-ng.conf file The main configuration file for syslog-ng is the /etc/syslog-ng/sylog-ng.conf file but only rudimentary help on its keywords can be found using the Linux man pages. $ man syslog-ng.conf Simple Server Side Configuration for Remote Clients Below is a sample syslog-ng.conf file and outlines some key features. The options section that covers global characteristics is fully commented, but it is the source, destination and log sections that define the true strength of the customizability of syslog-ng. Sample syslog-ng.conf File options { # Number of syslog lines stored in memory before being written to files sync (0); # Syslog-ng uses queues log_fifo_size (1000); # Create log directories as needed create_dirs (yes); # Make the group "logs" own the log files and directories group (logs); dir_group (logs); # Set the file and directory permissions perm (0640); dir_perm (0750); # Check client hostnames for valid DNS characters check_hostname (yes); # Specify whether to trust hostname in the log message. # If "yes", then it is left unchanged, if "no" the server replaces # it with client's DNS lookup value. keep_hostname (yes); # Use DNS fully qualified domain names (FQDN) # for the names of log file folders use_fqdn (yes); use_dns (yes); # Cache DNS entries for up to 1000 hosts for 12 hours dns_cache (yes); dns_cache_size (1000); dns_cache_expire (43200); }; # Define all the sources of localhost generated syslog # messages and label it "d_localhost" source s_localhost { pipe ("/proc/kmsg" log_prefix("kernel: ")); unix-stream ("/dev/log"); internal(); }; # Define all the sources of network generated syslog # messages and label it "d_network" source s_network { tcp(max-connections(5000)); udp(); }; # Define the destination "d_localhost" log directory destination d_localhost { file ("/var/log/syslog-ng/$YEAR.$MONTH.$DAY/localhost/$FACILITY.log"); }; # Define the destination "d_network" log directory destination d_network { file ("/var/log/syslog-ng/$YEAR.$MONTH.$DAY/$HOST/$FACILITY.log"); }; # Any logs that match the "s_localhost" source should be logged # in the "d_localhost" directory log { source(s_localhost); destination(d_localhost); }; # Any logs that match the "s_network" source should be logged # in the "d_network" directory log { source(s_network); destination(d_network); }; In our example, the first set of sources is labeled s_localhost. It includes all system messages sent to the Linux /dev/log device, which is one of syslog's data sources, all messages that syslog-ng views as being of an internal nature and additionally inserts the prefix "kernel" to all messages it intercepts on their way to the /proc/kmsg kernel message file. Like a regular syslog server which listens for client messages on UDP port 514, syslog-ng also listens on TCP port 514. The second set of sources is labeled s_network and includes all syslog messages obtained from UDP sources and limits TCP syslog connections to 5000. Limiting the number of connections to help regulate system load is a good practice in the event that some syslog client begins to inundate your server with messages. The above example also has two destinations for syslog messages, one named d_localhost, the other, d_network. These examples show the flexibility of syslog-ng in using variables. The $YEAR, $MONTH and $DAY variables map to the current year, month and day in YYYY, MM and DD format respectively. Therefore the example: /var/log/syslog-ng/$YEAR.$MONTH.$DAY/$HOST/$FACILITY.log refers to a directory called /var/log/syslog-ng/2005.07.09 when messages arrive on July 9, 2005. The $HOST variable refers to the hostname of the syslog client and will map to the client's IP address if DNS services are deactivated in the options section of the syslog-ng.conf file. Similarly the $FACILITY variable refers to the facility of the syslog messages that arrive from that host. Using syslog-ng in Large Data Centers Below example is a sample syslog-ng.conf file snippet that defines some additional features that may be of interest in a data center environment. More Specialized syslog-ng.conf Configuration options { # Number of syslog lines stored in memory before being written to files sync (100); }; # Define all the sources of network generated syslog # messages and label it "s_network_1" source s_network_1 { udp(ip(192.168.1.201) port(514)); }; # Define all the sources of network generated syslog # messages and label it "s_network_2" source s_network_2 { udp(ip(192.168.1.202) port(514)); }; # Define the destination "d_network_1" log directory destination d_network_1 { file ("/var/log/syslog-ng/servers/$YEAR.$MONTH.$DAY/$HOST/$FACILITY.log"); }; # Define the destination "d_network_2" log directory destination d_network_2 { file ("/var/log/syslog-ng/network/$YEAR.$MONTH.$DAY/$HOST/$FACILITY.log"); }; # Define the destination "d_network_2B" log directory destination d_network_2B { file ("/var/log/syslog-ng/network/all/network.log"); }; # Any logs that match the "s_network_1" source should be logged # in the "d_network_1" directory log { source(s_network_1); destination(d_network_1); }; # Any logs that match the "s_network_2" source should be logged # in the "d_network_2" directory log { source(s_network_2); destination(d_network_2); }; # Any logs that match the "s_network_2" source should be logged # in the "d_network_2B" directory also log { source(s_network_2); destination(d_network_2B); }; In this case we have configured syslog to: Listen on IP address 192.168.1.201 as defined in the source s_network_1. Messages arriving at this address will be logged to a subdirectory of /var/log/syslog-ng/servers/ arranged by date as specified by destination d_network_1. As you can guess, this address and directory be used by all servers in the data center. Listen on IP address 192.168.1.202 as defined in the source s_network_2. Messages arriving at this address will be logged to a subdirectory of /var/log/syslog-ng/network/ arranged by date as specified by d_network_2. This will be the IP address and directory to which network devices would log. Listen on IP address 192.168.1.202 as defined in the source s_network_2. Messages arriving at this address will also be logged to file /var/log/syslog-ng/all/debug.log as part of destination d_network_2B.This will be a single file to which all network devices would log. Server failures are usually isolated to single servers whereas network failures are more likely to be cascading involving many devices. The advantage of searching a single file is that it makes it easier to determine the exact sequence of events. As there could be many devices logging to the syslog-ng server, the sync option is set to write data to disk only after receiving 100 syslog messages. Constant receipt of syslog messages can have a significant impact on your system’s disk performance. This option allows you to queue the messages in memory for less frequent disk updates. Ref: http://www.balabit.com/sites/default/files/documents/syslog-ng-ose-3.3-guides/en/syslog-ng-ose-v3.3-guide-admin-en/html/bk01-toc.html

Logging your system messages to a remote server is a good security practice. With all servers logging to a central syslog server, it becomes easier to correlate events across your company. It also makes covering up mistakes or malicious activities harder because the purposeful deletion of log files on a server cannot simultaneously occur on your logging server, especially if you restrict the user access to the logging server. syslog-ng can be used to collect local syslog messages & monitor log files on your servers and then forward them to a collector. syslog-ng OSE is an open source alternative to the standard syslog daemon that's commonly found on UNIX and UNIX-like (*nix) systems. It uses the basic syslog protocol, but extends it with content-based filtering, flexible configuration options and adds important features, such as using TCP (as well as TLS), which is much more reliable than UDP. Installation - Using a Package Manager Depending on your Linux distribution you can use yum or APT (do this with root or sudo privileges): # apt-get install syslog-ng You will most likely need to enable Extra Packages for Enterprise Linux (EPEL) # yum install syslog-ng Installing and Starting syslog-ng You can install syslog-ng using standard Linux procedures.The syslog-ng and rsyslog packages cannot be installed at the same time. You have to uninstall one in order for the other to work. Here’s how you can install syslog-ng using RPM package files. Uninstall rsyslog using the rpm command. There are some other RPMs that rely on rsyslog so you will have to do this while ignoring any dependencies with the –nodeps flag. $ rpm -e --nodeps rsyslog Install syslog-ng using yum. $ yum -y install syslog-ng Start the new syslog-ng daemon immediately and make sure it will start on the next reboot. Systems using sysvinit: $ chkconfig syslog-ng on $ service syslog-ng start Starting syslog-ng: [ OK ] $ Systems using systemd: $ systemctl enable syslog-ng.service $ systemctl start syslog-ng.service Starting syslog-ng: [ OK ] $ Your new syslog-ng package is now up and running and ready to go! Configuring syslog-ng Clients Clients logging to the syslog-ng server don't need to have syslog-ng installed on them, a regular syslog client configuration will suffice. If you are running syslog-ng on clients, then you’ll need to modify your configuration file. Let’s look at the below example – Syslog-ng Sample Client Configuration. Syslog-ng Sample Client Configuration source s_sys { file ("/proc/kmsg" log_prefix("kernel: ")); unix-stream ("/dev/log"); internal(); }; destination loghost { udp("loghost.hosangit.com"); }; filter notdebug { level(info...emerg); }; log { source(local); filter(notdebug); destination(loghost); }; The s_sys source comes default in many syslong-ng.conf files, we have just added some additional parameters to make it work. Here the destination syslog logging server is defined as loghost.hosangit.com. We have also added a filter to the log section to make sure only the most urgent messages, info level and above (not debug), get logged to the remote server. After restarting syslong-ng on your client, your syslog server will start receiving messages. Logging your system messages to a remote server is a good security practice. With all servers logging to a central syslog server, it becomes easier to correlate events across your company. It also makes covering up mistakes or malicious activities harder because the purposeful deletion of log files on a server cannot simultaneously occur on your logging server, especially if you restrict the user access to the logging server. syslog-ng can be used to collect local syslog messages & monitor log files on your servers and then forward them to a collector. syslog-ng OSE is an open source alternative to the standard syslog daemon that's commonly found on UNIX and UNIX-like (*nix) systems. It uses the basic syslog protocol, but extends it with content-based filtering, flexible configuration options and adds important features, such as using TCP (as well as TLS), which is much more reliable than UDP. Installation - Using a Package Manager Depending on your Linux distribution you can use yum or APT (do this with root or sudo privileges): # apt-get install syslog-ng You will most likely need to enable Extra Packages for Enterprise Linux (EPEL) # yum install syslog-ng Configure either using our Configure-syslog script or manually. Compiling From Source Download syslog-ng source code & eventlog source code. Install both eventlog & syslog-ng. Eventlog is a generic event logging library developed by Balabit. Once you've unzipped both packages (evenlog_x.x.xx.tar.gz & syslog-ng-x.xx.tar.gz), do this in each of those directories: $ ./configure $ make $ sudo make install Check your syslog-ng version You'll need to know which version of syslog-ng you've got installed. We recommend running on the latest, but at least version 3.2 for best results. Configure syslog-ng The /etc/syslog-ng/syslog-ng.conf file The main configuration file for syslog-ng is the /etc/syslog-ng/sylog-ng.conf file but only rudimentary help on its keywords can be found using the Linux man pages. $ man syslog-ng.conf Simple Server Side Configuration for Remote Clients Below is a sample syslog-ng.conf file and outlines some key features. The options section that covers global characteristics is fully commented, but it is the source, destination and log sections that define the true strength of the customizability of syslog-ng. Sample syslog-ng.conf File options { # Number of syslog lines stored in memory before being written to files sync (0); # Syslog-ng uses queues log_fifo_size (1000); # Create log directories as needed create_dirs (yes); # Make the group "logs" own the log files and directories group (logs); dir_group (logs); # Set the file and directory permissions perm (0640); dir_perm (0750); # Check client hostnames for valid DNS characters check_hostname (yes); # Specify whether to trust hostname in the log message. # If "yes", then it is left unchanged, if "no" the server replaces # it with client's DNS lookup value. keep_hostname (yes); # Use DNS fully qualified domain names (FQDN) # for the names of log file folders use_fqdn (yes); use_dns (yes); # Cache DNS entries for up to 1000 hosts for 12 hours dns_cache (yes); dns_cache_size (1000); dns_cache_expire (43200); }; # Define all the sources of localhost generated syslog # messages and label it "d_localhost" source s_localhost { pipe ("/proc/kmsg" log_prefix("kernel: ")); unix-stream ("/dev/log"); internal(); }; # Define all the sources of network generated syslog # messages and label it "d_network" source s_network { tcp(max-connections(5000)); udp(); }; # Define the destination "d_localhost" log directory destination d_localhost { file ("/var/log/syslog-ng/$YEAR.$MONTH.$DAY/localhost/$FACILITY.log"); }; # Define the destination "d_network" log directory destination d_network { file ("/var/log/syslog-ng/$YEAR.$MONTH.$DAY/$HOST/$FACILITY.log"); }; # Any logs that match the "s_localhost" source should be logged # in the "d_localhost" directory log { source(s_localhost); destination(d_localhost); }; # Any logs that match the "s_network" source should be logged # in the "d_network" directory log { source(s_network); destination(d_network); }; In our example, the first set of sources is labeled s_localhost. It includes all system messages sent to the Linux /dev/log device, which is one of syslog's data sources, all messages that syslog-ng views as being of an internal nature and additionally inserts the prefix "kernel" to all messages it intercepts on their way to the /proc/kmsg kernel message file. Like a regular syslog server which listens for client messages on UDP port 514, syslog-ng also listens on TCP port 514. The second set of sources is labeled s_network and includes all syslog messages obtained from UDP sources and limits TCP syslog connections to 5000. Limiting the number of connections to help regulate system load is a good practice in the event that some syslog client begins to inundate your server with messages. The above example also has two destinations for syslog messages, one named d_localhost, the other, d_network. These examples show the flexibility of syslog-ng in using variables. The $YEAR, $MONTH and $DAY variables map to the current year, month and day in YYYY, MM and DD format respectively. Therefore the example: /var/log/syslog-ng/$YEAR.$MONTH.$DAY/$HOST/$FACILITY.log refers to a directory called /var/log/syslog-ng/2005.07.09 when messages arrive on July 9, 2005. The $HOST variable refers to the hostname of the syslog client and will map to the client's IP address if DNS services are deactivated in the options section of the syslog-ng.conf file. Similarly the $FACILITY variable refers to the facility of the syslog messages that arrive from that host. Using syslog-ng in Large Data Centers Below example is a sample syslog-ng.conf file snippet that defines some additional features that may be of interest in a data center environment. More Specialized syslog-ng.conf Configuration options { # Number of syslog lines stored in memory before being written to files sync (100); }; # Define all the sources of network generated syslog # messages and label it "s_network_1" source s_network_1 { udp(ip(192.168.1.201) port(514)); }; # Define all the sources of network generated syslog # messages and label it "s_network_2" source s_network_2 { udp(ip(192.168.1.202) port(514)); }; # Define the destination "d_network_1" log directory destination d_network_1 { file ("/var/log/syslog-ng/servers/$YEAR.$MONTH.$DAY/$HOST/$FACILITY.log"); }; # Define the destination "d_network_2" log directory destination d_network_2 { file ("/var/log/syslog-ng/network/$YEAR.$MONTH.$DAY/$HOST/$FACILITY.log"); }; # Define the destination "d_network_2B" log directory destination d_network_2B { file ("/var/log/syslog-ng/network/all/network.log"); }; # Any logs that match the "s_network_1" source should be logged # in the "d_network_1" directory log { source(s_network_1); destination(d_network_1); }; # Any logs that match the "s_network_2" source should be logged # in the "d_network_2" directory log { source(s_network_2); destination(d_network_2); }; # Any logs that match the "s_network_2" source should be logged # in the "d_network_2B" directory also log { source(s_network_2); destination(d_network_2B); }; In this case we have configured syslog to: Listen on IP address 192.168.1.201 as defined in the source s_network_1. Messages arriving at this address will be logged to a subdirectory of /var/log/syslog-ng/servers/ arranged by date as specified by destination d_network_1. As you can guess, this address and directory be used by all servers in the data center. Listen on IP address 192.168.1.202 as defined in the source s_network_2. Messages arriving at this address will be logged to a subdirectory of /var/log/syslog-ng/network/ arranged by date as specified by d_network_2. This will be the IP address and directory to which network devices would log. Listen on IP address 192.168.1.202 as defined in the source s_network_2. Messages arriving at this address will also be logged to file /var/log/syslog-ng/all/debug.log as part of destination d_network_2B.This will be a single file to which all network devices would log. Server failures are usually isolated to single servers whereas network failures are more likely to be cascading involving many devices. The advantage of searching a single file is that it makes it easier to determine the exact sequence of events. As there could be many devices logging to the syslog-ng server, the sync option is set to write data to disk only after receiving 100 syslog messages. Constant receipt of syslog messages can have a significant impact on your system’s disk performance. This option allows you to queue the messages in memory for less frequent disk updates. Ref: http://www.balabit.com/sites/default/files/documents/syslog-ng-ose-3.3-guides/en/syslog-ng-ose-v3.3-guide-admin-en/html/bk01-toc.html

If you have ever had to manage a bind server you'll understand when I say that the named can get overwhelming with entries. I created this awk script to go through the named.conf file and export the data into a csv file that you can easily sort and view easily. ** Downloadable Only as a Subscribed User ** name2csv.txt name2csv.txt