security & privacy
Zenoss jobs mailing list: Mistakes to avoid
Oh, how unfortunate: Zenoss, most likely not by malice but because they were not paying close enough attention to social netiquette, committed a big no-no: they decided that everyone whose email address they had on record was to be automatically added to their new jobs-related mailing list, no confirmation required.
Of course, now people are — some pretty aggressively — complaining and demanding to be removed from the list, and this makes matters worse because their list server is configured so that all replies go out to everybody on the list.
In the process, these unhappy responders’ signatures with work phone number, etc, are in turn published for everybody to see/collect.
And, to make matters worse, their list server does not properly weed out out-of-office messages and these, too, have become part of the email storm.
So, how could you avoid the same mistake(s)?
- When launching a new mailing list, it’s OK to *tell* people about it but the list itself should be opt-in (ideally double opt-in), never opt-out
- Even so, make sure that all emails sent from your list server contain a prominent link allowing your users to easily unsubscribe
- Configure your list server properly! Have a professional marketer do it for you it that’s not your thing. Do not underestimate what could go wrong: this is real-time communication, you do not have a safety net.
Update: - June 18th
Uh-oh. What was, I am sure, a misguided act, is starting to elicit more “hateful” reactions. I hope the Zenoss people address the issue before things get too ugly.
If you enjoyed this post, make sure you subscribe to my RSS feed!
How To Make The EFF ISP Throttling Tool Work On Leopard
I love the idea of Switzerland, the new EFF tool for checking ISP throttling; unfortunately as of release Zero.0.5, Leopard seems to still be a mere afterthought. Here is how I worked around the few things that were not working out of the box.
First, Switzerland is written in Python and will require Psyco. It’s a good thing since Psyco is all about performance. If you do not have it already installed:
svn co http://codespeak.net/svn/psyco/dist/ psyco-dist cd psyco-dist/ sudo python setup.py install cd .. |
Download Switzerland from https://sourceforge.net/project/showfiles.php?group_id=233013
Extract it and change to its directory; eg
tar zxvf switzerland-0.0.5.tgz cd switzerland-0.0.5 |
The FastCollector provided doesn’t work. So…
rm bin/FastCollector.darwin |
Now when we build FastCollector, it will be available in /usr/local/bin/FastCollector
Here comes the only moderately scary thing for non-developers. Use the patch command to modify switzerland/client/PacketListener.py. This is the input for patch:
diff --git a/switzerland/client/PacketListener.py b/switzerland/client/PacketListener.py index 211b68f..dc0bbcc 100755 --- a/switzerland/client/PacketListener.py +++ b/switzerland/client/PacketListener.py @@ -93,8 +93,7 @@ class PacketListener(threading.Thread): p = platform.system() # Implementing the recommendations from # http://www.net.t-labs.tu-berlin.de/research/hppc/ - if p[-3:] == "BSD" or p == "Darwin": - print p + if p[-3:] == "BSD": cmd = ["sysctl","-w","net.bpf.bufsize=10485760"] try: # Recent FreeBSDs proc = Popen(cmd, stdin=PIPE, stdout=PIPE) @@ -110,6 +109,14 @@ class PacketListener(threading.Thread): proc = Popen(cmd, stdin=PIPE, stdout=PIPE) assert proc.wait() == 0 + elif p == "Darwin": + cmd = ["sysctl","-w","debug.bpf_bufsize=10485760"] + proc = Popen(cmd, stdin=PIPE, stdout=PIPE) + assert proc.wait() == 0 + cmd[2] = "debug.bpf_maxbufsize=10485760" + proc = Popen(cmd, stdin=PIPE, stdout=PIPE) + assert proc.wait() == 0 + elif p == "Linux": vars = [("/proc/sys/net/core/rmem_default", "33554432"), ("/proc/sys/net/core/rmem_max", "33554432"), |
Let’s build and install everything:
sudo python setup.py install |
Well, it was easy (if it worked!)
Let’s create a log directory for Switzerland:
sudo mkdir /var/log/switzerland-pcaps sudo chmod a+wx /var/log/switzerland-pcaps |
And finally let’s run it:
sudo switzerland-client |
or if you wish to run your own server (you need to advertise it too!)
sudo switzerland-client --server yourserveraddress |
Questions?
If you enjoyed this post, make sure you subscribe to my RSS feed!
Beware: Google Adwords Phishing
I received this email today:
Your AdWords Google Account is stoped.
Dear Google AdWords Customer,We were unable to process your payment.
Your ads will be suspended soon unless we can process your payment.
To prevent your ads from being suspended, please update your payment information.Please sign in
to your account at http://adwords.google.com/select/login,
and update your payment information.
Of course I got suspicious right away, when I noticed the spelling of ’stopped’. But, hey, consider yourselves warned.
If you enjoyed this post, make sure you subscribe to my RSS feed!
Beware Of A False Sense Of Security
Every now and then, a developer makes a post on their blog that, to the unsuspecting novice, seems like common sense.
Beware, though. If the post is less than comprehensive or accurate, it better not be about security matters or that newly acquired peace of mince may be quickly shattered.
Exhibit A: This post on the topic of PHP and SQL injections. It’s not like there is a lack of information already freely available on the web.
The author even references this excellent material at the end of his post. It is too bad that his own article actually contains less relevant information than the original post.
For instance, he recommends the use of mysql_real_escape_string().
- Observation #1: this implies that you are using mysql as your database of choice. Granted you may use this method before sending a SQL query to Postgresql, but then there is no guarantee that mysql functions were compiled in the current php library.
- Observation #2: mysql_real_escape_string() does nothing more than escape quotes. From the original article: “Be aware that “sanitizing the input” doesn’t mean merely “remove the quotes”, because even “regular” characters can be troublesome.“
He recommends validating for the proper input, which is good practice. So, brownie points for that. But it wouldn’t hurt to have, for instance, mentioned the use of intval() to enforce that integer values are nothing but that. Integer values. I would say that it’s advice just as important as escaping input strings.
Now, the part that I found horrifying, but it’s just me, I’m a stickler: the author encourages you to code your HTML forms so that they will not accept too many characters. I see here some confusion: this is good usability advice, granted, but as far as security it is misguided.
The golden rule is simple: Always perform input validation server-side, where the user cannot ‘fake’ the values they are sending to your application.
Never, ever accept data “as-is” if it came through a path that allowed it to be tampered with.
Two other equally important points I wish he had mentioned are:
- Configure error reporting so that your server does not display these “helpful” error messages that he mentions and attackers are delighted to find
- A good SQL query is one cautiously put together, but a great SQL query relies on prepared statements. There are cases when you are after raw speed and direct queries feel more ‘natural’ -I know, I use them a lot- but whenever possible, use prepared statements, since the user is then not given a chance to “write” your query string himself.
If you enjoyed this post, make sure you subscribe to my RSS feed!
The confusing Smarty security model
While in the process of making sure that the web host integrity is maintained when using nBBS in multi mode, I realized that Smarty, beloved php templating engine, offers so many configuration options that it’s hard to tell what’s really secure and what isn’t. Here is how I have implemented our security model:
// BEGIN Template system require "smarty/Smarty.class.php"; $TEMPLATE = new Smarty; $TEMPLATE->force_compile = false; // true for development $TEMPLATE->compile_check = true; $TEMPLATE>debugging = false; // $TEMPLATE->caching = true; // Security $TEMPLATE->php_handling = SMARTY_PHP_REMOVE; // default: do not allow php tags $TEMPLATE->security = TRUE; // Pseudo-safe mode $TEMPLATE->security_settings['MODIFIER_FUNCS'] = array('substr'); $TEMPLATE->trusted_dir = array(); // No trusted directory. Ever. // $TEMPLATE->register_outputfilter("template_postfilter"); // END Template system |
Obviously, the section you should be concerned with is under ‘Security’.
Note that Smarty’s documentation is a bit confusing regarding allowing php words but in the end it boils down to this: there is an associative array, called ’security_settings’, and its keys are:
PHP_HANDLING, which allows you to ignore the setting of $php_handling (!!!)
IF_FUNCS lists PHP functions allowed in an {if} statement
INCLUDE_ANY allows you to ignore $secure_dir but it seems to take $trusted_dir in account
PHP_TAGS, when true, allows {php} statements, unless mamed by $php_handling
and finally:
MODIFIER_FUNCS is an array of functions allowed when interpreting php…note that it also allows functions for {if} statements!
Oh, and ALLOW_CONSTANTS. No relevance here.
What a mess.
If you enjoyed this post, make sure you subscribe to my RSS feed!
