Allowing ORANGE access to smoothwall’s NTP server

June 13th, 2009 by Dave · No Comments

For security reasons, a default install of Smoothwall 3.x isn’t designed to allow machines other than those on the GREEN network to use the NTP server running on the Smoothwall machine. But I find this is a bit annoying because the Smoothwall has a nice default ntpd config that synchronizes with a large group of random, publicly accessible time servers, and I’d rather not have to duplicate this on other machines, nor setup a timeserver in the GREEN network just to serve NTP requests to the ORANGE network. So here’s what I did to enable ORANGE connections to the NTP server on a Smoothwall install:

  1. First, let’s create a new modification directory in the standard Smoothwall location. I’m calling my extension ‘ntp_orange’:
    cd /var/smoothwall/mods
    mkdir ntp_orange
    
  2. Now, let’s follow the Smoothwall pattern for startup scripts by creating our script to enable NTP access within subdirectories like this:
    cd ntp_orange
    mkdir -p etc/rc.d
    
  3. Finally, let’s create our actual script to modify the system.
    vim etc/rc.d/rc.netaddress.up
    

    And then paste the following into the editor:

    #!/bin/sh
    
    # Source the standard smoothwall settings variables.
    . /var/smoothwall/ethernet/settings
    
    # Ensure the ntp.conf file contains instructions to listen on the orange
    # interface.  This is necessary because anytime the user edits the time
    # server settings page through the web interface, this setting goes away.
    NEW_LINE="listen on $ORANGE_ADDRESS"
    FILEPATH="/var/smoothwall/time/ntpd.conf"
    grep "$NEW_LINE" "$FILEPATH" > /dev/null
    if [ "$?" -eq "1" ]; then
      (
      echo $NEW_LINE
      cat $FILEPATH
      ) > ${FILEPATH}_TMP
      rm $FILEPATH
      mv ${FILEPATH}_TMP $FILEPATH
    fi
    
    # Restart the ntpserver.
    /usr/bin/smoothcom ntpdrestart
    
    # Insert a firewall rule to allow NTP packets on the ORANGE interface to
    # be accepted.
    # NOTE: Rule index 13 is designed to be after the rules for ipblocks,
    # spoofing, etc.  including the rules that accept all traffic on the loopback
    # and GREEN interfaces.
    iptables -I INPUT 13 -p UDP -i $ORANGE_DEV --dport 123 -j ACCEPT
    

    You can see that I’m sourcing the standard Smoothwall settings script to get the current definition of what interface and addresses are assigned to the ORANGE interface.

    I then have a block of code that checks to see if we’ve already configured NTP to listen on it’s ORANGE interface. If it is already configured, no modifications are made. But if it wasn’t, we simply insert the appropriate line at the beginning of the ntpd.conf file.

    Next, the script restart’s the Smoothwall’s NTP server.

    And finally, the script inserts a firewall rule to ensure the Smoothwall will additionally allow only UDP NTP connections from the ORANGE interface. Because this rule is limited to NTP’s port 123, and the UDP protocol, I figure this isn’t too much of a security hole.

  4. Then, to ensure our script gets run after reboots, we modify the file
    /etc/rc.d/rc.netaddress.up

    and append these lines at the very end:

    echo "Allowing NTP requests from ORANGE interface"
    . /var/smoothwall/mods/ntp_orange/etc/rc.d/rc.netaddress.up
    
  5. And lastly, either reboot your Smoothwall, or directly execute your new extension script. I would recommend that you actually do both: first, directly execute the script to ensure you had no cut and paste errors, etc. You can then verify the ntpd.conf file contains what you expected:
    cat /var/smoothwall/time/ntpd.conf
    

    and verify iptables contains the new INPUT rule:

    iptables -L INPUT -v -vv
    

    Once you know those are correct, do a reboot and then test them again to ensure you’ve gotten things working on reboot.

Good luck!

→ No CommentsTags: Hardware · IT/Network

What Brown Can Do For Me

June 28th, 2008 by Dave · 1 Comment

What Brown Can Do For Me:  Do your freaking job and get me my package!  I’ve not been happy with UPS for a long time but this kinda takes the cake.   I didn’t get my TSU9400 yesterday like I expected because UPS decided to have it stop in the middle of the flood-ravaged midwest states on its way from the store’s warehouse in Pennsylvania to Texas where, of course, they promptly delayed further shipping due to inclement weather.   Why would you send newly shipped packages into disaster areas??? Route around that.   I thought these people were supposed to be experts in logistics?

Since I’m already complaining about UPS, let me tell you about the thing that most ignores me.  They never ring the doorbell when the deliver to my house.  Absolutely.  Never.   Even when I have taped a sign to the door saying “I’m home.  Please ring bell over there” and I draw a nice little arrow pointing right at the thing.  They’ve still not rung the bell!  I’ve had UPS leave multiple packages that required signatures sitting on the stoop when I or someone else has been home.   I don’t like this for two reasons.  First I don’t like them leaving packages worth thousands of dollars sitting out where any Joe Schmoe wandering by can pick them up and walk off with them.   Second, I don’t like when they leave perishable items like food sitting in the Texas heat.   Is it too much to ask the driver to frickin’ push the button?  It’s not like he has to sit around and wait for an answer (but he should wait when a signature is required!)  Hell, the FedEx guy is already driving away when I get to opening the door, but at least he pushed the button.  Even when I don’t have a sign taped to the door!   Perhaps UPS drivers just can’t read?

Dammit, get me my package.  If all online retailers offered a choice, I’d never, ever, ever use “Brown” again.

→ 1 CommentTags: Uncategorized

Pronto TSU9400

June 24th, 2008 by Dave · No Comments

Man, it’s been a long-time since I posted.  I’m gonna break that streak by first admitting that I’m a clumsy idiot.  You see, Kimberly and I have recently gotten ourselves a Wii and while playing Wii sports, I hit our older black-and-white screened Pronto remote off of the back of a chair.  Normally, it falls onto the carpeted floor rather harmlessly, but this time it’s fragile LCD was hit squarely into the sharp corner of the new Wii sitting on the floor behind the chair.  The sound of shattering glass (or is it plastic) was rather disconncerting.  While the remote’s hard buttons still work, the touchscreen was now toast since the spider-web of cracks borked the ability to sense the location of a finger.

Now comes the fun part of this post.  We’ve just rectified our problem of having to have 5 remotes on hand by ordering a brand new Pronto TSU9400.   While it is a bit of a pricey item, it turns out that getting a new TSU3500 (which is what I broke)  wasn’t that much less in cost. (That’s me rationalizing btw.)  Okay, I admit it, the TSU9400 costs twice as much.  Anyway, the TSU9400 is supposed to arrive on Friday and then I’ll spend the weekend porting our programming to the new device.

I’m psyched about the new remote as it has a few more hard buttons, targeted at those heavy DVR users it seems — which we definitely are — plus it has a high res color screen.  That color screen should seriously aid our ability to create a quality user interface that makes it easy to distinguish actionable buttons vs descriptive text, common buttons from infrequently used ones, etc.   Finally, this Pronto claims to be activity-based rather than equipment-based — which I’m hoping means it has some memory or state storage so it can tell if devices are already on or off, etc.  We’ll see soon!

→ No CommentsTags: Home Theater

Installing Mailman To Use HTTPS On CentOS 5.1

March 30th, 2008 by Dave · 2 Comments

In starting up my new Python web-app project that I’ve blogged a bit about, I realized that I needed to setup a mailing list or two in order to keep the few people working on it all on the same page. Besides just having a list for development discussions among a distributed group of people, it is very handy to have SVN send out e-mail notices to everyone about commits. I could have used something like Majordomo or ezmim, but I like the features of Mailman - primarily the ability for users to subscribe, unsubscribe, etc. via a web page as well as through e-mail. I could have also just used an alias in the MTA config, but that doesn’t allow new developers to sign up on their own.

The following documents my notes along the way to installing and configuring Mailman on a CentOS 5.1 box such that its web pages are accessible only through https. It is important to note that I’m talking about an installation from scratch here. If you’re upgrading a previous installation from either an older mailman, or an older version of CentOS, then the following is NOT for you.

  1. As I had hoped, the CentOS base repo provides an RPM for the latest release of Mailman which, according to the GNU webpage for Mailman is version 2.1.9. You can install this as:
    $ sudo yum install mailman-2.1.9-2

    If you read the description of this package, you’ll see that it installs a special install instructions file into /usr/share/doc/mailman-2.1.9/INSTALL.REDHAT. You might want to read this yourself, but basically, it leads you through the following steps if you’re running your MTA (i.e. mailserver) on the same host as your web (httpd) server. You should note that the RedHat RPM does NOT install Mailman such that its configuration pages are accessible only through HTTPS. The following instructions include extra steps to make sure that this is true.

  2. Edit the newly installed file /etc/httpd/conf.d/mailman.conf to customize it for your host. In particular, edit the last line and replace the http://www.example.com with your own site’s hostname after an https:// prefix. It should end up looking something like this:
    RedirectMatch ^/mailman[/]*$ https://davmp.kimanddave.com/mailman/listinfo
  3. You’ll need to insert two RewriteRule lines in your httpd config files to redirect all non-https requests for Mailman features to the https site. And if you don’t have any rewrite features setup elsewhere, you’ll need a couple of other lines. You can find out the most about this process by reading the Apache docs for the RewriteEngine here. But, since I’ve already got a virtual host file that represents the config I want to have Mailman show up as a part of, I simply added lines like the following:
    <virtualhost _default_:80>
       ...
       RewriteEngine        on
       RewriteCond          %{HTTPS} !=on
       RewriteRule          ^/mailman/(.*) https://davmp.kimanddave.com/mailman/$1 [L,R]
       RewriteRule          ^/pipermail/(.*) https://davmp.kimanddave.com/pipermail/$1 [L,R]
    </virtualhost>
    
    <virtualhost *:443>
       ...
       Include "conf.d/mailman.conf.include"
    </virtualhost>

    And then renamed /etc/httpd/conf.d/mailman.conf to /etc/httpd/conf.d/mailman.conf.include. These settings prevent Apache from allowing these URLs to work for any other virtual hosts.

  4. Test your configuration changes by running
    $ apachectl -t

    This will print out <code>Ok</code> if everything is syntactically correct. Once you’ve fixed any issues, go ahead and restart the webserver via a command of:

    $ sudo /sbin/service httpd restart
  5. Create your site password for mailman by running
    $ sudo /usr/lib/mailman/bin/mmsitepass

    Contrary to the RedHat instructions, you do not need to type a password on the command line as you will be prompted for it. Clearly it is safer to type it at the prompt.

    Running this command sets the site password in to /etc/mailman/adm.pw so you do need to run it as sudo — don’t forget that the first password prompt will be for your sudo request if you haven’t run anything else sudo in a while. :-) This password will be accepted anywhere an individual user or mailman administrator password would be accepted, so make sure you’ll remember this in case you need to reset other passwords in your Mailman installation.

  6. (OPTIONAL) Setup the site-wide “list creator” role password by doing
    $ sudo /usr/lib/mailman/bin/mmsitepass -c

    This password can be given to those whom you want to have the ability to create and delete mailing lists through the web but without the risk of letting them change the mailman config itself.

  7. Edit /etc/mailman/mm_cfg.py. There is code in here to try and autodetect your domain names, but it’s probably safest to make it explicit. To do that, start with the line from socket import * and comment out (prepend with an #) all lines down to the one that sets the DEFAULT_MAIL_HOST variable. Then insert two lines to set up your explicit values. You should end up with something like this:
    #from socket import *
    #try:
    #    fqdn = getfqdn()
    #except:
    #    fqdn = 'mm_cfg_has_unknown_host_domains'
    #
    #DEFAULT_URL_HOST   = fqdn
    #DEFAULT_EMAIL_HOST = fqdn
    DEFAULT_URL_HOST   = "davmp.kimanddave.com"
    DEFAULT_EMAIL_HOST = "kimanddave.com"
  8. Ensure that Mailman renders its own URLs with the https scheme by appending the following line to the /etc/mailman/mm_cfg.py file.
    DEFAULT_URL_PATTERN = 'https://%s/mailman/'
  9. (ASIDE) If you had previous mailing lists configured, this is where you’d update Mailman’s files to use this new info by running
    $ sudo /usr/lib/mailman/bin/update

    but we can skip that since we’re a new install.

  10. Create the “site-wide” mailing list, also known as the one that Mailman password reminders come from. Usually this is called mailman but you can use any value you want as long as you set MAILMAN_SITE_LIST to the same value in /etc/mailman/mm_cfg.py. Let’s use this default and set this up by running
    $ sudo /usr/lib/mailman/bin/newlist mailman

    and then follow the prompts. Note that this MUST be done prior to starting up the Mailman daemon.

    Also note that this command will output a list of mail aliases after you answer a few prompts. Copy and paste these lines into your MTA’s aliases configuration. The simplest way to do that is to edit /etc/aliases (because most MTA’s respect the contents of that file) and append these lines to the end, then, after saving that file, run the newaliases command.

  11. It is now time to start the Mailman daemon! Do this with a command like:
    $ sudo /sbin/service mailman start

    Its important to note that the RedHat packagers do not ship RPMs that enable services as part of the installation, so you’ll need to enable the service as well if you want mailman to work after a reboot. You can do this with a command like:

    $ sudo /sbin/chkconfig --level 345 mailman on
  12. Add yourself to your new mailman mailing list. Do this by visiting your host’s mailman list info page at https://your.host.name/mailman, click the Mailman link at the bottom left, and use the resulting form to subscribe your e-mail address.
  13. If you want your mailing lists to be completely public, you’re done. You do NOT need to follow the remaining steps!
  14. If you want to limit who can access your mailing list web pages, then I recommend editing the /etc/httpd/conf.d/mailman.conf.include configuration file to put in lines to require authentication. Something like this would be a very basic authentication requirement, though you could also use LDAP, MySQL, etc. databases but setting those up are a whole separate topic.
    AuthType Basic
    AuthName "mysite"
    AuthUserFile /etc/httpd/auth/passwords
    AuthGroupFile /etc/httpd/auth/groups
    Require group mailman

    Of course, you’ll need to read up on using authentication files with Apache here.

→ 2 CommentsTags: IT/Network · Uncategorized