Nginx securiy problem

On Thu, Dec 03, 2009 at 02:01:21PM -0800, Michael S. wrote:

Yah. I tried thttpd but it crashed on me randomly. Apache is stable.
Works good enough. And the machines I use it on have more than enough
resources.

mini_httpd is much more simpler than thttpd: it’s just a simple server
forking for every request, i.e., exactly what is required for CGI.

On Dec 3, 2009, at 1:11 PM, Igor S. [email protected] wrote:

CGI at mailman.nginx.org Mailing Lists is run by mini_httpd.

Igor S.
Igor Sysoev

-------- Original-Nachricht --------

Datum: Thu, 3 Dec 2009 16:22:27 -0800
Von: Michael S. [email protected]
An: [email protected]
CC: [email protected]
Betreff: Re: Nginx securiy problem

On Thu, Dec 3, 2009 at 3:03 PM, Steve [email protected] wrote:

What? Because of mailman you run Apache? Well… I do run mailman 2.1.12
here on top of nginx 0.8.29 without any issues. No Apache involved in any
way. I don’t see any reason to use Apache for mailman.

yeah - CGI-based stuff i run apache behind nginx for those couple
things. i always have nginx on the frontend.

I only have one instance of Apache that I use and it’s used for web
pages that I know are not easy to handle for me (from the security
viewpoint). So I run mod_security on that Apache instance and other
stuff that helps me to narrow down the possible security problems. It
does not prevent them but I can sleep better knowing that mod_security
and other tools are doing a good job in preventing the most obvious
issues.

Every where else I use nginx. Some time as stand alone and in some
instances as a load balancer and and and…

how do you run mailman directly?

I did not say I run it directly. I run it as a FCGI instance with the
help of FcgiWrap (http://nginx.localdomain.pl/wiki/FcgiWrap). And I do
the same for other CGI applications (for example the DSPAM WebUI,
AWStats, for cgi-bin directory, etc).


nginx mailing list
[email protected]
nginx Info Page


Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox
3.5 -
sicherer, schneller und einfacher! Aktuelle Nachrichten aus Politik, Wirtschaft & Panorama | GMX

2009/12/3 Michael S. [email protected]:

It’d be nice if nginx could do cgi :stuck_out_tongue: I have to support mailman and
bugzilla. Both seem archaic. One reason I am actually starting a php mailman
replacement since there are literally only 3-4 mail list managers out there.
None are simple to use or configure either. If anyone wants to help
contribute to this effort… Email me off list. I’m hiring a coder to do it
for me. Then I will open source it like wordpress and such.

That sounds weird to me, rewriting Mailman in PHP. Mailman is an
excellent piece of software. If you need FastCGI support for Mailman,
why not hire a developer to implement that? With the excellent python
flup library, this will not be a daunting task.

Jean-Baptiste Q.

On Sat, Dec 5, 2009 at 1:54 AM, Jean-Baptiste Q. [email protected]
wrote:

That sounds weird to me, rewriting Mailman in PHP. Â Mailman is an
excellent piece of software. Â If you need FastCGI support for Mailman,
why not hire a developer to implement that? Â With the excellent python
flup library, this will not be a daunting task.

mailman is a pain in the ass to install, it leaves files all over the
system, it is remnant of early 1990’s software - i.e. when it began.

i am looking for a more modern approach, ala WordPress or Drupal;
upload the files, run an installer, MySQL as a backend for the user
list, configuration details, etc.

not proprietary weird command line crap you have to run to update
options and alter certain configuration items. totally web-based,
besides for adding the /etc/aliases lines, that’s all anyone has to
do.

while it has a long history of being the standard, the open source
community usually has multiple forks and options out there for just
about any type of software. oddly enough, mailman has no other options
besides the few i was able to find after a lot of searching:

  • sympa - also a pita to administer, cgi-based
  • ezmlm - doesn’t look like it’s been touched in years, perl-based
  • dadamail - cgi-based as well it seems
  • majordomo - doesn’t look like it’s been touched in years, perl-based
  • ?? - i forget the name now, but there was a commercial one at like
    $2k or something per year

it’s just easier to maintain status quo. more people at my work are
used to apache already. :slight_smile:

-------- Original-Nachricht --------

Datum: Sat, 5 Dec 2009 02:19:36 -0800
Von: Michael S. [email protected]
An: [email protected]
Betreff: Re: Nginx securiy problem

On Sat, Dec 5, 2009 at 1:54 AM, Jean-Baptiste Q. [email protected]
wrote:

That sounds weird to me, rewriting Mailman in PHP. Mailman is an
excellent piece of software. If you need FastCGI support for Mailman,
why not hire a developer to implement that? With the excellent python
flup library, this will not be a daunting task.

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.

it leaves files all over the
system,

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.

it is remnant of early 1990’s software - i.e. when it began.

This does not make the software automatically bad.

i am looking for a more modern approach, ala WordPress or Drupal;

All fine and dandy for a web application. But mailman can run without a
web server.

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?
Probably never or rarely when you switch to a never version and/or when
the new version is depending on a never Python and you need to alter
some stuff in order to get the web interface up and running again. The
bigger part of daily work with mailman is anyway from the web interface
and the initial configuration is mostly never touched again.

not proprietary weird command line crap you have to run to update
options and alter certain configuration items. totally web-based,
besides for adding the /etc/aliases lines, that’s all anyone has to
do.

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?

$2k or something per year

The good think about OSS is that you are free to invest time in making a
better solution. Believe it or not. Programming is hard and takes time.
A lot of time. I am involved in a big OSS software that every one wanted
to fork last year and every one wanted to recode the Web UI that the
software has in something more modern then Perl. Most of the user base
wanted to use PHP. Now almost one year later after we have started we
are still using the old interface. No one has coded one single line for
the Web UI. Every one was crying last year but after we took over the
development all those that where crying out loud are gone. It’s funny.

So your comments about recoding mailman to use PHP somehow remembers me
about the project that I am involved. I absolutely understand your
desire for the change but I would bet my last dollar on it that you will
not any time soon redo mailman in PHP. Not without investing a
substantial amount of your normal day time. I want to see the person
that is going to sit down months and months doing the Web UI for mailman
in PHP. Take the time and look at the code of mailman and analyze it.
You will soon realize that doing the Web UI in PHP is going to be a HUGE
task. A task that you can’t just easily do in a bunch of days or weeks
after you have come home from work. It’s going to use MONTHS of work. A
lot of work.

Most people think that it’s easy done but it’s not. It is time intensive
to code. And if you code for the masses then you will face problems that
you have not imagined in your wildest dreams that they could exist. And
fixing those issues are going to take time. I once had weeks to fix an
issue on Mac OS X that users had. I had those bug reports and reading
them just did not make sense to me. But Mac OS X users where reporting
them. So I could not ignore them. And for fixing you need to find some
one allowing you to access his Mac and you need time to understand what
is going on. If you are not familiar with the platform then this as well
is going to take time. And before you even have started to understand…
bam! 2 weeks of time gone. Just like that. For a small (but important)
bug. And it’s with all things like that. You think everything is going
to be easy and fast but it’s not. Things take a lot of time. And I don’t
know many private persons wanting to commit that much time after work
for doing coding on OSS projects.

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.


nginx mailing list
[email protected]
nginx Info Page


GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter Aktuelle Nachrichten aus Politik, Wirtschaft & Panorama | GMX

2009/12/5 Michael S. [email protected]:

i am looking for a more modern approach, ala WordPress or Drupal;
about any type of software. oddly enough, mailman has no other options
besides the few i was able to find after a lot of searching:

  • sympa - also a pita to administer, cgi-based

Sympa can run with fastcgi
(http://www.sympa.org/manual_6.1/web-interface?s[]=fastcgi) but yes
it’s a huge complicated system which is more than harder to
administer. It’s been made by some french searchers for universities
needs. It’s used mainly by universities or ministries to handle huge
databases of mailing lists.

For having more than one instance in production I can tell how it’s a
pain in the ass !

Note this has gotten wayyyy OT.

On Sat, Dec 5, 2009 at 3:20 AM, Steve [email protected] 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.

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?

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? :slight_smile:

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.

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.

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?

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.

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. :slight_smile:

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.

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.

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.

Funny, when looking at it quick, I just noticed this bug with mailman:

:slight_smile:

On Sat, Dec 05, 2009 at 10:26:11AM -0800, Michael S. wrote:

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? :slight_smile:

I :slight_smile:
I really like mailman expecially comparing to majordomo, although its
web interface looks as from late 90s.
But mailamn has no command line utility to add to the “list of
non-member
addresses whose postings should be automatically accepted”.
I have to go to the admin panel (several clicks), enter password,
then click 2 times, paste an address, and click 2 times again.

With command line utility I would go to the server, press Control-R,
“non”, maybe Control-R again, enter, paste an address, enter. Done.

BTW, it would be nice if some Python programmer will write
“add_non_member”
script by analogy with “add_members” script.

My opinion in console vs GUI interfaces comparision is the following:
for seldom and non-repeating tasks like browsing (and adding itself to
a mailing list) it’s better to use GUI, however, for routine operations
(like adding news address by administrator) it’s better to use the
command
line.


Igor S.
http://sysoev.ru/en/

-------- Original-Nachricht --------

Datum: Sat, 5 Dec 2009 10:26:11 -0800
Von: Michael S. [email protected]
An: [email protected]
Betreff: Re: Nginx securiy problem

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? :slight_smile:

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.

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?

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.

Bring on that thing :slight_smile:

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.

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:
Bug #490114 “Mailman should be compliant with the Filesystem Hie...” : Bugs : GNU Mailman
:slight_smile:

LOL. That’s a good one :slight_smile:


nginx mailing list
[email protected]
nginx Info Page


Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox
3.5 -
sicherer, schneller und einfacher! Aktuelle Nachrichten aus Politik, Wirtschaft & Panorama | GMX

On Sat, Dec 5, 2009 at 1:58 PM, Steve [email protected] wrote:

Then Softlayer does not understand anything about security. Security is not a tool nor is it something you apply once and then forget about it. Security is a process. You need constantly to take care of it. Some time it is technical (hardware that can be installed, software that can be hardened, etc) and some time it is organizational (you have a check list to follow in case of security breach, you alert a security person in case of a security breach, you close your forum for X hours in case of a security breach/break, etc).

Actually, SoftLayer is quite security-focused. I am a customer and
have been quite happy with them.

They are doing the standard “fix your servers or we’ll cut you off” -
they’re not saying security is a “tool” - they’re telling him that he
needs to hire someone they trust to fix his servers up as he does not
seem to be equipped to, or they will shut him off. It’s not worth the
overhead they have to take on to have people who don’t know how to
manage their own servers.

FYI: I run 0.8.x. I run the latest possible version Igor puts out
whenever I have time to update.

As someone once told me, “Igor’s betas are more stable than most
people’s stable versions” and I would have to agree. I’ve never ran
into an issue or bug that had to do with a new version of nginx
because I happened to be running a “beta” - all of my issues are
mainly due to something lacking or needing more understanding on how
to workaround a configuration limitation, etc.

Never something as stupid as “gzip + aliased locations doesn’t work”
as another popular alternative webserver that flies light had broken
in it for over a year before it was fixed…

-------- Original-Nachricht --------

Datum: Sat, 5 Dec 2009 14:01:19 -0500
Von: “egerci” [email protected]
An: [email protected]
Betreff: Re: Nginx securiy problem

Hallo egerci,

Thanks very much for you advise.
I have switched back to last stable version nginx 0.7.64.
Do you suggest me to use 0.8.** version?

it’s hard to say that. I am using 0.8.x version and have so far no issue
doing that. But I think Igor is not having 0.7.x releases marked as
stable for no reason. So if there is nothing in 0.8.x that you
ABSOLUTELY need then don’t go with 0.8.x. It will only add an additional
unsure factor to your setup and currently what you need is STABILITY
and PREDICTABILITY. And 0.7.x is exactly that.

I am not the system specialist. I will do your advises step bu step.
But fisrtly I have to check them because I am not sure is it possible to
install these applicaiton for my side.

I told you to not trust any one. That includes me as well. Please take
your time to UNDERSTAND what is going on. If you don’t know where you
are (lets mark this as “STARTING POINT” or SP) then it does not help to
know where you want to be (lets mark this as “TARGET POINT” or TP).
Because the path from STARTING POINT to TARGET POINT is not possible to
calculate, plan, influence, evaluate, whatever if you don’t have a
STARTING POINT. Do you understand what I mean?

Please try to solve the issue you are facing. And to do that you need to
stay calm. If you have problems with your setup then analyze it and find
out what the problem is. When you know the problem then you have that
STARTING POINT and you already do have the TARGET POINT (which is: Not
have the problem again in the future). So then you just need to look how
to get from SP to TP. That’s it.

And please don’t just react. Plan the worst scenario and plan how to act
when that case is happening. Lets assume that Apache is indeed a
possible way for you to ease the attacks you have. Then set up an
instance of Apache and make it ready that should your nginx setup again
have some issue then you could switch in a bunch of minutes to your
Apache instance and take the time to look more close at the issue you
had with nginx and learn out of the problem and eliminate that problem
for the future. Then when you have fixed your nginx setup, switch back
again from Apache to nginx and let nginx handle everything. After some
time your problem rate with nginx will slowly go down to zero and you
will never need that Apache instance again. But having it will still
allow you to sleep calm at home knowing that should anything happen you
have at least one backup plan that could help.

Thanks you again for your suggestion.

Don’t think that you are alone here. Every one doing serious web hosting
stuff or things like that was burn by the one or other security issue
some web applications have. Heck! I even was rooted. TWICE in a week.
And just because I had SSHv1 in my OpenSSH (that was years, years, years
ago).

It’s not a shame to run into such issues. But it’s a shame to not learn
from them.

You have here on this ML a gazillion of people with combined knowledge
that you alone probably will never have. So use that knowledge. Ask
nginx related stuff here and learn. I am pretty sure no one will push
you away if you have some nginx related question.

Sure I am not
Softlayer has forced me to apply one of the 6 servermanagment company
these are trusted and certified from Sofltlayer, or close my network.
They said me “If they report that your server is clean it is ok” So I had
have to go one of them.

Then Softlayer does not understand anything about security. Security is
not a tool nor is it something you apply once and then forget about it.
Security is a process. You need constantly to take care of it. Some time
it is technical (hardware that can be installed, software that can be
hardened, etc) and some time it is organizational (you have a check list
to follow in case of security breach, you alert a security person in
case of a security breach, you close your forum for X hours in case of a
security breach/break, etc).

Nevermind, I close my relation with Server Managemnt Comp. and reinstall
nginx. And I look ahead

That’s the way to go! Think positive! It only can get better :slight_smile:

Best regards

// Steve

Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox
3.5 -
sicherer, schneller und einfacher! Aktuelle Nachrichten aus Politik, Wirtschaft & Panorama | GMX

Michael S. wrote:

On Sat, Dec 5, 2009 at 1:58 PM, Steve [email protected] wrote:

Then Softlayer does not understand anything about security. Security is not a tool nor is it something you apply once and then forget about it. Security is a process. You need constantly to take care of it. Some time it is technical (hardware that can be installed, software that can be hardened, etc) and some time it is organizational (you have a check list to follow in case of security breach, you alert a security person in case of a security breach, you close your forum for X hours in case of a security breach/break, etc).

Actually, SoftLayer is quite security-focused. I am a customer and
have been quite happy with them.

I would agree. Softlayer is an excellent host which I have used on and
off over the years for different needs. I think this is their reaction
to a customer for whom they cannot provide hand holding services.

As someone once told me, “Igor’s betas are more stable than most
people’s stable versions” and I would have to agree. I’ve never ran
into an issue or bug that had to do with a new version of nginx
because I happened to be running a “beta” - all of my issues are
mainly due to something lacking or needing more understanding on how
to workaround a configuration limitation, etc.

It does happen however, as it did to me. See the thread at
Weird 0.8.11.1 connections spike. The difference is that Igor
fixed it in under 24 hours.

Never something as stupid as “gzip + aliased locations doesn’t work”
as another popular alternative webserver that flies light had broken
in it for over a year before it was fixed…


nginx mailing list
[email protected]
nginx Info Page


Jim O.

On Sat, Dec 5, 2009 at 1:30 PM, Steve [email protected] wrote:

And how would a Web UI have prevented that panic mode?

See below - this isn’t just web UI, but I see it as a chance to
someone re-architect it a bit better. First, match feature set.
Second, improve and adjust.

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.

I just mean that it could possibly influence delivery or other
mechanisms or in the case of some of those options additional mail
headers is how it works, you can inject those in using the MTA or you
could configure them using on the mailman level too.

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?

FYI/FWIW: this isn’t all about just a “fancy web UI” it’s also about
some modernization and simplification.

I am happy you’ve had such success with mailman. However myself and
other people I’ve talked to all have had similar pains with mailman.

We should stop the discussion here as we’re just going further and
further OT.

-------- Original-Nachricht --------

Datum: Sat, 5 Dec 2009 14:27:25 -0800
Von: Michael S. [email protected]
An: [email protected]
Betreff: Re: Nginx securiy problem

consequence is: Fully use mailman as much as possible but don’t try to make it do
Fundamental design flaws can’t always be fixed with a nice GUI. You can
I am happy you’ve had such success with mailman. However myself and
other people I’ve talked to all have had similar pains with mailman.

We should stop the discussion here as we’re just going further and further
OT.

Agree.


nginx mailing list
[email protected]
nginx Info Page


Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox
3.5 -
sicherer, schneller und einfacher! Aktuelle Nachrichten aus Politik, Wirtschaft & Panorama | GMX