(Adios Censorship, Hola ODDNS) Internet Censorship: state & solution

We are (and have been) living in a dark era of corrupted & controlled information, not because of hackers or e-criminals but due to white collared, bureaucratic Legal Organizations trying to control Internet.

They used to control books in old ages; newspapers since several numerous years and news channels for past few decades. This control was over information available to public.
The more informant they are, the less power Legal Agencies have to guide them on their determined decision.

They started with shutting down (supposed to be) bothering web portals, forcing them to change content and even leak information about their users.
When they found out they can't (without any controversy) dominate all web services around the globe. They started taking DNS servers under control.

 InteXnet CensoXship

Now just for those unsure how controlling DNS servers help.

In easy words... dns server is the service to which you tell the web portal name and guides you with the address format that all networking devices understand and help you reach the destination web server.

So, the problem why DNS Servers can be controlled currently is because of their structure.
DNS Servers have a tree-like hierarchical set-up.
It has few Root DNS Servers at the top, which contain the entire Internet Domain Name registration database and its relative IP. These are maintained by independent agencies, but maximum of those reside in U.S. and few others distributed over globe.
Then there are lower level DNS Servers maintained by Internet Service Providers, some Universities and also some IT organizations. These DNS servers contain a more specific subset of DNS entries specific to the domain requests they mostly serve.
If the queried lower DNS server doesn't have reply to an entry it contacts daddy DNS, retrieves the address and replies.

The thing is, these network address resolvers are very concentrated and dependent. So if these Legal Organization face threat from any newer (or even older) web portal, say www.wiki-still-leaks.org.
Only thing they need to do is block address resolution of that particular (and many more as per required) web portal name.
As you wouldn't be able to resolve network address for that particular website, you would find it offline.

Currently, how non government liked sites (as thePirateBay) handles it is making multiple dns entries.
Recently there was a firefox plug-in ThePirateBayDancing released by mafiaafire, which makes available portal jumping randomly over proxies.

In late 2010, when U.S. blocked WikiLeaks..... ThePirateBay floated around the idea of P2P DNS.
Peter Sunde (PirateBay co-founder) gathered coders to work on it. Cjd working on it, shifted his operations to cjd#irc.

This idea of P2P DNS was picked upon by vinced and put down as namecoin. A decentralized dns service based on Bitcoin. Now, that is the main problem with this..... its based on a money exchange system architecture. You either mine namecoins for a domain name or buy them.

Jimmy Rudolf is out with ODDNS : Decentralized and Open DNS. It removes intermediaries dns servers from the scene removing their crippled dns resolutions.

Social Engineering [from Eden Guide to Hacking >> Active Recon]

Eden Guide To Hacking : https://github.com/abhishekkr/eden_guide_to_hacking
 
Social Engineering
direct link :  https://github.com/abhishekkr/eden_.....  ineering.txt

Most creative non-technical hacker practice known to mankind.
 
a.) It's Art of Communication with People for 'Information Leakage'.

• You have a 'Victim' identified by now and wanna collect more and more available information related to them.
• Not just any relevant information, but sensitive details, that Victim or related people handover to you in confidence.
• You think like a con-artist, assess weakness of your victim & the possibilities of make-believe for them.
• Then you come up with an entire scenario to pose yourself a reliable savior for your Victim to be saved; a benefactor.
• And you will find them revealing such discreet and sensitive information so that they can encash the situation to its max. And let you gather all sensitive information that you can.

b.) Example: "The pretend employee loosing access at critical time"

• You are a management personnel on client location in middle of a very life-changing deal.
• You need to get some files from your organization's machine or file-share; but can't access them due to firewall policies on either side.
• If you can't seal the deal, the failure will take away your job and the person refusing you such crucial-moment help.
• And there are many chances that you'll get the data fetched from your pretended 'Employee', mailed to you.

 
c.) Example: "I'm here to check your Network from Agency"

• You are at home of your Victim when some family member, hopefully not much security aware is in-charge and pose as the Network Guy from the Telecom Agency they use.
• Offering new organization customer satisfaction mumble-jumble, you try to get access to check health status of network devices installed there, and more computing devices if possible.
• Now, if the devices are tweakable without any credential request from the family member there... try that first.
• If it doesn't work and even they don't have access, then pose as attempting the 'Master Password' so they don't inform the Victim.

d.) For ultimate case studies, read "Art of Deception" by "Kevin Mitnick", the most famous Social Engineering Hacker 'known'.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

BEAST beating SSL & TLS :: What You Can do to be Secured

B.E.A.S.T.?
Browser Exploit Against SSL/TLS Tool [B.E.A.S.T.], is the new Javscript utility created by J. Rizzo & T. Duong capable of breaking SSL3.0 & TLS1.0 level protection for HTTPS connections and deciphering the secure connection data.

What It Does?
There have been previous mention of cryptanalysis attacks over
+ SSL3.0
 |   (a Paper 'Analysis of SSL3.0 Protocol' by D.Wagner & B.Schneier in 1999 ), &
+ TLS1.0
 |   (a Paper 'Renegotitating TLS' by Marsh Ray in 2009).
B.E.A.S.T. is a pure exploit tool built over these (or similar) visions.
B.E.A.S.T. is based upon blockwise-adaptive chosen-plaintext attack approach exploited on victim's end via man-in-the-middle attack.

Point-to-Note!
It's a MitM over Browser, javascript injected does all harvesting of plaintext attack (which currently takes around 30 minutes for useful data) and then enables you to break the encrypted session.

Security Measures until F!XED

1. Use a different browser (totally different, i.e. just not a new instance of same browser but a new browser, as in FireFox & Chrome are different) for browsing your Secured Connection. And a different browser for you general web surfing experience, even any external links from your secured session used browser should be copied and opened in the general web-surfing browser.
2. It's better if the browser used for secured session is used in Private Browsing Mode.
3. Don't keep log-in active in any service if you are not using it currently.

Something you should already be doing, if not start now...
Use browser extensions like AdBlock & NoScript, to protect your browser from injected IFrames and infected AdServices which are the major source channel for BEAST also.

To get a more detailed insight at the exploit Paper & Code, get your hands over
http://www.insecure.cl/Beast-SSL.rar

What to do at Server Side
http://isc.sans.edu/diary/SSL+TLS+part+3+/11635

Open Intelligence Gathering FOR Passive Reconnaissance FROM "Eden Guide To Hacking"

Open Intelligence Gathering : github.com/abhishekkr.....Open_Intelligence..

FOR 

Passive Reconnaissance : github.com/abhishekkr.....section0_Passive_Recon

FROM 

"Eden Guide To Hacking" : github.com/abhishekkr/eden_guide_to_hacking



The following content structure is discussed in detail @

https://github.com/abhishekkr/eden_guide_to_hacking/blob/b00ef1502b9f91953f5d734efd4a03c3a0f04002/part1_Hacking_Cycle/chapter4_Reconnaissance/section0_Passive_Recon/article0_Open_Intelligence_Gathering.txt

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[+] Open Intelligence Gathering
 |
 |[+] What Is Open Intelligence?
 |
 |[+] Legal Documents Got Them
 |
 |[+] Search Engines Sort Them
 |
 |[+] Web Activity Caught Them
 | |
 | |[+] You Blog/Comment
 | |[+] You Socialize
 | |[+] You Subscribe
 | |[+] You Show/Click Ads
 | |[+] Even If You Surf Web
 | |_
 |
 |[+] Automating the Act
 | |
 | |[+] Paterva Maltego CE
 | | |[+] URL
 | | |[+] What it does?
 | | |[+] Example Usage
 | | |_
 | |
 | |[+] The Harvester
 | | |[+] URL
 | | |[+] What it does?
 | | |[+] Example Usage
 | | |_
 | |_
 |_

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"DevOps with SecOps" ~ short intro to Security Implications in DevOps Process

It's a short introduction to Security Implications in the new emerging & highly required domain of DevOps.

DevOps with Sec-ops

View more presentations from Abhishek Kumar

As currently, the major concern around DevOps world is 'The Mantra of Automation' at the level of
+ System/Environments Provisioning
    (easy & fast using Cloud Support)
+ Idempotent Configuration
    (using Automated Configuration Services)
+ Logging & Analytics
    (using automated detailed logging and clever analysis )

This presentation just mentions the security considerations related to all these 3 DevOps processes...

+ Provisioning being affected by

 |=+ Non-Robust Cloud Frameworks,

 |=+ Vulnerable Service APIs, &

 |=+ Virtualization BreakOuts

 |

+ Configuration Management threatened by

 |=+ Non-Robust Services, &

 |=+ Non-preferred storage of sensitive

 |     configuration data

 |

+ Analytics

 |=+ Log Analysis frameworks have been 

 |     several times attacked by infecting 

 |     the received logs resulting in service

 |     level non-sanitized input attacks. 

 |_

howto check for safety of Shorten URLs before opening them in your browsers

Short URLs were in fashion a while back and now they are in requirement.
No matter which social, professional or public web portal you browse, you get to see short url.

But Short URLs from so many sources are not secure as a carefully planted short url redirecting (sometimes single redirection and sometimes multiple) to an infected web portal.
So, all the short links from non-reliable sources must be first traced back to original links and only visited if they cross-check successfully.

So, how to know the actual portal to be visited without using that URL and following it to final location.

[] from your shell
$ curl --head -L http://short.en/url | grep Location:
so, place the short url to be checked in place of "http://short.en/url" in the command provided above and then you can see the entire url trace and the final url to be visited...
~~~~~~~~~~~~~~~~~~~~

[] from the web-app
Link: http://webhoudini.appspot.com/

At this portal paste in the link in Short URL text box and click the 'Unshorten' button to see the actual redirected URL.

~~~~~~~~~~~~~~~~~~~~

[Eden Guide to Hacking] 'Hacking Philosophy' ~ from Rig Veda and Sun Tzu's Art of War

This is a part of "Eden Guide to Hacking" which is my writing attempt for a quick to read, broadway guide to HACKING ~ for anyone to have grasp of important concepts and skills which makes up the knowledge base of a hacker.
W.I.P. @ https://github.com/abhishekkr/eden_guide_to_hacking/

'Hacking Philosophy' ~ from Rig Veda and Sun Tzu's Art of War

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[+] Art of Hacking
 |
 |[+] from 'Rig Veda'
 | |
 | |[+] "Who so would kill us, 
 | |  whether he be a strange foe or one of us."
 | |  Means: "The security parameters could be defeated by
 | |   (un/mis)-handled feature or an already compromised
 | |   component present within an un-breakable system."
 | |
 | |[+] "Loosed from the Bowstring fly away, thou arrow,
 | |   sharpened by our Prayer.
 | |  Go to the foemen, strike them home, and let not one
 | |   be left alive."
 | |  Means: "Make an exploit robust, accurate, infectious
 | |   and untraceable."
 | |_
 |
 |[+] skills could be seen as 13 chapters of Sun Tzu's
 | | 'Art of War' ~
 | |
 | |[+] Laying Plans
 | | |
 | | |[+] Exploit the parameter never thought to be a
 | | |  part of the security implications of the system.
 | | |_
 | |
 | |[+] Waging War
 | | |
 | | |[+] Don't overburden yourself with complex routes,
 | | |  if there exist less techie but more easy options.
 | | |_
 | |
 | |[+] Strategic Attack Planning
 | | |
 | | |[+] Exploit the parameter never thought to be a
 | | |  part of the security implications of the system.
 | | |_
 | |
 | |[+] Tactical Disposition
 | | |
 | | |[+] First secure your own location & technologies,
 | | |  then you are in safe & stronger place to attack.
 | | |_
 | |
 | |[+] Directed Energy
 | | |
 | | |[+] Attacking a complex security infrastrucure is
 | | |  no different than a simple one. Break it down.
 | | |_
 | |
 | |[+] Weaknesses & Strengths
 | | |
 | | |[+] Analyze the system well to aim its vulnerability
 | | |  and leave it's alarm system untouched.
 | | |_
 | |
 | |[+] Engaging the Force
 | | |
 | | |[+] One can't defeat an opponent without knowledge
 | | |  of opponent's security & service design.
 | | |_
 | |
 | |[+] Variations & Adaptability
 | | |
 | | |[+] The system, service & security could be set up
 | | |  with any kind of tweaking and hence makes the 
 | | |  pre-analysis for attack a failure.
 | | |  Attacker must be always ready to amend its ways.
 | | |_
 | |
 | |[+] The Army on the March
 | | |
 | | |[+] When to attack, and when to wait.
 | | |  Instincts to stay out of trap & sense enemies.
 | | |_
 | |
 | |[+] Situational Positioning
 | | |
 | | |[+] Access, attack & safety parameters involved.
 | | |_
 | |
 | |[+] The 9 Battlegrounds
 | | |
 | | |[+] Different types of security parameters lead to
 | | |  different attack or sometimes no attack practices.
 | | |_
 | |
 | |[+] 5 Ways of Attacking with Fire
 | | |
 | | |[+] Break-in target's system with deception
 | | |[+] Starve the resources powering security
 | | |[+] Attack availability of service
 | | |[+] Defeat the implemented security system
 | | |[+] Infect reachable systems related to target
 | | |_
 | |
 | |[+] Intelligence & Espionage
 | | |
 | | |[+] Gather as much information possible and 
 | | |  try attacks like spear phishing to have a slave.
 | | |_
 | |_
 |
 |[+] It's your Dharma to Hack, if you are a Geek.
 |
 |[+] & it all starts in following part of this Eden Guide
 |_
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Link: https://github.com/abhishekkr/eden_guide_to_hacking/blob/master/part0_Fundamentals/chapter2_Hacking_Philosophy/article1_Art_of_Hacking.txt

User Authentication & Authorization [AT] Google AppEngine

AppEngine, a PaaS provided with a 'limited free' version to all GMail users (Google Account Owners). So, you can host your WebContent their making use of Python, Java or Go.

AppEngine enables you to use existing Google A/c of your Web-App users to be used for their authentication & authorization at your AppEngine-hosted Web-App also.

So, there are two main ways to acieve that:

1. to import google.appengine.api.users
   this USERS module from AppEngine APIs enables your Web-App to identify the users on the basis of their Google A/c ID (GMail ID) and then make the decision of routing the user to secured Resource or forbidden resource error message.
   [ An Example on Usage ]
   
2. to specify 'login' under 'app.yaml'
   so the major basic configuration about your Web-App and routing configuration reside in 'app.yaml' file which has default location of Web-App root location.
   So, you can specify at secured 'url' specifications to enforce user for a Google A/c (GMail) login.
   [ An Example Of Usage ]

In, both of these implementations whenever a user tries to visit a 'secured url' on your Web-App, they are automatically redirected to Google A/c Log-In page further redirecting them back to your Web-App on succesful log-in.

The Curious Case of static_dir

Initially while working for my newly initiated opensource project 'py-gae-legs', I added entire 'secure URL' logic by method#1 i.e. using 'users' api.
It was all working fine & secured until I added some static-content using static_dir and tried securing it's url using the same tactic.

But, there was a thing about 'static_dir' which I investigated after my supposed-to-be secure static_dir's content was all publicly available if someone could enumerate/know the complete url.
{I'm in the category of people who keep their learning pace up along with working over it... and anyway I wasn't gonna read the entire #^(

The thing about it was... the directories marked to be 'static_dir' in 'app.yaml' are no more located on the AppEngine Server in the same location after you update your Web-App.
So, the entire directory structure would remain same... it's just that the 'static_dir' marked locations would somehow vanish from it on your Web-App's location at AppEngine and served from some other provision made by Google which maps back to the location.

So, to secure the 'static_dir' located urls... the only way ( that I know of ) is to implement it at the very core of Web-App configurations i.e. in 'app.yaml' using the Method#2.

So, you can enforce Google Login to be mandatory by setting 'login:required' for that 'url' setting. If you want only a selected Users to see that, then you'll have to add all those Google A/c (GMail) IDs by doing following
[a.] goto Dashboard of your GoogleAppEngine Web-App,
the URL-Box link would look like:
https://appengine.google.com/permissions?app_id=s%7E$GAE_APPLICATION_NAME
[b.] click the link 'Permission' from Right-Menu-Column,
[c.] now, invite all those user's by providing their e-mail ID and changing their role to 'Viewer'and at app.yaml provide 'login:admin' instead of 'login:required'.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Lately, I've been involved at starting an OpenSource project 'py-gae-legs'.

It's a very basic subset of WebApp-Framework for the lovers of RoR (have been working on it for past few months, love the ease it gives but hate the convention being the soul) style of web-app creation.

This project just aims web-development specifically aimed to be hosted over AppEngine (currently).
Almost done with it's basic starters to look at:
[] gae-flat-web : to create an architecture hosting your already created static website, http://gae-flat-web.appspot.com
[] gae-private-web : [W.I.P.] to host all your private content hosted securely (by Google) in an by-invite only website

How I got "2 Time Life-Time Banned" From Google Adsense

A Life-Time Ban from Google Adsense


I kin'of registered for Google Adsense service on my portal [ http://www.alwayspost.cjb.net/ (it's dead now, no more belongs to me) ] in very initial days, probably starting 2004.
I used to have few newbie blogs (not these, other newbie blogs) on blogger related to movies, wallpapers & technology.
So, in a very honest way I added the provided AdSense code to my blogs and started posting regularly. It was working at a sloooow rate but I was Ok with it.

I recently moved over from C++ to play with VB6 and was trying all fun stuff I could get my hands on.
One of the fun things I found was making mouse-clicks at desired locations.
& zooom~click~drag~code~drag~adjust~code... 
there was an ie-ocx-control in a form, loading all my blogs one-by-one and code (pre-loaded with specific locations of X-Y locations of Ads on the pages) forging mouse-left-clicks on all Ads... all repeated with a simple Timer.


Just left it on for a night... had LOADS of Ad Clicks and never tried it again.
One week later, there was a mail from AdSense in my GMail A/c stating I've been banned for life-time from Google's AdSense service.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

'Second Life' in Google AdSense

I signed-up for a new e-mail address and tried registering with a new mailing address, and there it was... my new AdSense account.
This time I did nothing against the rules.

Google released Page Creator (which is closed now) and I registered a new portal on my mailing-address at [ http://abhikumar163.googlepages.com ] and start linking it on forums with nice technological content to get valid page hits.


And, I made a mistake. I placed a link to my old-&-no-more-existing-portal [ http://www.alwayspost.cjb.net/ ] which was the portal registered with my earlier AdSense account.

Google's Crawler & Staff noticed it after I attained some amount in my account, and blocked my account and banned me for life-time Second time.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Currently, I'm on my Second Life-time Ban... and don't wanna Third Play, may be when I get bored again.

Full site SSL-ification is not an option, need to make SSL secure first

I have  heard (Recently and in past) security aware lives wasting a lot of their potential over the argument like 
+ 'Basic HTTP is insecure' {sometimes in novice past}
+ 'SSL-ify entire web service' {still a lot push is there}

Now, 'Basic HTTP' being insecure is not a flaw by design... but a flaw by choice.
First of all, when foundation of HTTP were laid attackers were not in the scene. The only concern was ultra productive usability and that is not possible putting all kind of security checks on the service.
Secondly, HTTP wasn't meant to be secure, it was just meant to transfer data in adhering to a protocol which can be used by web-services to recieve user's requests and deliver requested content, that's all.
Cryptography mixed into it will destroy the ease and speed it has. Cryptography over it is instead a necessary (in some cases) and correct (design) option.
Though it has been haunting the websites by attacks like
+[] SSL Stripping

It's due to a flaw in the way Security is implemented in a web application. For example, you visit Facebook Login page at facebook.com which have a HTTPS link in its unprotected page-content to send over the credentials in a protected manner. But what if some attacker using Monkey-in-the-Middle strategy changed that HTTPS link to a HTTP link and sniff your sent credentials... w00t right.

+[] Sidejacking

It occurs due to web-application sending cookie information over non-ssl links. This allows any Man-in-the-Middle to sniff the cookie then replicate in his/her own browser and use the service identifying user just on basis of cookie information... it pwn3d services like GMail, Y!Mail, Hotmail, etc. until Q1-2010.

Then, 'Full Site SSL-ification' is a good choice from theoretical security point-of-view, but just in theory.
Different SSL-Defeating attacks involving
+[] Flaws in Libraries like NSS

There was a (earlier exploited, later) famous flaw in libraries with the case of NULL inclusion in URLs used for Domain name on which SSL Certificate is being issued. Mozilla Engine used NSS Cryptography libraries purely written in C and using basic insecure string functions for comparisons were tricked by certificates for domain name like <<www.paypal.com\0innocent.com>> stopping at first null after <<www.paypal.com>>. Webkit, Opera used null-stripping but they were tricked in just reversed attack using certificates for domain-name like <<www.pay\0pal.com>> stripping out usefull null.

+[] Fake SSL Certificate generation

Not a flaw in SSL, neither in its implementation but in the authorities enforcing it.
In a recent disclosure, Comodo Inc (a major issuer of SSL Certificate) accepted that an attacker was able to get credentials of 'Comodo Registration Authority' based in Southern Europe.
An Iranian attacker used the privilege to issue 9 fraud SSL certificates to 7 web domains including those for Google, Yahoo and Skype.

  So, if you will look deeper into serial-murder case file of
  SSL Certificates, you'll see it ain't safe... 
  and so there is no point in argument over its mixed/full
  implementation.

Indian Airport Internet ~ Hacking Policies Not Tweaking Systems

Few Indian Airport avail WiFi Internet Connectivity to Customers... and what I'm going to discuss about is not hacking the WiFi Network but a simple naive way to hack the Service Scheme instead and gain much more free access than provided little i.e. 30min

I found it in two cities (Delhi, Bengaluru among visited Indian Airports) till now. Both have different hardware supporting it but the same service scheme.

The Service Acts in following way:
Step.1:
You'll get an Open WiFi Network by the name of Airport which lets you to connect without any credentials.
Connect to it.
Step.2:
Open web-browser and hit any URL; this will redirect you to a single page provided by Service Provider with details of how you can get credentials for free-demo WiFi-access.
Here, you'll have to submit your Mobile Phone number, which will receive SMS of credentials for demo access.
Get the credentials.
Step.3:
Use those credentials on the same page, under login section.
You are connected to WiFi for internet access until demo-time (30 minutes) pass.

Loopholes in Service Scheme:
[] Continuous Access For Longer Duration
The more mobile numbers you can have access to...

•  give your friends/family/personal/official Mobile Numbers to gain more demo credentials... 
•  and simply ask them to forward respective SMS to you

...the more duration you can have demo WiFi access.

Now, the system don't check your MAC Address for earlier demo privileged machines...
so you don't even require anything as simple as mac-changer.

[] Parallel Access For Same Credential Set
As, I already said MAC is not checked... so suppose you have multiple WiFi enabled devices.
You can use the same credentials on all devices at the same time.
Just need to consider what is the time-frame for that credential to expire.

Presentation on "XSS Defeating Concept in (secure)SiteHoster" : 'nullcon-2011'

this is the work that I presented in 'nullcon - 2011' an security conference held at Goa by an emerging Security Community of India known as 'null'
it's mainly regarding preventing XSS Attacks with an entire new Concept based on 'Bug-As-A-Service' and 'Attacking-The-Attacker'...
any views/questions/comments/critics/confusions
----------
Presentation:

Presentation on "XSS Defeating Concept in (secure)SiteHoster" : 'nullcon-2011'

View more presentations from Abhishek Kumar

----------
Concept-Part-1 WhitePaper:

XSS Defeating Trick ~=ABK=~ WhitePaper

View more documents from Abhishek Kumar

----------
Concept-Part-2 WhitePaper:

XSS Defeating Concept - Part 2

View more documents from Abhishek Kumar

----------

Apache SOLR ~ a talented yet careless server

SOLR... what it is?
link: http://wiki.apache.org/solr/FAQ#What_is_Solr.3F
in short... it's an enterprise class search server

SOLR Security Consideration... are clearly stated
link: http://wiki.apache.org/solr/SolrSecurity


[] Solr does not concern itself with security either at the document level or the communication level.


[] It strongly recommends that the application server containing Solr be firewalled such that the only clients with access to Solr are your own


[] Default installation of Solr allows any client with access to it to add, update, and delete documents (and of course search/read too), including access to the Solr configuration and schema files and the administrative user interface.


[] Even if firewalled, it might be vulnerable to CSRF because Solr's basic behavior is to receive updates and deletes via HTTP...
So if you restricted Solr's /update handler to accept connections from approved hosts/clients... then also approved clients can be tricked to open another page with malicious script while they are authenticated at Solr.


[] Basic technique to mitigate this risk is to configure Servlet Container to server speicifc IPs or with HTTP-Authentication.


[] Solr doesn't aim to for Document Level Security, recommended way is through Apache Lucene Connector Framework.

SOLR is a very capable search server, but if you need to use it... be sure to make it unreachable.