Glad to hear I'm not the only one paying attention to this particular
attack surface. There is nothing like a wide open 24x7 automated attack
surface to keep you up at nights wondering what web exploits will be
discovered next by the hacker community. Even with layers of security
well before things get to me, I'm still wanting to be extremely diligent
with threat mitigation when it comes to unsolicited email.
On 03/07/18 20:55, 799 wrote:
Do you mind writing some more details as I am interested how other
people solve the email problem.
Are you really separating email in different AppVMs?
I only separate attached documents and move them to the respective
project VMs. The email itself is coming in from IMAP and I have an
elaborate set of macro filters that test the SMTP headers details,
validate, flags their state, and process them by moving them off of IMAP
and into an offline mail storage location. If it doesn't pass my barrage
of sanity tests then I don't even pull it onto my system.
Even when you said, that the VM can only connect per SMTP I assume that
you are not separating IMAP (incoming) and SMTP (outgoing) into two two
VMs and then moving emails from the incoming mail VM to the offline mail VM?
Correct. Everything gets sorted base on work related vs personal
interests (eg. Qubes users forum has its own folder) with work/project
grouped and lower priority which I read when I can find time.
You have one VM which makes both IMAP and SMTP correct?
Yes. As far as I can see that is the only way other than building some
sort of rpc mail proxy to make a distributed VM email system, and that
might just widen the attack surface. My email VM does nothing but sort
my email and allow me to send outgoing SMTP as well.
My email VM is denied access to the Internet so any links to malware
content will denies rough sites reach-back capability and prevents
drive-by malware installs. I don't see icons or web content and I am
just fine with that.
The qubes Thunderbird/DVM integration works nicely for automatically
opening any untrusted documents for testing, and if the document needs
to be retained I merely copy it to the appropriate VM for processing or
archiving. The base of the email has already been moved off the IMAP
server and into file system storage into sorted folders for searching or
deletion after processing.
My goal is to automate the email processing grunt work and apply a
defense of security validations even before even copying it onto my
machine for processing. I have checks in place that validate which
emails came from what place, and test how it was authenticated and
passed through the IT infrastructure to get to me. A properly
authenticated internal email gets labeled as such.
If anything is different or suspicious it gets flagged as abnormal and
gets a manual inspection to determine the nature of the unexpected
"feature" of that email. External incoming PDF/DOC documents that could
have embedded macros get flagged as suspicious. It could be phishing or
IT changing their processing because of outages, etc. One day I might
look at putting in some basic deep-learning AI into the process stream
to make it even smarter at detecting processing anomalies such as faked
SMTP headers. That's a little too hard for Thunderbird at the moment.
Which email/calendar client are you using and how do you move mails to
your offline email VM?
I have Thunderbird/IMAP with Lightning for calendar, because it works
fairly well for my purposes. I do use Davmail, but only for the calendar
side of things. One issue with calendar is I keep getting told that a
calendar event had changed and it asks whether to discard or send any
way, and that gets annoying. One day I'll take the time to figure out why.
I like that Thunderbird and the Lightning/calendar invites work
together. At one point Thunderbird got an update and lightning stopped
working, to the point that Thunderbird deactivated it. That sucked, so I
used OWA access for a while and just now realized lightning had been
updated so I reinstalled it. That is one problem with my email VM being
off-line, in that Thunderbird can't check for updates automatically.
That is a catch-22, but I still prefer to keep it this way. The less it
can do on the network, more minimal its attack surface.
My setup:
Dedicated Email VM with Davmail installed. Davmail connects per OWA to
our corporate Microsoft Exchange Server and acts as some kind of gateway
to provide local SMTP/IMAP/CardDAV/CalDAV connections.
For emails I am running offlineimap which connects locally to Davmail
and downloads all emails and creates a local maildir-repository.
Contacts and calendar entries are downloaded via vdirsyncer.
I had not heard of that, thanks. I'll look into that.
All content is now locally available in this Email-AppVM and can now
also be used offline.
Within this VM I have setup:
For plaintext work:
- neomutt - email client
- khal - calendar
- khard - adressbook
- notmuch - fast search
And as GUI email clients (connecting to the Davmail gateway / not using
the maildir-repository)
- Evolution
- Thunderbird
Unfortunately not everything works with the Davmail Gateway:
I can see the exchange Calendar in Thunderbird, but not the calendars of
my colleques.
Yes, creating a meeting generally requires rdp session to an IT
controlled Windows(tm) VM. Life would be easier if I had my own local
Windows VM for software testing, but they want complete control of that
malware magnet.
If I open a calendar entry I get an error.
On Evolution calendar is working much better as I can open and view the
details of an calendar entry, I can create and edit calendar entries -
everything is synced per Davmail to our corporate Exchange.
Strangely I can not delete calendar entries in Evolution.
On lightning I can open, create, modify, and delete, but I do get that
annoying update-anyway-(y/n) prompt when saving it.
With khal I can also view/edit my calendar entries in the terminal.
Same for khard with my contacts.
Todo:
1) Check why I can add/edit calendar entries but not delete them
2) optimize handling of attachments that PDFs / Office documents /
Weblinks are always opened in a DVM.
I have been able to do this for Thunderbird but not yet for neomutt and
Evolution.
3) I'd like to integrate email and calendar into emacs org-mode, which I
am more and more using for PIM.
4) lock down EmailAppVM so that it can only access the Microsoft
Exchange Mailserver nothing more.
I would do so by running IPtables within the VM with a default
incoming/outgoing DROP policy only adding what is absolutely necessary
to get mail/contacts/calendar working with the Exchange server
Doing it in the email VM won't add much security, because an adversary
could just sudo and phone home. What I did was to set the firewallVM
settings to default deny and then use tcpdump to listen for ICMP
"administratively prohibited" messages coming back from the firewallVM.
I create a script running in dom0 that qvm-run's that session with the
'-p' io returned that creates formatted qvm-firewall permit commands,
and I just cut and paste the ones I want into a dom0 command window if I
want to permit one or two during a training session. Once you have the
core infrastructure mapped during the training session you can set all
that back on the shelf and the emailVM just works, and there are no
leaks out to the internet other than the sending of email. If the SMTP
server was session is momentary and and 2FA used, the the only chance
for exfiltration would be limited to when you are sending email. If you
shorten that window of opportunity then its again raising the bar for
the adversary exfiltrator.
I have also thought about separating email into more AppVMs but the
usability trade-off seems to high without gaining that much security.
As the Email AppVM only is used for email/calendar it should have the
same security level like our Exchange Server. If it gets compromise it
doesn't make a difference what I have setup in Qubes.
I don't think it would buy much and would only increase the attack
surface via email. keep it simple :>
Steve
[799]
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/7c987e7e-df8b-40e1-9ab9-fe3f70682290%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.
