Slashdot Mirror
SmoothWall Firewall Review
Daniel Goscomb, one of the lead developers of Smoothwall, responds:
In our opinion this article is extremely badly researched and written. Furthermore it shows a lack of knowledge on the author's part.
The main concern he has is that of people being able to log in to the firewall and read configuration files. This point is irrelevant as there is only a single user that can access the shell, root. This also removes the need of shadow password files, if you have access to the machine to get the passwd file, you are already in as root anyhow.
Secondly he complains of plain text passwords for the ppp passwords. This is not our doing. The passwords are stored in this format as pppd requires them to be in plain text in the two files. He also mentions that the permissions of these files are wrong. If he looked a little more closely he would have seen that they are in fact symlinks to the 2 real files, which do have the proper permissions on them.
He also mentions the same "problem" with the shared keys system in FreeSWAN. Again, they are stored like this as FreeSWAN requires them in this format to read them.
As to the part about user authentification of the CGI scripts. This is completely irrelevant. There is no authentication in the CGI scripts. The authentication is done via .htaccess files, and has no interaction with the CGI at all, other than when you change the passwords.
I also find it disturbing that the author gave us no room for comment in his article, nor did i see anything to suggest he had even asked us about these so called "problems". We would have been happy to answer any questions he had.
Sincerely,
Daniel Goscomb.
It's secure, featurefull and easy to configure - what more could you want?
I used smoothwall for a short time to evaluate it and technically it looked like quite a nice product, but then I started reading about the attitude of it's creator to the GPL.
Now I'm happy for people to write GPL software if they like, and I'm happy for people to write commecial software if they like, but smoothwall seems to want to get the benifits of both.
They seem to want to get make free use of other peoples work through the GPL, but to feel free to only release parts of their software commercialy. I'm not claiming they are breaking the GPL or anything, but there seems something very unfair about their approach.
Also if you get the GPL edition, there are all kinds of requests on the web site that you donate money to them "SmoothWall developers have kids and families too, and it's all about giving back to the people who helped you.
". And yet I would guess that about 90% of what they are giving out was written by other people and they don't suggest they are going to give 90% of their donations to them.
Again, nothing wrong with that, I just don't much like it.
Basically I suggest that people look at their web site, and search the internet for comments about the creators of this software and how unhappy some people are with them before they go and use it.
Sig is taking a break!
This debate seems to be over whether Smoothwall was designed to secure against attack from outside your DSL dialup or against attack from the inside. Shadow passwords are meant to provide a safeguard against dictionary attacks from logged-in users on a multiuser system. c't's complaint that there is no shadow password on a single-user system is valid; if you're worried about people in your own house trying to hack into your firewall.
It is true that internal security against logged in users can help defeat attackers who can only partially penetrate external defenses. If, for instance, you can only use a CGI bug to get ahold of the passwd file, you can leverage this with a dictionary attack if shadowing isn't installed. Provided you can disable the packet filter and attempt to login as root externally once you have the password... or even use an su type exploit from your original CGI bug. Either way, there are a lot of large corporations with bigger security holes than this.
However to claim that his review "shattered the illusion" of Smoothwall being a complete solution for home users is complete hyperbole. A home user who is trying to secure himself from internal attack from other logged in users in his house is probably pretty savvy in the first place and also has bigger problems. If the purpose of this product is have a CD you can ship to your parents to secure their DSL line against script Kiddiez and Hotmail's Traceroute function, then Smoothwall sounds to me like an outstanding effort.
c't': Two demerits.
--
What happens when you outlaw guns
I hope it is on-subject enough to point out that I believe this is an excellent job Slashdot has done, going out and getting the rebuttal for the review. Although it is not quite perfect -- it acts partially to discredit the link source -- it is much closer to what I think Slashdot could be, a first-run news source with original articles -- for [nerds|geeks]. Until then, while the editors post their comments after a link, it's little more than the second-run movie theatres (which have their place, don't get me wrong). Thanks, Slashdot.
I have noticed that the founder of Smoothwall, Richard Morrell has some issues to deal with. He has a huge ego and does not like users that do not pay for his "open source software." He enjoys complaining about how much money he has spent on making CDs and giving them away for free and how people don't donate to him. I have a few quotes that I have collected that he has said on the mailing lists for smoothwall. "i have contacts with people at the kernel team that none of you have... i know people who can get this fixed and i'm on top of it... so stop complaining because you don't know what you're talking about" "i used to work for microsoft, i know how they work" (he worked in the sales dept selling licenses) "You're also not a paying customer - I'll email DIRECTLY my friend who WROTE the official driver. Friendships help. Thats why I'm richard@linux.com" "this is fuck all to do with SmoothWall its hardware level" Also, Mr. Morrell decided to turn it into closed source "enterprise version" that isn't free with extra features. So he's not allowing open source developers to add new features to the open source project because it will compete with his private closed source project.
As your momma always said: 'If you don't have anything good to say about someone, don't say it' or 'if you someone keeps "bothering" you, just stay away from them.' It's as simple as that.
So if you don't like Richard Morrell, head of the SmoothWall project, consider:
Personally, I'm sick of the "one-sided" reporting on Mr. Morrell. I've seen way too many people "complain" about him, but never comment on various personal details that are partially the cause of this -- let alone the daily on-slaught of Windows users who've barely heard of Linux, who don't bother reading the FAQ, let alone demand that SmoothWall automagically support every little, crappy-designed Windows application and their proprietary protocols that don't work well with firewalls anyway. After a week of being on the SmoothWall lists, I'd kill some very rude and ungrateful users well before Morrell. If you feel Morrell is "really bad for the project," then that's his problem, not yours!
Now if you still want something like SmoothWall without the SmoothWall(TM), take notice that others have forked the project into a new one called IPCop. Version 0.1.0 features SmoothWall 0.9.9, all the major post-0.9.9 patches and various enhancements. A final 0.1.1 release is to follow shortly before the team starts to work on version 0.2.0, an Linux 2.4/Netfilter implementation.
For all I care, you can think of IPCop as "SmoothWall without Morrell." Just don't say it outloud since many of us are all sick of hearing it!
-- Bryan "TheBS" Smith
Independent Author, Consultant and Trainer
OpenBSD is a good solution for anyone with a 486 and 8MB RAM. It is fairly simple and easy to use. (If you are familiar with Unix).
./ heart...;-)
You can find all kinds of examples of how to set one up like here.
Older distro's used IPF, but as of 3.0 they use pf. You can read about pf here.
OpenBSD has gone 4 years without a remote hole in the default install. Pretty impressive.
But hey, only use it if you are SERIOUS about security AND don't want to pay anything.
Although you should consider helping fund the project out of the kindness of you
Twice this evening I've tried to get questions answered about their gpl'd smoothwall because my boss saw this slashdot article. And both times I've been nothing but insulted by Richard Morrell, the founder. The first time I was childish and incompetent all because I had the nickname 'nameless'. The second time I was k-lined from the server and he insults me because I have a german last name.
smoothwall.org.txt and smoothwall.org2.txt
Makes you wonder how these guys really act to customers.
Every part of the system has a (hopefully low) propability to be successfully hacked. The more barriers you have, the securer your system is.
It's also worth nothing that the only interactive account is root. There are daemons running under different user ids (I assume in favor of the SW team). As with every remote exploit, these daemons are the entry gates. Also note that remote exploits by definition don't relate to any interactive accounts!
Now, if one service has been hacked, the whole system is already compromised because there are no shadow passwords, files have the wrong permissions, etc.
You can argue about the passwort files for remote connections. You can't argue about not using shadow passwords, that's just plain stupid.
It's like leaving your safe unlocked because there is already the locked front door...
Claus
Several months ago, I was messing around with Smoothwall as a possible simple solution to my home LAN situation. It was the eve of the 0.9.8 release, and I went on the Smoothwall IRC chat area and joked about getting an early copy of the release. Joked. I know that doesn't happen, and figured that with a technically oriented crowd, that I'd be understood as kidding. At the time, it seemed that I was. However.
A couple days later, after having installed Smoothwall and found it to be almost-but-not-quite-right, I popped on and asked a pretty simple question. Why wasn't there a copy of any compilation tools present, or any other services that someone on a small, personal network might like?
The response was pretty terse. "It's a firewall." Repeated inquiries resulted in various forms of the same answer. Now I understand that a firewall has one main purpose, but the -attitude- I got from the developers was really too much. I figured, after being booted from the channel, I'd email Richard and hope that a cooler, more corporate head might reside at the leadership of the Smoothwall project.
Unfortunately, I could -not- have been further from the truth. The situation escalated with Richard harassing me VIA email for several days, after repeated requests of mine not to email me any longer. He continued, his crude insults became -threats-, and it took three days for the matter to settle.
I am currently an assistant administrator at a small college using Linux as a gateway/NAS solution that's desperately in need of updating. Smoothwall might have once been a contender for this, but definitely not now.
I have posted a rather extensive website airing the entire situation with Richard, my own warts and all, at my Smoothwall site for the perusal of anyone interested. Sure, I might have made a mistake or two, but I don't feel anything I may have said justified what I recieved.
Anyone else have similar experiences?
My own pointless vanity vintage computing page
Let's go even farther on this theme of bad choices.
You can logon directly to the root account remotely? You don't have to su first?
Ouch, but that's a major hole. That's like waving a Big Flag. Kiddies, look at this "firewall." Guess what account you should try?
Never allow remote logons to uid 0. Always at least force wheels to su.
There are CGIs available to manage the firewall? Oh, and they use port 81 to access it. How... creative. And it gets better. SSH is on port 222. Have you guys ever heard of port scanners? Custom ports is a way of flagging to intruders which firewall software is being used, except when the custom port pattern is unique.
I can go on. It has a built-in DHCP server. DHCP servers should never be mounted on external firewalls as their logfiles contain too much valuable information when the firewall's security is compromised.
Hmm, at least it has an HTTP proxy. Probably Squid. No SOCKS support though. And yes, it uses NAT. Gack.
Well anyway, maybe this c't review will convince a few people to give up a NAT-based solution. Sadly, they'll probably just go to another one.
my old sig used to be funny, but then slashcode ate it and now it's not funny anymore
I have visited irc.smoothwall.org only once. I do feel, however, that my experience there alone was almost enough to discourage my use of the product. I joined the #smoothwall channel in hopes that I might find answers from knowledgable users or developers that I had been unable to find in any of the available documentation (all of which I read in its entirety).
:: Please do not expect free
Upon joining the channel, I was bombarded with the omnipresent topic, "Welcome to #smoothwall
support if you haven't donated. http://redirect.smoothwall.org/donate"
Ignoring the blatantly anti-open-source sentiment, I proceeded to ask about features and functionality that I feel are paramount to implementation of a device designed to secure my entire network. Before anyone so much as regarded my first question, I was bombarded with "Have you paid yet?" A simple 'not yet' got me my first response: "Can't you read the f**king topc?!"
Of course, I wasn't looking for support -- simply answers to questions about the products capabilities. Off to a great start.
In the end, my questions were answered, privately, by MacGyver, whose answers unfortunaely indicated that features I think are critical in a firewall are only available in the commercial version. To suggest a few:
- No support for multiple IP's on the external interface
- No ability to write filter rules for outbound traffic
- No inherent ability to manage IDS policies used by Snort
- No immediate planned support for a stateful kernel
etc...
Granted, I could accomplish all of these tasks through custom modifications to the product -- but that would defeat the purpose of the product in the first place -- to create a secure filtering firewall that can be easily and securely managed through an integrated portable interface without the need for extensive customization.
To comment on the article posted this evening, I think that despite the article author's process for review or lack thereof, SmoothWall's response was unacceptable. To say that passwords are not shadowed because the box has but the root user would be to say that Bind and Sendmail need not be firewalled because their latest revisions have no vulnerabilities...
yet.
To say that the open-source security packages that comprise the firewall _require_ clear-text passwords is to insult the intelligence of everyone here who knows better or has found more secure alternatives to the same problems in the past. The open-source community is not ignorant, nor are we fooled by any comapny's efforts to conceal laziness.
Security is an unknown. We place our confidence in hybrid hardware and software solutions that provide protection from the exploits we've identified already, but we expect that new vulnerabilities are inevitable. We cannot neglect commonly accepted security practices because our products have not yet been broken. The correlary would be to argue against home alarms because we already have a lock on the door.
A single layer of security is never enough. ESPECIALLY for a firewall. If this were to be an end-user distribution sitting _behind_ a firewall, the lack of external access would _probably_ be enough. However, as a firewall, such neglect for security practices that have a negligible effect on performance but provide such a significant measure of protection is both arrogant and ignorant at the same time.
In conclusion, neither the product's lackluster featureset, nor it's father company's poor customer support practices would have individually discouraged my using it.
Couple those with questionable security practices, though, and I can assure you that SmoothWall will never be enough to protect _my_ network...
Some of this post is very on-topic, but I include the rest for context. Moderators, please be kind.
I and a buddy recently completed a network installation for a small business. They had about 25 PC's in a 100-year-old wood-frame office building with asbetos everywhere and wanted these people to be able to utilize the Internet for such tasks as tracking packages via web sites, etc. They wanted to reduce costs by eliminating some 6 dialup accounts and free up phone lines for voice. They were less than a quarter mile from the local telco POP. So, they tried ADSL on one PC and consistently got about 1.5 Mbps down and about half that up. They loved it.
They asked me as an independent consultant what they should do to get the access to the other PC's. We looked at wiring the building, but due to the structural nightmare of the building, we decided that for their needs we could go with 802.11b. We dropped several CAT5e lines to three locations in the building: the computer room, where their mission-critical apps run on an AS400, and two access point mounts we set up.
We set up a SmoothWall box as their NAT since the evil ISP would only give us one static IP. It looked a lot better than FreeSCO. It was painless, absolutely painless to configure. But it had a shortcomming: it did not support PPPoE, which was necessary for the ADSL drop. Schucks! So we double-NATed using a little Linksys NAT/switch thingy to actually negotiate the PPP for us. We thought this would be nice because if someone were trying to hack in, they would have to circumvent 2 NAT's. We also thought it would have no significant impact on throughput. Big mistake (read on). Regardless, the NAT solution could remain in place should they ever want to add a stateful packet inspection firewall or something like that, or switch to better broadband, or even wire the building.
We spent almost an entire afternoon trying to configure the blasted access points. They were DLink 1000AP's. I followed DLink's instructions to the letter. I have a little beef with DLink about requiring a Windows machine to configure the things, but I can overlook that. I installed the configuration software on my laptop and was ready-to-rumble. The software failed repeatedly to detect the access point using a DLink branded 802.11b client device (USB DWL120). So I tried step two, isolating the AP's on an Ethernet segment. They failed detection again. So I fed the software MAC addresses manually. This failed. I was using only one machine with a known-to-work crossover patch cable. What the *(!@?
We eventually tried swtiching PC's, and then we noticed that the typeface DLink used to print the MAC addresses on their AP's made 5's look like 6's because the ink ran too much. I was really pissed. Upon getting the conf software to work on a desktop, I went back to my laptop to try again. It flat out wouldn't work with either of my 3Com CC10BT PCMCIA cards in different machines. Don't know why to this day; DLink couldn't help me on that one. But it did work on a desktop wit a 3Com 3c509b.
So, we got the access points set up and clients on all the PCs. We set up WEP encryption and tried to hack around a little to get in without the keys. We made sure we altered the default network ID and set good hard-to-guess passwords. It was like butta, for just one day.
Next weekend, we came back and hooked up more PC's. We went up to say 18 from 12. This is where we started having problems.
We used MAC address control on the APs as we promised the company we would. But after hours and hours of trial and error, we discovered that after adding more than 17 MAC addresses to the control list on one AP, the AP would spontaneously loose all of its configuration data. This worked this way on both AP's. DLink was not helpful. We would later RMA one of these and the replacement would do the same. So, we ended up having to have control lists that were local instead of network-wide. This defeated the roaming feature of 802.11b entirely (although nobody has a laptop there right now, I don't like it one bit). It also causes more difficulty in configuring the damn things. My friend, who is an Apple Campus Rep, haunts me to this day with suggestions of buying their AirPort brand equipment and says it would work better. Anyway, we choose DLink 'cause it was a hell of a lot cheaper than Orinoco.
We saved the company lotsa money on their dial-up. Next, we moved their web pages in house on a Red Hat box on a DMZ. DMZ wasn't all that in SmoothWall at the time (no hole poking), but it did what we needed it to. We moved their primary DNS to publicdns.org and set up MX records, the whole works. Set up a sendmail box. Set them up with PHPGroupWare. And, we encouraged them to make donations to the various projects which provided them with these fine products and services. I felt all warm and fuzzy. I had turned them into a free-software shop on commodity hardware and it all worked.
After a while, I started getting phone calls from them saying their web pages were only accessible to some clients. I looked into this. I left myself a way to get in (a port forwarded to a pc with sshd, I had permission to do this), and so I hopped on in and looked around. I became acutely aware that my ssh sessions were being dropped very frequently. I kept getting some sort of error from my ssh client during sessions.
We went back down to isolate the problem. We kept removing pieces of hardware from the network to figure out what the &*^% was going on, but found nothing. Then we learned SmoothWall had added support for PPPoE. We scrapped the Linksys, and we had no more dropped TCP sessions. It was freaky . I have seen the same problem affect two other people who used port forwarding since then with Linksys boxes (I help folks out on Mandrake Expert). SmoothWall had also added better DMZ support. I just have to say the system works beautifully.
Other issues we encountered in the project were users compromising security by using AOL clients. AOL clients create VPNs which in theory could allow hackers to circumvent your company's security. Don't let your users do this.
Oh, I almost forgot, the AS400. Up until we set them up with a network, they were using this shitty twinax serial network to talk to their AS400. It was expensive. It required shitty ISA adapters to be installed in every PC. It almost made me puke.
At the start of the project in our proposal we told them that they should use encrypt everything, even internally, and that that was just common sense. We told them they could put the AS400 on the LAN and use ssh instead of those card-and-twinax interfaces. I even verified this with my fiancee's dad, an old-AS400-fart himself, before I promised them this. WE WERE WRONG.
IBM told us they COULD NOT RUN SSHD WITHOUT BUYING A NEW MACHINE. That is such a load of crap, but we, having no experience with AS400's, could do nothing about it. The IBM man convinced them to run telnet. We told them we would take no responsibility for that. End-of-story.
Hope this has been an informative venting session for all of you. Please note that there was some relevant content in here, and that SmoothWall solved some of my problems, and I think it is a great product.
My major concern is not, that somebody other than the administrator might log into the machine. The major issue of a firewall system is, to tighten security, not to remove existing security mechanisms like tight access rigts to sensitive files, shaddow passwords, etc. But that is exactly what Smoothwall does in direct comparism to any standard linux distribution.
I'm sorry, if the text doesn't make it clear, that I'm not complaining about the format of files but about sensitive files with passwords or secret keys, that are world readable (ie mode 0644). Something like
is a bad thing - period.
I made every effort, to get "printable" response from the developers. I wrote several E-Mails about the issues to Richard Morrel - who was named as contact person- and I went to the IRC channel of the developers. The only printable comment to the subject I got there is "This doesn't matter".