When I installed this server, I have decided to enable SELinux, and run
it in enforcing mode. And it works !
Finding relevant documentation for SELinux and Debian was more difficult
than expected, and even when it exists, it is often outdated. Also, It
does not give real examples, and one problem I encountered very often is
a policy module with correct labels, but created for another
distribution, and thus not labeling Debian packages correctly. Some
other distros (Gentoo and Fedora) have made huge progress on RBAC
security, it would be nice to see the same on Debian.
Internet ça a du bon. Enfin, pas toujours .. Et en combinant une jolie
on peut réaliser des choses dont personne n’aurait pensé au début …
En bref, et notamment pour faire suite au challenge que certaines
personnes m’ont lancé au SSTIC 2010 (très bonne année d’ailleurs), le
voila: LE pare-feu OpenOffice ! Mais attention: pas un truc codé à
l’arrache, nan, un vrai
pare-feu avec un design toussa
Donc, comment ça marche:
on veut filtrer des paquets avec OpenOffice, donc on a besoin d’OpenOffice
n’ayant pas eu le temps de planifier le portage d’OpenOffice en mode
noyau, j’ai donc fait l’inverse: amener les paquets en espace
utilisateur avec nfqueue + python
Donc, je commence à coder: on crée une feuille calc avec les numéros de
ports à filtrer, je récupère la valeur des cellules (et là je peux vous
le dire: quand on a l’habitude de LaTeX, OO c’est pas la joie), et on
s’en sert pour filtrer les paquets récupérés par nfqueue.
Premier problème: pour utiliser nfqueue, il faut être root. Et faire
tourner OpenOffice en root (donc avec une interface ...
I have started to work on a Live CD for Open Source tools like Prelude
SIEM, and software like Suricata, Snort, OpenVAS to send alerts. The
goal is to easily test these tools, register new agents, get some alerts
and be able to correlate them etc. I also want to add some visualization
tools, so this CD could maybe become a reference for security alert
detection and report.
First, a few points on applications used:
Debian Live for
building the CD. It’s very easy, it’s based on Debian, and it allows
me to re-use some work I’ve done
is the key point: suricata, snort, syslog etc. will send alerts to
Prelude, which has a database, a correlator, a web interface
Standard useful tools: nmap, scapy, wireshark, p0f, etc.
This first version is based on Debian Lenny and arch x86. Everything is
based on packages (.debs) to make it easier to maintain, upgrade
versions or add patches: most of the time, I just have to rebuild
packages from squeeze or sid.
This month, Joanna Rutkowska implemented the “evil maid” attack
This kind of attack can be done on any OS with disk encryption: when
using whole-disk encryption, you have to infect to bootloader. Linux
which has some nice features (including TKS1 and working encrypted
suspend-to-disk). But how does it play with this attack ?
Sadly, the answer is: pretty bad. LUKS has no protection against this
attack, and even requires a /boot partition in clear. Before looking at
the possible solutions, we’ll play with the /boot partition to see how
simple the attack is.
So, Ipoque has published its deep
inspection engine under a free license (LGPLv3):
OpenDPI This is always good news when a
company decides to release source code to the community, so first of all
thanks to Ipoque for this.
Basically, the project looks quite unprepared for release (only a
Makefile, no configure script - though no-one can be blamed for not
using autotools -), but after looking at the code it seems not so bad:
the code is reasonably clean
it builds fine on x86 or x86_64 platforms
the code is provided with a decent list of identified protocols
the demo uses pcap files
There are a few minor annoyances:
the provided lib is a static lib … building a shared library would
be better !
the build system is pretty awful, rebuilding everything each time,
without using deps, no install system etc.
no docs (looking at the demo file was sufficient to understand most
of the function).
no correct website, forums or whatever. I’m sure it will get better
in the future
This last point was the most annoying to me, so I ...
In section 5.1, “Minimum Required Transport Mapping”:
All implementations of this specification MUST support a TLS-based transport as described in RFC5425.
Yay ! So they discovered TLS, that’s great. Especially since RFC
5425 supports certificates authentication (section 4.2.1),
certificate path validation, fingerprints, etc.
2. Improved timestamps (Section 6.2.3) with supports for milliseconds,
time zones, UTC offsets
3. Section 6.3 describes structured data (name-value pairs)
4. Section 7: Structured Data IDs
This allows using an enterprise ID (registered to the IANA) for the
structured data elements
However, nothing really useful on reliability (resending events, making
sure they were delivered, etc.) except the very poor (and useless)
section 8.5, which only acknowledges the lack of support :/ Well,
Prelude IDS can do that pretty good.
Also, nothing on taxonomy, though it may be improved with structured
data. However, it would require a good definition of events ...