One important part of the European Prismacloud project is dissemination: make ordinary people understand some of our cryptographic directives. Out of this, the following clip originated: The technique in question is called secret-sharing and was originally detailed in 1979.
Firejail describes itself as a SUID program that reduces the risk of security breaches by restricing the running environment of running programs. We’ll just call it chroot or jail (for the BSDers out there).So, it’s SUID? First things first: it’s SUID, so if there’s an error within the firejail binary an attacker can gain root rights. This comes with the territory. How large is Firejail and how many dependencies does it have?
Keeping a good security and privacy is tough work. There’s always a trade-off between effort and achieved security. In this blog post I’ll mention small things that a ``normal” person should be able to perform — that still increase the overall security of that user’s data. Choose your Liege Bruce Schneier talks about the comeback of feudal security: you choose your liege lord and depend upon him for providing security.
I have just received my OSCP exam success notification. This is a penetration-testing certification by Offensive Security with focus on hands-on-training.You get an eBook and a week’s worth of video lectures with guided exercises; access to a virtual lab with approximately 55 machines that you should gain full control over and will finish with an 24 hour exam in which you are supposed to root five target machines. All this should be documented and submitted at last 24 hours after your exam is over – my documentation had 264 pages.
A project I’m involved with has a traditional distributed client-server architecture: multiple servers are interconnected, clients connect to one more servers. In this use-case we’re expecting around four to seven servers with long-running connections between them and approx. a dozen clients with short-lived connections to the server. Initially I had used plain Java networking but during 2013 I’ve switched over to netty.io as a communication layer. Benefits were more agile networking code, better concurrency, etc.
Pathogen was the first vim plugin management system that I’ve known of. The contender is Vundle which seems to be inspired in it’s configuration syntax (and name) by Ruby’s Bundler. So let’s compare those two. Pathogen Pathogen’s workings are quite easy to grasp: each plugin is a directory within “~/.vim/bundle/“; pathogen traverses through the plugin list and includes each one of them. Let’s see a sample directory: 1 2 3 4 5 6 7 [~/.
After a successful penetration test a re-test is performed. The common approach is that the customer fixes the code and I perform the necessary steps to confirm that that initial security breach was closed. Sometimes it takes the customer a couple of tries to achieve that. Most security problems (XSS, CSRF, SQLi) can easily be automated tested, but I had problems automating server-side authentication and authorization problems. The test would have to emulate multiple parallel user sessions.
My blog has a history of migrations. It started as wordpress, then was converted Octopress. After Octopress was missing update-love and jekyll started to be actively maintained again it switched over to jekyll. And now, it finally is based upon Middleman. Sorry for any inconvinient bugs or layout errors that will happen during the migration. Why have I switched to middleman? as I’m a RoR devleoper it seems better suited for me.
Full-disclosure: I was asked by PacktPublishing to provide a review of Penetration Testing with BackBox by Stefan Umit Uygur. They offered me a free copy of the ebook; otherwise I have not been compensated by any means for this review. The book aims to be an introduction to penetration-testing for experienced Unix/Linux users or administrators (seems like there are Linux users that aren’t administrators by now). After reading the book I believe that the assumed use-case is an administrator that wants to gain some insight into the tools that might be used against his server.
The basic idea is to move application servers into LXC containers while keeping the HTTP server part (which is also responsible for hosting static files) on the host system. Normally an incoming request would be handled by an HTTP server on the host as well as by an HTTP server on the virtualized client: 1 browser -> http server(host) -> http server (guest) -> app-server (guest) I’m configuring the host HTTP server to directly communicate with the app worker, thus: