Sponsored Content
Full Discussion: Our system was hacked
Special Forums Cybersecurity Our system was hacked Post 303037161 by MadeInGermany on Thursday 25th of July 2019 03:13:26 AM
Old 07-25-2019
Look in root's homedir for .history .bash_history or similar files.
Run the history command in the respective shell(s).

Ordinary system logins are listed with the last command.

Consult the system logs, for system access and unusual events.
Is there a su or sudo log in /var/log/ or /var/adm/?
Do you happen to have system accounting (sa) running?

Run netstat -a and look for LISTEN; what services are running that use the ports?
Do these services have extra logs?

How good is your root pw? The longer the better.
Did you switch from the 13byte Unix crypt to another crypt that allows longer pws?

Are you sure your system was hacked at all?
Maybe there was a fatal human error like
Code:
tar cf - dir | tar xf -

where the read files are already opened for writing, and such data corruptions can occur.
This User Gave Thanks to MadeInGermany For This Post:
 

3 More Discussions You Might Find Interesting

1. Linux

pc hacked

Hi, i think someone has hacked my server, the following rules used to come which i haven't put. Please help me i couldnt find out how this rules are apply, i think someone has put an script which generates enables the rules. But after restarting the iptables everything seems to be working... (0 Replies)
Discussion started by: naik_mit
0 Replies

2. Cybersecurity

How to know when you've been hacked

One of the most important ways to keep tou machine secure is to know when it has been broken into. The less time hackers have on your system, the less they can do to it, and the greater you chancens of kicking them off and repairing the damage. The more sophisticated the hacker, the less likely... (8 Replies)
Discussion started by: binhnx2000
8 Replies

3. Cybersecurity

Server hacked on known port

Hi, There is a recent case whereby it was reported that one of the production servers was hacked on port 1521. However, I am not sure how this was possible, as I checked that the OS firewall (iptables) is on : # /etc/init.d/iptables status Table: nat Chain PREROUTING (policy ACCEPT) num ... (7 Replies)
Discussion started by: anaigini45
7 Replies
TRIMHISTORY(8)						      System Manager's Manual						    TRIMHISTORY(8)

NAME
trimhistory - Remove old Xymon history-log entries SYNOPSIS
trimhistory --cutoff=TIME [options] DESCRIPTION
The trimhistory tool is used to purge old entries from the Xymon history logs. These logfiles accumulate information about all status changes that have occurred for any given service, host, or the entire Xymon system, and is used to generate the event- and history-log web- pages. Purging old entries can be done while Xymon is running, since the tool takes care not to commit updates to a file if it changes mid-way through the operation. In that case, the update is aborted and the existing logfile is left untouched. Optionally, this tool will also remove logfiles from hosts that are no longer defined in the Xymon bb-hosts(5) file. As an extension, even logfiles from services can be removed, if the service no longer has a valid status-report logged in the current Xymon status. OPTIONS
--cutoff=TIME This defines the cutoff-time when processing the history logs. Entries dated before this time are discarded. TIME is specified as the number of seconds since the beginning of the Epoch. This is easily generated by the GNU date(1) utility, e.g. the following com- mand will trim history logs of all entries prior to Oct. 1st 2004: trimhistory --cutoff=`date +%s --date="1 Oct 2004"` --outdir=DIRECTORY Normally, files in the BBHIST directory are replaced. This option causes trimhistory to save the shortened history logfiles to another directory, so you can verify that the operation works as intended. The output directory must exist. --drop Causes trimhistory to delete files from hosts that are not listed in the bb-hosts(5) file. --dropsvcs Causes trimhistory to delete files from services that are not currently tracked by Xymon. Normally these files would be left untouched if only the host exists. --droplogs Process the BBHISTLOGS directory also, and delete status-logs from events prior to the cut-off time. Note that this can dramatically increase the processing time, since there are often lots and lots of files to process. --progress[=N] This will cause trimhistory to output a status line for every N history logs or status-log collections it processes, to indicate how far it has progressed. The default setting for N is 100. --env=FILENAME Loads the environment from FILENAME before executing trimhistory. --debug Enable debugging output. FILES
$BBHIST/allevents The eventlog of all events that have happened in Xymon. $BBHIST/HOSTNAME The per-host eventlogs. $BBHIST/HOSTNAME.SERVICE The per-service eventlogs. $BBHISTLOGS/*/* The historical status-logs. ENVIRONMENT VARIABLES
BBHIST The directory holding all history logs. BBHISTLOGS The top-level directory for the historical status-log collections. BBHOSTS The location of the bb-hosts file, holding the list of currently known hosts in Xymon. SEE ALSO
xymon(7), bb-hosts(5) Xymon Version 4.2.3: 4 Feb 2009 TRIMHISTORY(8)
All times are GMT -4. The time now is 02:53 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy