LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   Configuring and Hardening a New Server to Replace Compromised Machine (https://www.linuxquestions.org/questions/linux-security-4/configuring-and-hardening-a-new-server-to-replace-compromised-machine-891764/)

sneakyimp 07-22-2011 03:55 PM

I created an Amazon Machine Image from my server as a backup and was able to instantiate an entirely new compute instance from it and all of the security hardening so far performed was preserved. I'm proceeding with the iptable rules now knowing that if I lock myself out here that I can just terminate my compute instance and create another.

As a protection against locking myself out on the basis of IP address (e.g., if Time Warner Cable suddenly moves me to an entirely different subnet), I am adding two additional IPs to my ssh ACCEPT rules:
* The static IP address of one my brother's servers.
* A different Elastic IP address I have acquired through Amazon AWS. I can always create some arbitrary compute instance at Amazon and connect this IP address to it and login to the box from there. I have tested this and it appears to work. I'm checking the AWS forums for confirmation that this is a reliable technique.

I have run these commands on my server
Code:

sudo iptables -A INPUT -i lo -j ACCEPT
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -s 76.173.0.0/16 -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -s aaa.bbb.ccc.ddd -p tcp --dport 22 -j ACCEPT
sudo iptables -I INPUT 3 -s www.xxx.yyy.zzz -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -j DROP
sudo iptables-save > ./ip_tables_save.txt
sudo reboot


Here is my ip_tables_save.txt document:
Code:

user@host:~$ cat ip_tables_save.txt
# Generated by iptables-save v1.4.4 on Fri Jul 22 20:41:34 2011
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s www.xxx.yyy.zzz/32 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -s 76.173.0.0/16 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -s aaa.bbb.ccc.ddd/32 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -j DROP
COMMIT
# Completed on Fri Jul 22 20:41:34 2011

EDIT: I re-read the ip table how-to and realized that I had to save the rules to a file and configure my server to load them on startup. I configured my server to load them by creating a script thusly:
Code:

sudo nano /etc/network/if-pre-up.d/iptablesload
enter this script:
Code:

#!/bin/sh
iptables-restore < /etc/iptables.rules
exit 0

and then set perms on that file:
Code:

sudo chmod +x /etc/network/if-pre-up.d/iptablesload
then reboot.

sneakyimp 07-22-2011 07:31 PM

Okey Doke I think these iptables are as locked down as they need to be for now. I've tried some testing and between pubkey login, iptables and the Amazon Security Zones, I think it's going to be quite difficult for anyone to get in via SSH.

I'm now looking at the AIDE/Samhain, Tiger, fail2ban installations and wondering which to install first. Does sequence matter?

As for AIDE vs. Samhain, I'm liking samhain and the idea that we could have a separate machine as some kind of security audit hub to which other machines report. This would require an additional machine, but I imagine I could use a micro instance and get away with it. I'm still wondering exactly what samhain does: "file integrity checker" and "log file analysis" are what the website says. The instructions on the samhain site describe manual download/compile/install/configure but I'm guessing it would probably be better in the long run to use the ubuntu/debian package. Unfortunately, there is no "yule" package for server and "samhain" package for client. I've read a bit of the samhain documentation and it would appear that a client/server configuration would require some manual setup. Should I compile this manually or rely on a package install? I'm a bit concerned about doing anything manually lest I fail to update software regularly and introduce insecurities.

unSpawn 07-22-2011 09:56 PM

Quote:

Originally Posted by sneakyimp (Post 4422808)
I think it's going to be quite difficult for anyone to get in via SSH.

Cool. Just like you need it.


Quote:

Originally Posted by sneakyimp (Post 4422808)
I'm now looking at the AIDE/Samhain, Tiger, fail2ban installations and wondering which to install first. Does sequence matter?

Yes. Consider OS installation as your "baseline", the installed data you trust. While GNU/Tiger can be installed any time I use it as both baseline and generic auditing tool notifying me of issues to address right after OS installation or after major (re-)configuration, update or SW installation changes. (For servers consider making it a habit to complement this by running remote tools like OpenVAS or Nessus etc, etc after changes.) Similarly Aide or Samhain provide integrity verification if installed right after OS installation. Snort + Guardian, Snort inline, fail2ban or equivalent provide service protection at the stage the machine is exposed to the 'net.


Quote:

Originally Posted by sneakyimp (Post 4422808)
I'm still wondering exactly what samhain does: "file integrity checker" and "log file analysis" are what the website says.

Look back at your past encounter. Ask yourself: what tools did you have at your disposal to verify OS integrity? When you decide to install Samhain ask yourself: how can you enhance it (Yule, Beltane)?


Quote:

Originally Posted by sneakyimp (Post 4422808)
The instructions on the samhain site describe manual download/compile/install/configure but I'm guessing it would probably be better in the long run to use the ubuntu/debian package. Unfortunately, there is no "yule" package for server and "samhain" package for client. I've read a bit of the samhain documentation and it would appear that a client/server configuration would require some manual setup. Should I compile this manually or rely on a package install? I'm a bit concerned about doing anything manually lest I fail to update software regularly and introduce insecurities.

Samhain (the client) is a locally running daemon. It does not interact with users. An unprivileged user must be able to exploit conditions to be able to manipulate Samhain. As you can see there's been only one in the last three years for Samhain (none for Yule and one for Beltane II) and this one only affected the Secure Remote Password aspect. Samhain is actively developed and supported and new versions are released once in a while. All in all a client installation of Samhain does not need much updates: if there are no security fixes in a newer version and no enhancements you need feel free to postpone until you need a new version. While this may not be any indication to you on Centos Samhain is one of the few packages I am willing to install manually.

sneakyimp 07-24-2011 06:45 PM

1 Attachment(s)
I installed samhain on my desktop PC and have been perusing the samhainrc file. I'm beginning to understand it.

Email is a problem here. Amazon puts each and every EC2 compute instance and elastic ip address on a policy block list -- you can't send email from these machines/IP blocks. The samhainrc allows one to specify a mail relay address but does not have a facility for specifying a username or password. I therefore need to set up some other machine -- NOT an EC2 instance -- as a mail relay which will relay mail for this EC2 machine without requiring login or password. I think this may be feasible using Amazon Simple Email Service which I was planning to set up later. I reckon the time has come to chat about mail considerations. Amazon offers instructions for setting up sendmail or postfix. Which should I choose?. I have a few considerations for mail:
* I need to send mail from PHP
* I'm concerned about the spam ratings of my outgoing mail so I want to be sure to avoid outgoing mail headers that are at odds with any return-to or from headers inserted by my MTA.
* I need samhain to be able to send mail and it's not really clear to me what mechanism samhain will use.

RE: samhain setup. Given that it's taking me forever to get this new server secured and on-line, I simply don't feel up to the whole renamed-binary-and-steganography approach. I am hoping (but not yet sure) that I will be able to specify a MySQL host/db/user/pass in samhainrc and this will allow an "append only" type situation for the machine. The samhain docs are not at all clear on what sort of permissions are required for MySQL, but this tutorial suggests that only SELECT and INSERT are required. Unless I'm mistaken, this would be slightly more secure that simply keeping the samhain database on localhost where it could also be compromised in the event of an exploit.

I've attached the default samhainrc file and hope I could get some feedback on the settings in it. I realize we are balancing security with performance in some cases. For example, It looks like a file integrity check happens every 2 hours by default. That could give a hacker as much as 2 hours to clean up after themselves.

sneakyimp 07-25-2011 01:21 AM

Another question: I'm not certain under which conditions samhain will attempt to notify me. Can someone recommend a test that will trigger an alert (meaning the highest level of critical notification) ??

sneakyimp 07-25-2011 02:08 AM

Seeing as how I need to sort out mail issues before I can properly set up samhain, I've turned my attention to Tiger. I'm a bit confused by your prior directions:
Quote:

Originally Posted by unSpawn
+ Configure tiggerrc and set Tiger_Check_SENDMAIL=N, Tiger_Check_ROOTKIT=N (run Chkrootkit separately), Tiger_Collect_CRACK=N, Tiger_SSH_Protocol='2' and populate (use something like 'sudo lsof -Pwln|awk '/REG.*bin {print $NF}|sort -u';' for that) Tiger_Running_Procs= with full path and not plain names. Run GNU/Tiger, eyeball report, address issues, rinse, repeat. Be sure to run it with "-e" or "-E" and read and research the explanations. (Posted before in this forum.)

I've edited tigerrc and set most of the options you specified, but don't understand the lsof command you've offered or the Tiger_Running_Procs setting. unSpawn, could you please clarify? I tried running the lsof | awk command but it returns an error:
Code:

user@host:~$ sudo lsof -Pwln|awk '/REG.*bin {print $NF}|sort -u'
awk: line 1: runaway regular expression /REG.*bin { ...

What's the objective here? I'm not familiar with awk but might be able to tease something out using grep.


Also, I was wondering if there are any flags I should be setting aside from -e or -E. I've read the tiger man file but the flag descriptions are not particularly helpful. For instance, why might I want to specify a workdir or bindir?

Also, in the tigerrc file, what the heck does this mean?
Code:

TigerNoBuild=Y                  # C files are corrupted (ouch.)

sneakyimp 07-25-2011 12:45 PM

I ran tiger a couple of times on my dev box and I think I am prepared to try it on my server. Unfortunately apt wants to install sendmail:
Code:

jason@ip-10-100-237-252:~$ sudo apt-get install tiger
Reading package lists... Done
Building dependency tree     
Reading state information... Done
The following extra packages will be installed:
  binutils chkrootkit diff john john-data libdb4.7 m4 procmail sendmail sendmail-base sendmail-bin sendmail-cf sensible-mda
Suggested packages:
  binutils-doc wenglish wordlist sendmail-doc rmail logcheck resolvconf sasl2-bin
Recommended packages:
  postfix mail-transport-agent fetchmail
The following NEW packages will be installed:
  binutils chkrootkit diff john john-data libdb4.7 m4 procmail sendmail sendmail-base sendmail-bin sendmail-cf sensible-mda tiger
0 upgraded, 14 newly installed, 0 to remove and 0 not upgraded.
Need to get 6,204kB of archives.
After this operation, 23.9MB of additional disk space will be used.
Do you want to continue [Y/n]? n

Having done some reading about send mail and postfix, I'm inclined to install postfix. I understand that it's supposed to be easier to configure and maintain. Additionally, this page says it is the default MTA for ubuntu and part of the main repository and will therefore receive updates.

I was rather hoping to get tiger and samhain running before dealing with mail, but both packages apparently require an MTA for notifications. Granted, we're not using mail notifications for tiger, but the package would install sendmail. I'm thinking I should install the postfix before tiger and samhain. If we have concerns about the security of the mail stack, we should deal with these now.

unSpawn 07-25-2011 05:01 PM

Quote:

Originally Posted by sneakyimp (Post 4424185)
I've attached the default samhainrc file and hope I could get some feedback on the settings in it. I realize we are balancing security with performance in some cases. For example, It looks like a file integrity check happens every 2 hours by default. That could give a hacker as much as 2 hours to clean up after themselves.

* Reading config files with 'grep -v ^# /path/to/file|grep .|less' makes it easier to see what really remains. In your case did you notice (find intervals: 'grep -i interval samhainrc') you can set separate intervals for different tests? Spreading risk depending on how an intruder makes its move (plus Samhain not being your only line of defense). Also you might want to see if you can or can not enable the kernel check (RHEL/Centos/Fedora CAN NOT due to /dev/.*mem-excluding kernel builds), check which files you actually have (find non-existent files: 'awk -F'=' '/file=/ {print $NF}' samhainrc|xargs -iX stat -c '%N' 'X' >/dev/null') and which log files you have (find selected open files in /var: 'lsof -Pwln +D/var/|awk '/\// {print $NF}'|egrep -v "(cache|run|db|lib|spool)/"|sort -u'). Then read /usr/share/doc/samhain/manual.html/filedef.html again and propose which areas of the system you want to exclude and check once it's operational.


Quote:

Originally Posted by sneakyimp (Post 4424396)
don't understand the lsof command you've offered or the Tiger_Running_Procs setting. (..) What's the objective here?

My apologies, it contains an error. The objective is to list processes by their full path. It should read:
Code:

sudo lsof -Pwln|awk '/REG.*bin/ {print $NF}'|sort -u

Quote:

Originally Posted by sneakyimp (Post 4424396)
Also, I was wondering if there are any flags I should be setting aside from -e or -E. I've read the tiger man file but the flag descriptions are not particularly helpful. For instance, why might I want to specify a workdir or bindir?

"Not particularly helpful" seems out of place here as each switch is accompanied by multi-line text in plain English. "-w" is for temporary files (I prefer /dev/shm for most temporary write ops) and "-b" if you installed Tiger binaries out-of-tree. Once (configure and) installed you generally won't need more switches. One useful switch (as with more applications ranging from Apache to Nagios to Snort) is the test flag "-t" as it allows you to see pre-flight if you misconfigured something.


Quote:

Originally Posted by sneakyimp (Post 4424396)
Also, in the tigerrc file, what the heck does this mean?
Code:

TigerNoBuild=Y                  # C files are corrupted (ouch.)

This rebuilds Tiger binaries like realpath, snefru, testsuid, md5, and getpermit. You don't need this.


Quote:

Originally Posted by sneakyimp (Post 4424767)
Having done some reading about Sendmail and postfix, I'm inclined to install postfix. I understand that it's supposed to be easier to configure and maintain. Additionally, this page says it is the default MTA for ubuntu and part of the main repository and will therefore receive updates.

I'd say by all means install what you're comfortable with.


Quote:

Originally Posted by sneakyimp (Post 4424767)
I was rather hoping to get tiger and samhain running before dealing with mail, but both packages apparently require an MTA

One other way could be to install tiger-3.2.3.tar.gz (notice the SHA1 and sig) from the GNU/Tiger official source and use a --prefix to confine it like --prefix=/opt/tiger? Installed files should be owned and used only by root and while it's maintained and supported (and has a mailing list) GNU/Tiger updates are rare.


Quote:

Originally Posted by sneakyimp (Post 4424767)
If we have concerns about the security of the mail stack, we should deal with these now.

Not really. You'll not be running your MTA on an external interface (you're not hosting domains or providing users with email), right? (BTW note fail2ban has a Postfix section as well.) Anyway, here's "Sendmail vs Postfix" security the CVE way. Good you found the Ubuntu Postfix documentation. Should contain most of what you need.

sneakyimp 07-26-2011 01:44 PM

Quote:

Originally Posted by unSpawn (Post 4424963)
In your case did you notice (find intervals: 'grep -i interval samhainrc') you can set separate intervals for different tests?

I did indeed notice this and that is what triggered my question. Check my values:
Code:

## Interval for check (seconds)
# SuidCheckInterval = 7200
## Check interval (seconds); btw., the check is VERY fast
# KernelCheckInterval = 300
## Interval for login/logout checks
# LoginCheckInterval = 300
## Interval between time stamp messages
SetLoopTime = 600
## Interval between file checks
SetFileCheckTime = 7200

2 hours between file checks seems like plenty of time for any successful break-in to cover their tracks. On the other hand, performing checksums on the file system more frequently sounds like a performance no-no on a busy server. Do these look like reasonable values?


Quote:

Originally Posted by unSpawn (Post 4424963)
Also you might want to see if you can or can not enable the kernel check (RHEL/Centos/Fedora CAN NOT due to /dev/.*mem-excluding kernel builds)

What would you recommend to determine the feasibility of kernel check? It appears to have the kernel check enabler commented out by default. Is it safe to just remove the comment and turn it on? Remember that I have installed tiger using the apt package so the fact that its commented out might be telling.
Code:

# KernelCheckActive = True
Quote:

Originally Posted by unSpawn (Post 4424963)
check which files you actually have (find non-existent files: 'awk -F'=' '/file=/ {print $NF}' samhainrc|xargs -iX stat -c '%N' 'X' >/dev/null') and which log files you have (find selected open files in /var: 'lsof -Pwln +D/var/|awk '/\// {print $NF}'|egrep -v "(cache|run|db|lib|spool)/"|sort -u'). Then read /usr/share/doc/samhain/manual.html/filedef.html again and propose which areas of the system you want to exclude and check once it's operational.

Let me just say I truly appreciate the super-helpful awk commands. You're talking about paring back the samhainrc so that I don't bother checking files I don't already have, right? I notice that there are some related to apache and others related to postfix on my current machine. Seems to me I should wait until I get my web stack installed to do this sort of configuration, shouldn't I?

Quote:

Originally Posted by unSpawn (Post 4424963)
"Not particularly helpful" seems out of place here as each switch is accompanied by multi-line text in plain English...Once (configure and) installed you generally won't need more switches.

I realize the man page is pretty detailed, but the level of detail is only meaningful if one has sufficient understanding of the context, which I do not (yet). I have both tiger and samhain running on my desktop box and haven't received any notifications yet from samhain so I'm not sure it's doing its job. The output of tiger with nothing but a -e flag looks like it is doing precisely what it should so it's my guess (and a guess only) that the apt-get install I performed did in fact install it correctly so there are no additional flags required. On the other hand, the output of the tiger scan is also full of detail which I don't understand and I wonder if the default settings present any security or stability risk.

Quote:

Originally Posted by unSpawn (Post 4424963)
This rebuilds Tiger binaries like realpath, snefru, testsuid, md5, and getpermit. You don't need this.

Not sure what you mean by "don't need this". "TigerNoBuild=Y" is the setting applied when I installed tiger via apt-get install. I'll just leave it as-is.

Quote:

Originally Posted by unSpawn (Post 4424963)
Not really. You'll not be running your MTA on an external interface (you're not hosting domains or providing users with email), right? (BTW note fail2ban has a Postfix section as well.) Anyway, here's "Sendmail vs Postfix" security the CVE way. Good you found the Ubuntu Postfix documentation. Should contain most of what you need.

While I'd prefer to use some pre-built mail stack (google apps or similar hopefully) running on some external machine for incoming mail, I'm not certain that is acceptable. In fact, I was looking at a variety of pages in the Ubuntu documentation that describe how to set up postfix/pop/imap/spamassassin/clamAV/amavis-new/squirrelmail on this machine. I am NOT looking forward to it at all but using Google Apps may introduce privacy concerns and I'll need to find a way to migrate our existing mail. I've done this once before and it was a nightmare.

Ultimately, I want to use apt-get install to install tiger and samhain and they both want to install smtp which I would like to avoid as it is my understanding that postfix is a) easier to configure, b) the default for ubuntu, and c) better documented as far as I can tell. I'm thinking that I might do an apt-get install for postfix before installing tiger and samhain, but I am totally uncertain how much configuration will be required or how to test samhain. I believe that my configuration of tiger is merely so that I can run commands to audit my system's condition, but samhain must be able to alert me when security issues arise, and must therefore be able to send mail. Complicating matters further is that the amazon compute instances cannot themselves send mail so I would need to follow the instructions on how to configure postfix to send mail via Amazon SES using a perl script.

I am anxious to move forward and it's my feeling that postfix is the next step. At the very least, outgoing mail capability must be established so that samhain can do its job. Otherwise, I have no warning system in place.

unSpawn 07-26-2011 07:08 PM

Quote:

Originally Posted by sneakyimp (Post 4425835)
2 hours between file checks seems like plenty of time for any successful break-in to cover their tracks. On the other hand, performing checksums on the file system more frequently sounds like a performance no-no on a busy server. Do these look like reasonable values?

Mine runs with SetFileCheckTime=14400, LoginCheckInterval=3600, ProcessCheckInterval=7200 and PortCheckInterval=3600. The amount of hashes to check also depends on your configuration. For instance excluding /usr/share and /usr/local may cause blind spots wrt attacks potentially storing files there but together with detecting other signs of mischief like the previously mentioned checks and for instance Logwatch reporting this might mitigate risks down to a (what you might view as a) reasonable level. As always it's a trade-off. (Having more than one layer may help. I'm not trying to make you dizzy but there is absolutely no rule against leveraging the specialties of and using multiple applications. For instance I run Samhain on /sbin and /bin every hour with the other checks, Monit to check process availability, log entry regexes, disk space and hashes for some applications, Aide to check other paths, SELinux and Logwatch. What I mean is that, depending on what you value protecting, you might prefer redundancy and overlap over missing out on things.)


Quote:

Originally Posted by sneakyimp (Post 4425835)
What would you recommend to determine the feasibility of kernel check? It appears to have the kernel check enabler commented out by default. Is it safe to just remove the comment and turn it on?

If you kernel does not support /dev/.*mem then I wouldn't turn it on. As I've found out the hard way this will OOPS your machine real good :-]


Quote:

Originally Posted by sneakyimp (Post 4425835)
You're talking about paring back the samhainrc so that I don't bother checking files I don't already have, right?

Indeed.


Quote:

Originally Posted by sneakyimp (Post 4425835)
I notice that there are some related to apache and others related to postfix on my current machine. Seems to me I should wait until I get my web stack installed to do this sort of configuration, shouldn't I?

Yes. Looking at common points of entry I've never seen say Apache subverted (though there are processes that mimic argv[0] to make IRC bouncers look like they're "/usr/local/bin/httpd -SSL" ;-p) but what runs in the web stack to be exploited. Apart from watching publicly accessible, writable temp and upload dirs Samhain isn't going to catch much of that like inotify+ClamAV would.


Quote:

Originally Posted by sneakyimp (Post 4425835)
I realize the man page is pretty detailed, but the level of detail is only meaningful if one has sufficient understanding of the context

Thanks for pointing that out. I do sometimes forget I am no longer blessed with the clear view new Linux users possess...


Quote:

Originally Posted by sneakyimp (Post 4425835)
I have both tiger and samhain running on my desktop box and haven't received any notifications yet from samhain so I'm not sure it's doing its job. The output of tiger with nothing but a -e flag looks like it is doing precisely what it should so it's my guess (and a guess only) that the apt-get install I performed did in fact install it correctly so there are no additional flags required. On the other hand, the output of the tiger scan is also full of detail which I don't understand and I wonder if the default settings present any security or stability risk.

Compress and attach GNU/Tiger log to an email to me? Would be good to have as this helps figure out where you stand wrt host hardening.


Quote:

Originally Posted by sneakyimp (Post 4425835)
Not sure what you mean by "don't need this". "TigerNoBuild=Y" is the setting applied when I installed tiger via apt-get install. I'll just leave it as-is.

Indeed best leave it as it is.


Quote:

Originally Posted by sneakyimp (Post 4425835)
While I'd prefer to use some pre-built mail stack (google apps or similar hopefully) running on some external machine for incoming mail, I'm not certain that is acceptable. In fact, I was looking at a variety of pages in the Ubuntu documentation that describe how to set up postfix/pop/imap/spamassassin/clamAV/amavis-new/squirrelmail on this machine. I am NOT looking forward to it at all but using Google Apps may introduce privacy concerns and I'll need to find a way to migrate our existing mail. I've done this once before and it was a nightmare.

Ultimately, I want to use apt-get install to install tiger and samhain and they both want to install smtp which I would like to avoid as it is my understanding that postfix is a) easier to configure, b) the default for ubuntu, and c) better documented as far as I can tell. I'm thinking that I might do an apt-get install for postfix before installing tiger and samhain, but I am totally uncertain how much configuration will be required or how to test samhain. I believe that my configuration of tiger is merely so that I can run commands to audit my system's condition, but samhain must be able to alert me when security issues arise, and must therefore be able to send mail. Complicating matters further is that the amazon compute instances cannot themselves send mail so I would need to follow the instructions on how to configure postfix to send mail via Amazon SES using a perl script.

I am anxious to move forward and it's my feeling that postfix is the next step. At the very least, outgoing mail capability must be established so that samhain can do its job. Otherwise, I have no warning system in place.

Maybe I haven't read the docs too well but to me it seems the AWS Perl script drop-in provides your locally installed Postifx with the capacity to send email through SES as it would take care of authentication. So if you can install Postfix and test you can send email from your instances account to an external email address then IMHO you should have no trouble at all wrt sending out notifications.

sneakyimp 07-27-2011 01:22 PM

Quote:

Originally Posted by unSpawn (Post 4426111)
Mine runs with SetFileCheckTime=14400, LoginCheckInterval=3600, ProcessCheckInterval=7200 and PortCheckInterval=3600.

Thanks for the parameters. I'll be revisiting these when I finally get Tiger running on the server. For the moment, it's postfix time. I learned yesterday that it's OK to use Google Apps for mail and I have that more or less sorted out. I just need to set up postfix to handle outgoing mail from my server. I created a separate thread for the details of that in the hope that I might reach a broader audience. It's pretty quiet in this thread and the security forum.

Quote:

Originally Posted by unSpawn (Post 4426111)
If you kernel does not support /dev/.*mem then I wouldn't turn it on. As I've found out the hard way this will OOPS your machine real good :-]

Yikes. I haven't the foggiest idea how to check if my kernel supports /dev/.*mem . I'm not even sure what that means.

Quote:

Originally Posted by unSpawn (Post 4426111)
Compress and attach GNU/Tiger log to an email to me? Would be good to have as this helps figure out where you stand wrt host hardening.

I haven't installed it on the server yet. I've been testing things on my desktop Ubuntu box so far. As previously discussed, I have to get postfix installed first.


Quote:

Originally Posted by unSpawn (Post 4426111)
Maybe I haven't read the docs too well but to me it seems the AWS Perl script drop-in provides your locally installed Postifx with the capacity to send email through SES as it would take care of authentication. So if you can install Postfix and test you can send email from your instances account to an external email address then IMHO you should have no trouble at all wrt sending out notifications.

Working on this now. Tiger log to come after.

unSpawn 07-27-2011 04:28 PM

Quote:

Originally Posted by sneakyimp (Post 4426902)
I haven't the foggiest idea how to check if my kernel supports /dev/.*mem .

https://wiki.ubuntu.com/Security/Features#dev-kmem

sneakyimp 07-29-2011 03:01 PM

So that's good news about the /dev/.*mem not being enabled. I gather that's one less thing to configure/enable.

Update: After a substantial struggle and lots of dependency-hunting, my EC2 instance is now hooked into Amazon SES and I have sent one successful mail from the machine. I'm pretty nervous about the setup being reliable enough for use by the myriad applications that might want to send mail from my machine, but I'm hoping for the time being that it just might work. I'd like to know how this mail installation process might affect security. The details:
* sudo apt-get install postfix, choose "no configuration"
* Configure postfix main.cf:
a) no delivery to local mailboxes so we don't have root mailbox growing without bound
b) no mail delivery to external machines
c) route email destined for local mailboxes to fully qualified domain
d) use amazon SES for default mail transport. The details:
Code:

$ sudo postconf -n
config_directory = /etc/postfix
default_transport = aws-email
inet_interfaces = loopback-only
local_transport = error:local delivery is disabled
mydomain = mydomain.com
mynetworks_style = host
myorigin = $mydomain
relayhost = $mydomain
smtp_generic_maps = hash:/etc/postfix/generic
smtpd_banner = $myhostname ESMTP $mail_name

* edit postfix master.cf to add aws-email:
Code:

aws-email  unix  -      n      n      -      -      pipe
  flags=R user=mail argv=/opt/third-party/amazon/ses-send-email.pl --verbose -r -k /opt/third-party/amazon/aws-credentials -e https://email.us-east-1.amazonaws.com -f user@mydomain.com ${recipient}

NOTE: This will route all of my mail through a perl script from amazon.
* Install Amazon scripts in /opt/third-party/amazon. IMPORTANT: One of these files, aws-credentials, contains my AWS Access Key and my AWS Secret Key. The AWS docs say to remove read permission to this file from anyone but "your" account. Given that I'm trying to provide outgoing email access to my entire machine, it seems obvious that this would preclude access to this file to many other services (e.g., postfix, samhain, tiger) that might need to send mail. Currently the file is world-readable. I suspect creating a group and giving group read access would be the right approach here, but I'm not sure which users should be added to this group. ALSO IMPORTANT: These amazon scripts (and their dependencies) were not installed using the package system and I need to determine a scheme to keep them up-to-date.
* Install Amazon script dependencies and there are numerous ones. After getting a couple of complaints about missing perl functionality, I installed a few packages somewhat blindly. Some of these helped, others did not. Are any of these unsafe or a security risk?
Code:

apt-get install libnet-ssleay-perl
apt-get install libnet-sslglue-perl
apt-get install libio-socket-ssl-perl
apt-get install libcrypt-ssleay-perl
apt-get install libwww-perl

I subsequently learned that the README file for the Amazon SES scripts contains installation instructions. The documentation failed to mention this. The instructions in that file describe using perl and CPAN to install some perl modules *outside* the package system of my OS. I am concerned about making sure these are up to date. The perl commands themselves had some packages prerequisites:
Code:

sudo apt-get install gcc
sudo apt-get install libssl-dev
sudo apt-get install libxml2-dev

Here are the perl/cpan commands I ran:
Code:

sudo perl -MCPAN -e 'install YAML'
sudo perl -MCPAN -e 'install Digest::SHA'

sudo perl -MCPAN -e 'install URI::Escape'

sudo perl -MCPAN -e 'install Bundle::LWP'

sudo perl -MCPAN -e 'install LWP::Protocol::https'

sudo perl -MCPAN -e 'install MIME::Base64'

sudo perl -MCPAN -e 'install Crypt::SSLeay'

sudo perl -MCPAN -e 'install XML::LibXML'

Also of note: When you first run CPAN commands in perl, you are asked if you want to auto-config or whether you'd like to set each individual setting. I tried individual settings at first but found myself ultimately prompted for a CPAN URL which I couldn't seem to satisfy despite trying urls from the mirror list. Ultimately I ended up running the auto-config. This worries me a bit as the CPAN install stuff a)comes from god knows where and b) is not maintained by the package system and may not have an update process. Sadly I felt compelled to do it because I need Amazon SES and they recommended it.

At this point, the amazon scripts seem to run, but the saga continues. Because of mail failures, some additional steps were required:
* add symbolic link to amazon SES.pl at /usr/lib/perl5/SES.pl
* Alter ses-send-email.pl to scrub Precedence and Auto-Submitted headers out of emails so they are not rejected by the SES gateway.
* use hard-wired (and valid) sender address for all outgoing mail to solve various problems.

As soon as I am granted 'production' access to SES, I will run a couple more tests, create a snapshot machine image of the system, and move on to configuration of tiger and samhain. At that point, I'll want to know what I can do to trigger a notification by tiger and/or samhain so that I can make sure the email setup works.

As usual, any advice or input you have would be much appreciated.

sneakyimp 07-31-2011 09:22 PM

1 Attachment(s)
I have installed tiger on the server now. It did not want to install sendmail so I believe my choice to install postfix first was the right thing to do. It took about 2 minutes to run:
Code:

user@ip-WWW-XXX-YYY-ZZZ:~$ sudo tiger -E
Tiger UN*X security checking system
  Developed by Texas A&M University, 1994
  Updated by the Advanced Research Corporation, 1999-2002
  Further updated by Javier Fernandez-Sanguino, 2001-2007
  Covered by the GNU General Public License (GPL)

Configuring...
 
Will try to check using config for 'x86_64' running Linux 2.6.32-317-ec2...
--CONFIG-- [con005c] Using configuration files for Linux 2.6.32-317-ec2. Using
          configuration files for generic Linux 2.
Tiger security scripts *** 3.2.2, 2007.08.28.00.00 ***
02:12> Beginning security report for ip-WWW-XXX-YYY-ZZZ.ec2.internal.
02:12> Starting file systems scans in background...
02:12> Checking password files...
02:12> Checking group files...
02:12> Checking user accounts...
02:12> Checking .rhosts files...
02:12> Checking .netrc files...
02:12> Checking ttytab, securetty, and login configuration files...
02:12> Checking PATH settings...
02:12> Checking anonymous ftp setup...
02:12> Checking mail aliases...
02:12> Checking cron entries...
02:12> Checking 'services' configuration...
02:13> Checking NFS export entries...
02:13> Checking permissions and ownership of system files...
--CONFIG-- [con010c] Filesystem 'devtmpfs' used by 'none' is not recognised as a valid filesystem
02:13> Checking for indications of break-in...
--CONFIG-- [con010c] Filesystem 'devtmpfs' used by 'none' is not recognised as a valid filesystem
02:13> Performing system specific checks...
02:14> Performing root directory checks...
02:14> Checking for secure backup devices...
02:14> Checking for the presence of log files...
02:14> Checking for the setting of user's umask...
02:14> Checking for listening processes...
02:14> Checking SSHD's configuration...
02:14> Checking the printers control file...
02:14> Checking ftpusers configuration...
02:14> Checking NTP configuration...
02:14> Waiting for filesystems scans to complete...
02:14> Filesystems scans completed...
02:14> Performing check of embedded pathnames...
02:14> Security report completed for ip-WWW-XXX-YYY-ZZZ.ec2.internal.
Security report is in `/var/log/tiger/security.report.ip-WWW-XXX-YYY-ZZZ.ec2.internal.nnnnnn-02:12'.

unSpawn, I have emailed you the output of this file (it contains incriminating IP addresses so I don't feel that it's safe to post here). I've attached the tigerrc to this thread.

unSpawn 08-01-2011 11:29 AM

Quote:

Originally Posted by sneakyimp (Post 4430283)
output of this file

Thanks, you'll find most of the common 'tiger -E' explanations here. Any questions just ask.


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