store | blogs | forums | twitter | facebook | wiki | downloads | support portal
Atomic Secure Linux
It is currently Tue Oct 21, 2014 7:56 am

» Feed - Atomicorp

All times are UTC - 5 hours [ DST ]




Post new topic Reply to topic  [ 40 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
 Post subject: Re: Vote for new features in ASL 3.1 and beyond
Unread postPosted: Wed Aug 17, 2011 12:39 pm 
Offline
Atomicorp Staff - Site Admin
Atomicorp Staff - Site Admin
User avatar

Joined: Thu Feb 07, 2008 7:49 pm
Posts: 3656
Location: Chantilly, VA
Quote:
Yeah, I can envisage that being useful. The Rule Management is becoming pretty complex, so being able to back-up, runs some test's and revert easily would be advantageous (and save me keeping countless notes). Additionally it would allow ASL config to be copied to another system (good when migrating/setting up new server).


Thats an interesting idea, maybe a way to save the "policy" for the rules and make it possible to load others (move them, etc.)?

_________________
Michael Shinn
Atomicorp - Security For Everyone

Co-Author of Troubleshooting Linux Firewalls.


Top
 Profile  
 
 Post subject: Re: Vote for new features in ASL 3.1 and beyond
Unread postPosted: Wed Aug 17, 2011 3:35 pm 
Offline
Forum Regular
Forum Regular

Joined: Tue Jun 24, 2008 12:05 pm
Posts: 153
Quote:
Atomicorp Candidate #9: Upgrade, but do not enable option. For example, if ASL adds in new PHP checks, do not enable the fix automatically, just report this as a vulnerability.


This should not be a candidate to vote on, but just implemented. I recently opened 2 posts about this, because upgrading ASL (and not sending a mail that it got upgraded, which imho should be done as well) is one thing, but ASL should not ever touch the php.ini or http.conf and related files without permission. Web(hosting) environments rely on these files (especially php.ini), and when you change (disable) something, then some application may not work properly anymore. And the administrator may not find out about this for days until someone points him/her to it, and then he may not even know that ASL got upgraded and then spends hours looking for the cause of the problem. Which is what happened to me with this last upgrade to version 3.


Top
 Profile  
 
 Post subject: Re: Vote for new features in ASL 3.1 and beyond
Unread postPosted: Wed Aug 17, 2011 6:36 pm 
Offline
Forum Regular
Forum Regular

Joined: Wed Jan 02, 2008 3:21 pm
Posts: 521
Location: United Kingdom
Sempiterna wrote:
Quote:
Atomicorp Candidate #9: Upgrade, but do not enable option. For example, if ASL adds in new PHP checks, do not enable the fix automatically, just report this as a vulnerability.

This should not be a candidate to vote on, but just implemented...

Totally agree, the recent changes to PHP caused problems with several websites which relied upon curl_exec to handle credit card authorisation.


Top
 Profile  
 
 Post subject: Re: Vote for new features in ASL 3.1 and beyond
Unread postPosted: Wed Aug 17, 2011 8:03 pm 
Offline
Atomicorp Staff - Site Admin
Atomicorp Staff - Site Admin
User avatar

Joined: Thu Feb 07, 2008 7:49 pm
Posts: 3656
Location: Chantilly, VA
I'm adding in a new one/old one based an incident a customer just caused for themselves. :-( (Wish I could do a really big frown, I feel so bad for them)

Candidate # 30: Light weight apache proxy with modsecurity to sit in front of nginx, litespeed, etc.

This customer unfortunately installed nginx in front of apache, and proxied almost all their sites to apache - except one, which nginx served up for them like the excellent web server that it is. And of course,because there is no modsecurity (or any WAF) for nginx, that site got totally owned using a really simple set of web attacks. :-(

BTW, there is an effort underway to port to ngix, which brings me to candidate #31:

Candidate # 31: modsecurity port for nginx

This doesnt help litespeed though, which has a closed implementation of some of the features in modsecurity, but not the whole rule language unfortunately.

For any litespeed customers, we've been providing litespeed with free ASL licenses so they can work on making their modsecurity implementation complete. I was emailing them about it today, so its possible they may support the full rule language in the immediate future, they do not currently though so its not complete, and if you use it you will be vulnerable to attacks that apache users are not. So do encourage them to support the entire language, we would love to be able to check that off as a fully supported web server!

_________________
Michael Shinn
Atomicorp - Security For Everyone

Co-Author of Troubleshooting Linux Firewalls.


Top
 Profile  
 
 Post subject: Re: Vote for new features in ASL 3.1 and beyond
Unread postPosted: Thu Aug 25, 2011 7:30 pm 
Offline
Forum Regular
Forum Regular

Joined: Thu Oct 26, 2006 11:56 pm
Posts: 678
selinux


Top
 Profile  
 
 Post subject: Re: Vote for new features in ASL 3.1 and beyond
Unread postPosted: Thu Aug 25, 2011 7:35 pm 
Offline
Atomicorp Staff - Site Admin
Atomicorp Staff - Site Admin
User avatar

Joined: Thu Feb 07, 2008 7:49 pm
Posts: 3656
Location: Chantilly, VA
Quote:
selinux


Can you elaborate some more? The ASL kernel supports the weaker selinux system now, the stronger RBAC system is enabled by default.

_________________
Michael Shinn
Atomicorp - Security For Everyone

Co-Author of Troubleshooting Linux Firewalls.


Top
 Profile  
 
 Post subject: Re: Vote for new features in ASL 3.1 and beyond
Unread postPosted: Fri Sep 02, 2011 4:54 pm 
Offline
Forum User
Forum User

Joined: Sat Jul 21, 2007 7:31 pm
Posts: 28
Here are my votes:

Near future:
Atomicorp Candidate #4: Redirect blocked users. (I don't understand the difference between this and #5)
Candidate # 31: modsecurity port for nginx

Down the road:
Atomicorp Candidate #1: ASL RBL
*NEW*: Configure service monitoring from asl gui (possibly replacing psmon with monit). I've been using monit for a little while now and I think I've finally got it configured so that it can bring apache back up even with a "subsys locked" error.


Top
 Profile  
 
 Post subject: Re: Vote for new features in ASL 3.1 and beyond
Unread postPosted: Sat Sep 10, 2011 5:19 pm 
Offline
Atomicorp Staff - Site Admin
Atomicorp Staff - Site Admin
User avatar

Joined: Thu Feb 07, 2008 7:49 pm
Posts: 3656
Location: Chantilly, VA
Great feedback so far everyone. It looks like the redirect pages are in the lead right for one of the big features, so we're going to start working on them shortly. This doesnt mean the voting has ended, we just want everyone to know what we will be working on in the mean time. :-)

_________________
Michael Shinn
Atomicorp - Security For Everyone

Co-Author of Troubleshooting Linux Firewalls.


Top
 Profile  
 
 Post subject: Re: Vote for new features in ASL 3.1 and beyond
Unread postPosted: Fri Oct 28, 2011 5:54 pm 
Offline
Forum User
Forum User

Joined: Tue Sep 16, 2008 9:59 am
Posts: 25
AC #4 - with support to upload custom html with tags for where the explanation messaging (generated by ASL) would go. Multi-lingual support also would be good here.
and
Candidate #21

And my own...

Improve the license manager interface so I can see which servers are using ASL and how many licenses I have purchased, expiration dates etc. Could be cleaner and nicer design for this.


Top
 Profile  
 
 Post subject: Re: Vote for new features in ASL 3.1 and beyond
Unread postPosted: Fri Oct 28, 2011 7:50 pm 
Offline
Forum Regular
Forum Regular

Joined: Thu May 07, 2009 12:46 pm
Posts: 297
rnolds wrote:

And my own...

Improve the license manager interface so I can see which servers are using ASL and how many licenses I have purchased, expiration dates etc. Could be cleaner and nicer design for this.


I agree with that :)


Top
 Profile  
 
 Post subject: Re: Vote for new features in ASL 3.1 and beyond
Unread postPosted: Sat Nov 05, 2011 12:32 pm 
Offline
Forum Regular
Forum Regular

Joined: Sat Mar 28, 2009 6:58 pm
Posts: 865
Location: Germany
For me those would be great:
Atomicorp Candidate #4

Atomicorp Candidate #21
rergarding #21:
might it be useful to write a wrapper that DNS lookups for the characteristic googlebots?
something that has the logic in it to verify real bots by the user-agent and only whitelist it if it matches.
http://www.google.com/support/webmasters/bin/answer.py?answer=80553
http://www.google.com/support/webmasters/bin/answer.py?answer=1061943

Maybe those links are useful somehow (could not attach them another way without getting shunned):
perishablepress.com/press/2010/07/14/blackhole-bad-bots/
sebastians-pamphlets.com/smart-robots-txt
projecthoneypot.org
botsvsbrowsers.com
Just an idea.


Top
 Profile  
 
 Post subject: Re: Vote for new features in ASL 3.1 and beyond
Unread postPosted: Sat Nov 05, 2011 2:42 pm 
Offline
Atomicorp Staff - Site Admin
Atomicorp Staff - Site Admin
User avatar

Joined: Thu Feb 07, 2008 7:49 pm
Posts: 3656
Location: Chantilly, VA
Thanks for the feedback we really appreciate it! :-)

Quote:
Maybe those links are useful somehow (could not attach them another way without getting shunned):


You are limited to four URLs in a post to the forums. Any more than that and you will get shunned.

_________________
Michael Shinn
Atomicorp - Security For Everyone

Co-Author of Troubleshooting Linux Firewalls.


Top
 Profile  
 
 Post subject: Re: Vote for new features in ASL 3.1 and beyond
Unread postPosted: Sat Nov 05, 2011 2:51 pm 
Offline
Atomicorp Staff - Site Admin
Atomicorp Staff - Site Admin
User avatar

Joined: Thu Feb 07, 2008 7:49 pm
Posts: 3656
Location: Chantilly, VA
Quote:
Atomicorp Candidate #21
rergarding #21:
might it be useful to write a wrapper that DNS lookups for the characteristic googlebots?
something that has the logic in it to verify real bots by the user-agent and only whitelist it if it matches.
http://www.google.com/support/webmaster ... swer=80553
http://www.google.com/support/webmaster ... er=1061943


Yeah, I'm still trying to figure out a way to do this that doesnt kill the users experience with the server. DNS lookups on source IPs *before* serving up content will make the server appear to be really slow to the user (the server isnt actually slow, its just waiting for the lookup to complete).

So we dont want that, any thoughts on how you would like to see candidate #21 work? Heres my current working idea:

1) If the UA claims its googlebot then, dont serve up content until we finish the steps below:
2) lookup the IP, if it says its google, then do a reverse and make sure the FQDN matches the IP as well.
If it really is a google boot:
auto-whitelist the IP (dont shun it)

If it is NOT really a google bot:
block and shun the host

Optional: If it is a search engine, dont block anything it does either (let google/bing/etc. do whatever it wants to the system)

That may work and if you slow down google, thats probably not so bad and we could cache the IP for a period of time and only look it back up on an interval so this doesnt happen every time the IP connections. I dont think the option step (and dont block it either) should be the default, not shunning a search engine is a good idea, not blocking it may not be a good idea.

Let me explain, and please lend me your thoughts:

We have rules that try to trick search engines when they are being used to do bad things. For example , that is if a bad guy is carrying out a "google hack" to try and find vulnerable applications we return a 404 for those searches, so the bad guy doesnt think you are vulnerable (and moves on) - and by badguy that might be a fully automated worm so you definitely want them to get a 404 and leave.

If you have shunning setup, ASL will also shun the search engine. So, maybe we make that class of rules by default to not-shun, but still "block". The same is true for DLP rules, we dont want google caching sensitive data from your server, but we dont want to shun it either.

Are there any rules you think a search engine should never be blocked on? (not shunned, we can handle that differently) My gut says no to the security rules, although maybe to the spam rules.

Thoughts appreciated.

_________________
Michael Shinn
Atomicorp - Security For Everyone

Co-Author of Troubleshooting Linux Firewalls.


Top
 Profile  
 
 Post subject: Re: Vote for new features in ASL 3.1 and beyond
Unread postPosted: Sat Nov 05, 2011 7:24 pm 
Offline
Long Time Forum Regular
Long Time Forum Regular

Joined: Thu Dec 09, 2004 11:19 am
Posts: 2079
This is kind of like graylisting, but for web access, isn't it?

Unfortunately Google now insists everybody serves pages asap and is actively recording page serve times. If they don't do it already, they will start making speed of page serving part of the ranking algorithm before too long. So any slowdown, at all, will cause problems.

If Google allowed any sort of human contact you could get in touch and discuss this with them, suggesting they specifically exclude the first X accesses or Xth percentile or something. But oh no. No such thing as human contact with Google.

You may note I'm a bit bitter --well I am. But that's for another post in another secion.

_________________
--------------------------------
<advert>
If you want to rent a UK-based VPS that comes with friendly advice and support from a fellow ART fan, please get in touch.
</advert>


Top
 Profile  
 
 Post subject: Re: Vote for new features in ASL 3.1 and beyond
Unread postPosted: Sun Nov 06, 2011 7:15 am 
Offline
Forum Regular
Forum Regular

Joined: Sat Mar 28, 2009 6:58 pm
Posts: 865
Location: Germany
thanks for the feedback.

@faris: I feel your pain. It's love&hate thing regarding Google for me. Some things Google does very well, others they take advantage of their monopoly and that is scary and makes me upset.

@Mike: havent thought about the delay you and faris mentioned, but I think a delay is not good. I totally agree that the "bad code" should be left out. Unfortunately my knowledge on rules level is not good enough to comment on that one.
But "Google hacks" and "Spam Stuff" should be kicked somehow. If we shunn than for Google it looks like being "blocked" or not? Even if not they give you a bad rate due to speed which would upset the customers.
Due to lack of knowledge regarding the rules I'm not very helpful I think :( Sorry. But I do my best.

What about this idea:
Maybe it's a good point to mix with #1 and thinking about an ASL-collaborative-collection of search-engine-whitelist & blacklist. It might be longterm think. For example if we start with a learn mode and all ASL people that want to can collect data and we share them automatically. in a few months we might have a good list of IP's to start AWL with! Make a ipwhois check to get subnets out of it and than use the AWL. I can't believe that Google ever gets rid of his subnets they already have.

btw. why can't we get a list from iana? I have always asked that myself.
Maybe getting in touch with Ben Laurie at Google (benl&google.com) might be an idea?!
He's listed as contact at iana for Google Inc. and a founding director of The Apache Software Foundation and a core team member of OpenSSL. He wont give us the IPsfor sure but he might come up with something useful.
He, as an IT guy, might/should be interested in security.
Like always, just and idea. Might be silly but just brainstorming doesnt hurt. :)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 40 posts ]  Go to page Previous  1, 2, 3  Next

» Feed - Atomicorp

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: Yahoo [Bot] and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group