LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   is it bad to have open ports? (https://www.linuxquestions.org/questions/linux-security-4/is-it-bad-to-have-open-ports-428882/)

Murdock1979 03-27-2006 02:30 AM

is it bad to have open ports?
 
Hello!

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?

thanks,
Murdock

jschiwal 03-27-2006 03:35 AM

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.

win32sux 03-27-2006 05:46 AM

i think by "open" he means "closed"... :)

like, unfiltered, yet unused ports... it's a question i've heard before...

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

just my :twocents:...

Murdock1979 03-27-2006 01:54 PM

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

rickh 03-27-2006 02:41 PM

Quote:

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.

haertig 03-27-2006 03:12 PM

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

soulestream 03-30-2006 04:28 PM

Ill go ahead and say this first

P2P APPS DO NOT NEED OPEN INCOMING PORTS.

Bittorrent works better, but not needed.

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.


Soule

rickh 03-30-2006 04:42 PM

Quote:

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.

win32sux 03-30-2006 04:55 PM

Quote:

Originally Posted by rickh
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)...

rickh 03-30-2006 06:11 PM

Quote:

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.

win32sux 03-30-2006 06:20 PM

Quote:

Originally Posted by rickh
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...

rickh 03-30-2006 07:20 PM

Quote:

i can confirm that DEFINITELY bittorrent and a couple gnutella clients will share (albeit non-optimally) even if you're completely firewalled...
I'll bet that's got a few SysAdmins really torqued off.

Murdock1979 03-30-2006 07:28 PM

I heard they manage to use port 81 that's already opened for HTTP.

win32sux 03-30-2006 07:34 PM

Quote:

Originally Posted by rickh
I'll bet that's got a few SysAdmins really torqued off.

most definitely... :)

but they could always turn to application-layer proxies (Zorp, for example) to do the filtering i guess...

there's also some iptables methods for dealing with this kinda stuff, like:

http://www.lowth.com/p2pwall/

Quote:

Originally Posted by Murdock1979
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...


All times are GMT -5. The time now is 11:49 AM.