14 October 2010

arrogance, personified

I see this in the overnights from the OpenJDK front:
IBM joins the OpenJDK community, will help unify open source Java efforts, with the salient 'pull quote'

It became clear to us that first Sun and then Oracle were never planning to make the important test and certification tests for Java, the Java SE TCK, available to Apache
This dovetails with my prior post

It's official -- Oracle is a profit maximizer and could care a hoot about being anything but dictate what is best to FOSS. But then you already knew that, right?

Not to sound arrogant, but we know how to deal with the Linux community
... naw, that does not sound arrogant, at all, Wim

08 October 2010

checklist RO rsync server

Setting up a new RO RSYNC server setup

The primary usage case is we describe is how to deploy a read-only RSYNC server with no end user accounts, to be used for distribution of content (here, to move a builder result archive that is intentionally NOT 'visible' from the internet to a more capable transfer server) From there, the content is integrated into a internal archiving server, and after that, to a publicly accessible binary archive, accessible through ftp, rpm, or yum

As before, we start with a freshly deployed, and hardened PMman instance. At all times, we will strive to follow proper sysadmin 'best practices' discipline under SElinux, wrappers and iptables

Install and enable rsync, which is the package holding the stock rsync daemon. As rsync supports wrappers, we also need the xinetd which is the package holding the stock inetd in recent Red Hat derived distributions -- Let's get started:

  1. yum can do the install trivially

    yum install rsync xinetd
  2. Then enable the needed services:

    /sbin/chkconfig rsync on
    /sbin/chkconfig xinetd on
  3. We need to do some configuration for the rsync daemon as to permissions and directories to serve:

    [root@trap64 etc]# cd /etc
    [root@trap64 etc]# cat rsyncd.conf
    # motd file = /etc/rsyncd.motd
    log file = /var/log/rsyncd.log
    pid file = /var/run/rsyncd.pid
    lock file = /var/run/rsync.lock

    [trap64]
    path = /var/ftp/pub/local
    comment = x86_64 fruit
    uid = nobody
    gid = nobody
    read only = yes
    list = yes
    # auth users = username
    # secrets file = /etc/rsyncd.scrt
    hosts allow = 10.0.0.0/24 127.0.0.0/24
    hosts deny = 0.0.0.0/0

    [root@trap64 etc]#
  4. Set up the iptables -- I do not recall the rsync daemon port off the top of my head, so I look it up:

    [root@trap64 etc]# grep rsync /etc/services | head -2
    rsync 873/tcp # rsync
    rsync 873/udp # rsync
    [root@trap64 etc]#

    ... so the port is 873

    # localhost can do all ...
    -A RH-Firewall-1-INPUT -i lo -j ACCEPT
    # ...
    # rsync daemon
    -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 10.0.0.0/8 --dport 873 -j ACCEPT
    # ...
  5. Open the wrappers

    #
    ALL: ALL@127.0.0.1
    #
    # ...
    #
    rsync: ALL@10.0.0.0/255.0.0.0
    #
  6. Restart the wrappers enforcing daemon

    [root@trap64 sysconfig]# /sbin/service xinetd restart
  7. Test it:

    [root@trap64 sysconfig]# rsync localhost::
    trap64 x86_64 fruit
    [root@trap64 sysconfig]#
  8. To put it into production on a client, we can use something like this:

    #!/bin/sh
    #
    # this file: /root/bin/update-archive.sh
    # Copyright (c) 2010 R P Herrold
    # License: GPLv3+
    #
    # ln -s /root/bin/update-archive.sh /etc/cron.hourly/
    #
    export PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
    umask 022
    # -- non local content goes into the mirror constellation
    [ ! -e /var/ftp/pub/mirror/pmman/RPMS/x86_64/ ] && \
    mkdir -p /var/ftp/pub/mirror/pmman/RPMS/x86_64/
    #
    # export VERBOSE="-v "
    export QUIET="-q "
    #
    /usr/bin/rsync -a ${VERBOSE} ${QUIET} --exclude=working \
    trap64.darkside.lan::trap64/pmman/RPMS/x86_64/. /var/ftp/pub/mirror/pmman/RPMS/x86_64/.
    chown -R root.root /var/ftp/pub/mirror/pmman/RPMS/x86_64
    #
  9. All done


Earlier in this series:

 Function  Link 
hardening http://www.pmman.com/usage/hardening/ 
 lftp  http://orcorc.blogspot.com/2010/08/mirroring-upstream-master-with-lftp-to.html 
 RO vsftpd  http://orcorc.blogspot.com/2010/07/checklist-ro-ftp-server-setup.html 
 RO NFS  http://orcorc.blogspot.com/2010/08/nfs-aide-to-memory.html 

06 October 2010

too funny

I mentioned in my last blog post:

More importantly, it seems that the sending email account webteam (at) bhphotovideo.com is unmonitored, although one has to assume an e-commerce vendor DOES have a 'webteam'. How curious

Having a unmonitored email sending role account is fine, of course; driving responses into a webbish workflow is fine as well; but why not use something obvious not a monitored account like: noreply@ ... or unmonitored@ ... instead

After I submitted feedback through their web workflow form, I received a confirmation email containing this:

If for any reason you have any additional questions, thoughts or comments, please feel free to email us at webmaster (at) bhphotovideo.com, as we would be happy to hear from you.

So ... the right hand does not know what the left is doing?

Lost password #FAIL

The file with my old saved password (a strong one: see: a prior post on the topic) for an e-commerce site was inadvertently deleted. No particular reason to chase the backup file out, as there was a lost password mailer. And so, I had occasion to use the 'lost password link' of that site today

Date: Wed, 6 Oct 2010 12:13:36 -0400 (EDT)
From: webteam (at) bhphotovideo.com
To: herrold (at) ...
Subject: Your Password from bhphotovideo.com
----------------------------------------

Dear Russell Herrold

Thank you for your inquiry. Here's your password:

t3f38RbMMweRhg

We look forward to your next visit to our site. Please feel free
to let us know if there's any other way we may assist you.

Thank you,
The B&H Web Team
www.bhphotovideo.com
NNN Ninth Avenue
New York, NY 10001, USA
800-606-asdf
212-444-qwer
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is an automated email response and cannot be replied to.

A couple threshold matters: I changed the password value they sent me to something similar. More importantly, it seems that the sending email account webteam (at) bhphotovideo.com is unmonitored, although one has to assume an e-commerce vendor DOES have a 'webteam'. How curious

Having a unmonitored email sending role account is fine, of course; driving responses into a webbish workflow is fine as well; but why not use something obvious not a monitored account like: noreply@ ... or unmonitored@ ... instead?

Back to the topic at hand. That is: The 'lost password' mailer sent me a unhashed, plaintext prior password, and when using so, did NOT require an immediate change of credential when I used it to log in

There was a 'feedback form' on their site, and so I sent along this:

email is inherently insecure as it cannot be protected from being read by people 'along the way' on the transfer (such as the ISP of the server that received the email)

Sending a 'reset your password' one time link, and noting a credential change in a permanent part of an account history, is pretty basic

Not having this in you user account management interface, and sending a prior password in plaintext are a big red warning sign. I am left to wonder: Would they also disregard credit card data security [CISP/now PCI] credit card 'hashing' and no saved plaintext' credentials restrictions ;(

There is an old saying: A chain is only as strong as its weakest link ... I think we found a weak one here