-
Notifications
You must be signed in to change notification settings - Fork 0
Idea & Project list
This is the idea list page, the main page contains general information about the Google Summer of Code program and BalaBit.
The goal of the project would be to set the stage for a libdbi-less SQL destination, focusing on MySQL for a start. The idea is to implement a destination that does not have any of the drawbacks of the libdbi-based solution, and brings a lot of good things instead, such as better performance, support for value-pairs (and optionally type-hinting), and making it much easier to extend the driver to use more efficient methods than transactioned INSERT statements.
An overhaul of the SQL destination has been in the roadmap for a long, long time, this GSoC project is the first step in that direction, with a strong possibility of further involvement in syslog-ng development.
Proposed by: Gergely Nagy
Mentor: Gergely Nagy
Student: Gyula Petrovics
Deliverables of the project:
- A basic driver that can store logs in MySQL...
- ...with support for authentication and database selection
- ...with support for transactions
- ...with support for templatable table names, and automatic table & index creation
- ...with support for value-pairs()
- Higher speed than the existing libdbi-based solution
- If type hinting lands in syslog-ng mainline during GSoC, then support for type hinting would become an optional goal, if time permits
Desirable skills:
- Familiarity with syslog-ng on at least a strong user level
- Familiarity with MySQL on a simple user level
- Familiarity with the C language (deep knowledge not required, but C coding experience is strongly recommended)
- Prior knowledge of the syslog-ng code base is recommended, but not required
What the student will learn:
- Working with an existing, well-established software project
- Simple, but efficient multi-threaded programming in C
- How to use the mysql C client library
- How to store data in SQL efficiently
- Basic Bison & Flex skills, an intro into writing parsers and grammars
Communication & Code repository: The syslog-ng OSE mailing list will be used for communication, and GitHub for code hosting.
The goal of the project is to develop a new syslog-ng destination plugin, one that can add or change data in redis. Unlike most other destinations, the primary objective is not log storage (though that should be possible and supported aswell), but real-time counters, statistics, or in other cases, caching. This would open up a whole new field where syslog-ng can be used, and would make it much easier to collect log statistics, as the collection can be combined with the log processing power of syslog-ng.
Proposed by: Gergely Nagy
Mentor: Gergely Nagy
Student:
Deliverables of the project:
- A new syslog-ng destination driver that interfaces with Redis
- ...with support for MULTI & EXEC -based transactions
- ...supporting customisable, complex commands (such as a combination of INCR, LSET, and so on, within a single transaction, or one after another)
- Documentation, both a HOWTO, and a few example use-cases
- If type hinting lands in syslog-ng mainline during GSoC, then support for type hinting would become an optional goal, if time permits
Desirable skills:
- Familiarity with syslog-ng on at least a strong user level
- Familiarity with redis on a simple user level
- Familiarity with the C language (deep knowledge not required, but C coding experience is strongly recommended)
- Prior knowledge of the syslog-ng code base is recommended, but not required
What the student will learn:
- Working with an existing, well-established software project
- Simple, but efficient multi-threaded programming in C
- How to use the hiredis client library
- Use-cases for redis
- Basic Bison & Flex skills, an intro into writing parsers and grammars
Communication & Code repository: The syslog-ng OSE mailing list will be used for communication, and GitHub for code hosting.
In the world of the Cloud, many services offer REST APIs, logging and indexing services are no exceptions either. The goal of this project would be to lay the foundations of a flexible HTTP destination, that would make syslog-ng able to talk to these REST APIs.
As an added bonus, there is more work on this topic than it is feasible to implement during a GSoC, so there's compelling reason to stay working on the project even past GSoC. Nevertheless, a complete solution can be done during the summer, with well defined goals.
Proposed by: Gergely Nagy
Mentor: Viktor Tusa (co-mentor Gergely Nagy)
Student:
Deliverables of the project:
- A simple HTTP destination, able to communicate with the REST API chosen by the student
- Code flexible enough to support other use-cases, or at worst, code that is easy enough to adapt and improve upon
Desirable skills:
- Familiarity with syslog-ng on at least a strong user level
- Strong knowledge of the HTTP protocol
- Familiarity with at least one REST API (ElasticSearch would be best, but anything useful works)
- Familiarity with the C language (deep knowledge not required, but C coding experience is strongly recommended)
- Prior knowledge of the syslog-ng code base is recommended, but not required
What the student will learn:
- Working with an existing, well-established software project
- Simple, but efficient multi-threaded programming in C
- Working with REST APIs, and distributed systems
- Basic Bison & Flex skills, an intro into writing parsers and grammars
Communication & Code repository: The syslog-ng OSE mailing list will be used for communication, and GitHub for code hosting.
The goal of this project is to deliver an XMPP destination, which can push log messages to an XMPP server as XMPP messages. Either simple messsage push, with configurable node, jid, password, and destination jid, or publish/subscribe model should be supported.
Proposed by: Viktor Tusa
Mentor: Viktor Tusa (co-mentor Gergely Nagy)
Student: Gergely Csordás
Deliverables of the project:
- A simple XMPP destination, able to communicate with an XMPP server, and deliver messages.
- Simple message push model, or publish subscribe model.
- Code flexible enough to support the other model later, or at worst, code that is easy enough to adapt and improve upon
Desirable skills:
- Familiarity with syslog-ng on at least a strong user level
- Stable knowledge of XML
- Familiarity with at least one IM protocols.
- Familiarity with the C language (deep knowledge not required, but C coding experience is strongly recommended)
- Prior knowledge of the syslog-ng code base is recommended, but not required
What the student will learn:
- Working with an existing, well-established software project
- Simple, but efficient multi-threaded programming in C
- XMPP protocol knowledge, and Instant Messaging systems model.
- Basic Bison & Flex skills, an intro into writing parsers and grammars
Communication & Code repository: The syslog-ng OSE mailing list will be used for communication, and GitHub for code hosting.
Creating a complicated configuration for syslog-ng, especially one that spans multiple files and uses advanced features like blocks or junctions is no small task. Debugging them is even harder. The goal of this project would be to write a tool (of some sort) that gives one an overview of syslog-ng's config, a visual graph of how the different pieces are connected.
This tool would be in part embedded in syslog-ng, and would work on the instantiated structures it internally has, and a tool outside of it, that would do the actual display.
Proposed by: Viktor Tusa
Mentor: Viktor Tusa (co-mentor Gergely Nagy)
Student:
Deliverables of the project:
- Support added to syslog-ng that can observe the configuration in use
- ...that can output enough information about it that allows displaying a graph visualizing it
- An external tool that turns the raw information into something visible
Desirable skills:
- Familiarity with syslog-ng on at least a strong user level
- Familiarity with the C language (deep knowledge not required, but C coding experience is strongly recommended)
- Familiarity with (or willingness to learn) data structures in C and Glib (trees, hash maps, arrays, etc)
- Fundamental skill in graph theory, and theory of graph drawing
- Prior knowledge of the syslog-ng code base is recommended, but not required
What the student will learn:
- Working with an existing, well-established software project
- How complex configuration is read and stored in syslog-ng
- How to graphically display the complex internal state of an application
Communication & Code repository: The syslog-ng OSE mailing list will be used for communication, and GitHub for code hosting.
The goal of the project is the development of a library offering a signing mechanism for the log
entries that could assist in the reliable use of log files either for internal verification by the system administrators or in their use as forensic evidence. Although log files can be used to reveal malicious or abnormal activities, the grade up to which the validity of their contents can be guaranteed is under question because they are one of the first targets of attackers. Hence, additional cryptographic mechanisms have to be embedded to enhance their integrity. This project will focus on integrity checks by using Message Authentication Codes in combination with a hash chain scheme that provides a consecutive correlation between each subsequent entry with its previous one. Such proposals are documented in [1] and [2].
Other papers have also been published but to the best of our knowledge, no such mechanism is added to any widely used open source logging system. This GSoC project can generate the workground to the direction of secure logging since further additions can be made to extend their protection with syslog-ng as its benchmark. The contribution will be not just the implementation of the proposed model but also additional characteristics that are added by the contextual operation of log servers which are critical for the admissibility of the proof in a digital forensic investigation like key management issues and log files' rotation handling.
Proposed by: Christos Tsopokis
Mentor: Gergely Nagy
Student: Christos Tsopokis
Deliverables of the project:
- A mechanism signing regular log files in the above mentioned fashion...
- ...with the ability to check log files' consistency once they are opened
- ...with the ability to verify violation of messages generated before an intrusion takes place
- ...with the ability to report detected discrepancies in the predefined log files
- ...with the ability to report tactful files in the predefined log files
- ...with support to easily extend the available hashing algorithms
- Low computational overhead compared to current syslog-ng performance
- If time permits the ability to adopt a flexible attaching scheme for the log stamps of each entry specified by the user through the configuration file
- Deploy a server key management scheme for the keys used by the log server for the verification and the signing of the logs in a way that to the best of our knowledge is not proposed in the past. The mechanism will use regular files with appropriate extension which is absolutely compliant with the way syslog-ng stores and rotate files.
Desirable skills:
- Familiarity with syslog-ng on at least a strong user level
- Familiarity with openssh library on a simple programming level
- Familiarity with the C language (deep knowledge not required, but C coding experience is strongly recommended)
- Prior knowledge of the syslog-ng code base is recommended, but not required
What the student will learn:
- Working with an existing, well-established software project
- How to shield and add value to the content of generated log files
- How to embed cryptographic primitives in a logging service reliably
Communication & Code repository: The syslog-ng OSE mailing list will be used for communication, and GitHub for code hosting.
[1] Bruce Schneier and John Kelsey. 1999. Secure audit logs to support computer forensics. ACM Trans. Inf. Syst. Secur. 2, 2 (May 1999), 159-176. DOI=10.1145/317087.317089 http://doi.acm.org/10.1145/317087.317089
[2] Jason E. Holt. 2006. Logcrypt: forward security and public verification for secure audit logs. In Proceedings of the 2006 Australasian workshops on Grid computing and e-research - Volume 54 (ACSW Frontiers '06), Rajkumar Buyya, Tianchi Ma, Rei Safavi-Naini, Chris Steketee, and Willy Susilo (Eds.), Vol. 54. Australian Computer Society, Inc., Darlinghurst, Australia, Australia, 203-211.
The task is to develop an application which simulates one or more clients sending log messages to syslog-ng. It would be cool, because without access to production environment and sensitive log messages you could
- simulate realistic traffic,
- check configuration of syslog-ng,
- tune up syslog-ng, improve its performance
during testing / deploying phase.
Proposed by: [Adrienn Pallagi][gh:csacskamacska] [gh:csacskamacska]: https://github.com/csacskamacska
Mentor:
Student:
Deliverables of the project:
An application which can send log messages
- legacy-syslog (http://tools.ietf.org/search/rfc3164) vs. syslog (http://tools.ietf.org/html/rfc5424) format,
- TCP vs. UDP transport,
- amount (x log messages) vs. time (for x minutes),
- randomly vs. fixed message rate, peaks,
- act as more client, bind to more IP addresses on host,
- fixed vs. random message size,
- messages with vs. without sequence number,
- fix vs. templated vs. random message content.
Desirable skills:
- Familiarity with the C language (deep knowledge not required, but C coding experience is strongly recommended)
- Familiarity with syslog-ng on at least a strong user level
What the student will learn:
- Working with an existing, well-established software project
- Simple, but efficient multi-threaded and socket programming in C
Communication & Code repository: The syslog-ng OSE mailing list will be used for communication, and GitHub for code hosting.
Most serious issue about cloud services (like Amazon S3) is privacy. It could be solved by Zorp, with the following steps:
- interpret the web services interface (REST, SOAP, and BitTorrent)
- identify the data in it
- use public-key cryptography to encrypt/decrypt the data
In the cloud there will be only encrypted data, while the client does not need to be modified, or even know about the encryption at all.
Proposed by: Szilárd Pfeiffer
Mentor: Szilárd Pfeiffer
Student:
Deliverables of the project:
- A Zorp proxy that can capture Amazon S3 traffic, and encrypt/decrypt it on the fly
- A network transparent solution to one of the biggest problems of the cloud: privacy
- Based on technologies already used world-wide
Desirable skills:
- Familiarity & experience with Amazon S3
- Cryptography & privacy knowledge
- Prior knowledge of the zorp code base is recommended, but not required
What the student will learn:
- Working with an existing, well-established software project
- L7 protocols & firewalling
- Cloud computing technologies aimed at the Enterprise
- Encryption & privacy issues and solutions
- Working with, and writing a transparent proxy
Communication & Code repository: The zorp mailing list will be used for communication, and GitHub for code hosting.
The ideas below are here only for the fun of it, please do not take them seriously, as their single purpose is to stretch the possibilities to their furthest, and a little bit beyond.
House automation is a recurring topic in geek circles, and many wonder how far one should go. We'd like to go a step further, and embed small emitters in every single brick, in every component of the house, that will operate on batteries that last a lifetime (or at least long enough that the house - like any other software projects after it reaches a certain level of maturity - needs to be rebuilt from the ground up, to improve upon its original design). These emitters would send logs to a central server in the house, and thus, the inhabitants would know everything. Imagine the beautiful statistics, the constant flow of information! You'll always know where little Johnny Tables is, the walls, the floor, the room itself will tell you.
The goal of this project would be to get the software side of this vision implemented, and time permitting, a proof of concept demo built as well.
Mentor: None yet.
Student: None, please.
Deliverables of the project:
- A system image, ready to receive transmitted logs over the selected medium (most likely some kind of radio signals and WiFi)
- A web interface that - based on the sample data - can answer queries such as:
- Where in the house is Carmen Sandiego?
- Show me the heat-map of the house, in 3D!
- Which rooms did the guests frequent at last night's party?
- What's the music loudness trend of parties over the past two months?
Desirable skills:
- Strong knowledge of embedded, long-life hardware
- A fair amount of systems design experience
- Know what "data scientist" actually means
- A good amount of coding knowledge is also required
What the student will learn:
- This being a proposal purely for the fun of it - most likely nothing, but the possibilities are, nevertheless, endless!
There were multiple attempts at making a Death Star, there is obviously demand for it, and with everything that is in demand, it will happen at some point.
We want to be prepared, and even take part in this colossal project, by doing what we do our best: contributing to its security, in the shape of a well designed Firewall, built on the battle-tested Zorp application level firewall.
The goal of the project is to build an inpenetratable proxy, for which protocol, that is to be decided during the project, but it must be either an existing protocol that will survive until such time that a Death Star is built (and will have a place on it too); or a completely new one, designed for use on the Death Star.
Mentor: None yet.
Student: None, please.
Deliverables of the project:
- Yeah, well. Don't know. The prospective student will need to come up with a plan (but don't let the rebels have it, thank you).
Desirable skills:
- Strong knowledge of the Star Wars universe
- Limitless imagination
- A fair amount of network design experience
- Knowledge of network protocols (ability to design new ones is highly recommended too!)
What the student will learn:
- This being a proposal purely for the fun of it - most likely nothing, but the possibilities are, nevertheless, endless!
In previous attempts we were not able to find the person responsible for the venitaliton shaft. So our top security officers decided to have the whole Death Star build steps be audited, and reviewable. The goal would be to create a lifelong possibility to review every step of the "Building Death Star v2.0", and find any flaws or errors that could lead to a catastrophic disaster (like a ventialation shaft at the wrong place). If any flaws are found we can blame the worker and the engineer and exile them to Belsavis or Coruscant.
Mentor: None yet.
Student: None, please.
Deliverables of the project:
- Consultation with the build team would be desirable, since no ETA on Death Star v2.0 funding yet until the possible errors in planning are corrected.
Desirable skills:
- Strong Ethical Hacker skills
- Limitless imagination ( Finding new possibilities to spy on people )
- Knowledge of intergalactic Law ( We don't want to break an civil law )
What the student will learn:
- This being a proposal purely for the fun of it - most likely nothing, but the possibilities are, nevertheless, endless!