[Webinar] Streamline your web hosting managementRegister Today

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 393
  • Last Modified:

Backup logfiles over network

I'm planning to back-up my logfiles to antoher server. So my question is as followed:

I'm planning ot write a script that copies a number of logfiles to another directory. When the files are copied the script wil tar/zip the direcotry so there is 1 file named DIRECOTRY.TAR/ZIP.
So far so good. Now i want to get this tar to be copied to another server in the network. So what is the smartes thing to do here ? SMB protocol FTP ? how can i get this tar file to antoher pc ?
0
Mr-sark
Asked:
Mr-sark
  • 9
  • 7
  • 2
  • +1
1 Solution
 
rindiCommented:
The easiest way would be to use a ntework protocoll that is mountable. SMB/CIFS are mountable, NFS too. Then you would copy the files as just to that mounted folder.
0
 
Mr-sarkAuthor Commented:
After doing some googlin i found that you can setup a remote syslogser.
the thing to do is edit the file /etc/syslog.conf and add the following line:

*.*                   @xxx.xxx.xxx.xxx. <----ip of remote syslog server that you can setup.

so far so good. So i was wondering if anyone know where these files wll be stored on the syslog server ?
0
 
rindiCommented:
Usually they go to the syslog file on that server.
0
The new generation of project management tools

With monday.com’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.

 
Mr-sarkAuthor Commented:
I was  thinking the same thing! but is it possible to define a direcotry so the logs from different servers are sperated
0
 
rindiCommented:
Not directly, but I believe you can use the "local0.." labels to have them piped to another file.
0
 
yves_junqueiraCommented:
Hi.

Do you have ssh installed in all machines? I believe you do, since that is necessarily these days.

Try the following script:

--------------------------------------------------------------------
#!/bin/sh

THISMACHINE=$(hostname)
COPYTO="destination-hostname-or-ip"


mkdir -p /usr/local/backup/logs

cp -R /var/log/syslog* /usr/local/backup/logs/

#this will create /usr/local/backup/mylogs.tar.gz:
tar -zcvf /usr/local/backup/mylogs.tar.gz /usr/local/backup/logs/

#this will create the target dir in the target server, and
# copy the file
ssh root@$COPYTO "mkdir -p /usr/local/backup/$THISMACHINE"
scp /usr/local/backup/mylogs.tar.gz root@$COPYTO:/usr/local/backup/

--------------------------------------------------------------------

Please notice that, using this script, it will keep asking your password.

You'd have to share your root's public keys between the hosts, and it will stop asking for it.

A quick way to do that is:

# ssh-keygen -t rsa
# cat ~/.ssh/id_rsa.pub  | ssh <THE OTHER HOST> 'cat >> ~/.ssh/authorized_keys'

Do this in each host.

Then you're done :-)
0
 
yves_junqueiraCommented:

Sorry.

change this line:
scp /usr/local/backup/mylogs.tar.gz root@$COPYTO:/usr/local/backup/

to:
scp /usr/local/backup/mylogs.tar.gz root@$COPYTO:/usr/local/backup/$THISMACHINE-logs.tar.bz

0
 
Mr-sarkAuthor Commented:
This looks great. Only a few questions so i'll understand it

the 2 computer will make ssh connection. for a ssh connection you need a username and password rigth ?
so the username and password are known in the file ? or do i let the computer have acces between eachother (ssh keys) ? The only problem with this is that if a hacker is hacking the system he also will have acces tot the other system where the logfiles ar stored.

Correct me if i'm wrong
0
 
rindiCommented:
With SSH you can configure your system so that it authentifies itself via private/public keys, plus your login. The hacker would need those keys in order to connect. You can use OpenSSL to manage these keys.
0
 
Mr-sarkAuthor Commented:
so when i make those keys on a system, the hacker can't use them?
0
 
Mr-sarkAuthor Commented:
btw i'm raisng the point so i can give some more assistent points away
0
 
rindiCommented:
The hacker would either need the files, or break theencryption of those keys, and that is very difficult with today's knowledge and hardware, as long as you use a strong key (with 1024 bit encryption or higher). Of course if the hacker can access a PC which contains those keys and knows your login, then you might as well not use any security at all. The advantage of SSH compared to telnet is that the athentification happens encrypted using SSH, and in Telnet it is in the clear, so a hacker listening in could pick up that data and then have no problem missusing your login.
0
 
Mr-sarkAuthor Commented:
i'm finally back from the weekend. I'm planning to try this script todat! only the following line is a little bit unclear to me:

# cat ~/.ssh/id_rsa.pub  | ssh <THE OTHER HOST> 'cat >> ~/.ssh/authorized_keys'

I'm using a Red Hat 4 machine and a fedora 3 machine.
0
 
Mr-sarkAuthor Commented:
Ok :) i've got it working! only 1 thing is bugging me ( maybe i don't get it ).

I have 2 machines

machine 1
machine 2

i performed the SSH key authentication on both machines

machine 1 writes it's logfiles to machine 2. So i have a crontab running @ machine 1 that is backinup the log files daily @ 11 pm.
Now lets say a hacker hacked into machine 1 and looks into the crontab of machine 1. Now he will se a backup script is running to machine 2.
The only thing he has todo is type (ssh machine 2IP) to gain access.
Isn't this way to dangerous
0
 
rindiCommented:
How would the hacker hack into machine 1? If the hacker doesn't have actual physical access tp machine 1, you need to make sure that this machine itself alco can only be reached from the outside via SSH. Also make sure you can't SSH to the machine as root, but only as a restricted user. Being a restricted user in his own environment would hide all system files including cron jobs etc from a hacker. If you still need more access once you have ssh'd to the box, you can use su to get more access. Even if the hacker had physical access to the PC, you can restrict access that way. Just never use root when not absolutely necessary.
0
 
Mr-sarkAuthor Commented:
ok well i'm still testing it. it is still possible to ssh into the machine as ROOT. what file/line do i have to modify to prefent ssh login as root.?
0
 
rindiCommented:
Just create a line in sshd_config:

DenyUsers root

0
 
Mr-sarkAuthor Commented:
ok, 1 last question: i've just added this line:

# cat ~/.ssh/id_rsa.pub  | ssh <THE OTHER HOST> 'cat >> ~/.ssh/authorized_keys'

So the ssh conection wouldn't keep asking for a password, but lets say i want to remove the auto authentication so every connection from that computer requires a password again....how :?

raised to 500 points! you 2 guys helped me perfectly so each will get 250 points.
0
 
macker-Commented:
Without intending disrespect to anyone, this sounds like a haphazard solution and very weak on security.  As has been observed, a hacker can potentially gain access to the second machine if the first machine is compromised.  There are ways to limit what a user can do via SSH, but in the end, if the user uploaded the data, the data can then be replaced.

The goal of this, if I'm understanding it correctly, is to transmit specific data from system 1 to system 2, such that if system 1 is compromised, the data is still available on system 2.  Real-time would be preferred.

Now since you're talking about syslog data, syslog is the answer.  Either syslog-ng or minisyslogd would be good options.  syslog-ng is a full syslog replacement, supports features such as cryptographically hashed log files (to prevent tampering), and is very configurable over how it writes out logfiles (e.g. writing to independent logfiles for data from a remote host).  minisyslogd is also a useful option for bulk writing of these files; you simply establish directories for each IP that's going to submit syslog data... if the IP exists, it writes the data, if not, it discards it.  log files are auto-timestamped, making it easy to manipulate on the remote end with find or similar tools.

If you want a method for depositing files to the remote host, then you have a few options.  Some FTP daemons can be setup for one-way writes (e.g. ProFTPd could be used and configured to allow a user to store files, but not delete or retrieve files).  ncftpput would be a good option for the actual transfer mechanism in this case.

rsync is another noteable option, but not particularly for the security side.  scp is an option, and there's a much simpler way of dealing with the above headaches.

1) null keys.  you establish an RSA or DSA key with a null pass-phrase.  the client host can then connect to the remote host without prompting for a password; possession of the key is sufficient.

2) ssh-agent.  the agent is a program that runs in memory and caches the pass-phrase for the RSA/DSA key, so that it can continue to be used for future SSH sessions.  if the server is rebooted, the key is lost.

Both of these solutions are sub-standard for the scenario described, because the hacker has opportunity to connect to the second machine, once he has access to the first.  That's the worst possible scenario, and should be avoided at all costs.

The point of using SSH in this manner is that the CLIENT is the trusted host, and the remote is the untrusted host.  To wit, one could configure the remote host to be the trusted host, using a null key on the client side, assuming that the file name (time-stamped, etc.) is predictable without advance knowledge.  E.g. dated based on the day, or hour, assuming the clocks are in sync.  (This could be achived with ntp, etc.)

To answer your latest question, Mr-sark, you could follow the example to do ssh <THE OTHER HOST> 'rm -f ~/.ssh/authorized_keys'

The authorized_keys file contains the keys that are recognized as being legitimate.  The client has the "trusted" version of the key, while the remote host has the "untrusted" (public) version of the key.  This assumes that the client is the secure system, and the remote is a system that could become compromised, and that the key may be used on other systems.

All in all, syslog seems to provide the best possible solution, since it provides real-time logging and doesn't involve additional layers beyond what you're already doing.  scp'ing log files that are created by syslog is like using a sledge-hammer on a penny nail.. sure, you'll hit the nail, eventually... but it'd be a lot simpler/easier to use a regular hammer.
0

Featured Post

The new generation of project management tools

With monday.com’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.

  • 9
  • 7
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now