On Fri, Nov 10, 2000 at 08:54:53AM -0600, Bill Carlson wrote:
> > Other than that my guess would be that if up to now noone has yet
> > changed that database, it's probably only a matter of time until they
> > start doing so... (Hm, wouldn't it suffice to simply delete the database
> > to foil usi
On Thu, 9 Nov 2000, Thomas Ribbrock wrote:
> On Thu, Nov 09, 2000 at 09:46:08AM -0600, Bill Carlson wrote:
> [...]
> > So, is there a consensus, should rpm -Va be trusted after a successful
> > attack?
>
> I'd say, the easiest way to accomplish that would be to take a copy of
> the RPM database
On Thu, 9 Nov 2000, Ed Lazor wrote:
> I'm using hosts.allow and hosts.deny, but I don't see anything about
> /usr/sbin/tcpd in there. Should it be?
You _could_ do that, but you're just adding an extra layer of
complexity. xinetd supports host based control itself, so it eliminates
the overhea
At 03:35 PM 11/9/2000 -0600, you wrote:
>For any $FILE,
>
>rpm -qf $FILE
>
>will tell you the owning rpm.
>
>In the present case,
>
>rpm -qf `which ps` <-- note: backquotes
>
>...will tell you the owning rpm of whichever ps happens to be in your
>default search path, on the off chance that your s
For any $FILE,
rpm -qf $FILE
will tell you the owning rpm.
In the present case,
rpm -qf `which ps` <-- note: backquotes
...will tell you the owning rpm of whichever ps happens to be in your
default search path, on the off chance that your system has more than
one installed.
Cheers,
-m
Ed
At 02:48 PM 11/9/2000 -0500, you wrote:
>I wasn't aware you were using xinetd.
It's default in RedHat 7.0
>I am unclear on how xinetd makes use of tcpwrappers, actually, or if one
>would need to install tcpd and add /usr/sbin/tcpd to the "server" line.
I'm wondering if it will work if I just mo
rpm -qf [filename]
rpm -qf /bin/ps
On Thu, 9 Nov 2000, Ed Lazor wrote:
> At 07:04 AM 11/9/2000 -0800, you wrote:
> >3) Reinstall the package with ps. Look at ps output and see if there are
> >any unusual processes running.
>
> Is there a way to find out which rpm installed ps? If not, anyone
>5) Look for odd things; one way I have seen backdoors and pieces hidden is
>to create 'hidden' directories - esp. popular in /dev. Here are a couple
>of commands:
>
> find / -name '. ' -print
> find /dev -type f -o -type d -print
This reminded me you should check and verify all of
At 07:04 AM 11/9/2000 -0800, you wrote:
>3) Reinstall the package with ps. Look at ps output and see if there are
>any unusual processes running.
Is there a way to find out which rpm installed ps? If not, anyone know which
one installs it?
-Ed
___
I wasn't aware you were using xinetd.
I am unclear on how xinetd makes use of tcpwrappers, actually, or if one
would need to install tcpd and add /usr/sbin/tcpd to the "server" line.
On Thu, 9 Nov 2000, Ed Lazor wrote:
> I have a question about this part and how it applies to RedHat 7.0.
>
>
I have a question about this part and how it applies to RedHat 7.0.
As you probably know, RedHat 7.0 moves entries from the inetd.conf file
to individual files in the /etc/xinetd.d directory. I checked the file
/etc/xinetd.d/telnet and found this:
---
On Thu, Nov 09, 2000 at 09:46:08AM -0600, Bill Carlson wrote:
[...]
> So, is there a consensus, should rpm -Va be trusted after a successful
> attack?
I'd say, the easiest way to accomplish that would be to take a copy of
the RPM database (onto an external medium, e.g. floppy) each time you
chang
On Thu, 9 Nov 2000, Rick Warner wrote:
> 1) Find out what has changed on the machine. Use 'rpm -V' against all
> packages and see what was modified. If they had root access, it is likely
> they changed some system utils to add a backdoor.
Sorry to hear you've been hacked Fred.
On a related n
Ok.. Here's an update... The log entry where it shows the login time
(20:19 - crash (5+12:25) ) has a domain name attached to it. I called the
person responcible for that server, and they said they've had several
complaints today on this, and have done a 'last' and looked through seve
There are a number of things you should do.
1) Find out what has changed on the machine. Use 'rpm -V' against all
packages and see what was modified. If they had root access, it is likely
they changed some system utils to add a backdoor.
2) Look for any other signs of backdoors. Reinstall
On Thu, 9 Nov 2000, Fred Edmister wrote:
> Thank you so much! This helped tremendously! The good news
> is, I've not only found thier IP address, traced them back to their ISP
> (BEZEQINT.NET) and found that they did NOT do anything to the
> system!! (aparently he's been using h
Well, you could look in their homedir, and see if there's any sort of
history file...if they really were as inept as we're hoping, they might
have bash as a shell, with a .bashhistory file left in the homedir.
On Thu, 9 Nov 2000, Wahid Belhaouane wrote:
> you can type the command :
> last | gr
Hi, Fred.
I'm not sure how it was determined that the hacker didn't do anything to
the system, but I wouldn't be so sure. I would be more inclined to
follow Dan's advice, personally.
That having been said, I'll address your last question, here.
You have a couple of options...to secure telnet
On Thu, Nov 09, 2000 at 08:23:14AM -0500, Fred Edmister wrote:
: This morning I awoke to my Linux server not responding, and when I went to
: the system itself, there were a bunch of PAM *** info lines on the screen
: for a username I had never seen... I couldn't log in, and had to just po
you can type the command :
last | grep shlomi to know how long this user logged on your system.
about what he did , i also waiting for others to answer.
Wahid
Fred Edmister wrote:
> This morning I awoke to my Linux server not responding, and when I went to
> the system itself, there wer
Dan,
Thank you so much! This helped tremendously! The good news
is, I've not only found thier IP address, traced them back to their ISP
(BEZEQINT.NET) and found that they did NOT do anything to the
system!! (aparently he's been using his telnet account since this past
Hi - I have a couple of quickie bits of advise for you...
1) remove the machine from the network (pull the net / modem cable) so you
can check exactly what has happened without him / them logging back in and
screwing stuff up more / covering their tracks. don't bring the machine
back up till you'
This morning I awoke to my Linux server not responding, and when I went to
the system itself, there were a bunch of PAM *** info lines on the screen
for a username I had never seen... I couldn't log in, and had to just power
down and do a manual fsck when it came back up... (bear with m
23 matches
Mail list logo
