However, I guess we're getting carried away here. Of course you can additionally slap a packet filter on your machine, but it's not a must-have, and pretty much useless if your concept is feasible, and should therefore not be included in a linux distribution by default. That was our topic, and that's my opionion on it, adorned with my reasoning.
I suppose we're not exchanging news anymore, so may I suggest killing this thread?
Regards,
Dennis
If you'va some time left couldn't you then write a simple howto for setting up a chroot eg for apache and how to set it up the way it runs on your box
]]>person B writes a script to test it and publishes it on the internet
If person C can find info on the exploit, I can as well, and therefore my apache is patched. To minimize actual damage in case of a break in (which can still happen of course, man race condition), my apache runs not only chrooted, but also with a more than useless user id, which makes gaining root access basically impossible for your version of person C. Where was your root exploit for Apache, again? Happening _before_ it binds to it's port and chuids to something less braindead? Wow, that's rare.
Moral: No, I will not allow any script kiddie to become root remotely on my box, simply because I have no daemons running as root, and all which are running are safely tucked away behind dedicated uids and chroots. The ptrace bug was a major problem, but that's been fixed soon enough.
]]>you have no packetfilter running and person C connects to your port 31337 on my pc person C tries to connect but the port seems closed due to my packetfilter which doesn't allow new connections on port 31337.
person C won't adapt the script made by person B because he can't. so you become a public anon mailserver, or whatever, and i don't.
in this situation, the same way most scriptkiddies like person C operate, you are safe because of the packetfilter.
I know that if person B would have done this he probably would have adapted his code and could have disabled my firewall first but that is not the situation i am talking about.
It's people like person C that in general compromise computers. this large part can be stopped by a packerfilter, so a packet filter makes sense.
the packetfilter does not stop the attack but it stops person C from connecting to port 31337
generally when people are talking about a firewall people mean packetfilter
Yeah. And when people generally say TV they mean a computer monitor. It's not my problem that some people just don't grasp the most basic differences, and I surely won't adhere to this *cough*standard*cough* and make it worse that way. There are specific descriptive words, even in the english language, so please use them.
Anyhoo..
With a packetfilter you can stop a large part of the attacks of people checking if they can get in.
What now. An attack, or "checking whether one can get in"? There's a difference. "Checking" usually consists of broader portscans, and if there are any running services, banner probing. That's the common scriptkiddie stuff you're referring to, right? Now, pray tell, where is the problem with a script kiddie portscanning your machine if you don't have a local packet filter running? Of course you configured your machine correctly, so that simply nothing is bound to your ppp interface that you dont need. Ergo, the scan will yield no results, as everything is already handled by your TCP stack just fine. If you do offer a public service (Apache, maybe, on a DynDNS host), you WANT people to find and use it, hence "preventing a portscan" is utterly pointless, even contra-productive. In the case of no running remote services, you already have a firewall (in the sense of a concept), but no packet filter whatsoever, and it is not needed, either. Attacks on publically available services are not prevented by a packet filter, as those services are by definition public. A kiddie exploit is a b0rken Content-Length header exploit, or an "evil" HELO string. That's nothing a packet filter on layer2/3 could prevent.
There simply are no "attacks" that a packet filter can help against in these scenarios. A portscan is no attack, not even a preparation of an attack. It's a probing of available, _public_ services. It's like looking at a list of vendors in a mall, and calling this a preparation of burglary. Of course it happens before an burglary, but preventing this does not improve security, but deteriorate service. Same goes for DROPping packets. It's the same principle, really. Security by Obscurity.
What is it that I'm unable to convey? What "attacks" are blocked by your packet filter that makes you sleep better at night? I simply cannot think of anything that would be a threat at all, and be helped against with a local packet filter. Help me. This is not (overly) sarcastic, I mean it. Give me a real world example where a packet filter makes more sense than a cleanly configured host. And don't tell me about "safeguard in case of unclean configurations". If you cannot bind your services correctly, you cannot create usable packet filtering rules, either. And if you need to learn one of both methods, learn the first one. It's easier and better.
And LIDS is indeed not a bad idea. Can prevent privilegue escalation after a remote exploit, but that's an entirely different scenario.
Best regards,
Dennis
A "firewall", in the first place, describes a concept and additionally the methods of implementation needed to seperate networks according to specific rules. A packet filter, however, is NOT a firewall, it's a packet filter. Hence the name. It may be (and often is) part of a firewall, but note the little word "concept" in my defition. THIS is what makes your machine/network secure, not the packet filter, so if you need to supply anything with Arch to increase security, write a good howto about how to create a working security concept for a single machine connected to an untrusted network, and put it online. THAT would help.
Cool. A rant that's even staying on topic.
Greets,
Dennis
I know the difference between a firewall and a packetfilter. though generally when people are talking about a firewall people mean packetfilter. With a packetfilter you can stop a large part of the attacks of people checking if they can get in. most people just try it and are not qualified to improve whatever script they downloaded so a packetfilter will help securing a system in a lot of cases. If you want extreme security install lids and read their tutorial
]]>and how about including one as a sample ?
One can find literally hundreds of examples on the net already, and is thus supposed to die the same death that /usr/doc experienced as a whole.
And additionally, you have the same problem; What to put in this example? A local packet filter is friggin' superfluous until you have some sort of special setup already, and in that case generic examples wouldnt be of help anyway.
Let's face it, it's just an annoying waste of space for anyone who has the slightest clue of configuration, and merely a deterrent for everyone else. A deterrent to solving the underlying problems instead of tinkering with the symptoms. The phrase "Yeah, a firewall is a good thing!" falls often, but unfortunately it does not make sense without futher qualification. A "firewall", in the first place, describes a concept and additionally the methods of implementation needed to seperate networks according to specific rules. A packet filter, however, is NOT a firewall, it's a packet filter. Hence the name. It may be (and often is) part of a firewall, but note the little word "concept" in my defition. THIS is what makes your machine/network secure, not the packet filter, so if you need to supply anything with Arch to increase security, write a good howto about how to create a working security concept for a single machine connected to an untrusted network, and put it online. THAT would help.
Cool. A rant that's even staying on topic.
Greets,
Dennis
What about people who don't install iptables, that's a lot of data to waste on their hard drive... or people who run 2.2 kernels (that's sort of a stretch)...
But the point is that there are too many different configurations of network/server/system for any default firewall (even package-based configurable) scripts to be effective. Personally they'd just get in my way and piss me off.
]]>advanced users will build their own scripts.
]]>And i think most of the people that hack computers are scriptkiddies using known exploits. of course you could change it to break through
my point is that every obstacle counts and if it would stop about 50% of the attacks i'd be happy
]]>I'm just playing around. The point is that once someone gets root it's pretty difficult to stop them, no matter what "obstacles" you put in front of them. The hope is to not let them get root in the first place. It's a lot easier to work to stop the problem than it is to try to clean up afterwards.
]]>