Please submit the original article. Spamblog submissions are subject to removal and readers are encouraged to report them.

GNU/Linux is a free and open source software operating system for computers. The operating system is a collection of the basic instructions that tell the electronic parts of the computer what to do and how to work. Free, Libre and open source software (FLOSS) means that everyone has the freedom to use it, see how it works, and change it.

GNU/Linux is a collaborative effort between the GNU project, formed in 1983 to develop the GNU operating system and the development team of Linux, a kernel. Initially Linux was intended to develop into an operating system of its own, but these plans were shelved somewhere along the way.

Linux is also used without GNU in embedded systems, mobile phones and appliances, often with BusyBox or other such embedded tools.

A coworker and I are deploying a web services frame work to the public within the next 8-12 weeks after a long period of internal development. One of the suggested best practices was to move the port on which the web server and database connect. I bluntly stated with the sophistication of port scanners (being able to scan and fingerprint services from a perl script, for example), if a public facing system is compromised (which the external database is not public facing in the strictest sense, it is in the DMZ but is configured to respond to an internal subset of IP addresses) moving the port a service resides on is going to do absolutely nothing as far as reducing the attack surface.

I've done the same at my work, and had pretty much the same results, though its just a public key ssh login only, so its relatively secure.

I don't think we've had any attempts - I do a daily grep for the process in the auth logs, and email them to the team, just to see what the noise is on it.

That said, we also run chrooted ssh on 22 on the same machine for clients to send us files, and it might act as a honey pot for attackers.

Edit: *secure isn't probably the best word there. Moving the port just adds a few more bits of information required for someone to know before making a connection. It seems to be a hurdle most don't get over. The external security scans that we get done generally do find the alternative port though.

I was under the impression that every script kiddie had access to a script-able port scanner as I can find them in most of the app stores (and I am not trying that hard) plus wireshark, airsnort or tcpdump is not that hard to use. It looks like I am assuming capabilities where they do not exist and not modeling the threat realistically enough.

I've done the same on an ip outside of my public block without any dns pointing to it for services with setuid. Costs ~$2/month and I haven't seen a malicious login attempt since ~2008. I'm probably not any more secure from a determined attacker. However, I'm less worried about zero days because I don't think I'm in (m)any databases of potential targets with a specific version.

Botnets etc looking for SSH to try and bruteforce tend to just do a broad scan of IP ranges for open port 22. If you change SSH to port 2222 then these scans won't find you and you'll avoid all the dumb bruteforcing in your logs.

Of course, this only works until the botnets start scanning port 22 and 2222, in which case you need to go to a "random" port like 14529.

None of this will stop someone saying "/u/zgggg has pissed me off and I want to own his/her box" and then doing a comprehensive scan of your one host on all ports, fingerprinting them and seeing "hey, port 14529 responds with SSH".

Think of a botnet scan as a "horizontal" scan across a broad range of hosts for a specific port, while a targeted attack as a "vertical" scan from "top to bottom" of your specific host.

But again, you have to get over the firewall. I get what you are saying, but once you are in a position to scan this db server, our firewall and DMZ is compromised anyways. (you are in , have control of a system or three, and I did something stupid.).

There's no security improvement. Listen() on socket bound to port <1024 just requires root or CAP_NET_BIND_SERVICE.

The only benefit is that an attacker who can already launch processes on your system could start a malicious service on this high numbered port. The problem is that the attacker has to be able to kill the process currently bound to that port, which basically requires root privileges. If the attacker already has sufficient privileges to kill your services, he owns the entire system.

Security by Obscurity was taped above my desk so that I would question. I have since moved onto more of analyst style work than implementation for the past 10 years. Even though I have kept up with most of what was going on, I wanted to make sure I was not missing something foolish.

Since Linux forms are less polite about being stupid, it is the best place to ask.

Ports < 1024 are not treated in a more secure fashion. The difference in UNIXland is that the process needs to be running as root to bind to a socket with a port number < 1024. If anything, an improperly coded application that does not drop root privileges after binding to the port is actually likely to be much less secure.

port scanners scan only a fraction of ports. only the ones that have known services on it. normaly for a quick recon a portscanner scans those ports unless the attacker defines the portrange wich they almost never do.

My thought was that this system was not going to be public facing anyways, so that the initial scan would be to fingerprint the firewall and come through that into the web/email/whatever is public facing. Granted, coming through the webserver is still a valid route, but that is now more guarded against. (db accounts are not running as sa, least privileges are granted to service accounts in the db, etc) . I am making the educated assumption that the database server will not be in the first wave of compromises. Second or third, yes. But not the initial compromise.

What I am curious about is do you have any statistical information to back up the assertion that only the well defined or privileged ports are the ones that are tested ? Granted it makes sense, I would poke at DNS, SMTP, Web, FTP, and a few others, maybe. Then if I did not find anything interesting, move on.