Commentary So Long CrunchBang, And Thanks For All The Fish

2 Comments

They say nothing lasts forever, and sadly that statement seems to have been proven true again. Yesterday, Philip Newborough (aka corenominal) announced that he would no longer be developing CrunchBang Linux.

In his post, Philip stated that he felt that it “…no longer holds any value…,” and that “… it would be in the best interest of its users, who would benefit from using vanilla Debian.” I couldn’t disagree more Philip. For those of us who were trying to escape the trappings of increasingly bloated distributions like Ubuntu, Fedora, Mint, and their ilk, CrunchBang, with its light-weight Openbox window manager, was an asylum. A minimalist distribution; designed to be efficient and customizable, CrunchBang struck the right balance between speed and functionality. I still think there is a demand for such a distribution.

I can’t tell you how profoundly sad I am about this news. I of course wish Philip the very best in whatever the future may bring. He should be very proud of his creation, and he should know that CrunchBang Linux will always hold a special place in my heart.

Tags: , ,

News Now HTTPS

1 Comment

Over this past weekend I reconfigured this site to use HTTPS by default. This is something I’ve been interested in doing for some time, partly due to a desire to improve general online security in the wake of the Edward Snowden revelations, but also because Google recently announced that they would be begin using HTTPS as a ranking signal. SEO means little to me from a financial perspective – I sell no ads on this site, nor will I, but I am interested in getting the information on this site securely to the people who search for that information.

Anyway, please advise if you encounter any difficulties or anomalies when using the site. And, as always, thanks for visiting.

Tags:

News Blame The Spammers

7 Comments

When I first started this blog I wanted those that visited here be free to leave comments without the need for said comments to be approved before they were posted. Unfortunately the amount of spam I’m getting now exceeds my ability to keep up with them. So, from now on those that leave a comment will need to wait for me to approve it before it’s posted. If you’re a spammer, your comment will not be approved. If you’re not a spammer I will approve your comment as soon as possible, likely within 24 hours.

This was bound to happen at some point I guess. My apologies. Blame the spammers.

Tags:

BSD How To Setup And Configure FreeBSD As A Syslog Server

0 Comments

I’ve grown tired of connecting to each host individually in my network to examine their log files. In addition to logging events locally, I would like these hosts to send their logs to a designated host in my network, resulting in a single location where I can examine and analyze all logs.

This post describes how to setup and configure a machine running FreeBSD to be a system log or “syslog” server, receiving incoming log events from other hosts in the network. A second machine, also running FreeBSD, will be configured to send its log events to the syslog server.

For purposes of example, we’ll use the hostname “server” for the machine hosting our our syslog server, and “client” for the other machine – the one sending its log events to the syslog server. All steps involved assume that FreeBSD is installed and operating correctly on both machines. All commands are issued as the root user.

The versions for the software used in this post were as follows:

  • FreeBSD 10.0-RELEASE
  • Let’s get started…

    Configure the syslog server

    First, we need a file in server’s /var/log directory to host the log events coming from client. For our example, we’ll make this file name the same as client’s hostname. While you don’t need to use the .log extension, I find it helpful as it clearly indicates the purpose of the file:

    touch /var/log/client.log
    

    Next we need to add a couple of options to syslogd, the FreeBSD utility that reads and logs messages to the system console and log files. Open server’s /etc/rc.conf file and add the following line, substituting the IP network and network mask for your own:

    syslogd_flags="-4 -a 192.168.1.0/24 -vv"
    

    The -4 (IPv4) option forces syslogd to listen for IPv4 addresses only.

    The -a (allowed_peer) option specifies which clients are allowed to log to this syslog server. This option can take the form of IP address/mask:service, such as “-a 192.168.10.1/24:*” (the `*’ character permits packets sent from any UDP port), or hostname.domain, such as “-a client.home”, or “-a *.home” (assuming that the hostname can be successfully resolved to the correct IP address in the network). Multiple -a options may be also be specified. In this example, allowed_peer will the form of any host within an entire IP network, in this case 192.168.1.0/24.

    Finally, the -v opton indicates verbose logging. If -v is specified once, the event’s numeric facility and priority will be added to the log. If specified more than once, the names of the event’s facility and priority (e.g., “user.notice”) are also added to the log.

    Now we need to add some lines to server’s /etc/syslog.conf file, the configuration file for syslogd. First, the name of server’s hostname, preceeded by a + character, must be added to top of the file – before any existing syslog options (i.e., right before *.err; …, etc.) – so that those existing options will be applied only to log events generated by locally by server. If we did not add this line then all those options would also be applied to the log events that arrive from client. In other words, any options after a +(some_hostname) in the this file will apply until the next +(some_hostname) is parsed:

    +server
    

    Then add following lines to the bottom of /etc/syslog.conf after the last !* , substituting the .home domain for your own:

    +client.home
    *.*	/var/log/client.log
    

    The first line specifies that remote log events will be arriving from client. client can be specified using either its hostname or its IP address. Note that when using a hostname the domain name must be appended to it. In either case, the hostname.domain or host ip address is preceded by a + character.

    The second line contains parameters to control the handling of incoming log events from client, specifically a selector field followed by an action field. The syntax of the selector field is facility.level. The facility portion describes which subsystem generated the message, such as the kernel or a daemon, while the level portion describes the severity of the event that occurred. Multiple selector fields can be used for the same action and should be separated using a semicolon (;). In our example we’ll use the * characters in the selector field to match any log events received by client.

    The action field denotes where to send the log message. In our case, log events will be sent to the log file we created previously. Note that spaces are valid field separators in FreeBSD’s /etc/syslog.conf file. However, other nix-like systems still insist on using tabs as field separators. If you are sharing this file between systems, you may want to use only tabs as field separators.

    Managing the log files

    The file /var/log/client.log will grow over time, making it difficult to locate useful event information as well as taking up disk space. FreeBSD mitigates this problem using using newsyslog, a built-in utility that, among other things, periodically rotates and compresses log files. newsyslog is scheduled to run periodically by the system crontab (/etc/crontab). In its default configuration, it runs every hour.

    newsyslog reads from its configuration file, /etc/newsyslog.conf in order to determine which actions to take. This file contains one line for each log file that newsyslog manages. Each line is comprised of various fields which control the log file’s owner and group, permissions, and when the log file should be rotated. In addition there are several optional fields for controlling log file compression and programs that should be signaled when the log file is rotated. Each field is separated with whitespace.

    In order to have newsyslog recognize client’s log file, we’ll place the following line at the botton of /etc/newsyslog.conf:

    /var/log/client.log		640		5	100		*	JC
    

    In this example, the file permission for /var/log/client.log is set to 640. newsyslog will retain up to five archive files, and rotate the file when its size reaches 100 kB. The * character in the when column instructs newsyslog to ignore a time interval, a specific time, or both and instead only consider the size of the file when determining whether or not to rotate the file. The J flag tells newsyslog compress the rotated log file using bzip2, and the C flag tells newsyslog to create the log file if it does not already exist.

    Finally, let’s restart syslogd and newsyslog on server:

    service -v syslogd restart
    service -v newsyslog restart
    

    Configure the client

    Let’s move on now and configure client so that it will send its event logs to server. Open client’s /etc/syslog.conf file and add the following line after the last !*, to instruct client to send log events of any facility and level to server:

    *.*   @server
    

    server can be specified using either its hostname, hostname.domain or its IP address, preceded by a @ character.

    Now let’s restart syslogd on client:

    service -v syslogd restart
    

    Finally, let’s make sure client is sending its log events to server using the logger utility. Logon to client and issue the follow command:

    logger This message is from client
    

    Now login to server and and check client’s log file:

    tail /var/log/client.log
    

    You should see the message you sent using the logger utility:

    Aug  2 12:54:14 <user.notice> test.home iceflatline: This a test message from client
    

    Conclusion

    That’s it. In addition to logging events locally, the client host will send its logs to our syslog server, resulting in a single location where log events can be examined and analyzed.

    References

    NEWSYSLOG(8)
    NEWSYSLOG.CONF(5)
    SYSLOGD(8)
    SYSLOG.CONF(5)

    Tags: , ,

    Networking How To Assign Static IP Addresses to OpenVPN Clients In pfSense

    3 Comments

    (20150120 – Steps were added to this post to address an issue resulting from system reboot — iceflatline)

    This post describes how to configure the OpenVPN server in pfSense to assign static IP addresses to its remote access client hosts.

    pfSense (i.e., “making sense of packet filtering”) is a customized version of FreeBSD tailored specifically for use as a perimeter firewall and router, and can be managed entirely from a web-based or command line interface. In addition to being a firewall and routing platform, pfSense includes a long list of other features, as well as a package system allowing its capabilities to be expanded even further. pfSense is free, open source software distributed under the BSD license.

    OpenVPN is a lightweight VPN software application supporting both remote access and site-to-site VPN configurations. It uses SSL/TLS security for encryption and is capable of traversing network address translation devices and firewalls. The OpenVPN community edition is free, open source software and portable to most major operating systems, including Linux, Windows 2000/XP/Vista/7, OpenBSD, FreeBSD, NetBSD, Mac OS X, and Solaris. It is distributed under the GPL license version 2.

    All steps involved assume that pfSense and its OpenVPN server are installed and operating correctly. The versions for the software used in this post were as follows:

  • pfSense v2.1
  • Let’s get started…

    Connect to your pfSense firewall using SSH and open /var/etc/openvpn/server1.conf. Ensure that this configuration file contains the following line pointing to a valid directory for containing OpenVPN client host configuration files. The default directory in pfSense for this purpose is /var/etc/openvpn-csc. You can change this directory if you wish but for our example we’ll retain the default:

    	
    client-config-dir /var/etc/openvpn-csc
    

    In this directory we will create a file for each remote access client host we want the OpenVPN server to assign a static IP address to. The file name of each file must be the same name as the client host’s OpenVPN SSL certificate. For example, if you would like to configure a static IP for a client host with the certificate name “bob” then create the following file:

    cd /var/etc/openvpn-csc	
    touch /var/etc/openvpn-csc/bob
    

    Open this newly created file and add the following line, which contains a pair of IP addresses from the IPv4 virtual network you’ve configured for private communications between the OpenVPN server and your client hosts. Note that you cannot use just any pair of addresses from within this subnet. Each pair of ifconfig-push addresses represent the OpenVPN client and server IP endpoints. They must be taken from successive /30 subnets in order to be compatible with Windows client hosts and the TAP-Windows driver. Specifically, the last octet in the IP address of each endpoint pair must be taken from set defined in the “Configuring client-specific rules and access policies” section of the OpenVPN HOWTO. In this example, our OpenVPN server is using the virtual network 192.168.20.0/24 and we’ve chosen an appropriate pair of endpoint addresses to use from this subnet. Note that the first IP address in following line is the IP address assigned to the client host, the second is the address the server uses:

    ifconfig-push 192.168.20.6 192.168.20.5
    

    Once you’ve added this line to /var/etc/openvpn-csc/bob you’ll need to restart the OpenVPN server in pfSense. You can do this from Status->Services in the pfSense “webConfigurator” interface.

    Note that any files added to /var/etc/openvpn-csc will be deleted by the system if it reboots. To protect these files you can use the chflags utility to set the system immutable flag on the file. Once this flag is set, no one can delete or modify file, including root. You must be a root user to setup or clear the immutable flag:

    chflags schg /var/etc/openvpn-csc/bob
    

    To verify that the immutable flag has been set:

    ls -lo /var/etc/openvpn-csc/bob
    

    Output:

    -rw-r--r--  1 root  wheel  schg 42 Jan 20 15:58 bob
    

    To clear the immutable flag:

    chflags noschg /var/etc/openvpn-csc/bob
    

    Conclusion

    There you have it. Some minor configuration of your pfSense machine and its OpenVPN server will start assigning static IP addresses to the remote access client hosts you designate.

    References

    http://openvpn.net/index.php/open-source/documentation/howto.html

    Tags: , ,