Nginx securiy problem

[Steve]

-------- Original-Nachricht --------
> Datum: Sat, 5 Dec 2009 10:26:11 -0800
> Von: Michael Shadle <mike503 at gmail.com>
> An: nginx at nginx.org
> Betreff: Re: Nginx securiy problem

> Note this has gotten wayyyy OT.
> 
> On Sat, Dec 5, 2009 at 3:20 AM, Steve <steeeeeveee at gmx.net> wrote:
> 
> >> mailman is a pain in the ass to install,
> >>
> > Mailman is not hard to install. Normally you just execute one command
> from your distro and the package is installed. Configuration is another
> issue.
> 
> Sorry you're right. "Installing" it to me means not just unpacking or
> apt-getting but also getting it initially setup.
> 
That is configuration/setup and something totally different.


> > And why is that an issue? You normally don't mess with the installed
> files. You just edit mm_cfg.py and that's it.
> 
> Whenever you need to migrate? Ever had to migrate a mailman install
> from one server to another? What about one distro to another? With
> different paths on each machine?
> 
YES! Once my distro of choice had the great idea in moving the whole mailman file structure to another one. I first messed it up totally but today I could in no time move from one FS structure to another. I did it once wrongly, failed, learned and now I know. And yes. I have moved from server A to server B as well. One of my systems got so borked up that I needed to replace it. And I did it. Not only did I move the mailman installation/list from server A to server B. No! I have moved from server A to a cluster server B and server C. Was death easy. The only thing that I needed to think about is how to make the various cron scripts to be cluster aware. That's it. Mailman on its own was easy. Running now on two cluster nodes that both have a clustered FS (GlusterFS) where all the mailman stuff is sitting.


> > All fine and dandy for a web application. But mailman can run without a
> web server.
> 
> Sure, it can, as will mine. But the easiest way to manage everything
> will be from a web UI, and nowadays, who really makes a fuss about
> having to use a web UI? :)
> 
If the tool was from the start written for the Web then it's okay. But most tools are written for the console and then later on top of that they add an Web UI. In general the Web UI has then less possibilities then doing it from the command line. And this is what I don't like.


> >> upload the files, run an installer, MySQL as a backend for the user
> >> list, configuration details, etc.
> >>
> > I like the approach from mailman. I can just install it and configure
> with a simple text file all my initial options, then just glue it together
> with my MTA of choice and that's it. Okay. Doing the whole user management
> and list management and configuration management from the command line is not
> the best choice but it's possible. I do use both. And to be honest: Once
> you have configured mailman then you don't touch the configuration in years.
> You just manage every thing from the web interface. So be honest: How many
> times have you needed to go on the server and change options in the
> command line for mailman after you have installed and configured it?
> 
> Well, I've had to run it in a "high-security" mode where I stripped
> out attachments and some other stuff and the options to do this were
> quite confusing. I was almost too scared to allow it to be used, as it
> could have cost all of us our jobs for using it if any confidential
> document got attached and somehow snuck through.
> 
Ha! Don't tell me that. I run two lists that need to be ABSOLUTELY anonymous and no information about the sender nor any attachment is allowed to sneak through. Attachment stripping is easy in mailman. But the anonymity? ULTRA BAD! It does hide the sender but still you could look at the headers of the mail and see who sent it. Enter Postfix. Thanks to Postfix and the great possibility found in Postfix I can filter out as much as I like. I can even plug stuff into the delivery chain that allows me to change every single bit inside a mailman message. Stripping headers: No problem. Generating a new message id: no problem. Stripping attachments: No problem. etc, etc, etc...


> However yes all that was done before deployment, but it also did not
> give me a lot of confidence if post-deployment we found a small glitch
> and had to go into panic mode to see if it could be fixed.
> 
And how would a Web UI have prevented that panic mode?


> Regarding the one file of changes, I have tried that route and it
> still didn't seem to get it all right for me. Maybe I was doing it
> wrong but that's the whole point of it. Why would something as simple
> as editing a configuration file be difficult or wrong?
> 
I don't know? I have that little file there with a bunch of configuration options and that's it. I don't fiddle around with it. I don't remember when I have touched that beast the last time?


> > Oh boy. If command line is an problem for you then I ask my self how you
> manage to use nginx? Or things like Postfix, Dovecot, Cyrus, Courier,
> Sendmail, QMail, etc... Are you aiming to get those web based as well?
> 
> Honestly, I've thought about a web-based nginx UI, mainly to make it
> easier to manage clusters. But think about it this way. Do you need to
> run a bunch of command line tools to make postfix work? or nginx? Not
> really, install, configure a couple config files, and you can start it
> up and it's useful. Not some bin/newlist and then weird bin/withlist
> -i -l stuff to alter it later. Depending on the distro, the binaries
> are in different places, etc.
> 
You don't need to run bin/newlist, bin/withlist and I don't know what else. From within the mailman Web UI you can create, delete, modify new lists all the time. No need to fuss around with the binaries. Okay, okay. If you change the host for the archive from hostA to hostB then you might have your hard time doing that in the Web UI but how often do you do that? I mean the change is done easy in the Web UI but the migration of pipermail/archives can't be IMHO done from within the Web UI. 

And beside that: We are in 2009! No one is just fiddling around on the server without having a proper release to management environment. So you test the stuff in dev/test, then you document it, then you install in pre-poduction/acceptance and if all is going fine then you go on and deploy it in production. If anything happens in the production then the documentation written by you before going to production should have +/- all the steps needed to redo all your work on another system. And if you ever need to move from server A to server B then you make a copy of the mailman installation from production and install that stuff in dev/test and try there until you are confident enough to do the step.

While testing a possible migration path you write everything down and there you are. You have validated a possible migration and you have a documentation describing how to do it.


> > Don't get me wrong. If you redo mailman in PHP and make it sexy, fast,
> AJAX GUI, etc... I am sure going to use it. But I my self would not invest
> time in doing that. Mailman just works and I don't see any significant
> benefit in having it in PHP and using a super duper Web UI. It would probably
> look nicer but it would not reduce my list management time by factors. Maybe
> today I have about 1 to 15 minutes that I need for managing the hand full
> of lists that I do manage. And I don't think a modern Web UI for mailman
> would reduce that.
> 
> I'm glad you'll be a user. :)
> 
Bring on that thing :)


> It sounds like you have a fine grip on mailman, but I am tired of
> having to deal with the pain of configuration and such and the little
> tweaks here and there. I would like to re-work it to emulate a more
> modern style of package like WP, Drupal, phpList, etc.
> 
Ach! It's as with many things in life. You see that great thing of software and then you thing: I need that!

Then you download and install it. Then you try to configure it and you fail. Okay. Back to documentation. Reading. Not understanding everything you follow blindly some How-To you have found on the net. Damn! Again not working. Okay. Another How-To. Hmm... it works. Somehow. I don't understand what it does but it works. Good! I am happy. I use the product.

Then later (months, maybe years have passed) you need to touch that thing again. Ohhh boy. You don't understand what is going on but now you NEED to make it working. A gazillion of customers are using it and you can't just bring it down and fiddle around with it for days. It should work NOW. Ahh. Sorry. YESTERDAY! And you idiot did not understood it when you installed/configured it and now you pay for that ignorance. Damn!

But time has passed by and you not only have lost some hair on your head but you are more confident with all the tools you are using and this time reading the documentation of mailman gives you *AHA* *OOH* *now I understand* etc... and then things start to become clear and they settle in your brain. From now on touching mailman is not any more black magic but something you know how to handle and where to tweak it in order to get things done.


> I understand it takes effort. I have already listed the job on a
> couple freelance sites. I believe I already have an extremely talented
> coder who is familiar with mailman and MTAs and everything in between
> and would love to get some open source credibility. So the main thing
> for me is - do I want to invest my own personal money into the
> project? I think so. There's a decent sized market and not a lot of
> options, that short list I made a couple of the options haven't even
> been touched in years. Since then there's been adaptations of things
> like SPF records and domain keys and such which may or may not be
> useful things to be implemented.
> 
Why not utilizing the MTA to do that? I have on my mailman installation: SPF, Sender ID, DKIM, Anti-Virus, Anti-Spam (using mainly DSPAM but have CRM114 and OSBF-Lua as well), Hashing (DCC, Pyzor, Razor), selective greylisting (SQLGrey, GROSS), various blocking features (mainly policyd-weight patched to use p0f, GeoIP (allowing me to penalize by country, distance (YES! Little nice addition I have written after reading this here: http://www.technologyreview.com/communications/23086/), by continent, etc), S25R (http://www.gabacho-net.jp/en/anti-spam/paper.html), etc, etc...) and and and...

I think it would take you ages to get mailman to be on par with the possibilities a full blown up MTA is giving you. So for me the logical consequence is: Fully use mailman as much as possible but don't try to make it do something that it is not build for and that my MTA could do light years better then mailman could ever do.


> Also the source code will be freely available and written in PHP,
> which will have a large audience of people who can contribute and
> enhance it and keep it alive. Worst case, it goes nowhere, but at
> least I'm giving it a shot. I know a few places I can implement it
> quite easily and it will help gain some traction immediately.
> 
While doing that code you will quickly realize that some limitations you are facing now will not vanish if you abstract mailman in a Web UI. Fundamental design flaws can't always be fixed with a nice GUI. You can definitely work around some design issues and handle that in the GUI but don't expect the mailman crew to be strict with their design flaws. They will fix and reorder things and you will hunt them. You will mostly be one or more step behind them. Some time you will be in front of them but that will happen rarely. And after some time doing this hunting you will come to the point asking yourself: Why am I doing this? WHY?


> Funny, when looking at it quick, I just noticed this bug with mailman:
> https://bugs.launchpad.net/mailman/+bug/490114
> :)
> 
LOL. That's a good one :)


> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://nginx.org/mailman/listinfo/nginx

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser