Forgot your password?
typodupeerror
Security

SmoothWall Firewall Review 495

Posted by michael
from the security-in-a-box dept.
ray-x sent in a pointer to a review by c't of the Smoothwall firewall product. c't's reviewer described several flaws in the firewall. We asked Smoothwall for their comments on the review, which are posted below.

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.

This discussion has been archived. No new comments can be posted.

SmoothWall Firewall Review

Comments Filter:
  • by snake_dad (311844) on Wednesday January 09, 2002 @07:30PM (#2813376) Homepage Journal
    as c't is (imho ofcourse) a much respected magazine, and normally I would call it a trustworthy source. I would certainly not expect them to publish such a damaging article without giving the authors of Smoothwall a chance to comment on the findings.
  • Smoothwall & GPL (Score:5, Insightful)

    by johnburton (21870) <johnb@jbmail.com> on Wednesday January 09, 2002 @07:30PM (#2813380) Homepage
    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.
  • Old debate...? (Score:5, Insightful)

    by mwalker (66677) on Wednesday January 09, 2002 @07:35PM (#2813406) Homepage
    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.
  • by hellcore (549684) on Wednesday January 09, 2002 @07:39PM (#2813446) Homepage
    I was in the Smoothwall IRC channel on several occasions when this reporter came in. First of all he didn't conduct himself like any other reporter I have ever met. He was elusive regarding his motives (ie he wouldn't say he was from the press), he was beligerent beyond belief and gave the impression he already knew what he was going to write. Refusing to even listen to the dev team's answers, the sticking the fingers in the ears behaviour he exhibited was most flattering. I just hope c't are more exclusive in future with regards to the staff they employ. This guy was nothing but underhanded and stubborn.
  • Excuses (Score:4, Insightful)

    by Antity (214405) on Wednesday January 09, 2002 @07:44PM (#2813474) Homepage

    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."

    Tsstss.. Look at this excerpt from the article that this SmoothWall guy is complaining about:

    The PPP-Daemon complains in the log file, every start, about the permissive reading rights to its password file, hard to imagine that the developers missed this one.

    I also have a strange feeling about other "security" options that they choose. For example: Not using shadowed password files. They say it wouldn't be neccessary since the only user available is root anyway. But what is the _sense_ of not using shadowed password files? (And what is the sense to require the user to be root to configure the system? Even Apache is supposed to be quite secure, but nobody will run it as root because there still might be holes. Impossible in a hacked-together firewall distribution?) The bytes in length on the harddisk they would have saved would be a joke.

    All in all, I believe there are some truth- and insightful bits in the c't review, even if the reviewer did a mistake.

    btw: To complain that the passwords had to be plaintext because PPPd and FreeSWAN required it is complete nonsense for a Firewall! Sources are available, so why not add a patch to have the passwords encrypted if this is supposed to become a Firewall?

    (Sorry, had to emphasize this, since this is not some desktop distribution but supposed to be a Firewall.)

  • by Lumpy (12016) on Wednesday January 09, 2002 @07:44PM (#2813477) Homepage
    First off reviewing a firewall like that is just whining by a non-techie. you want to review a firewall? crack it... Show me times it took and what kiddie tools took it down or circumvented it because of a flaw in the firewall. bitching about how the scripts are written is clutching at straws and trying to add content to an already empty review.

    Why is it that we all will not listen to a SQL review without stats and figures but a firewall review get's any attention at all if it isnt even tested properly by the reviewer?

    This review was like a review about ram and bitching about the color and shape.
  • by zzzeek (43830) on Wednesday January 09, 2002 @07:44PM (#2813478)
    if a cgi script running as "nobody" is compromised, then it is possible that the user "nobody" can gain shell access as well. A shell is simply another executeable, just like the CGI script itself.
  • by byolinux (535260) on Wednesday January 09, 2002 @07:50PM (#2813517) Journal
    Okay, maybe I was a little hasty, but if someone gives you a bad review, and this was a bad review, you should just suck it up.. Imagine Microsoft sending out a press release everytime someone at /. gave them a bad review - they'd have to pay Taco to incorporate random-ms.pl
  • Re:Old debate...? (Score:4, Insightful)

    by RC514 (546181) on Wednesday January 09, 2002 @07:53PM (#2813537) Homepage

    A false sense of security is worse than no security.

    Even if no users other than root should ever be able to log in to the firewall, there is a reason to carefully set file permissions: Just like on a server, the services running should do so under their private username. That is to prevent a security related bug (aka vulnerability) from compromising the whole system. This is obviously less important on a router/firewall where services are only provided to the inside, but the attitude shown by the authors of Smoothwall certainly destroys my confidence in their general ability to provide a secure system.

    Then there is the false discrimination between inside and outside: Especially when you deal with "non-techie" users you have to expect their systems to become infected by the latest worms and viruses. This opens the possibility of attacks from the inside which really are attacks from the outside. Granted, that is a remote possibility and if it happens, you have bigger problems than firewall file permissions, but it is still not understandable how an easy to fix thing like this is completely ignored. The german review makes it quite clear that the attitude of the firewall authors played a big part in the thumbs-down.

  • by OeLeWaPpErKe (412765) on Wednesday January 09, 2002 @07:58PM (#2813581) Homepage
    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.

    sjah ... reading on

    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.

    so you only have one layer of security ? The inability of any attacker to get a shell ? That's it ? I must admit I have not checked if you do that or not but ...

    In my opinion you should at least take a number of these precautions ...

    -> no shell access for nobody but root (of course this is enforced by putting a check in the main loop of bash, which mails "murder" if anybody tries differently)
    -> all binaries --x--x--x, on a single partition which is the only one mounted without the "noexec" and with "ro" flag
    -> *all* daemons chrooted, none have anything in their /bin or /sbin directory that even remotely resembles a shell or mount program (ie do not use perl, use mod_perl, do not use php, use mod_php, etc)
    -> *all* programs compiled from source
    -> there is no such thing as an irrelevant permission

    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.

    plain text ? wrong permissions ? why would you take a chance ?

    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.

    again ... why take the chance ?

    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.

    user authentication is only irrelevant until a hacker gets by the first layer of security (which apparently on your system is the *only* layer of security)

    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.

    to quote the other article :
    When a group of developers- more than ever one active in the spirit of GPL-want to successfully distribute a good product, they are usually interested in feedback, in order to improve their product. My concrete indications of security problems within SmoothWall found sheer disinterest with Richard Morrell, developer and project initiator. "That doesn't matter" was about the politest of all comments comment. Trust in the developer's competence and integrity is a basic pre-requisite for the usage of security relevant software. Morell has thoroughly destroyed mine."

    this suggests he has contacted you ... wether or not he did I cannot verify, but if he quotes answers from you ("That doesn't matter"), he probably did contact you, and you certainly confirmed that comment with the above reply, I politely wonder about the next part of that sentence ( ... was about the politest of all comments comment.)
  • Re:sharethenet (Score:3, Insightful)

    by shani (1674) <shane@time-travellers.org> on Wednesday January 09, 2002 @08:02PM (#2813609) Homepage
    If you get hacked, simply restart your machine, and you are back to factory settings.

    And are hacked again in 15 minutes.

    This is why computer forensics [honeynet.org] are important.
  • by Anonymous Coward on Wednesday January 09, 2002 @08:27PM (#2813764)
    Last time I emailed him he had the attitude that he demands respect for his pet project because he put lots of sweat, blood, and his own personal funds, and that makes it different from everyone else.

    Thats not working with the community, thats working against the community.

    It's not like they are hiring up freeswan hackers to get freeswan to do more than it does right now (like interoperate with leading vpn manufactures vpn boxes, etc) Its mostly a nice default setup with a ton of knobs that hook into config files.
  • 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).
    You can find all kinds of examples of how to set one up like here. [onlamp.com]
    Older distro's used IPF, but as of 3.0 they use pf. You can read about pf here. [openbsd.org]

    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 ./ heart...;-)
  • by wpanderson (67273) on Wednesday January 09, 2002 @08:35PM (#2813814)
    Strange that we've yet to hear of an 0wned smoothie, outside of some theoretical situations, and some "i already have root because i installed the box" fiddlings.

    If we see a posting on bugtraq or a properly documented break-in sent to us, we'll act on it.
  • by Colloquy (29948) on Wednesday January 09, 2002 @08:44PM (#2813859)
    Sorry, this isn't how things work on Linux, nor many other modern operating systems. File space cannot be "allocated", then "read" in the manner described. You cannot allocate a file without writing to it, thus you cannot fish information from someone else's temp file like you describe. Maybe under DOS, but probably not on anything newer.

    Whoever moderated this post as "Informative" needs to stick to moderating posts on which they are competent to judge, not just anything that sounds good but might be a line of complete BS.
  • by Anonymous Coward on Wednesday January 09, 2002 @08:56PM (#2813935)
    Judging from your other comments here, there seems to be an ongoing quarrel between Smoothwall developers and developers of a fork. Add to that the comments about attitude and the complete ignorance towards possible attack vectors (until they have been exploited in the wild) and I'll know to keep away from this mess. Security requires either inspection or trust. I don't have the time to do the inspection and after reading the Slashdot comments aswell as the c't review I absolutely don't trust Smoothwall.
  • by 3247 (161794) on Wednesday January 09, 2002 @09:02PM (#2813960) Homepage
    The problem with the SmoothWall developers is that they completly fail to understand that security is always only a probability. A complex product can never have 100% security.
    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...

  • Re:Old debate...? (Score:2, Insightful)

    by RC514 (546181) on Wednesday January 09, 2002 @09:40PM (#2814109) Homepage

    From the review: The password for the DSL access was in plain text in an unprotected file.

    The provider password is probably the most valuable information on the firewall, second only to full backdoor access. I have not yet verified that it is actually the secrets file itself which has the wrong permissions, but since c't has a reputation to lose, they wouldn't let an obvious misperception as mistaking a link for the file slip through.

    There are many ways an attacker could gain inside access to the firewall. Most involve security vulnerabilities, others rely on uneducated users. Anyway, if the cgi-bins which are used to configure the firewall are not 100% secure, a buffer overflow in one of them could potentially be used to read any file which is accessible to the cgi-bins user. That's why file permissions do matter. Seeing how many people defend the "only root can log in anyway" statement, do you think they have really taken the necessary steps to avoid such a vulnerability by implementing several layers of security?

    Now aren't you in deep shit already if an attacker can use your inside systems to connect to the firewall? Of course you are. But think about this: Anti-Virus tools will eventually detect backdoors on your user system(s), but not on the firewall. An undetected attacker can easily cause much more damage by actively destroying your data or just abusing your connection for his purposes over a long time. And who would suspect a backdoor on a rock-solid, completely secure firewall? That's why a false sense of security is worse than no security.

  • Re:Excuses (Score:5, Insightful)

    by hearingaid (216439) <redvision@geocities.com> on Wednesday January 09, 2002 @09:56PM (#2814180) Homepage
    I also have a strange feeling about other "security" options that they choose. For example: Not using shadowed password files. They say it wouldn't be neccessary since the only user available is root anyway.

    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.

  • by Yankovic (97540) on Wednesday January 09, 2002 @10:35PM (#2814347)
    I realize I may get flamed/labeled troll here, but this is too much. As much as /. bags on MS, we've NEVER allowed them to post a response right next to the article. Just because this is released under the GPL, we'll make a special exception? What about the kernel devs or the mutt developers when a bug comes out? Shouldn't they get a shot?

    THEN the guy goes on to blame pppd and FreeSWAN which comes bundled with the product for using plain text passwords. Are you joking? If you want one that's secure write it yourself. I don't care who wrote the thing originally, if you want a secure product, then follow the openbsd model and check and recode every line yourself. We don't blame MS Indexing Server (the cause of many of the recent MS bugs), we blame IIS.

    I'm sorry but this is just terrible.
  • by Anonymous Coward on Thursday January 10, 2002 @01:02AM (#2814792)
    I concur with the assessment of Richard Morrell. Morrell doesn't appear to understand that getting angry at people that don't pay for SmoothWall is unlikely to encourage anyone to contribute charitably or think about purchasing a more functional SmoothWall. When people see Morrell cursing someone out on IRC, kicking and banning them from the channel and k-lining them from the server, they come away thinking Morrell has an explosive temper and they want nothing to do with him. If being on IRC helping people is that difficult for Morrell, he should reconsider going on IRC at all.

    Please don't misunderstand me: I understand it requires a lot of time, money and effort to bring SmoothWall into existance; the work is appreciated. SmoothWall is a valuable addition to the free software world. It is frustrating dealing with people who won't read docs. But there is no reason to be belligerant. Morrell does his work and his SmoothWall finances no favors by being rude.
  • by dr.ka0s (549707) on Thursday January 10, 2002 @01:11AM (#2814830)
    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).

    Upon joining the channel, I was bombarded with the omnipresent topic, "Welcome to #smoothwall :: Please do not expect free
    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...
  • by wpanderson (67273) on Thursday January 10, 2002 @03:38AM (#2815149)
    > Ignoring the blatantly anti-open-source sentiment [...]

    what is anti-open-source about giving away the software under the GPL, but asking that people donate something back to the project to get support?
  • by cmkrnl (2738) on Thursday January 10, 2002 @06:30AM (#2815438)
    Well I suppose if the source of whatever product they were reviewing committed an utterly hilarious PR faux-pas by calling C't "No-nothings! how dare you question the mighty dick@how-f*cking-stupid-can-you-be.org" (politely or otherwise).

    One can see their dilemma. Given their most excellent track record (shame my German is not much better). I would tend to give the benefit of the doubt to C't on this occasion.

    Curmudgeon
  • by juct (549812) <ju@heisec.de> on Thursday January 10, 2002 @06:33AM (#2815448) Homepage
    Just a couple of comments to the Smoothwall answer to my review:
    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
    -rw-r--r-- /etc/ipsec.secrets
    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".
  • by night-shade (1935) on Thursday January 10, 2002 @07:15AM (#2815533) Homepage
    Sometime ago I helped my younger brother with a smoothwall install (I had to bolt on a pnp init script for an NE2000 isa card). I read through the docs and mailing list stuff to see if this has:
    1. Been done before
    2. Being worked on now

    It didn't apper tobe the case so I joined the irc chan and asked about the problem I had had, result: kickban

    I was actually going to offer to write the pnp stuff I had done properly and then submit it to them, not any more thank you :)

  • by iGawyn (164113) on Thursday January 10, 2002 @08:40AM (#2815694) Homepage Journal
    However, if your product gets a bad reputation because you refuse to support people, because they haven't donated, then less people will want to use your product, which means less donations. It's a vicious circle, which eventually the Smoothwall developers will have to break.

    Sure, it's free, it's GPLed. Big deal. There are plenty of free, GPLed firewalls out there, and the developers of them are probably a lot nicer. What sets Smoothwall above the rest? Tech support? Reading /., that doesn't seem likely. Features? That only goes so far. Security? You have to plan for the worst, and just because you don't think there's a chance in hell of someone gaining root on the box doesn't mean you don't shadow your passwords, etc.

    Gawyn
  • by dr.ka0s (549707) on Thursday January 10, 2002 @09:51AM (#2815921)
    ASKING? How about virtually demanding?!

    I use open-source software EVERY day, general applications and security tools alike. And you guys at SmoothWall are the _first_ I've encountered to beg for money and refuse to assist those who don't offer any. That's not GPL, that's shareware. Shit, that's not even shareware, that's worse than nagware. You give me a feature-limited product and when I ask about the product's capabilities, you tell me, "donate money for us to help you with it, pay more if you want a real version, or piss off and leave us alone."

    Many of the tools I use were written from scratch by people who had to expend at least as much time and money in development as your group. Look at Ethereal, Nessus, Astaro, FreeS/WAN, OpenSSH and the OpenBSD project.
    Spend a while using Trinux, whose developer has personally invested countless hours individually supporting the people who use his product simply because we've all helped him to make it better! The end result? A damn fine product! And a well-tested product at that!

    You guy's need to do a little reality check, here. If you want money for the development of your project/product -- then make it SO DAMN GOOD people feel karmically compelled to send you donations. Bullying people into paying isn't gonna make them like your product, and probably won't help with word-of-mouth either. Hell, that's why we're having this discussion in the first place...
  • Re:Old debate...? (Score:3, Insightful)

    by jcostom (14735) on Thursday January 10, 2002 @11:08AM (#2816330) Homepage
    Finally, someone gets it.

    In this day and age, the majority of network security incidents have some sort of internal connection. Implicitly trusting your internal users is suicidal in terms of network defense.

    I think c't is right on with his assessment regarding things like file permissions, shadowed passwords, etc. In a security device, there is no excuse for not finishing the job - that is, securing your file permissions, using shadowed passwords, etc.

    The SmoothWall people argue against the need for shadowed passwords as the only interactive user on the system is root. How about the CGIs that manage the applications? How about the possibility of exploiting some sort of weakness in one of them, resulting in the display of the encrypted passwords? Or are they so arrogant as to believe there couldn't possibly be any vulnerabilities in their code?

  • by King_TJ (85913) on Thursday January 10, 2002 @12:22PM (#2816845) Journal
    Almost all of the complaints I've ever seen lodged against Smoothwall were either accusations of the author being rude, a jerk, etc. - or accusations of GPL violations.

    I think it's pretty clear that they haven't openly violated GPL. (They had a previous version where some wording needed a couple small changes to fully comply with GPL, but those changes were made before the latest release.)

    As for the author, so what? The guy invested a lot of his time to give you a product that you can use for free. *That* is the bottom line. Is there a requirement anyplace that says you have to regularly report to Richard Morrell or interact with him directly in any way while you use Smoothwall? Not that I know of!

    I joined the Smoothwall mailing list for quite a while, and what I saw was a flood of beginner questions that could have been answered by the user reading the instructions (or by actually installing the product before asking if it did or didn't have certain features!). If I was the author, I'd get angry with these people after a while too.

"Never give in. Never give in. Never. Never. Never." -- Winston Churchill

Working...