Are firewalls useful?
Posted by Steve on Wed 10 Oct 2007 at 09:29
For many years I've been configuring servers without firewalls, and generally find this a good way to do things. However several people have recently questioned my judgment on this manner, so I'm interested in hearing your thoughts.
My general belief has been:
I don't need a firewall, because all the services I run are supposed to be public.
To give a concrete example I run a webserver, and if I firewall access to port 80 nobody will see it! So, short of abusive clients, I have no reason to restrict that.
Similarly I may run other services and again they are supposed to be public.
There are some, minor, exceptions such as running a memcached server - but for those I will configure them sensibly, so the deamon(s) are only listening upon the loopback interface.
This seems to me to be a fine compromise:
- Run public services publically.
- Run non-public services non-publically.
I can easily believe I can make a mistake, and a firewall would prevent people from connecting to services which were accidentally public, but otherwise? Why should I run a firewall?
I've been reconsidering this policy a little recently, after implementing an outgoing firewall - designed to ensure that I'll not take part in a DOS, or similar, if my server is ever compromised by a non-root user. But so far I can't persuade myself that I'd be any better off.
Do you run a firewall? Incoming and outgoing? Does it really help you, or your security?
I run a firewall merely because I know I sometimes make a mistake.
OR a dependency may default to listening on all interfaces (DHCP rings a bell).
That way I know that even despite my own mistakes I *should* be covered.
Cheers,
[ Parent | Reply to this comment ]
('Cos I'm perfick - obviously.)
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
on the other hand, there are a lot of scenarios where firewalls are useful and necessary. and even if you know you don't need it, if it's configured thoughtfully, it won't hurt either, but become something like an additional security insurance (and i guess you won't argue "i don't need health insurance because i never broke my leg before").
so, my opinion in one sentence: a firewall is very helpful, but you must configure it properly, and having an eye on all runnig services in the first place will indeed give you much more security.
[ Parent | Reply to this comment ]
think of an exploit in server Software, or same malicous code
run by a webserver with php.
I firewall would prevent hackers to connect to a port opened by a script or an exploit. Also it would prevent scripts from opening session to remote computers e.g. irc.
So you just find a script trying to open a port (killing such a script will do most time), and not a rooted maschine.
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
This is the case where I've been considering things, I've added outgoing firewalls to many of my machines recently precisely to make sure that if I'm compromised the machine(s) won't be able to download bot software.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
anonymous :for 1 I gotta hand it to you .thanks for the comments about firewalling. they are very thought
provoking.
thanks to all who participate in this internet community, It is so usefull.
!!!
buds
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
So unless someone breaks into your FW or into the VPN, they simply cant get SSH access.
Port forwarding to without at least an ACL is not such a good idea since its a request for a dictionary attack.
Cheers,
BuffPuff
[ Parent | Reply to this comment ]
- Most modern firewalls are more than OSI layer 3 stateful inspection paket filters and add some layer 7 protocol knowledge. Enforcing certain protocol standards (like maximum field length) can give more time to apply patches for security flaws in your applications (buffer overflows etc). Useful e.g. for bind.
- The kernel sometimes contains bugs in its protocol stack or tcp/ip handling not related to a special service. Having a firewall filtering some known attacks can help to keep the kernel safer or give you time to upgrade. Same applies to strange tcp protocol options (syn,ack,reset games, synfloods etc).
- I highly recommend to limit outgoing (from a stateful perspective) connections to prevent an attacker using a flaw in your web application to reload a rootkit or prevent a rootkit from connecting to an irc channel for instructions. It is one thing to get a non-privilegded shell on a machine, but another to get further code (or DVD images or ...) on the box. An attacker in a shell without outgoing connection is rather helpless.
- Having a defined set of incoming ports prevents an attacker to bind his rookit on a free port and access it from the outside.
- I recommend some sort of onion security model. Of cause you can limit connections to your nfs services by hosts.allow, but having a separate barrier between the server and the outside can protect it from bugs in the filter code.
- Having a hardware firewall means adding additional (and most of the time unreasonable) effort for the attacker to make your server his machine.
All those considerations do more apply to hardware firewalls separate from the PC. And of course a firewall is not THE remedy for security problems, it is just another step besides updated, well configured daemons, well chosen software (who needs gcc on a webserver?) and commen sense.
Regards,
Henning
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
Outgoing limits seem like a great idea, and something I've recently introduced.
Your point about kernel bugs is well taken, particularly in light of attacks such as CVE-2007-4567.
[ Parent | Reply to this comment ]
On the other side, many linux tools especially for layer 7 protection are quite advanced, usable and mostly are for real world scenarios ... a premise some closed source firewall systems sometimes do not accomplish.
What do you think?
[ Parent | Reply to this comment ]
Can you elaborate more about these tools, please ?
[ Parent | Reply to this comment ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
Sorry I didn't realise that was non-public. The point I was trying to make is that there are kernel-related networking bugs which can cause problems.
Something like CVE-2007-1388 for example. (Although that is a bad example as it isn't a remotely exploitable issue.)
[ Parent | Reply to this comment ]
For example, if you run a public mail server, it should be put in a DMZ, and then you'd need a firewall.
In the case of a web server, if it's not connected to your LAN, or to any other critical equipment, maybe you don't have much to loose if you don't install a firewall. However, if your server is also connected to your LAN, it should be on a DMZ (with a firewall in place). There are other useful approaches you may want to consider, such as mounting a reverse proxy in order to provide indirect access to an http service that is listening on your LAN.
Other than that, i can think of other benefits of having a firewall, such as logging capabilities, and integration with other security solutions, such as intrusion detection and prevention systems.
[ Parent | Reply to this comment ]
Why do yo need a DMZ for your mail/web servers? Just instruct the firewall to allow incoming connections to the http and smtp ports of the server, and that's it.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
Now to discuss the main point, do I need a firewall? Are you running any sort of intrusion detection/prevention systems (IDS/IPS) to detect malicious activity? A firewall, at a minimum, will provide logs of dropped traffic to alert you to suspicious activity. Most firewalls now have IDS/IPS modules that can run on the applicance (or you can run SNORT on a UNIX box). These modules do require a maintenance contract, since they need to be kept up to dat the way antivirus is. Also, if it is a transactional website, a firewall can help you protect the database from attacks by placing the web server in the DMZ and the database behind the firewall. DMZs are easy to set up, since most firewall appliances have a built in DMZ port and Linux firewalls can be dual-homed (i.e. two NICs). Finally, whether it is a UNIX server or a Windows server, there will always be services that need to run that should not be public facing (leaving NetBIOS ports exposed to the Internet is begging for someone to hack it).
[ Parent | Reply to this comment ]
* Blocking ssh brute force attacks. I want ssh publically available, to connect to my home server from work or from friends connections, but I don't want the continual ssh probes attacking my machine.
* Blocking samba open ports. You can't stop samba from opening up some ports on all interfaces. Even if it's only to read in broadcast traffic, I still don't want it available on my internet interface.
* Traffic monitoring. It's easy enough to put in a firewall rule, which does nothing except match specific traffic. I can then monitor counters on that rule.
Of course, I also use the Linux firewall for NAT purposes, but I'm assuming you're only talking about the filter table.
[ Parent | Reply to this comment ]
There is another firewall between the host and internet, so strictly speaking the host firewall would not be necessary, but I don't trust the very basic HW firewall too much.
[ Parent | Reply to this comment ]
Are you talking of a separate box to protect your LAN, or just an additional software layer to be run on the same machine where the other servies are run?
Only in the first case you might have additional security, as pointed out by some of the previous posts.
But the extra box must be either a hardware firewall, or a Linux machine running a stable kernel, without any extra software, otherwise you expose your firewall to the same type of risks that your server suffers (exploit, misconfiguration, ...)
[ Parent | Reply to this comment ]
1. You might want to run services such as SSH and use firewall to only allow yourself to access these services.
2. You might want to run UDP based non-public services such as portmap (for NFS), NTP or local DNS cache. Sometimes, you can configure these to only listen on loopback, but for example you might want one of your servers to provide NTP to others or something like that and you cannot restrict RPC mapper to loopback.
3. Firewall might protect you from kernel level TCP/IP stack exploits. Yes, firewall might also be vulnerable to such exploits, but I would guess that the source code specifically designed to protect from attacks might be somewhat better scrutinized then generic networking code.
4. By default (according to RFCs) a closed port will immediately return an ICMP packet, which indicates that although the port is closed there IS a host there and a more detailed port scan might be in order. I always configure my firewalls to just drop packets not destined to one of the provided services.
On other hand, your statement about not needing firewall on a service that you already provide is not very accurate. All my web servers are running mod_security firewall to protect me from malformed requests, SQL injections and other high level attacks.
You are off the edge of the map, mate. Here there be monsters!
[ Parent | Reply to this comment ]
We deploy servers with set configurations so that they only listen for SSH from specific addresses. Similarly NTP service, and DNS service is only provided to and from appropriate addresses by the configuration of those services during configuration (Sorry pool.ntp.org is out of the question, as we do port filtering we only talk to three trusted off network timeservers, otherwise port 123 is dead).
Portmapper is a no go on public servers, but even that can be configured to listen to specific IP address ranges. These days OpenSSH is used to avoid using NFS on public servers, and the connections can all be initiated from inside our firewall to the exposed servers.
Where a server exists, providing a public service, there is little reason to try and prevent it returning RFC compliant ICMP packets, since its existence is advertised.
Thus in most cases we can achieve our security policy with publicly exposed servers, without a firewall.
I'd accept the point that a carefully configured firewall might avoid known issues with a specific TCP/IP stack, but then it might also take down all the machines behind it.
Most of our servers are behind a firewall, and behind a proxy server, but the firewall, and proxy, and traffic shaper are bog standard Debian servers.
It was interesting to speak to serious networking folk who regarded firewalls as a stop-gap because the end user OSes and software are just too badly written to expose. I don't get that feeling with the Linux kernel, VSFTP, OpenSSH, Postfix, Squid, & Apache. I do get that feeling from PHP, Windows (all versions), browsers (most), most desktop apps that network, and almost all browser plugins and rich browser functionality (except Java, and even then I've wary).
I agree there is a need to monitor outgoing traffic, that can be met with IDS, and other tools, it doesn't have to be a firewall.
I use to sell firewalls, I know their strong points, and their weak, and for some ISP type scenarios firewalls are not necessarily the best way of implementing security policy. In my case I so need more intruder detection, and I so don't need a better firewall.
The main gain I would see from a firewall would be proxying HTTP traffic, to identify known abuse inside HTTP, but then it would also be desirable to proxy HTTPS, and that gets messy very quickly. It would also have to do a lot of checks very quickly to meet load across a number of busy web servers. As such it may be more sensible to implement such HTTP security inside the web servers, as you mention. Similarly we are interested in PHP hardening, but the reality is most PHP is poorly written that PHP hardening is an exercise in introducing weird bugs.
Last malware (known!) to make it into the Office network came in via the front door on a laptop. The firewall stopped it propagating outside of the network (saved us a trivial amount of bandwidth and nothing more). What was noticeable was how pathetic the Windows software that was suppose to prevent that is at detecting or stopping the problem. Despite the fact once I knew it was there(!) I found the executable in a few minutes by manual inspection, the software on the PC failed to spot the behaviour or the malware, and no major antivirus software recognized the file in question (which is increasingly common). The firewall was useful here more as a point of monitoring, hence my comments on intruder detection, if you know what is happening you can deal with it. Monitoring is key in system administration, this malware would have been less expensive to deal with had we spotted it earlier.
[ Parent | Reply to this comment ]
Excuse me?! Could you explain that statement?
You are off the edge of the map, mate. Here there be monsters!
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
1. Can you point me to any performance benchmarks for NFS vs. SSHFS?
2. Are there any SSHFS clients for non-linux systems?
3. Is there any data on SSHFS scaling?
4. What are the SSHFS mechanisms to separate shared resources from not shared?
5. What ioctl()'s SSHFS support?
6. Does SSHFS support ACLs?
You are off the edge of the map, mate. Here there be monsters!
[ Parent | Reply to this comment ]
To point 2, at least, I can say yes: SSHFS uses FUSE, which works on FreeBSD and apparently on Mac OS X.
[ Parent | Reply to this comment ]
I try to keep firewalls everywhere and to accept traffic from one machine only from the places it really need to do it, in and outbond, yes I AM PARANOIC, no I dont look under my bed when i went to sleep. But the thing is, doing this reduce the impact if one of your servers is taken not only to the rest of the world but to yourself.
Yes, a real hacker would know how to overcame this things, like noexec,nodev in home or data mount point, yes I DO separate directory mount points, and no it is not bullet proff.
But, most of day to day problems are cause by script-kids and this type of mesure either stop them at all or prevent them from doing real damage, and you protect yourselfe from daily punks not from Rambo knocking at your door.
I work with the security concept of the wall, u place a brik over another, and another, and another, it's long hard work, but pays back and with time and practice it becames routine, wich is also an enemy of security, but then you work it back again, find new ways to hardened things and everithing is back to normal.
So my foreword is place a firewall in your servers, restrict inbound and outbound traffic considering Internet and DMZ traffic, and then place a border firewall, with nowaday tools it's incredibly easy, have u try Firewall Builder, it's amazing how simple it's to set up a host firewall fore every server on your net. Then you can start working with some honeyhost, and/or honeynets, get yourselfe a good IDS like snort or something more complex like nagios. And then relax and play your favorit MMORPG, like wow, eve or what ever you like, while you wait for the bells to ring.
Cheers,
rak
[ Parent | Reply to this comment ]
A firewall provides some features but I think they are over-rated and even the Linux magazines dwell on them too much. If you don't know what you are doing farting about with a firewall isn't really going to make your box any more secure. If you know what you are doing they do have their uses but then gain you are less likely to need one just to feel safe.
In many cases Firewalls are pure security theatre.
--
"It's Not Magic, It's Work"
Adam
[ Parent | Reply to this comment ]
Not so long a go one of the sites I just sarted to work got hacked by a group of IRC-script-kiddys, they exploit a CMS whidly use here call Mambo, they gave as a lot of work just becacuse they where able to download, install & run, some irc-web server call traffic and other stuff. We manage to find that the first point of entry was other server with the same soft and the launch the attack from there.
Had those servers block inbound outbound packages, the problemas would nt had spread to the other server so easily.
A better config in the server itself would have prevent the problem at all, but the previus sysadmin, didint consider necesary that because he had a border firewall.
I do agree that when ppl talks about firewall they think in the ultimate security tool, and they are actually just one more. But that doesnt mean they aint usefull at host level.
You will have more work firewalling all your servers, but things will run smuther that way, and when problems show up, and they allways do, u will be able to limitate the damage much more easily that way.
To answer your question, if all ports are closed, well yes they are close o what, do you wont your server to be able to connect to any other server, does he need to, u have an ssh service running in your server, does it need to be accessible from anywhere, or only from your local network, or better so from only one specific master control server?
That questions can only be answer in a security politcies point of view you must set a group of security policies, and follow them that is the starting point of your server setup, and then you will know whether u need or not a host firewll.
Sorry for the spelling, but Im not use to this much writing in english.
Cheer,
rak
PS: a final note things to consider:
1.- How much is the information/service/reputation of your employers worth
2.- How much work will u have to do if the servers get busted
3.- How much time do u have to prepare a good secure server with its firewall
4.- How many ppl will be involve
5.- Do your employers know what your doing, and do they wont you to do it that way
6.- Do you have the knowhow, or do you wont to buy/reasearch it
7.- Replace the employers with your work/reputation and reconsider all the points
8.- Why am I writing this crap instead of being working
[ Parent | Reply to this comment ]
I agree that firewalls are a useful tool in a tool-box but they are not a magic silver bullet that suddenly solves all your problems. I think the Windows media has become fixated on firewalls in an attempt to mitigate Windows terrible security and that this has spilled over into Linux and Unix.
My personal opinion is that unless you know what you are doing, you should never connect a box directly to the internet at all. I strongly encourage people to sit behind a NAT firewall/router device with all in-bound ports closed. In an ideal world I'd have all but certain well known out-bound ports closed too but that leads to problems and problems lead to security being turned off.
My original point is that if you install a firewall and you tick the audit box but don't configure it properly then it's just security theatre and serves no purpose. People have become to lazy to understand what they are doing and a firewall is like a fire alarm both need installing in the right place and maintaining correctly, get it wrong and your box gets rooted or your house burns to the ground with you in it...
For example, Windows users and even some Linux magazines complain that Debian is inferior to Windows (or distro x) because the default install doesn't have a firewall. However no where in the discussion is what a good policy for the firewall should be! Just because you have an air-bag and seat belt does not mean your car is safe if you hit an immovable object at 200 km/h.
--
"It's Not Magic, It's Work"
Adam
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
Cheers, Martin
[ Parent | Reply to this comment ]
Regards,
Henning
[ Parent | Reply to this comment ]
Things become very different in load balanced environment where you have to manage 24 webserver cluster and a 4-node mysql cluster. But a correct firewall isn't only filtering incoming traffic. I find it rather important that our webservers can't start an http browsing session itself. Let's say there's a hack in Apache which give you full root access. First thing a hack will do is download some software/scripts to install on your server. By preveting outgoing http connection (only replies are allowed, accept for a few IP's (such as Debian Security repository - apt update) a hacker is forced to write all the scripts itself. Giving the fact that most hacks are performed by script kiddies and have no programming background, thing become more difficult for the hacker.
Our firewall also only permits 10 connections per 10 seconds for an destination IP. Theirby reducing the change for a DDOS attack. When a port scan is detected (at least 5 connection attempts to 5 different ports within 1 minute) the IP is placed on a blacklist for a week. During the blacklisting any connection, also the ones to a public port, are refused.
Fact is that programs are written by people and that people make mistakes (read bugs). In the worst case this leads to a remote exploid. Using a firewall you can prevent a whole lot of problems when that happens. I guess you have insurances? A insurance is, just like a firewall a precaution, a way to minimise damage/suffering. And believe me, when a commercial server is hacker, the sysadmin WILL suffer!
So yes, firewall's are useful.
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
I wonder how you manage your server? Thru SSH? How do you prevent the whole world accessing your SSH Service.
I manage my servers via a combination of SSH and CFEngine.
To prevent other people from accessing the server(s) via SSH I use the PermitUsers feature of SSH, along with mandatory public keys. (i.e. no passwords).
Previously I used password authentication and denyhosts to prevent dictionary attacks, but nowadays I just disallow passwords instead. Much easier.
Reading your statement I guess you only have one server, and theirfor a very very very small website where only a few people per day will visit.
I run sites like this one, personally, where more than a few people come every day! At work I manage significantly more machines and they rarely use firewalls.
[ Parent | Reply to this comment ]
Let me make clear that our servers self don't run a firewall, but the network router is filtering traffic.
Not running a firewall to prevent yout network is just asking for serious trouble. Because you don't run a firewall you also don't know which connections fail (logdrop on everything that doesn't match).
By default our servers cannot be accessed (not even by SSH) and cannot make any connection to the outside world. By setting the correct rules in the firewall we only connectivity.
So even a new machine on the network cannot be exploited. I know a sysadmin that was installing Debian over a remote connection. With some very bad luck a hacker used a exploit that wasn't fixed by an security update yet. The hacker only installed a very small program. He replaced the binary sshd program with a bash script called ssh which was starting then spyware program and ofcourse the ssh deamon. After the installation was completed the server was rebooted. After the reboot he saw some very strange connection origin from this server in the firewall logs. The spyware program was called "sshd " (note the extra space). Luckily nothing bad happend because the spyware couldn't reach it's host. Before that i was using a special installation (IP range) zone which allowed http connections to the outside world. Now every new machine is isolated from the network accept from within the 'local' network. We also have our own apt reposiory which syns with security.debian.org and also contains some self written programs and scripts for managing a server.
Our webservers handle over 25M sessions (we count sessions, not hits) every day. Theirfor we get every day more than 1000 portscans. Our portscanning blacklist contains currently 9163 entries. We're using hipac for basic filtering (about 98% of all rules). To speed up rule loading we using a self written program that's using the C api's and mysql to insert the firewall rules. In comparisment with the normal cli iptables, loading is about 40% faster.
Without a firewall changes that your hacked or a victim of a DDOS attack is higher that with a proper configured firewall. A month ago we faced (and lived) a DDOS attack from a botnet making over 10,000 connections per second for almost 16 hours to our webservers. That only resulted in a slower website, but all webservers kept being responsive. (homepage was visible within 8 seconds). The routers had a average load of 8.23 (according to big sister) during the attack.
[ Parent | Reply to this comment ]
We have seen such things happen with lot less complex code in the past.
A proper FW setup would block the unwanted connections before they had a chance to find out SSH was even running.
I tend to view firewalls as an added layer. I configure my systems as though there was no firewalling. Then I add the firewall on top of it all.
Besides I have a few machines where I collect IPs that I deem to be hackers (multiple mod_security violations, traps in the PHP code for monkeys trying to get in), and block them for a few days.
I also use the firewall to mitigate D(D)oS attacks. (the worst I blocked was using 1200 attacking machines. And the site did stay up and running after an initial few minutes of timeouts.)
So yes, you can configure a server without firewall. It may even be secure.
But firewalls add some benefits that are hard to reproduce otherwise.
just my 2 cents. :)
[ Parent | Reply to this comment ]
Packet filtering is next to pointless unless you're protecting an entire network at it's _boundary_, (i.e. gateway firewall, DMZ bastion)
- jws
[ Parent | Reply to this comment ]
--
Jaume Sabater
http://linuxsilo.net/
"Ubi sapientas ibi libertas"
[ Parent | Reply to this comment ]
Generally I do believe that all services on a publicly accessible host SHOULD be configured securely. However, mistakes happen, and a firewall can protect you from some of them. There may also be cases where a safe configuration of a service is not possible without a firewall - now you may argue that something like that should not be run on a server at all - but hey, I only have ONE linux server at home so where else should I...? ;)
[ Parent | Reply to this comment ]
I like you have demystify the idea of Firewall=Security. Thats just not the case. If you have a public server and only run the bare necessities, having a firewall and blocking ports that are not used does not protect you anymore than not having a firewall at all.
[ Parent | Reply to this comment ]
Well about firewall, just like steve i configured my servers without firewall.
The was ok for the last 5-6 years.
Now im running a minimal firewall
1) against brute force password hackers,
why? it scrinks my logs so save disk space
2) im running anti p2p (ipp2p) in my iptables,
why? i simple line and blocks a lot.
this is because i had a script kiddy hacked in to joomla and this generated about 600GB traffic and this costs money.
3) block irc incomming and outgoing port ( 6667-7002 )
same reason a nummer 2.
this + mod-security keeps my servers up and running.
but if your not experianced linux administrator, you better run a firewall
for i't same as steve, im running everything on unix socket or localhost and only the services i need run on external interface.
I use this also i the wan/lan's i manage.
so why no firewall
pro: you cannot block yourself, i makes you a better linux administrator.
con: no protection agains ddos, you must configure everything on localhost.
[ Parent | Reply to this comment ]
You're missing the point Steve.
Let's imagine that we have a server doing nothing but serving up web pages. The only daemons running are sshd and apache, and we want both of those to be globally accessible. We don't need a firewall, right?
Wrong.
Imagine an attacker manages to exploit a script on the web server. Generally the first thing the attacker will do is try and launch a shell listening on some port so that they can then further escalate their privileges. If you've got a firewall with inbound rules in place they are prevented from doing this. As you've not got any firewall rules, they've now succeeded in getting a shell as user www-data (in Debian). They then connect to this shell. Now they want to download an escalation exploit from somewhere else. If you had outbound firewall rules, these would stop the attacker - but you don't, so they succeed. Hey presto, the attacker now has root and proceeds to load a rootkit which hides everything they're doing from your prying eyes.
I'm not saying that the simple act of having a firewall in place is going to stop someone from successfully attacking your box, but it's certainly going to make their job far more difficult. Every piece of protection you can put in place (firewalls, SELinux) makes it more difficult for an attacker. Sam Bashton
Bashton Ltd - Linux Consultancy
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]