Head's starting to spin a little, but I just attended a session called "21st Century Networking: Time to throw out your medieval gateways"
It's an interesting take on the state of network design, and starts off by telling us what we know is true, deep down, but never tell anyone: Network Firewalls are useless.
Because so much traffic tunnels over other ports, or random ports, or malicious code comes in via valid network ports, having a port based firewall is not going to stop stuff getting in or out.
And, nowadays, the operating system itself is reasonably secure. Attacks are coming in via applications and running services, rather than against the OS.
The solution to this is, basically, to retreat: The network, even an internal LAN, chould be considered a hostile place. Get use to it anyway, because IPv6 addresses are globally routable and tunnellable too.
So, to mitigate this, Microsoft recommend dividing client machines into to groups. Manage and Unmanaged.
Unmanaged clients are the PCs/devices beyond the control of the company. Home users, Internet cafes - ones not in the domain. To mitigate against risks from these, using two-factor authentication (Smart cards were the recommended one) and have the user access the corporate servers via MS's Internet Application Gateway software. This gets installed on the application server, and provides an application level firewall which can be modified based on the user's permissions. So, for example, if a user accesses a web page and there's data on the server that the user is not authorised to access, then the gateway filters out that information from the server's responses before allowing the server to client traffic.
Managed clients should have their own local firewall on by default, protecting that client from outside-in access. They should have an X.509 certificates and extensive IPSec policies delivered via Group Policy. Basically, the IPsec policy should contain the IPv6 address of every host in the corporate network (updated by GP every time they boot up), plus the IPv6 address of the corporate DNS server.
Using this method, the client can boot up anywhere in the world, in the company or from home. When the user tries to access a server, the corporate DNS server (which is public facing) provides the IP address. The IPSec policy then kicks in, requiring an encrypted tunnel between the client (using its own X.509 certificate, provided by the domain controller when the client machine joined the domain) and the server it is accessing (which has a certificate signed by the domain controller).
Totally invisible to the end user, and no VPN required at all, and protected against man-in-the-middle-attacks.
The servers, meanwhile, are hardened to only accept traffic coming from clients that are encrypted via IPSec, using valid certificate signed by the domain controller. Therefore, only pre-authorised clients can access them, but from anywhere in the world and with no LAN level firewall required.
As the speaker said: Implimenting this is 99% possible now with Windows software (the only piece missing to de-tunnel tunneled IPv6-over-IPv4 connections, which you can do on Linux but Windows won't have that until early next year).
What is significantly hard to do, is to convince bosses that you don't need a firewall anymore.
Thursday, November 6, 2008
TechEd 2008, Day 4 14:00
I attended a session on "Exchange 2007 Unified Messaging Component description and overview".
You'd be forgiven for think this was a dry and boring topic because... it was. That was 90 minutes of my life that I will never get back.
You'd be forgiven for think this was a dry and boring topic because... it was. That was 90 minutes of my life that I will never get back.
Microsoft TechEd 2008, Day 4, 11:30
My first session for today was on Co-existence and Migration with Exchange Online.
Most of the session was about provisioning new users and migration from local Exchange. As far as Domino migration goes, there are 3 main strategies:
1) Use IMAP, and only migrate mail - no calendars or contacts
2) Migrate from Domino to Exchange locally first (on a staging server), then migrate up to Online. The speaker cited a US company that did this with 1,000 users in one weekend. Friday night they did the migration from Domino to Exchange, then on the Saturday pushed them up to Online. On the Monday, the majority of users used Outlook Web Access while they did client deployments.
3) Partner with a 3rd party vendor. Apparently, our good friends at Quest are about to release a toolset to migrate from Domino directly to Exchange online.
Most of the session was about provisioning new users and migration from local Exchange. As far as Domino migration goes, there are 3 main strategies:
1) Use IMAP, and only migrate mail - no calendars or contacts
2) Migrate from Domino to Exchange locally first (on a staging server), then migrate up to Online. The speaker cited a US company that did this with 1,000 users in one weekend. Friday night they did the migration from Domino to Exchange, then on the Saturday pushed them up to Online. On the Monday, the majority of users used Outlook Web Access while they did client deployments.
3) Partner with a 3rd party vendor. Apparently, our good friends at Quest are about to release a toolset to migrate from Domino directly to Exchange online.
Subscribe to:
Comments (Atom)