There is a great series of articles over at the matasano blog about the deficiencies of dnssec. While I have no deep knowledge of the matter, the series seems to bring up very valid points against this security feature (the most near to my heart being the CPU cost of cryptography – which is expensive even on modern hardware – which is good because it means that it’s harder to break). Here are the links to the currently available articles (two more are to come):
- A Case Against DNSSEC (A Matasano Miniseries)
- A Case Against DNSSEC, Count 1: Solves A Non-Problem
- A Case Against DNSSEC, Count 2: Too Complicated To Deploy
What I want to write about today (or better yet, plea to the ISPs) are two things:
- Egress filtering – this means that router check the source IP of the packets which leave their perimeter and drop any packet which has an invalid source IP (meaning that it has an IP from a subnet not associated with that given interface). If all ISPs would perform this filtering IP spoofind would be greatly reduced (because it would be possible to spoof an other IP from the local subnet) and it would lead to better traceability (in case of a DDoS for example). Such filtering could (and may already be) deployed without any impact on legitimate applications. I can think of only two possible problems with it: routers needing additional configuration for each interface (but maybe there are intelligent routers which can perform egress filtering based on routing tables) and routers needing additional processing power for filtering.
- The filtering of the SMTP port on consumer networks (except for the SMTP server of the ISP). This would greatly reduce spam. There is no reason for the average consumer PC connecting to other SMTP servers than the one of the service provider. The only case when a user would need to do such a thing is when s/he has a mail account in a different place (for example at work or at an other service provider). These rare cases could be resolved very simply and without burdening the helpdesk too much by offering a web page (of course with printed description of it given to each user at connection time) – available only the customers of the ISP – which would permit to add one exception at a time for the rules involving the IP where the request came from (so that one customer can’t add exceptions for other customers) and a specified host. The submission should be protected with a CAPTCHA.
It is my opinion that these two measures, if implemented by the wast majority (preferably all) IPSs, would greatly reduce the malicious activity on the Internet.
2 responses to “Securing the Internet”
I certainly wouldn’t like that second step; in fact, running my own domain’s mail server from my home network is already problematic. I’ve left ISPs in the past for the sole reason that they filtered and/or blocked port 25 inbound and outbound to anyone but them. That’s big enough to me to be a dealbreaker.
I don’t even know what my ISP’s mail servers and accounts are, since I don’t use them at all and really don’t want to.
This is not the first time I hear this argument (or variations thereof like: I can’t connect to my work mail server from home), but my opinion remains unchanged:
The SMTP port should be blocked! This may cause a little discomfort for a small percentage of the users (I would guestimate less than 5%), but the zombie spam (which is the prime way to send out unsolicited email these days) would decrease radically. Of course those 5% can also be kept relatively happy by providing an easy mean to add exceptions to the filter (as suggested in the post).
Finally, for companies there are alternative solutions which are guaranteed to work (almost) every time, like webmail over HTTPS or a VPN over port 80.