24

A few days ago I started to care a lot about my data security, I end up nmaping myself with: nmap 127.0.0.1

Surprise, surprise, I have lots of active services listen to localhost:

$ nmap 127.0.0.1 Starting Nmap 5.21 ( http://nmap.org ) at 2013-05-05 00:19 WEST Nmap scan report for localhost (127.0.0.1) Host is up (0.00025s latency). Not shown: 993 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 53/tcp open domain 111/tcp open rpcbind 139/tcp open netbios-ssn 445/tcp open microsoft-ds 631/tcp open ipp Nmap done: 1 IP address (1 host up) scanned in 0.05 seconds

The only one that I might use is ssh (although it is probably not well configured, I will keep this matter to another question).

As far as I know ipp protocol is used by CUPS to share my printers, I don't need to share them, just access printers from a server.

This is the output of netstat -lntup by the root user, removing the localhost addresses:

Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 497/sshd tcp 0 0 0.0.0.0:17500 0.0.0.0:* LISTEN 2217/dropbox tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 892/smbd tcp 0 0 0.0.0.0:50022 0.0.0.0:* LISTEN 1021/rpc.statd tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 892/smbd tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 906/rpcbind tcp6 0 0 :::22 :::* LISTEN 497/sshd tcp6 0 0 :::42712 :::* LISTEN 1021/rpc.statd tcp6 0 0 :::445 :::* LISTEN 892/smbd tcp6 0 0 :::139 :::* LISTEN 892/smbd tcp6 0 0 :::111 :::* LISTEN 906/rpcbind udp 0 0 0.0.0.0:51566 0.0.0.0:* 615/avahi-daemon: r udp 0 0 0.0.0.0:68 0.0.0.0:* 7362/dhclient udp 0 0 0.0.0.0:111 0.0.0.0:* 906/rpcbind udp 0 0 192.168.1.255:137 0.0.0.0:* 1782/nmbd udp 0 0 192.168.1.67:137 0.0.0.0:* 1782/nmbd udp 0 0 0.0.0.0:137 0.0.0.0:* 1782/nmbd udp 0 0 192.168.1.255:138 0.0.0.0:* 1782/nmbd udp 0 0 192.168.1.67:138 0.0.0.0:* 1782/nmbd udp 0 0 0.0.0.0:138 0.0.0.0:* 1782/nmbd udp 0 0 0.0.0.0:655 0.0.0.0:* 906/rpcbind udp 0 0 0.0.0.0:17500 0.0.0.0:* 2217/dropbox udp 0 0 0.0.0.0:5353 0.0.0.0:* 615/avahi-daemon: r udp 0 0 0.0.0.0:34805 0.0.0.0:* 1021/rpc.statd udp6 0 0 :::40192 :::* 1021/rpc.statd udp6 0 0 :::111 :::* 906/rpcbind udp6 0 0 :::655 :::* 906/rpcbind udp6 0 0 :::5353 :::* 615/avahi-daemon: r udp6 0 0 :::42629 :::* 615/avahi-daemon: r

How do I configure those services so they only listen to the outside world when I'm actually using them?

Improve this question
13
  • How do you want to tell it you're using them? Commented May 4, 2013 at 23:39
  • starting the services myself (with user privileges and a parent shell) Commented May 4, 2013 at 23:41
  • 2
    Correct, also if you're using CUPS just from the local system you can have it listen only to port 631 on the localhost (127.0.0.1). I'd re-run the nmap using the actual IP the machine has and not just 127.0.0.1. Commented May 5, 2013 at 0:00
  • 1
    a better command to run would be netstat -lntup -l=listen -n=number -t=tcp -u=udp -p=pid. Shows what processes you have running and what ports they're exposing. Anything open to 127.0.0.1 is inaccessible to the internet. Commented May 5, 2013 at 1:19
  • 1
    If you do not need Samba, simply uninstall it. If you do need it, you can restrict it to the local interface (e.g. eth0?) by adding in smb.conf the two directives bind interfaces only = yes and interfaces = eth0. Commented Jun 23, 2013 at 20:57

3 Answers 3

Reset to default
27
+50

Determine your exposure

Taking your output from the netstat command, what looks like a lot of services is actually a very short list:

$ netstat -lntup | awk '{print $6 $7}'|sed 's/LISTEN//'| cut -d"/" -f2|sort|uniq|grep -v Foreign avahi-daemon:r dhclient dropbox nmbd rpcbind rpc.statd smbd sshd

Getting a lay of the land

Looking at this list there are several services which I'd leave alone.

  • dhclient
    • DHCP server daemon responsible for getting your IP address, have to have this one.
  • dropbox
    • obviously Dropbox, have to have

Start reducing it - disable Samba

You can probably right off the bat disable Samba, it accounts for 2 of the above services, nmbd and smbd. It's questionable that you'd really need that running on a laptop whether on localhost or your IP facing your network.

To check that they're running you can use the following command, status:

$ status nmbd nmbd start/running, process 19457 $ status smbd smbd start/running, process 19423

Turning services off can be confusing with all the flux that's been going on with upstart, /etc/rc.d, business so it might be difficult to figure out which service is under which technology. For Samba you can use the service command:

$ sudo service nmbd stop nmbd stop/waiting $ sudo service smbd stop smbd stop/waiting

Now they're off:

$ status nmbd nmbd stop/waiting $ status smbd smbd stop/waiting

Keeping them off ... permanently

To make them stay off I've been using this tool, sysv-rc-conf, to manage services from a console, it works better than most. It allows you to check which services you want to run and in which runlevel they should be started/stopped:

$ sudo apt-get install sysv-rc-conf

   ss of sysv-rc-conf

Disabling the rest of what's NOT needed

So now Samba's off we're left with the following:

  • avahi-daemon
    • part of zeroconf (plug-n-play), turn it off
  • rpcbind
    • needed for NFS - turn it off
  • rpc.statd
    • needed for NFS - turn it off

For the remaining 3 you can do the same things we did for Samba to turn them off as well.

CUPS?

To turn CUPS off, which you don't really need by the way, you can follow the same dance of turning the service off and then disabling it from starting up. To be able to print you'll need to setup each printer individually on your system. You can do so through the system-config-printer GUI.

Making these services on demand?

This is really the heart of your question but there isn't really a silver bullet solution to making these services "smart" so that they run when they're being used, rather than all the time.

#1 - systemd vs. upstart

Part of it is the current split between systemd and upstart. There's a good overview of the 2 competing technologies here.

Both technologies are trying to do slightly different things, IMO, given their feature sets, systemd seems geared more towards servers whereas upstart seems geared more towards the desktop roll. Over time this will work itself out, IMO, and both services will be stable and feature rich.

Eventually both services will offer on demand starting & stopping across the board for all the services they manage. Features such as StopWhenUnneeded=yes already exist in systemd for example, so it's only a matter of time until these capabilities get fleshed out.

#2 - service support

Some services don't support being stopped/started very well if at all. Services such as sshd seem to make little sense to run as on-demand, especially if they're used heavily. Also some services such as Apache provide mechanisms within themselves to spin up more or less of their own listeners managing themselves. So it's unclear how on-demand provided by systemd or upstart are going to integrate with these types of services.

Is this really necessary?

You'll hear from both sides that this is overkill or that you should take a minimalist's approach only installing what you absolutely need, but it's really a personal choice. Understanding that these services are there and what they do is really what's important. At the end of the day a computer is a tool, and by using a Unix system you're already saying that you're willing to peek behind the curtain and understand what makes your computer tick.

I'd say that this type of questioning is exactly the frame of mind one should strive for when dealing with computers and Unix in general.

References

Improve this answer
2
  • 2
    @RSFalcon7 - you're welcome! Thanks for the question! Commented Jun 27, 2013 at 13:52
  • dropbox is not a secure service - so not a "must have" Commented Oct 12, 2024 at 19:17
12

127.0.0.1 is not the "outside world", it is looking around inside the house.

Check your firewall configuration (iptables in Linux today), most of them shouldn't be accessible from the ouside.

Don't run services you don't need. Uninstall all not required software.

Change passwords to be stronger. Check your usage of the system, don't go chasing any interesting website at random. Check the browser's anti-phising, anti-scripts, etc. configuration. Revise you usage of SSH and su/sudo.

But most of all, excessive paranoia is counterproductive. Don't get trapped by the glitter of technology.

Improve this answer
4
  • 3
    I agree with "Don't run services you don't need". But "Uninstall all not required software.", seriously? What shall that help against? Commented May 5, 2013 at 0:49
  • 6
    @HaukeLaging, as the saying goes, "mice nest in heaps of unused clothes". Any piece of software can have a vulnerability that might be exploited. If the program isn't there, that risk doesn't exist. If it isn't used, the cost is negligible. Besides, a simpler system is easier to oversee and keep tidy. Commented May 5, 2013 at 1:39
  • Thanks to remind that 127.0.0.1 is not the outside woruld. I totally subscribe to don't run services that I don't need, but uninstall is a bit of a overkill, if they are here they were useful in sometime Commented May 5, 2013 at 22:12
  • 2
    @RSFalcon7, if they were useful (or are useful for somebody else, they are in the distribution after all) is of no consecuence. If you don't use it, chuck it. Less disk use, less updating, less risk overall. If you need it later, reinstall. Commented May 6, 2013 at 0:33
3

While you can 'shut' individual services - perhaps it may just be easier to setup a firewall. Nearly all common distro's (Ubuntu, Debian, Centos, etc) have support for iptables built-in.

A simple rule-set to get started: (you can just type these in at a command-prompt; to make them permanent add them to your startup scripts or tell us what distro you're using. On Centos for example: system-config-firewall is a good UI for configuring iptables rules)

iptables -A INPUT -p tcp --dport ssh -j ACCEPT iptables -A INPUT -j DROP

Basically - allow ssh inbound; drop everything else.

Your INPUT chain now looks like this:

  • If a packet is coming into my computer for 'ssh' - allow it
  • If a packet has not matched any of the previous rules - just throw it away.

Then at a later date, say you want to allow 'samba' (windows file sharing): you could run

iptables -I INPUT-p tcp --dport 465 -j ACCEPT

The -I prepends and rule to the list; -A appends a rule. So your chain now looks like this:

  • If a packet is coming into my computer for 'samba' - allow it
  • If a packet is coming into my computer for 'ssh' - allow it
  • If a packet has not matched any of the previous rules - just throw it away.

The INPUT chain refers to packets destined for your system. Other chains are OUTPUT for packets from your computer, going to the internet and FORWARD for packets that are routed through your computer (that is packets that 'transit' your computer, like an airport's transit area - stuff that is not INPUT because it is not entering your computer).

As a parting note: nmap'ing 127.0.0.1 is not very useful; a lot of services are accessible only from 127.0.0.1 and no other address. If you don't have another machine you can run nmap from - try using Gibson Research' Shields UP! (https://www.grc.com/shieldsup) - which is a free, online nmap-lite. Or add a comment with your IP/email and I'll nmap you :)

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.