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

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

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