loong
04-08-2001, 11:23 AM
do u know how to close port 111 and 113
in linux 6.2 ?
thanks
[ 08 April 2001: Message edited by: loong ]
in linux 6.2 ?
thanks
[ 08 April 2001: Message edited by: loong ]
Click to See Complete Forum and Search --> : how to close port 111 and 113
jemfinch
04-08-2001, 01:48 PM
Portmap listens on port 111, kill it (and remove it from your /etc/rc.d directories.)
Identd listens on port 113. Comment out the necessary line in /etc/inetd.conf.
Jeremy
Identd listens on port 113. Comment out the necessary line in /etc/inetd.conf.
Jeremy
Craig McPherson
04-10-2001, 03:37 AM
If you set up a firewall that block all incoming connections except those you specifically allow, you won't HAVE to shut down any services. Iptables makes this much easier than before with its new stateful firewalling. Putting up a good firewall should always be your first task, any security measures you take after that are secondary.
jemfinch
04-10-2001, 06:53 AM
Originally posted by Craig McPherson:
Putting up a good firewall should always be your first task, any security measures you take after that are secondary.
I actually disagree. Firewalls are large systems, and trusting your security to a large system that can have several bugs in it (for instance, ipfilter and ipfw on the BSD side have both had significant bugs in the past month or so) isn't a good idea.
Your first task should be to either install an operating system that follows a "secure by default" policy, like FreeBSD (which gives you the option of several "security profiles", one of which is "Extreme", which has no ports listening after the install) or OpenBSD; or to disable all unneeded network services before connecting your computer to the network.
If you stop a program from listening on a port, you can be 100% sure that you won't be compromised because of that program. If you stop people outside from knowing that program is listening on a port, you stand a chance of a bug popping up in the firewalling system, a chink being discovered in your firewalling rules, or worse (are you sure your firewall rules come up when you boot? Do they come up before your network listening utilities start listening?)
It's also far easier to stop the few services that are listening by default than to design and test an adequate set of rules for a firewall.
Firewalls are good tools to assure yourself of the security of your box, but they shouldn't be the first thing you use to secure it -- turning off useless daemons should be.
Jeremy
Putting up a good firewall should always be your first task, any security measures you take after that are secondary.
I actually disagree. Firewalls are large systems, and trusting your security to a large system that can have several bugs in it (for instance, ipfilter and ipfw on the BSD side have both had significant bugs in the past month or so) isn't a good idea.
Your first task should be to either install an operating system that follows a "secure by default" policy, like FreeBSD (which gives you the option of several "security profiles", one of which is "Extreme", which has no ports listening after the install) or OpenBSD; or to disable all unneeded network services before connecting your computer to the network.
If you stop a program from listening on a port, you can be 100% sure that you won't be compromised because of that program. If you stop people outside from knowing that program is listening on a port, you stand a chance of a bug popping up in the firewalling system, a chink being discovered in your firewalling rules, or worse (are you sure your firewall rules come up when you boot? Do they come up before your network listening utilities start listening?)
It's also far easier to stop the few services that are listening by default than to design and test an adequate set of rules for a firewall.
Firewalls are good tools to assure yourself of the security of your box, but they shouldn't be the first thing you use to secure it -- turning off useless daemons should be.
Jeremy
Craig McPherson
04-10-2001, 08:23 AM
Originally posted by jemfinch:
<STRONG>If you stop a program from listening on a port, you can be 100% sure that you won't be compromised because of that program. If you stop people outside from knowing that program is listening on a port, you stand a chance of a bug popping up in the firewalling system, a chink being discovered in your firewalling rules</STRONG>
Certainly, you can prevent your house from being robbed either by removing all your valuables from the house, OR by locking the front door. But why throw away all your valuables when you could just lock the front door? If there's no way to get in through the front door, it doesn't matter what's INSIDE the house.
You can say... "If you shut down a service running on a port, you don't have to block that port from outside."
I can say... "If you block a port from outside, you don't have to shut down the service running on that port!"
I think philosophy calls that a "set of mutually self-perpetuating contradictory viewpoints" or some rubbish like that.
Ultimately, they're both "true", but I prefer to stop before at the OUTSIDE of the system, instead of letting them INSIDE only to discover that there's nothing there they can steal. In the latter case, I have to get rid of everything inside they might be able to steal, even if it's stuff I want to keep. In the former case, I can keep whatever I want inside, and simply stop them from getting in.
The great flaw of the shut-down-services philosophy is that you don't know if they'll STAY shut down. Especially with Redhat. I used it for a while. Upgrades tend to overwrite configuration files, turn on services you've turned off, etc. etc.
What happens when your inetd.conf is accidently (or purposefully) overwritten by a new version with 75 services enabled?
What happens when you install LDAP to play around with it for a few hours, then forget to uninstall it -- or think you've uninstalled it, when you haven't?
What happens when a virus or malicious program starts up some service you don't know about?
Have you noticed that all the worms (Ramen, anyone?), trojans, and rootkits allow the attacker a permanent entry point by setting up some service to run on the machine? Wouldn't it be nice if somehow, somehow, packets weren't allowed in despite that service being running??
or worse (are you sure your firewall rules come up when you boot?
My firewall script has 37 echo lines, and 12 logger lines. I think I'd miss it if it weren't there. Also I have lines in 3 other startup scripts that run before the firewall script that set all default policies to DROP, so even if the firewall script doesn't run, the computer has no network access.
Do they come up before your network listening utilities start listening?
I know what the little numbers next to my init symlinks mean.
It's also far easier to stop the few services that are listening by default than to design and test an adequate set of rules for a firewall.
But what about services you DON'T know about? Are you going to do a full (65,000 port) portscan, TCP and UDP on yourself, every day, just to make sure no new ports have popped open during a system upgrade?
The point is, you may know what services are running NOW, but you don't know what will be running in the FUTURE.
Firewalls are good tools to assure yourself of the security of your box, but they shouldn't be the first thing you use to secure it -- turning off useless daemons should be.
Ideally, a person will do both, so it's really a moot argument. However, I'll always say that locking the front door of the house will always take priority over hiding the valuables. What happens if someone walk in the front door WHILE you're hiding the valuables? With iptables, you can have a 5-line script which blocks ALL packets not related to an existing connection -- the power of statefull firewalling means that with just such a tiny script, you make it completely impossible for your box to act as a server to the outside world, in any capacity, at ALL. That's hardly a complex and tuned script: one line does the work. If a person decides he does want certain services open to the outside world, he'll need a more elaborate script, but that comes later. Firewall scripting is NOT difficult if you think logically and procedurally, and your statement that it "takes a lot of time" is silly -- any person who's not willing to devote time to security probably has very, very little security.
You also assume that the set of all services consists of only two categories: services that a person wants open to the entire world, and services that a person doesn't want running at all. Certainly, a person should shut down any services that he doesn't need or want running at all. But what about services that he wants available only to the localhost, or only to the local network but not to the outside world?
What if your productivity depends on finger service running, but only being accessible to the local network? You'd have the person shut it down completely, and lose it productivity, or open it wide to the Internet.
Don't tell me "TCP Wrappers" or "hosts.deny". First, those are the most evil things in existence because so many newbies are confused about them and wind up getting h4x0red because of it. As we both know, but uneducated users don't, those things ONLY affect services that run through TCP wrappers.
How is relying on TCP wrappers for individualized access control ANY different than relying on a firewall for the same? You've already said that relying on a firewall for access control is bad. TCP wrappers, in this instance, are doing exactly the same thing. So which is it?
Instead of futzing with TCP Wrappers, and then worry about any non-wrapped services individually (it's not like you want Apache running through TCP wrappers on a high-traffic webserver), why not do ALL your access control from one, centrally-controlled source?
Everybody needs to be running an SMTP server on their own machine. You lose a great deal of functionality if you don't have one running. But even if you think you have your SMTP server configured to prevent relaying and other unauthorized use, you still don't want your SMTP port open to the world (unless you're actually running a public mail server). In your system, we either have to shut it down completely, losing a great deal of functionality, or leave it open to the world, and be forced to watch spammers try to relay "THE NET'S HOTTEST, YOUNGEST, NAKEDEST TEENS!" e-mail through it all day long. OR use TCP wrappers to have it refuse connections from outside, but still allow access from inside -- but then, you're criticizing a firewall for doing exactly the same thing!
Also, with TCP wrappers, people port scanning the machine won't see the port as closed: they'll be able to open a connection to it, but will get a "Connection Closed" rather than anything useful. That's just how TCP Wrappers works. But then the person KNOWS that you have, for example, a mail server running on your machine. That may just make the person more determined to get in by OTHER means. AND the TCP responses will provide way more OS fingerprinting than you need to give out. I'm not advocating security through obscurity, but I do follow the old adage, "if they don't need to know, don't tell them."
If you make your firewall your primary access control device:
1. You make sure packets you don't want never get into userland, where flaws in userland daemons can be exploited.
2. You can run services that you want to be available ONLY to the local machine, or ONLY to the local network, or even ONLY to certain hosts on the Internet, without making every service wide-open to the world.
3. You don't have to worry about new ports opening in the future, during system upgrades or as a result of malicious action -- the firewall blocks them all.
4. You can see and test your firewall, you can't really see or test several dozen disparate daemons and other security mechanisms, because even if you might know what's running NOW, you can never be sure what'll be running in the future. Anything could bind to a port, and it'd be wide open without you even knowing about it. You have to think not just about the present, but about the future.
5. You get all your filtering done in the kernel -- meaning much better performance than routing packets you don't want through userland.
You say "What if a flaw is found in the firewall?" Well, I say what if a flaw is found in
<STRONG>If you stop a program from listening on a port, you can be 100% sure that you won't be compromised because of that program. If you stop people outside from knowing that program is listening on a port, you stand a chance of a bug popping up in the firewalling system, a chink being discovered in your firewalling rules</STRONG>
Certainly, you can prevent your house from being robbed either by removing all your valuables from the house, OR by locking the front door. But why throw away all your valuables when you could just lock the front door? If there's no way to get in through the front door, it doesn't matter what's INSIDE the house.
You can say... "If you shut down a service running on a port, you don't have to block that port from outside."
I can say... "If you block a port from outside, you don't have to shut down the service running on that port!"
I think philosophy calls that a "set of mutually self-perpetuating contradictory viewpoints" or some rubbish like that.
Ultimately, they're both "true", but I prefer to stop before at the OUTSIDE of the system, instead of letting them INSIDE only to discover that there's nothing there they can steal. In the latter case, I have to get rid of everything inside they might be able to steal, even if it's stuff I want to keep. In the former case, I can keep whatever I want inside, and simply stop them from getting in.
The great flaw of the shut-down-services philosophy is that you don't know if they'll STAY shut down. Especially with Redhat. I used it for a while. Upgrades tend to overwrite configuration files, turn on services you've turned off, etc. etc.
What happens when your inetd.conf is accidently (or purposefully) overwritten by a new version with 75 services enabled?
What happens when you install LDAP to play around with it for a few hours, then forget to uninstall it -- or think you've uninstalled it, when you haven't?
What happens when a virus or malicious program starts up some service you don't know about?
Have you noticed that all the worms (Ramen, anyone?), trojans, and rootkits allow the attacker a permanent entry point by setting up some service to run on the machine? Wouldn't it be nice if somehow, somehow, packets weren't allowed in despite that service being running??
or worse (are you sure your firewall rules come up when you boot?
My firewall script has 37 echo lines, and 12 logger lines. I think I'd miss it if it weren't there. Also I have lines in 3 other startup scripts that run before the firewall script that set all default policies to DROP, so even if the firewall script doesn't run, the computer has no network access.
Do they come up before your network listening utilities start listening?
I know what the little numbers next to my init symlinks mean.
It's also far easier to stop the few services that are listening by default than to design and test an adequate set of rules for a firewall.
But what about services you DON'T know about? Are you going to do a full (65,000 port) portscan, TCP and UDP on yourself, every day, just to make sure no new ports have popped open during a system upgrade?
The point is, you may know what services are running NOW, but you don't know what will be running in the FUTURE.
Firewalls are good tools to assure yourself of the security of your box, but they shouldn't be the first thing you use to secure it -- turning off useless daemons should be.
Ideally, a person will do both, so it's really a moot argument. However, I'll always say that locking the front door of the house will always take priority over hiding the valuables. What happens if someone walk in the front door WHILE you're hiding the valuables? With iptables, you can have a 5-line script which blocks ALL packets not related to an existing connection -- the power of statefull firewalling means that with just such a tiny script, you make it completely impossible for your box to act as a server to the outside world, in any capacity, at ALL. That's hardly a complex and tuned script: one line does the work. If a person decides he does want certain services open to the outside world, he'll need a more elaborate script, but that comes later. Firewall scripting is NOT difficult if you think logically and procedurally, and your statement that it "takes a lot of time" is silly -- any person who's not willing to devote time to security probably has very, very little security.
You also assume that the set of all services consists of only two categories: services that a person wants open to the entire world, and services that a person doesn't want running at all. Certainly, a person should shut down any services that he doesn't need or want running at all. But what about services that he wants available only to the localhost, or only to the local network but not to the outside world?
What if your productivity depends on finger service running, but only being accessible to the local network? You'd have the person shut it down completely, and lose it productivity, or open it wide to the Internet.
Don't tell me "TCP Wrappers" or "hosts.deny". First, those are the most evil things in existence because so many newbies are confused about them and wind up getting h4x0red because of it. As we both know, but uneducated users don't, those things ONLY affect services that run through TCP wrappers.
How is relying on TCP wrappers for individualized access control ANY different than relying on a firewall for the same? You've already said that relying on a firewall for access control is bad. TCP wrappers, in this instance, are doing exactly the same thing. So which is it?
Instead of futzing with TCP Wrappers, and then worry about any non-wrapped services individually (it's not like you want Apache running through TCP wrappers on a high-traffic webserver), why not do ALL your access control from one, centrally-controlled source?
Everybody needs to be running an SMTP server on their own machine. You lose a great deal of functionality if you don't have one running. But even if you think you have your SMTP server configured to prevent relaying and other unauthorized use, you still don't want your SMTP port open to the world (unless you're actually running a public mail server). In your system, we either have to shut it down completely, losing a great deal of functionality, or leave it open to the world, and be forced to watch spammers try to relay "THE NET'S HOTTEST, YOUNGEST, NAKEDEST TEENS!" e-mail through it all day long. OR use TCP wrappers to have it refuse connections from outside, but still allow access from inside -- but then, you're criticizing a firewall for doing exactly the same thing!
Also, with TCP wrappers, people port scanning the machine won't see the port as closed: they'll be able to open a connection to it, but will get a "Connection Closed" rather than anything useful. That's just how TCP Wrappers works. But then the person KNOWS that you have, for example, a mail server running on your machine. That may just make the person more determined to get in by OTHER means. AND the TCP responses will provide way more OS fingerprinting than you need to give out. I'm not advocating security through obscurity, but I do follow the old adage, "if they don't need to know, don't tell them."
If you make your firewall your primary access control device:
1. You make sure packets you don't want never get into userland, where flaws in userland daemons can be exploited.
2. You can run services that you want to be available ONLY to the local machine, or ONLY to the local network, or even ONLY to certain hosts on the Internet, without making every service wide-open to the world.
3. You don't have to worry about new ports opening in the future, during system upgrades or as a result of malicious action -- the firewall blocks them all.
4. You can see and test your firewall, you can't really see or test several dozen disparate daemons and other security mechanisms, because even if you might know what's running NOW, you can never be sure what'll be running in the future. Anything could bind to a port, and it'd be wide open without you even knowing about it. You have to think not just about the present, but about the future.
5. You get all your filtering done in the kernel -- meaning much better performance than routing packets you don't want through userland.
You say "What if a flaw is found in the firewall?" Well, I say what if a flaw is found in
jemfinch
04-10-2001, 10:17 PM
Ok, I'll try to break this down into smaller chunks and address each one :)
Certainly, you can prevent your house from being robbed either by removing all your valuables from the house, OR by locking the front door. But why throw away all your valuables when you could just lock the front door? If there's no way to get in through the front door, it doesn't matter what's INSIDE the house.
First, let me mention that's I'm not against using a firewall. I use one myself, as assurance of my other security measures.
But to take your analogy further, if one's assets are valuable enough, locking the front door isn't all you're going to do. You're going to get yourself a safe that you can put behind a picture, or a hollowed-out book for your bookshelf, or another means of further securing your belongings.
I think philosophy calls that a "set of mutually self-perpetuating contradictory viewpoints" or some rubbish like that.
Ultimately, they're both "true", but I prefer to stop before at the OUTSIDE of the system, instead of letting them INSIDE only to discover that there's nothing there they can steal.
You're right -- we are basically arguing the same thing. Where the disagreement comes in is with the "I prefer to stop at the OUTSIDE of the system." I disagree with that because a firewall is a part of the system, as much as the other network utilities are. Bugs happen in firewalls that allow people to circumvent your firewall rules (There used to be one in ipchains, I know, where masq'ed boxes could be reached trivially; just last week one was discovered in ipfilter, a very well tested firewall, that allowed packets through because it mishandled message fragments.)
The great flaw of the shut-down-services philosophy is that you don't know if they'll STAY shut down. Especially with Redhat. I used it for a while. Upgrades tend to overwrite configuration files, turn on services you've turned off, etc. etc.
That's a major flaw in the system. If your distribution overwrites your config files when you "upgrade" it, then you should raise hell. That shouldn't happen (and doesn't, with FreeBSD or Debian, which are the two free *nices I work with.)
I know what the little numbers next to my init symlinks mean.
And those little numbers aren't applicable to every linux distribution nor the BSDs. :)
The point is, you may know what services are running NOW, but you don't know what will be running in the FUTURE.
Again, keep in mind I'm not arguing against having a firewall at all. What I'm saying is that turning off needless programs is a higher priority than setting up a firewall.
And again, if you don't know what's running on your box, before or after an upgrade, then you need some more skill as a sysadmin or a system that doesn't surprise you like that.
What happens if someone walk in the front door WHILE you're hiding the valuables? With iptables, you can have a 5-line script which blocks ALL packets not related to an existing connection
That's why all production computers should be set up before every being connected to the network.
What if your productivity depends on finger service running, but only being accessible to the local network? You'd have the person shut it down completely, and lose it productivity, or open it wide to the Internet.
No I wouldn't. Again, I'm not arguing about firewalls in general. I'm saying that needless services should be turned off before trying to create a seamless, working firewall.
Don't tell me "TCP Wrappers" or "hosts.deny". First, those are the most evil things in existence because so many newbies are confused about them and wind up getting h4x0red because of it. As we both know, but uneducated users don't, those things ONLY affect services that run through TCP wrappers.
I never run anything through inetd (which is required for TCP Wrappers) :)
You make sure packets you don't want never get into userland, where flaws in userland daemons can be exploited.
Personally, I trust Postfix far more than I trust any firewalling software I use. Kernelland bugs are far more dangerous than userland bugs, for one, and postfix is much more widely tested than most firewalling software.
Turning off needless programs is a much better, holistic approach to security than using just a firewall. Trusting the security of your box to a single layer, the firewall, is a very poor idea in computer security. And IMO, the first layer of security should be the fact that there's nothing that can possibly be insecure, not that what is insecure has been hidden (obscured) by a firewall.
Jeremy
P.S: it looks like the last part of your post got cut off.
Certainly, you can prevent your house from being robbed either by removing all your valuables from the house, OR by locking the front door. But why throw away all your valuables when you could just lock the front door? If there's no way to get in through the front door, it doesn't matter what's INSIDE the house.
First, let me mention that's I'm not against using a firewall. I use one myself, as assurance of my other security measures.
But to take your analogy further, if one's assets are valuable enough, locking the front door isn't all you're going to do. You're going to get yourself a safe that you can put behind a picture, or a hollowed-out book for your bookshelf, or another means of further securing your belongings.
I think philosophy calls that a "set of mutually self-perpetuating contradictory viewpoints" or some rubbish like that.
Ultimately, they're both "true", but I prefer to stop before at the OUTSIDE of the system, instead of letting them INSIDE only to discover that there's nothing there they can steal.
You're right -- we are basically arguing the same thing. Where the disagreement comes in is with the "I prefer to stop at the OUTSIDE of the system." I disagree with that because a firewall is a part of the system, as much as the other network utilities are. Bugs happen in firewalls that allow people to circumvent your firewall rules (There used to be one in ipchains, I know, where masq'ed boxes could be reached trivially; just last week one was discovered in ipfilter, a very well tested firewall, that allowed packets through because it mishandled message fragments.)
The great flaw of the shut-down-services philosophy is that you don't know if they'll STAY shut down. Especially with Redhat. I used it for a while. Upgrades tend to overwrite configuration files, turn on services you've turned off, etc. etc.
That's a major flaw in the system. If your distribution overwrites your config files when you "upgrade" it, then you should raise hell. That shouldn't happen (and doesn't, with FreeBSD or Debian, which are the two free *nices I work with.)
I know what the little numbers next to my init symlinks mean.
And those little numbers aren't applicable to every linux distribution nor the BSDs. :)
The point is, you may know what services are running NOW, but you don't know what will be running in the FUTURE.
Again, keep in mind I'm not arguing against having a firewall at all. What I'm saying is that turning off needless programs is a higher priority than setting up a firewall.
And again, if you don't know what's running on your box, before or after an upgrade, then you need some more skill as a sysadmin or a system that doesn't surprise you like that.
What happens if someone walk in the front door WHILE you're hiding the valuables? With iptables, you can have a 5-line script which blocks ALL packets not related to an existing connection
That's why all production computers should be set up before every being connected to the network.
What if your productivity depends on finger service running, but only being accessible to the local network? You'd have the person shut it down completely, and lose it productivity, or open it wide to the Internet.
No I wouldn't. Again, I'm not arguing about firewalls in general. I'm saying that needless services should be turned off before trying to create a seamless, working firewall.
Don't tell me "TCP Wrappers" or "hosts.deny". First, those are the most evil things in existence because so many newbies are confused about them and wind up getting h4x0red because of it. As we both know, but uneducated users don't, those things ONLY affect services that run through TCP wrappers.
I never run anything through inetd (which is required for TCP Wrappers) :)
You make sure packets you don't want never get into userland, where flaws in userland daemons can be exploited.
Personally, I trust Postfix far more than I trust any firewalling software I use. Kernelland bugs are far more dangerous than userland bugs, for one, and postfix is much more widely tested than most firewalling software.
Turning off needless programs is a much better, holistic approach to security than using just a firewall. Trusting the security of your box to a single layer, the firewall, is a very poor idea in computer security. And IMO, the first layer of security should be the fact that there's nothing that can possibly be insecure, not that what is insecure has been hidden (obscured) by a firewall.
Jeremy
P.S: it looks like the last part of your post got cut off.
Craig McPherson
04-11-2001, 09:45 AM
It looks like the end of my post did get cut off, but I don't think there was very much of importance after that. No big deal. Maybe the new UBB version imposes a post limit size?
But to take your analogy further, if one's assets are valuable enough, locking the front door isn't all you're going to do. You're going to get yourself a safe that you can put behind a picture, or a hollowed-out book for your bookshelf, or another means of further securing your belongings.
First of all, I'll confess that I hate analogies. I think they're usually pretty meaningless, and I feel dirty whenever I discuss one. I always say, "Don't tell me what it's LIKE, tell me what it IS."
That said, I'd still have to say that in that analogy, locking the front door would be the FIRST thing a person should do, otherwise someone can walk right in while the person is drilling a hole in his wall for a safe. Anything after that is secondary in importance.
Bugs happen in firewalls that allow people to circumvent your firewall rules (There used to be one in ipchains, I know, where masq'ed boxes could be reached trivially; just last week one was discovered in ipfilter, a very well tested firewall, that allowed packets through because it mishandled message fragments.)
That's why it's a person's responsibility to find out when security problems like that happen, and patch. When a problem comes up, fix it. By the nature of open-source, it's more likely that the person who discovers the bug will be a developer or other involved person who'll get the news out to the security sites than a scr1p7 k1dd1e who'll keep it to himself, so anybody should be able to find out about and fix any problem in very short order after the problem is revealed.
And it's much easier to monitor security advisories for your firewall than for who knows how many daemons you have running naked to the world.
That's a major flaw in the system. If your distribution overwrites your config files when you "upgrade" it, then you should raise hell. That shouldn't happen (and doesn't, with FreeBSD or Debian, which are the two free *nices I work with.)
You're right about those, but it DOES happen with Redhat and company, which is what the scr1p7 k1dd13z are targetting, and new users are getting hacked to heck because of it. And the fact that it doesn't happen regularly with your distro doesn't mean it COULDN'T happen. A badly-written installation script in a package or port could reactivate an init script that you've turned off. I'm sure it's happened before. A lot of things could happen.
And those little numbers aren't applicable to every linux distribution nor the BSDs.
Yes, and with the BSD init system, it's even simpler to make sure your startup stuff is running in the order you want it to, right?
And again, if you don't know what's running on your box, before or after an upgrade, then you need some more skill as a sysadmin or a system that doesn't surprise you like that.
I'm not a professional sysadmin, just a volunteer, but I've been doing it for quite a while, and have a decent bit of UNIX and general security knowledge.
A couple months back, I noticed a new package in Debian that would download the Microsoft Windows fonts from Microsoft's website and register them with the X font server. I went ahead and installed this package, not noticing (because I was installing and upgrading a lot of other packages at the time) that that particular package depended on the "macutils" package (because the font archive on Microsoft's website was in Stuffit format), and the "macutils" package just happened to have a "recommends" dependency on the AppleTalk daemon package.
A couple days later, I was having the machine portscan itself, and I noticed a new port open. I had no idea where it came from, and wasn't references in /etc/services, so I had to use lsof to track the port back to the program that was binding it, and found a daemon called "aptd". After some initial puzzlement "APT is a daemon now"? I tracked the program as belonging to the AppleTalk Daemon package, and removed it after puzzling out how it go there in the first place.
Yes, I caught it because I regularly check what's running on the system and what ports are open -- but I didn't catch it until two days later. If the firewall hadn't been up, then for two entire days that port would have been open to the outside world, which would have been one more point of entry for an attacker. I have no idea of Linux's AppleTalk daemon's security record, but that still would have been bad just on principle even if the service had never had a single security advisory filed on it.
That's the kind of thing that can happen.
This could happen under ANY Un*x OS with a smart package manager, Debian and *BSD included: What about a person installing a package or port that has a mail server, or mysql, or ldap, etc., as a dependency, and the user installs it either not knowing what it means (in the case of a new user), or not noticing the dependency being installed, or planning to just try out the package temporarily but then forgetting to also remove the servers it depended on? It could happen.
That's why all production computers should be set up before every being connected to the network.
I'll agree there, but not every UNIX box is a production server run by an experience administrator. I'm more concerned about new users who are attacked and have no idea what to do about it. I'd rather tell a newbie, "Run this iptables script first, then you'll be 99.9% safe while you read this 380KB text file on disabling services, using TCP wrappers, port scanning yourself, and inspecting your process list for unknown daemons" rather than "Be a sitting duck for the time it takes you to read this this 380KB text file on disabling services, using TCP wrappers, port scanning yourself, and inspecting your process list for unknown daemons" or "Unplug your computer from the network and turn it into a glorified paperweight while you read (from another computer) this 380KB text file on disabling services, using TCP wrappers, port scanning yourself, and inspecting your process list for unknown daemons". Which of those would really be most helpful and encouraging to a new user?
No I wouldn't. Again, I'm not arguing about firewalls in general. I'm saying that needless services should be turned off before trying to create a seamless, working firewall.
If you're going to be doing all this before connecting the computer to a public network, fine, it doesn't matter WHAT order you do things in. But in the real world that's not always how things work. Most new users want to get on line NOW and learn the details later, unfortunately. A simple "block all NEW and INVALID connections" iptables script will prevent about 97.2185% of the security problems that new users have, problems caused by distros with shipping with many, many services turned on: not only does one have to worry about their superserver services, but also as services running as independent daemons. In Debian, for example, you may have checked the rc directory for your runlevel and shut down anything you didn't like, but did you remember to check /etc/rcS.d also?
I never run anything through inetd (which is required for TCP Wrappers)
Then you have the problem that, unless you're using a firewall, access control for each service you ARE running has to be configured by whatever method that service has for doing so.
Personally, I trust Postfix far more than I trust any firewalling software I use. Kernelland bugs are far more dangerous than userland bugs
You can look at it that way, however, if the packet is stopped at the kernel, it never GETS to userland. If the firewall allows a packet through to userland because of a bug, then there STILL has to be an exploitable bug in userland for someone to gain any sort of unauthorized access -- a flaw in the firewall AND a flaw in one of the machine's daemons, at the same time. Less likely.
for one, and postfix is much more widely tested than most firewalling software.
I know you're running a firewall on your box, but would you be comfortable running Postfix on a a machine WITHOUT a firewall, relying only on Postfix's built-in access controls to prevent abuse?
If so, you're braver than I.
If I were using Postfix just for outgoing mail (as I said earlier, I think every Unix box really needs a mail server running, even if it's only for outgoing mail), I'd much rather block incoming port 25 at the firewall than learn Postfix's access control methods, and hope that I did them right. And can portscan my box from outside and verify that port 25 is closed to the outside world, but I can't try every series of SMTP commands that might allow someone to relay through my box (either through a bug in the program or through misconfiguration of the Postfix config files on my part), or every possible Postfix exploit. Maybe I made an error in the configuration file and someone CAN relay mail through the server despite my intent, and the next day the FBI is at my door because my box was being used to host a kiddie porn mail list. (Really, that's what it was-- a mail server configuration error, honest!!!)
Turning off needless programs is a much better, holistic approach to security than using just a firewall. Trusting the security of your box to a single layer, the firewall, is a very poor idea in computer security.
I think that trusting your security to the fact that there aren't any services running RIGHT NOW that you don't want running is equally poor. You might know NOW what services are running, but you don't know what services are running TOMORROW. Even if you realize you've accidently started a service up 8 minutes after you do so, that's 8 minutes when you're vulnerable. I had AppleTalk running for 2 days, but thanks to the firewall, nobody could get to it.
The crux: I think that an exploitable hole being discovered in the firewall is going to happen much, much less often than an instance where you're running some service that you don't know about. I know that firewall exploits have been discovered, but I trust the solidarity of the firewall much more than I trust the human capacity to ensure no undesired services are running on the box. In the latter case, there are too many wildcards, too many factors, too many things that can go wrong, than to rely on that as the sole means of security.
And again, I'd imagine most people want to run services on their box that they DON'T want open to the outside world.
I have a server that runs the following services: daytime, ftp, ssh, telnet, smtp, time, DNS, DHCP, http, pop3, ntp, netbios (Samba), imap, ntalk, junkbuster, squid, Distributed.Net proxy, and ldap. All are used extensively on the local network. Almost all are closed to the outside world by the firewall. I imagine many people are in similar circumstances. That's why I say: firewall first!
Where the disagreement comes in is with the "I prefer to stop at the OUTSIDE of the system." I disagree with that because a firewall is a part of the system, as much as the other network utilities are.
But you can't deny that kernel space is OUTSIDE userspace, as far as the outside world is concerned. They can't get to userspace without going through the firewall, and that's my point. I draw a sharp distinction between the firewall in the kernel, and userland networking tools, as I think anyone should.
[ 11 April 2001: Message edited by: Craig McPherson ]
But to take your analogy further, if one's assets are valuable enough, locking the front door isn't all you're going to do. You're going to get yourself a safe that you can put behind a picture, or a hollowed-out book for your bookshelf, or another means of further securing your belongings.
First of all, I'll confess that I hate analogies. I think they're usually pretty meaningless, and I feel dirty whenever I discuss one. I always say, "Don't tell me what it's LIKE, tell me what it IS."
That said, I'd still have to say that in that analogy, locking the front door would be the FIRST thing a person should do, otherwise someone can walk right in while the person is drilling a hole in his wall for a safe. Anything after that is secondary in importance.
Bugs happen in firewalls that allow people to circumvent your firewall rules (There used to be one in ipchains, I know, where masq'ed boxes could be reached trivially; just last week one was discovered in ipfilter, a very well tested firewall, that allowed packets through because it mishandled message fragments.)
That's why it's a person's responsibility to find out when security problems like that happen, and patch. When a problem comes up, fix it. By the nature of open-source, it's more likely that the person who discovers the bug will be a developer or other involved person who'll get the news out to the security sites than a scr1p7 k1dd1e who'll keep it to himself, so anybody should be able to find out about and fix any problem in very short order after the problem is revealed.
And it's much easier to monitor security advisories for your firewall than for who knows how many daemons you have running naked to the world.
That's a major flaw in the system. If your distribution overwrites your config files when you "upgrade" it, then you should raise hell. That shouldn't happen (and doesn't, with FreeBSD or Debian, which are the two free *nices I work with.)
You're right about those, but it DOES happen with Redhat and company, which is what the scr1p7 k1dd13z are targetting, and new users are getting hacked to heck because of it. And the fact that it doesn't happen regularly with your distro doesn't mean it COULDN'T happen. A badly-written installation script in a package or port could reactivate an init script that you've turned off. I'm sure it's happened before. A lot of things could happen.
And those little numbers aren't applicable to every linux distribution nor the BSDs.
Yes, and with the BSD init system, it's even simpler to make sure your startup stuff is running in the order you want it to, right?
And again, if you don't know what's running on your box, before or after an upgrade, then you need some more skill as a sysadmin or a system that doesn't surprise you like that.
I'm not a professional sysadmin, just a volunteer, but I've been doing it for quite a while, and have a decent bit of UNIX and general security knowledge.
A couple months back, I noticed a new package in Debian that would download the Microsoft Windows fonts from Microsoft's website and register them with the X font server. I went ahead and installed this package, not noticing (because I was installing and upgrading a lot of other packages at the time) that that particular package depended on the "macutils" package (because the font archive on Microsoft's website was in Stuffit format), and the "macutils" package just happened to have a "recommends" dependency on the AppleTalk daemon package.
A couple days later, I was having the machine portscan itself, and I noticed a new port open. I had no idea where it came from, and wasn't references in /etc/services, so I had to use lsof to track the port back to the program that was binding it, and found a daemon called "aptd". After some initial puzzlement "APT is a daemon now"? I tracked the program as belonging to the AppleTalk Daemon package, and removed it after puzzling out how it go there in the first place.
Yes, I caught it because I regularly check what's running on the system and what ports are open -- but I didn't catch it until two days later. If the firewall hadn't been up, then for two entire days that port would have been open to the outside world, which would have been one more point of entry for an attacker. I have no idea of Linux's AppleTalk daemon's security record, but that still would have been bad just on principle even if the service had never had a single security advisory filed on it.
That's the kind of thing that can happen.
This could happen under ANY Un*x OS with a smart package manager, Debian and *BSD included: What about a person installing a package or port that has a mail server, or mysql, or ldap, etc., as a dependency, and the user installs it either not knowing what it means (in the case of a new user), or not noticing the dependency being installed, or planning to just try out the package temporarily but then forgetting to also remove the servers it depended on? It could happen.
That's why all production computers should be set up before every being connected to the network.
I'll agree there, but not every UNIX box is a production server run by an experience administrator. I'm more concerned about new users who are attacked and have no idea what to do about it. I'd rather tell a newbie, "Run this iptables script first, then you'll be 99.9% safe while you read this 380KB text file on disabling services, using TCP wrappers, port scanning yourself, and inspecting your process list for unknown daemons" rather than "Be a sitting duck for the time it takes you to read this this 380KB text file on disabling services, using TCP wrappers, port scanning yourself, and inspecting your process list for unknown daemons" or "Unplug your computer from the network and turn it into a glorified paperweight while you read (from another computer) this 380KB text file on disabling services, using TCP wrappers, port scanning yourself, and inspecting your process list for unknown daemons". Which of those would really be most helpful and encouraging to a new user?
No I wouldn't. Again, I'm not arguing about firewalls in general. I'm saying that needless services should be turned off before trying to create a seamless, working firewall.
If you're going to be doing all this before connecting the computer to a public network, fine, it doesn't matter WHAT order you do things in. But in the real world that's not always how things work. Most new users want to get on line NOW and learn the details later, unfortunately. A simple "block all NEW and INVALID connections" iptables script will prevent about 97.2185% of the security problems that new users have, problems caused by distros with shipping with many, many services turned on: not only does one have to worry about their superserver services, but also as services running as independent daemons. In Debian, for example, you may have checked the rc directory for your runlevel and shut down anything you didn't like, but did you remember to check /etc/rcS.d also?
I never run anything through inetd (which is required for TCP Wrappers)
Then you have the problem that, unless you're using a firewall, access control for each service you ARE running has to be configured by whatever method that service has for doing so.
Personally, I trust Postfix far more than I trust any firewalling software I use. Kernelland bugs are far more dangerous than userland bugs
You can look at it that way, however, if the packet is stopped at the kernel, it never GETS to userland. If the firewall allows a packet through to userland because of a bug, then there STILL has to be an exploitable bug in userland for someone to gain any sort of unauthorized access -- a flaw in the firewall AND a flaw in one of the machine's daemons, at the same time. Less likely.
for one, and postfix is much more widely tested than most firewalling software.
I know you're running a firewall on your box, but would you be comfortable running Postfix on a a machine WITHOUT a firewall, relying only on Postfix's built-in access controls to prevent abuse?
If so, you're braver than I.
If I were using Postfix just for outgoing mail (as I said earlier, I think every Unix box really needs a mail server running, even if it's only for outgoing mail), I'd much rather block incoming port 25 at the firewall than learn Postfix's access control methods, and hope that I did them right. And can portscan my box from outside and verify that port 25 is closed to the outside world, but I can't try every series of SMTP commands that might allow someone to relay through my box (either through a bug in the program or through misconfiguration of the Postfix config files on my part), or every possible Postfix exploit. Maybe I made an error in the configuration file and someone CAN relay mail through the server despite my intent, and the next day the FBI is at my door because my box was being used to host a kiddie porn mail list. (Really, that's what it was-- a mail server configuration error, honest!!!)
Turning off needless programs is a much better, holistic approach to security than using just a firewall. Trusting the security of your box to a single layer, the firewall, is a very poor idea in computer security.
I think that trusting your security to the fact that there aren't any services running RIGHT NOW that you don't want running is equally poor. You might know NOW what services are running, but you don't know what services are running TOMORROW. Even if you realize you've accidently started a service up 8 minutes after you do so, that's 8 minutes when you're vulnerable. I had AppleTalk running for 2 days, but thanks to the firewall, nobody could get to it.
The crux: I think that an exploitable hole being discovered in the firewall is going to happen much, much less often than an instance where you're running some service that you don't know about. I know that firewall exploits have been discovered, but I trust the solidarity of the firewall much more than I trust the human capacity to ensure no undesired services are running on the box. In the latter case, there are too many wildcards, too many factors, too many things that can go wrong, than to rely on that as the sole means of security.
And again, I'd imagine most people want to run services on their box that they DON'T want open to the outside world.
I have a server that runs the following services: daytime, ftp, ssh, telnet, smtp, time, DNS, DHCP, http, pop3, ntp, netbios (Samba), imap, ntalk, junkbuster, squid, Distributed.Net proxy, and ldap. All are used extensively on the local network. Almost all are closed to the outside world by the firewall. I imagine many people are in similar circumstances. That's why I say: firewall first!
Where the disagreement comes in is with the "I prefer to stop at the OUTSIDE of the system." I disagree with that because a firewall is a part of the system, as much as the other network utilities are.
But you can't deny that kernel space is OUTSIDE userspace, as far as the outside world is concerned. They can't get to userspace without going through the firewall, and that's my point. I draw a sharp distinction between the firewall in the kernel, and userland networking tools, as I think anyone should.
[ 11 April 2001: Message edited by: Craig McPherson ]
FoBoT
04-11-2001, 09:51 AM
Originally posted by Craig McPherson:
<STRONG>It looks like the end of my post did get cut off, but I don't think there was very much of importance after that. No big deal. Maybe the new UBB version imposes a post limit size?</STRONG>
there is a post limit size, not sure what it actually is, but i got sliced a while back with a "how i did it" post, had to chop it up into smaller pieces
<STRONG>It looks like the end of my post did get cut off, but I don't think there was very much of importance after that. No big deal. Maybe the new UBB version imposes a post limit size?</STRONG>
there is a post limit size, not sure what it actually is, but i got sliced a while back with a "how i did it" post, had to chop it up into smaller pieces
redhanded
10-16-2002, 07:52 PM
Certainly one of the best discussions I've found regarding security of linux systems and the role of firewalls. I was searching for tips on the role of host deny in securing my system, but I now have second thoughts about relying solely on host deny while I read the next 700 pages to find out how to set up a firewall. Being a newbie - 4 whole weeks with linux - I would be interested in Craig's five line script for iptables.
Currently the only thing I've figured out so far is netstat -a, left over from the window days to help me see what's listening and what's not. During this linux learning curve it's like a blind man driving a car - you've got your box up and running - but you don;t have any clue where it going. Especially if I'm allowing someone to use my system to store and forward kiddie porn.
I've tried to install a couple of systems like tripwire and SNMPLog without success. Program installation seems to be somewhat more difficult than the windows norm. So I guess it's better to start off simple with some good lines in iptables and hope for the best when it comes to malicious code and sharing my box with the world.
Currently the only thing I've figured out so far is netstat -a, left over from the window days to help me see what's listening and what's not. During this linux learning curve it's like a blind man driving a car - you've got your box up and running - but you don;t have any clue where it going. Especially if I'm allowing someone to use my system to store and forward kiddie porn.
I've tried to install a couple of systems like tripwire and SNMPLog without success. Program installation seems to be somewhat more difficult than the windows norm. So I guess it's better to start off simple with some good lines in iptables and hope for the best when it comes to malicious code and sharing my box with the world.
divakar
10-18-2002, 03:41 AM
Originally posted by Craig McPherson
Don't tell me "TCP Wrappers" or "hosts.deny". First, those are the most evil things in existence because so many newbies are confused about them and wind up getting h4x0red because of it. As we both know, but uneducated users don't, those things ONLY affect services that run through TCP wrappers.
I am an uneducated user. I have asked a question on this forum with subject as "Security for a home desktop" where I ask whether for my home desktop is hosts.deny with all:all enough protection. I did not understand much of your long reply but does it mean that full protection against the recent internet worms is not possible without a firewall configured? What about portsentry. By default, on my system, it is configured to add hosts that try portscanning to the hosts.deny list.
I would appreciate your comments on that thread either here or at that thread.
Thanks in Advance.
Don't tell me "TCP Wrappers" or "hosts.deny". First, those are the most evil things in existence because so many newbies are confused about them and wind up getting h4x0red because of it. As we both know, but uneducated users don't, those things ONLY affect services that run through TCP wrappers.
I am an uneducated user. I have asked a question on this forum with subject as "Security for a home desktop" where I ask whether for my home desktop is hosts.deny with all:all enough protection. I did not understand much of your long reply but does it mean that full protection against the recent internet worms is not possible without a firewall configured? What about portsentry. By default, on my system, it is configured to add hosts that try portscanning to the hosts.deny list.
I would appreciate your comments on that thread either here or at that thread.
Thanks in Advance.
slapNUT
10-19-2002, 06:58 AM
Being a newbie - 4 whole weeks with linux - I would be interested in Craig's five line script for iptables
The below was taken from this (http://www.netfilter.org/documentation/tutorials/lw-2000.tar.gz) tutorial.
3.1 A Simple Scenario
Single machine with no forwarding: PPP interface
Only ident requests to come in from outside
3.2 A Simple Solution
iptables -A INPUT -i lo -j ACCEPT
iptables -P INPUT DROP
iptables -N LOGDROP
iptables -A LOGDROP --m limit --limit 5/hour -j LOG
iptables -A LOGDROP -j DROP
iptables -N ppp-incoming
iptables -A ppp-incoming -p ! tcp -f -j LOGDROP
iptables -A ppp-incoming -p tcp --dport ident -j ACCEPT
iptables -A ppp-incoming -p tcp ! --syn -j ACCEPT
iptables -A ppp-incoming -p udp --dport 53 -j ACCEPT
iptables -A ppp-incoming -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A ppp-incoming -p icmp --icmp-type pong -j ACCEPT
iptables -A ppp-incoming -j LOGDROP
In ip-up script:
iptables -A INPUT -i $1 -j ppp-incoming
It's more than 5 lines now but it used to be just 5. Then he added LOGDROP and the ident access which made it longer. But you could trim it down to five lines if you wanted.
The below was taken from this (http://www.netfilter.org/documentation/tutorials/lw-2000.tar.gz) tutorial.
3.1 A Simple Scenario
Single machine with no forwarding: PPP interface
Only ident requests to come in from outside
3.2 A Simple Solution
iptables -A INPUT -i lo -j ACCEPT
iptables -P INPUT DROP
iptables -N LOGDROP
iptables -A LOGDROP --m limit --limit 5/hour -j LOG
iptables -A LOGDROP -j DROP
iptables -N ppp-incoming
iptables -A ppp-incoming -p ! tcp -f -j LOGDROP
iptables -A ppp-incoming -p tcp --dport ident -j ACCEPT
iptables -A ppp-incoming -p tcp ! --syn -j ACCEPT
iptables -A ppp-incoming -p udp --dport 53 -j ACCEPT
iptables -A ppp-incoming -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A ppp-incoming -p icmp --icmp-type pong -j ACCEPT
iptables -A ppp-incoming -j LOGDROP
In ip-up script:
iptables -A INPUT -i $1 -j ppp-incoming
It's more than 5 lines now but it used to be just 5. Then he added LOGDROP and the ident access which made it longer. But you could trim it down to five lines if you wanted.
redhanded
10-19-2002, 11:21 AM
Thanks. I'll also take a look at the tutorial.
There is an amazing amount of material on the web regarding security and firewalls.
And an equal number of opinions. That's why I found this post interesting.
I suspect firewall rules are as unique as the individual that maintains the firewall, in that each system has it's own requirements. But we all need to start with a base set of rules and work from that point forward.
Thanks again.
There is an amazing amount of material on the web regarding security and firewalls.
And an equal number of opinions. That's why I found this post interesting.
I suspect firewall rules are as unique as the individual that maintains the firewall, in that each system has it's own requirements. But we all need to start with a base set of rules and work from that point forward.
Thanks again.
slapNUT
10-20-2002, 05:32 AM
You're welcome.
What Craig always said about firewalls was basically, you've got the kernel and you've got "userland" programs. If you can stop a packet with the kernel, then why let it through and rely on "userland" programs?
I agree. I use iptables as my firewall and a "log monitoring program" just to keep an eye on who's knocking on the door at 4:30AM. :D
:cool: iptables :cool:
What Craig always said about firewalls was basically, you've got the kernel and you've got "userland" programs. If you can stop a packet with the kernel, then why let it through and rely on "userland" programs?
I agree. I use iptables as my firewall and a "log monitoring program" just to keep an eye on who's knocking on the door at 4:30AM. :D
:cool: iptables :cool:
justlinux.com
Copyright Internet.com Inc. All Rights Reserved.
Copyright Internet.com Inc. All Rights Reserved.