Archive

Archive for the ‘Security’ Category

For discussion: Orphaned package in Fedora

2015-03-26 6 comments

The Fedora Security Team (FST) has uncovered an interesting problem.  Many packages in Fedora aren’t being actively maintained meaning they are unofficially orphaned.  This is likely not a problem since at least some of these packages will happily sit there and be well behaved.  The ones we worry about are the ones that pick up CVEs along the way, warning of unscrupulous behaviour.

The FST has been plugging away at trying to help maintainers update their packages when security flaws are known to exist.  So far we’ve almost hit the 250 bug level.  Unfortunately we forced a policy that still isn’t perfect.  What do you do with a package that is no longer is supported and has a known vulnerability in it?  Unless you can recruit someone to adopt the package the only responsible choice you have is to retire the package and remove it from the repositories.

This, of course, leads to other problems, specifically that someone has that package installed and they know not that the package is no longer supported nor do they know it contains a security vulnerability.  This morning, during the FST meeting, we discussed the problem a bit and I had an idea that I’ll share here in hopes of starting a discussion.

The Idea

Create a file containing all the packages that have been retired from a repository and perhaps a short reason for why this package has been retired.  Then have yum/dnf consume this information regularly and notify the user/admin when a package that is installed is added to this list.  This allows the system admin to become aware of the unsupported nature of the package and allows them to make a decision as to whether or not to keep the package on the system.

Okay, discuss…

Categories: Fedora Project, Security

A change in thinking…

2015-03-25 Leave a comment

When I entered the information security world in late 2001 I received training on communications technologies that included a significant interest in confidentiality.  Obviously the rest of the trifecta, integrity and availability, were also important but maintaining communications security was king.

Now, almost fifteen years later, I’m still focused on the trifecta with confidentiality coming out with a strong lead.  But my goals have changed.  While confidentiality is an important piece of the puzzle, for privacy and other reasons, I feel it should no longer be king with my work and writing.

Over the coming weeks I plan to focus on the availability of data.  And not just whether or not a file is on a server somewhere but diving into the heart of the availability problem.  File format standards, flexibility of the data to be used with accessibility tools, ability to translate the words into other languages to ease sharing, and the ability to move the information to other forms of media to improve access are all topics I want to cover.

I’m largely writing this as a reminder of ideas I want to research and discuss but I hope this gets other people thinking about their own works.  If you have a great idea don’t you want to make it easier for other people to consume your thoughts and be able to build on them?  Unfortunately the solution isn’t simple and I suspect much will be written over time about the topic.  Hopefully we’ll have a solution soon before that StarWriter file you have stored on a 5.25″ floppy drive is no longer readable.

Categories: Availability

Postfix Encryption

2015-03-12 3 comments

I’ve been tinkering with the encryption options in Postfix for a while.  Encryption between clients and their SMTP server and between SMTP servers is necessary to protect the to, from, and subject fields, along with the rest of the header, of an email.  The body of the message is also protected but it’s always better to utilize PGP or S/MIME cryptography to provide end-to-end protection; encryption between clients and SMTP servers doesn’t provide this.

As rolled out now, encryption between SMTP servers is opportunistic encryption and is generally not required.  While doing a review of my mail log I seem to be receiving most personal mail via some encrypted circuit while much of the mail coming out of listservs, like Yahoo! Groups, is not negotiating encryption on connect.  I’ve also noticed that some email providers actually run their incoming email through an external service, I suspect for spam control, before accepting the message into their servers.  Some of these spam services don’t support encryption making it difficult to protect mail in transit.

Postfix documentation is pretty decent.  The project seems to document most settings but sometimes they don’t actually put the entire picture together.  Encryption is one of those things where a complete picture is difficult to put together just by looking at a single page of documentation.

Postfix’s documentation on TLS is fairly complete.  What they miss on that page, forward security, must be found else where.  Until last night, I had missed that last page and now have fixed my configuration to include, what I consider, acceptable settings.

Here’s what I’ve got:

main.cf

### TLS
# enable opportunistic TLS support in the SMTP server
smtpd_tls_security_level = may
smtpd_tls_eecdh_grade = ultra
tls_eecdh_strong_curve = prime256v1
tls_eecdh_ultra_curve = secp384r1
smtpd_tls_loglevel = 1
smtpd_tls_cert_file = /etc/pki/tls/certs/mail.crt
smtpd_tls_key_file = /etc/pki/tls/private/mail.key
smtpd_tls_CAfile = /etc/pki/tls/certs/mail-bundle.crt
smtpd_tls_session_cache_timeout = 3600s
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtpd_tls_received_header = yes
smtpd_tls_ask_ccert = yes
smtpd_tls_received_header = yes
tls_random_source = dev:/dev/urandom
#TLS Client
smtp_tls_security_level = may
smtp_tls_eecdh_grade = ultra
smtp_tls_loglevel = 1
smtp_tls_cert_file = /etc/pki/tls/certs/mail.crt
smtp_tls_key_file = /etc/pki/tls/private/mail.key
smtp_tls_CAfile = /etc/pki/tls/certs/mail-bundle.crt

master.cf

submission inet n       –       –       –       –       smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_sasl_type=dovecot
-o smtpd_sasl_path=private/auth
-o smtpd_sasl_security_options=noanonymous

Those familiar with setting up TLS in Apache will notice a few differences here.  We haven’t defined ciphers or SSL protocols.  This is because this is opportunistic encryption.  We’re just happy if encryption happens, even using EXPORT ciphers, since the alternate is plaintext.  In a more controlled setting you could define the ciphers and protocols and enforce their use.  Until encryption becomes the norm on the Internet (and why shouldn’t it be?) I’ll have to stick with just begging for encrypted connections.

It should also be noted that client-to-SMTP server connections are forced to be encrypted in master.cf as seen in the submission portion.  This was a quick and dirty way of forcing encryption on the client side while allowing opportunistic encryption on the public (port 25) side.

It should be noted that ECC keys can be used with Postfix, which forces good ciphers and protocols, but most email servers have RSA keys established so problems could arise from that.  Dual keys can always be used to take advantage of both ECC and RSA.

As SSLLabs is for testing your web server’s encryption settings, so is CheckTLS for checking your SMTP encryption settings.  These tools are free and should be part of your regular security check of your infrastructure.

USB Killer (or maybe it’s a killer via USB?)

2015-03-12 Leave a comment

A co-worker passed this along to me and I felt this was worthy of further dissemination.

http://kukuruku.co/hub/diy/usb-killer

And this, my friends, is why you shouldn’t just plug in random, unknown USB devices.

Categories: Security Tags:

CERN cares about information security… what about you?

2015-03-08 Leave a comment

As a security engineer it’s usually difficult for me to endure many of dumb things companies do.  It’s quite sad when a company that prides itself on creating solutions for building internal solutions to protect customer data actually starts pushing its own data out to Google and other “solution” providers.  It’s as if they don’t actually believe in their own products and actually think that a contract will actually protect their data.

So it’s quite refreshing when you run across a group that actually gets information security.  Recently, I ran across the information security bulletins at CERN (particle physics is another interest of mine) and was excited to find a group that actually gets it.  They provide internal, secure solutions for getting their work done without using outside solutions such as Google, Apple, Microsoft, Amazon, and Dropbox cloud solutions (I wish more of the internal solutions were FOSS but…).  In fact, CERN feels externally-hosted solutions are a bad idea for both business and personal uses.  I concur.

Here is a sample of their infosec bulletins:

What about you?  Do you care about the security of your information?

RC4 prohibited

2015-02-19 Leave a comment

Originally posted on securitypitfalls:

After nearly half a year of work, the Internet Engineering Task Force (IETF) Request for Comments (RFC) 7465 is published.

What it does in a nutshell is disallows use of any kind of RC4 ciphersuites. In effect making all servers or clients that use it non standard compliant.

View original

Categories: Confidentiality, Encryption Tags: , ,

What’s worse?

2015-01-06 Leave a comment
Categories: Fedora Project, Security
Follow

Get every new post delivered to your Inbox.

Join 233 other followers