You are not logged in.
Is there anyway to close/stealth port 111? I've been trying to find a way to make port 111 invisible to the net while keeping it open so that my local services (FAM, portmap, etc.) can use it.
Currently I've set iptables to refused connecting to port 111 from my Ethernet device (eth0). Is this solution good enough?
Offline
That's probably the best way.
Offline
to make that port invisible to the net you need to tell iptables to DROP requests coming into to it -not DENY. Most firewall generators can do this for you.
Offline
When the Port is visible from outside, that means that some service is listening on it. Find out which one it is and bind it to lo or 127.0.0.1 instead.
Note: a portscan running over localhost will therefore always find the ports on which a service is listening. Try to portscan the machine in question from a different machine and look what it reports.
Last edited by mucknert (2007-07-26 04:43:17)
Todays mistakes are tomorrows catastrophes.
Offline
The best solution is stopping the service that use the port 111. With
netstats -anp | grep LISTEN
you'll be able to read what services are you running, and related ports.
Offline
The best solution is stopping the service that use the port 111. With
netstats -anp | grep LISTEN
you'll be able to read what services are you running, and related ports.
netstat -l works too
Offline
Port 111 is used by portmap (as it appears the OP already knew). It's not a very smart or configurable app, so that's why I agreed with the idea to use iptables to guard it. portmap also supports TCP wrappers, so the other way to block it is to use hosts.allow and hosts.deny. It's nice to know iptables, though, since some apps don't even give you as much flexibility here as portmap does.
Offline
Mmmh, a little of topic perhaps, but please bear with me.
I found this really good page on how IPtables works. Here's the link
http://iptables-tutorial.frozentux.net/ … orial.html
Last edited by madeye (2007-07-27 06:43:13)
MadEye | Registered Linux user #167944 since 2000-02-28 | Homepage
Offline
I found this really good page on how IPtables works. Here's the link
http://iptables-tutorial.frozentux.net/ … orial.html
Ah yes, I also read that one. Really, really good. Especially if you want a detail guide of how iptables work.
Oh! and thanks for all suggestions. I think blocking port 111 with iptables will do for now.
But want makes me wonder is how Ubuntu manages to close all ports by default (and without using iptables). I seem to remember that when I do a local port scan on Ubuntu there's no open port.
Last edited by zodmaner (2007-07-27 11:02:30)
Offline
But want makes me wonder is how Ubuntu manages to close all ports by default (and without using iptables). I seem to remember that when I do a local port scan on Ubuntu there's no open port.
Simply, Ubuntu doesn't have any service active. If you want stop portmap and closing 111 port without iptables, delete it from /etc/rc.conf .
Offline
But isn't FAM depends on portmap to work? (It did even start portmap on its own). How did Ubuntu makes FAM work then? I'm puzzled.
Last edited by zodmaner (2007-07-27 12:31:40)
Offline
I could be wrong, but I think Ubuntu uses Gamin instead of Fam. And yes, Fam needs portmap.
Offline
to make that port invisible to the net you need to tell iptables to DROP requests coming into to it -not DENY.
That is pure bullshit.
The normal behaviour for an operating system is to send a "tcp-reset" as an answer to any tcp SYN sent to a closed port.
If you drop packets, meaning you don't answer at all, that can only mean two things:
1) there is a stupid firewall somewhere on the way not behaving properly (like my D-Link router for example)
2) there is a stupid firewall on the machine itself and an admin who thinks he can "hide" services by not answering
The right way to make a service "invisible" to the outside is to mimic the default behaviour, meaning you send back a tcp-reset (-j REJECT --reject-with tcp-reset in iptables).
Offline
Unless, of course, you also drop packets for any unused ports, so that the important ones aren't obvious, and so that portscanning takes a lot longer than in the return-rst case.
Offline
Excuse me while I lol at all these old guru and go use firestarter ftw! Although thanks for the info about gamin and the iptables guide, hopefully I can optimize my firewalls speed a bit. Forgot to mention /etc/hosts.deny and /etc/hosts.allow which come in very handy as second precaution.
Last edited by h4mx0r (2008-04-22 01:56:07)
Offline
The typical solution is rejecting packets to port 111 with iptables (-j REJECT --reject-with tcp-reset as brain0 mentioned). This mimics default TCP behaviour for closed ports and doesn't cause network problems (connection, portscan delays).
@T-Dawg: Just dropping packets instead of sending RST means port is open but firewalled.
Offline
i was with these ports opened (and not filtered), i searched over wiki and found this awesome tutorial http://wiki.archlinux.org/index.php/Sim … wall_HOWTO
i have scanned my box with nmap, getting this as output
~$ nmap -p 1-65535 -T5 localhost
Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-14 22:54 GMT
Interesting ports on supernova.localdomain (127.0.0.1):
Not shown: 65529 closed ports
PORT STATE SERVICE
80/tcp open http
111/tcp open rpcbind
217/tcp open dbase
631/tcp open ipp
918/tcp open unknown
2277/tcp open unknownNmap done: 1 IP address (1 host up) scanned in 2.41 seconds
after, I 'actualizated' the iptables rules, by using that tutorial, so Im posting the /etc/iptables.rules
here
# Generated by iptables-save v1.4.2 on Wed Jan 14 23:04:09 2009
*raw
:PREROUTING ACCEPT [1343334:82895651]
:OUTPUT ACCEPT [1341363:63309483]
COMMIT
# Completed on Wed Jan 14 23:04:09 2009
# Generated by iptables-save v1.4.2 on Wed Jan 14 23:04:09 2009
*nat
:PREROUTING ACCEPT [4805:1515372]
:POSTROUTING ACCEPT [658946:34285236]
:OUTPUT ACCEPT [658263:34257916]
COMMIT
# Completed on Wed Jan 14 23:04:09 2009
# Generated by iptables-save v1.4.2 on Wed Jan 14 23:04:09 2009
*mangle
:PREROUTING ACCEPT [1343337:82896713]
:INPUT ACCEPT [1342989:82846411]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1341363:63309483]
:POSTROUTING ACCEPT [1341363:63309483]
COMMIT
# Completed on Wed Jan 14 23:04:09 2009
# Generated by iptables-save v1.4.2 on Wed Jan 14 23:04:09 2009
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [1695764:80833229]
:interfaces - [0:0]
:open - [0:0]
-A INPUT -p icmp -m icmp --icmp-type 18 -j DROP
-A INPUT -p icmp -m icmp --icmp-type 17 -j DROP
-A INPUT -p icmp -m icmp --icmp-type 10 -j DROP
-A INPUT -p icmp -m icmp --icmp-type 9 -j DROP
-A INPUT -p icmp -m icmp --icmp-type 5 -j DROP
-A INPUT -s 10.0.0.0/8 -i eth1 -j DROP
-A INPUT -s 172.16.0.0/12 -i eth1 -j DROP
-A INPUT -s 192.168.0.0/16 -i eth1 -j DROP
-A INPUT -s 127.0.0.0/8 -i eth1 -j DROP
-A INPUT -s 127.0.0.0/8 -i eth0 -j DROP
-A INPUT -s 192.168.0.0/16 -i eth0 -j DROP
-A INPUT -s 172.16.0.0/12 -i eth0 -j DROP
-A INPUT -s 10.0.0.0/8 -i eth0 -j DROP
-A INPUT -p icmp -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -j interfaces
-A INPUT -j open
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -f -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A INPUT -i eth0 -p icmp -m icmp --icmp-type 8 -j DROP
-A INPUT -i eth1 -p icmp -m icmp --icmp-type 8 -j DROP
-A INPUT -p tcp -m tcp --dport 111 -j REJECT --reject-with tcp-reset
-A INPUT -p tcp -m tcp --dport 631 -j REJECT --reject-with tcp-reset
-A INPUT -p tcp -m tcp --dport 937 -j REJECT --reject-with tcp-reset
-A INPUT -p tcp -m tcp --dport 890 -j REJECT --reject-with tcp-reset
-A interfaces -i lo -j ACCEPT
-A open -p tcp -m tcp --dport 2277 -j ACCEPT
-A open -p tcp -m tcp --dport 22 -j ACCEPT
-A open -i eth1 -p tcp -m tcp --dport 80 -j ACCEPT
-A open -p tcp -m tcp --dport 217 -j ACCEPT
COMMIT
# Completed on Wed Jan 14 23:04:09 2009
after that, scanned from other machine:
~$ nmap -p 1-65535 -T5 -A -vv <my_ip>
Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2009-01-14 22:55 WET
Machine <my_ip> MIGHT actually be listening on probe port 80
DNS resolution of 1 IPs took 0.00s.
Initiating Connect() Scan against <my_hostname> (<my_ip>) [65535 ports] at 22:55
Discovered open port 80/tcp on <my_ip>
Connect() Scan Timing: About 12.39% done; ETC: 22:59 (0:03:32 remaining)
Connect() Scan Timing: About 83.00% done; ETC: 23:00 (0:00:50 remaining)
The Connect() Scan took 301.88s to scan 65535 total ports.
Initiating service scan against 1 service on <my_hostname> (<my_ip>) at 23:00
The service scan took 6.04s to scan 1 service on 1 host.
Host <my_hostname> (<my_ip>) appears to be up ... good.
Interesting ports on <my_hostname> (<my_ip>):
Not shown: 65440 filtered ports, 94 closed ports
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.2.11 ((Unix) mod_ssl/2.2.11 OpenSSL/0.9.8j DAV/2)Nmap finished: 1 IP address (1 host up) scanned in 308.226 seconds
Last edited by quarkup (2009-01-14 23:12:34)
If people do not believe that mathematics is simple, it is only because they do not realize how complicated life is.
Simplicity is the ultimate sophistication.
Offline
T-Dawg wrote:to make that port invisible to the net you need to tell iptables to DROP requests coming into to it -not DENY.
The right way to make a service "invisible" to the outside is to mimic the default behaviour, meaning you send back a tcp-reset (-j REJECT --reject-with tcp-reset in iptables).
So brain0 that would generate the same behaviour as -j DROP ie telling the sender there is nothing at the other end of the line?
Just getting things straight here, I know a bit about networking but protocols aren't my cup of tea . I know dropping incoming traffic is not the 'nice' way to go but a lot of sources 'recommend' it if you want to stealth your box.
@T-Dawg: Just dropping packets instead of sending RST means port is open but firewalled.
Ok so sending the reset means no delays, and the sender will still think the box on the other end of the line is down?
Excuse me while I lol at all these old guru and go use firestarter ftw!
Arch is about learning... I can get a typical Ubuntu user (nofi!) wants to have his box running, as do Arch users, but an Arch user will want to know how it runs and why it does this and that .
Firestarter is nice, but as with any frontend, you learn the frontend, not the real deal. A bit of understanding of how things works under the hood never hurt anyone.
Got Leenucks? :: Arch: Power in simplicity :: Get Counted! Registered Linux User #392717 :: Blog thingy
Offline
DROP will make it appear that there's no box at the IP address. The packet will disappear in to /dev/null (not literally, but for explainations sake ) and the other end will never get a reply. Eventually it will timeout -- but not before attempting to resend a couple of times usually.
REJECT will actively tell the other end that it can not connect. The other end will not be able to tell the difference between a machine that's actively blocking the port versus a machine that just doesn't have a program/service on that port.
Last edited by fukawi2 (2009-01-15 10:00:14)
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
hosts.deny defaults to ALL: ALL: DENY, so I guess there is no reason to panic. i have deactivated fam because it kept freezing on me and i hardly ever use GUI file browsers and such. any reason to keep portmap running? i don't use nfs either.
Offline