Yes, I do use root. Isn't it unlikely a hacker could get past a strong password with only 2 attempts per minutes as according to my firewall?
I will put in pubkey auth when I get round to it bt need to setup some other stuff on the server in the meantime.
Just remembered, there must be other users on my server set up by the hosting company and then of course there are apache, squid user logins. I tried AllowUsers root, dummyname in the sshd config but it locked me out completely even from using root.
I couldn't fin it in the httpd.conf. However, when I tried installing the module and changing the conf, I got:
Starting httpd: [Wed Aug 12 10:12:38 2009] [warn] module security2_module is already loaded, skipping


merely as a web proxy on port 8080 or 3128
It has acls loaded for ncsa_auth and other standard installtion.
I only have rate limiting on my ssh port.
Does it make sense to rate limit http and proxy ports? These can get a lot of multiple hits just from loading standard webpages?
I suppose I could rate limit the icmp ports - I only have allowed 8 incoming and 0 outgoing at present.
Is this all I need:
iptables -A INPUT -p icmp -m limit --limit 1/s --limit-burst 1 -j ACCEPT

Is syn needed anymore? iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j RETURN

I believe "hacking in through a port" is what happens in Britain when you're sick and instead of taking medicine you drink wine until you fall asleep.
Or what insomniacs in the Matrix do.

From your other discussions I think that when you say you log in as root you have to distinguish if this goes for all interfaces or only for the interface that already has an iptables filter set for your management IP or range (and if you actually did set the restriction). The point is that, as opposed to pubkey auth, passwords can be cracked, that exposing the root account to the 'net increases the risk unnecessarily so and that it is not a best practice. Saying "when I get around to it" shows you have a different way of prioritizing things. However some risks are in more need to be taken care of right now.

Most of the topics below are dealt with in your other threads. It would be good if you link to it. That way discussions don't wander between threads as they will do now.


"Other users" as in human users (UID >= 500 or 1000) or system users?


From one of your other discussions I got you are not using a "default" Apache but some package that includes Apache among other things. Is that right? What is the package called? Was it "webkit" or something?



So it is loaded. Have you reviewed what rules it uses?


Iptables-based rate limiting depends on what you're actually serving, how you prioritise services and resources and if those services include their own mechanisms for dealing with request floods. For instance would it be OK for the machine to be swamped in proxy requests if the main purpose of the machine is to serve web pages? (source net ACL, maxconn)


// ICMP is dealt with in another thread so please link to it from here. That way discussions don't wander between threads.



I may have said it before in one of your other discussions but I don't get the idea you confidently admin your machine. Again I strongly suggest you pace things better and please read Rute, the admin docs that come with your distro and the docs for each service you're dealing with. You should know basic (admin) tasks before you manage the machine. Using a web-based panel is no substitute for required knowledge.


In my opinion proper server management should start before the installation by knowing the machines purpose, how it should interact with others and where it fits in the network. Offering the information makes things more efficient for all of us. Configuring a new server should start by shielding it from network access while performing your postinstall assessment of the machine, removing, installing and configuring the OS before adding and hardening publicly accessable networked services and before exposing it to the 'net. Doing things the other way around by offering you "just" run Apache, OpenSSH and Squid will get you there in the end but it will take way more effort to properly harden the machine and without checklist the chance you do not address everything you should is rather large. You are free to proceed and do as you like but I would suggest you take a step back and check if what you have accomplished right now is what you should aim to.

I've only the machine a few days so I'm essentially hardening it at the moment - I take all your points but it's somewhat of a learning curve for me as well. I took the option that before learning about ssh keys I would do as much as I could to immediately lock down 99% of ssh and I took that to be rate limiting connections to 2 per minute and having a very strong password. I do intend on making it stronger but the rest has turned to my server installations at present.
I intend this to be primarily a squid server so I could further rate limit http requests.
I have rate limited ICMP requests as follows (but I'll put in the other thread)
As for users, I can see this:

Yes, I do realize that.


The division between system users (daemons) and unprivileged users (daemons and human users) is at . Usually it'll be 500 or 1000, so to list system users you could and just unprivileged users with . * There's two tools you will want to run in terms of initial assessment: Tiger and LSAT.

system users
other users
Can any of these get in through ssh?

Ok, so with tiger, I am getting a lot of
The ./scripts/check_passwd script will not be run since it is owned by a user (1000) different than the one running Tiger (0)
Do I need to chmod the folder to root?

Though the UID doesn't need to be less than $GID_MIN, system users have will usually be locked out using an inert shell like 'nologin' or 'false'. The "admin" account I don't know but the name is such that you definately want to know what it can do.


Wether you build RPM's or untar a tarball it's always good to do it as unprivileged user as it will help keep you from harm, inspect contents, chown if necessary, then let root move or use it.

So, login as a different user and the you change to root and chown the entire folder? The problem is that most packages install themselves all over the place don't they?

No, what I mean is that untarring as unprivileged user (since you log in as unprivileged user anyway, right?) will make all tarball contents be owned by the current user. After that you let root do its thing.


Installing is something completely different because this will almost always involve writing to locations only root can write to. However it's good to note that because you value your systems integrity and run a matured package management system it is preferable to install OS+release-specific packages over just about any tarball you can lay your hands on.

Not yet I don't because I tried adding AllowUsers and my logon to SSH and it locked that user and also root.
Is it because you might have something dodgy in the tar that you wouldn't want root permissions?

Please post the URI of your SSH thread and maybe we can speed this up.


Think of it as a precaution, a safeguard. Sure you expect (application source) tarballs to include a leading directory named like the tarball and sure you could remember to first move to a safe directory and remember to explicitly "-C " things but making assumptions and having to remember too much makes for nice pitfalls. Add lack of concentration, deadlines, stress and sleep deprevation for a better recipe for disaster. Unlike not logging in as root some best practices can't be prevented (easily), like building packages as unprivileged user this is one of those discipline things.