Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I am wondering what the securtiy risks are to have open ports that do not connect to any meaningful application or protocol (like ftp, smb, etc.). It's like have a telephone where nobody ever answers.
There may be some issues with overflows and other programming bugs that could be used in tandem with an open port, but essentially what could be wrong?
An open port means that someone can try connecting to them. You probably have a service running that uses that port. If for example you have an ftp service running, but don't need it, you should disable the service.
well, if that's the case then: some of the risks are that your stealth is compromised (in cases where you actually don't need anything listening) and plus if you ever start any service aimed at the LAN but you accidentaly had it configured to listen on the WAN also then the entire WAN will have access... there's also the risk that non-root users could start their own daemons on your box (on non-root ports), etc... there's actually many reasons why you should filter all your ports even if you don't have anything listening at this current time...
Yes, by "open" I do mean "closed". If I'd only get my network jargon correct. So does that mean "open" is where a service is running, "closed" when it's available, but without a service, and finally "stealthed", when the firewall just doesn't respond to the request?
A specific example I have is for P2P clients. Clients use many ports (from port 6000 and on), and if I'd like to have all of those ports open. So the only service actually listening on those ports is the P2P client application.
I am behind a NAT, so the computer is stealthed. However, the P2P client (not the router) still routes requests from those ports to my P2P system. I still don't understand how that works exactly if NAT totally hides my computer, but somehow the translation works.
Thanks,
Murdock
Last edited by Murdock1979; 03-27-2006 at 02:04 PM.
I am behind a NAT, so the computer is stealthed. However, the P2P client (not the router) still routes requests from those ports to my P2P system.
Something is not as good as it could be there. Some p2p clients use Port 0 and get thru firewalls. That is not a good thing. Your NAT firewall should be stopping those requests unless you have purposely opened those ports.
I have opened ports 6696-6699 on my NAT firewall, but I also have Firestarter installed on my PC, and I only open those ports in Firestarter when I'm using the p2p program.
"open" - There is a service running on a port and people can connect to the port.
"closed" - Someone tries to connect to a port and is actively denied. This means a packet is sent back from your computer, firewall, or router telling them "No way Buddy, you're not connecting". There may or may not be a service actually running on the port. Your firewall or router may REJECT the incoming connection request before it even gets to the point of trying to invoke a service. If the connection request gets through your router and firewall, it will also be REJECTED if there is no service actually running on the port. Or a service COULD be running, and some configuration is telling it to REJECT the connection request.
"stealthed" - Someone tries to connect to a port and they just never hear back from your computer, firewall, or router. The connection request is said to be DROPPED (as opposed to REJECTED as described above). You could very well have a service running on the port in question, but you have things configured (firewall, router, etc.) to not let outsiders know that fact. You are trying to completely hide your existance. DROP hides, REJECT shows your existance but doesn't allow connections.
P2P apps create an outgoing port for connectivity so you dont need to open any ports.
If your NAT router has UPnP turned on, TURN IT OFF. This will allow apps to automatically open and close ports. Bad Idea.
Unless you are running a service/server that you want accessed from the internet(or a speedier bittorrent), there is no reason to have any ports open on a home router. Close them all, all will be stealthed.
Unless you are running a service/server that you want accessed from the internet(or a speedier bittorrent), there is no reason to have any ports open on a home router. Close them all, all will be stealthed.
That assumes you just want to get stuff, and not allow anyone else out there to get yours. If you want other p2p users to be able to get your files, you need to open some NAT ports.
That assumes you just want to get stuff, and not allow anyone else out there to get yours. If you want other p2p users to be able to get your files, you need to open some NAT ports.
i think what he was saying was that it isn't *necessary* anymore to do that in order to share files with most P2Ps... AFAIK, P2P software nowadays will share your files even if you don't have any open incoming ports open (granted not as optimally as they would if they did have open ports, but still)...
AFAIK, P2P software nowadays will share your files even if you don't have any open incoming ports
Maybe some will. I only use opennap & DC++, and if I don't open ports, nobody gets anything ... I can, of course get other people's files fine, since I am establishing the connection.
Maybe some will. I only use opennap & DC++, and if I don't open ports, nobody gets anything ...
no maybes here... i can confirm that DEFINITELY bittorrent and a couple gnutella clients will share (albeit non-optimally) even if you're completely firewalled... of course not all P2Ps will employ these kinda techniques obviously...
Quote:
I can, of course get other people's files fine, since I am establishing the connection.
yeah, i believe that the outgoing connections one establishes are precisely the ones that are used to send stuff outward in cases where there is stealth firewall compatibility... but well, i'm not really familiar with how the technique works so i won't try to pretend like i am... perhaps someobody else could give us an overview...
I heard they manage to use port 81 that's already opened for HTTP.
you mean port 80, right?? yeah, since you need to pretty much always allow access outward to port 80, 443, etc. there's always gonna be P2P apps that squeeze through there in order to connect... this forces admins to use methods to detect wether, for example, packets going out through TCP port 80 are indeed HTTP packets and not P2P packets... the p2pwall project above helps with that, and application layer proxies are the optimal solution for this AFAIK... but then of course there's encryption and stuff which would throw a whole new monkey wrench into the admin's filtering scheme... LOL...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.