about hacking

about hacking

Post by crow » Thu, 25 Jan 2001 03:39:45



In one of the messages about automaticly rebooting I noticed someone was
talking about hacking so I started to wonder.. how can you tell if your
system is hacked?  Which logs can provide information etc..
 
 
 

about hacking

Post by Donn Mille » Thu, 25 Jan 2001 07:37:27



> In one of the messages about automaticly rebooting I noticed someone was
> talking about hacking so I started to wonder.. how can you tell if your
> system is hacked?  Which logs can provide information etc..

First, you can set this option

log_in_vain="YES"               # YES to log connects to ports w/o
listeners.

in /etc/rc.conf.  Then, all failed connection attempts to your box will
be logged via syslogd, so the output will show up in /var/log/messages.

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

 
 
 

about hacking

Post by Lowell Gilber » Thu, 25 Jan 2001 08:07:15




> > In one of the messages about automaticly rebooting I noticed someone was
> > talking about hacking so I started to wonder.. how can you tell if your
> > system is hacked?  Which logs can provide information etc..

> First, you can set this option

> log_in_vain="YES"               # YES to log connects to ports w/o
> listeners.

> in /etc/rc.conf.  Then, all failed connection attempts to your box will
> be logged via syslogd, so the output will show up in /var/log/messages.

Just to be pedantic, I'd like to point out that this technique (and
many others, such as verbose TCP wrappers, firewall logging,
honeypots, and so on) will give you information on people who tried
and *failed* to contact your system (often, but not remotely always,
implying a hack attempt), but may well not show anything if a hack
attempt succeeded.  

Any kind of logs that are kept on the machine under attack can be
cleaned up afterwards.  Logging to another machine (or, say, a
hard-copy printer) is the only way to be remotely sure you get that
information.  Other than that, the only thing I can think of is
trusted checksums of key files; Tripwire does this, and with enough
preparation you could do the same with mtree.

That said, Donn Miller's advice is still the first way to go (although
I prefer using ipfw logging, to the same purpose, because it makes it
easier for me to be selective, and also because the firewall is a
fairly easy way to tighten down the machine anyway).  The reason for
this is that detecting *failed* attacks is one of the best ways to stop
*successful* ones.  So it's not exactly the answer to what the original
poster asked, but it's the best advice to give him (?) anyway.

 - Lowell Gilbert
--
"Computers make it easier to do a lot of things, but most of the things
they make it easier to do don't need to be done."
                -- Andy Rooney

 
 
 

about hacking

Post by Alexandr » Thu, 25 Jan 2001 11:54:40



> In one of the messages about automaticly rebooting I noticed someone was
> talking about hacking so I started to wonder.. how can you tell if your
> system is hacked?  Which logs can provide information etc..

After it's been hacked it's kind of tough.  I'd put back up all your data
files then wipe the disk and reinstall.  Then before you put your computer
on the network get an integrity checking program such as tripwire or aide.
This way you can make sure files aren't being altered.  Also run at secure
level one and make your logs append only so
they can't be erased in the event there is a root compromise.  Read the
O'reilly book
"Practical Unix and Internet Security", it has lot's of good info.

Scott

 
 
 

about hacking

Post by Bill Vermilli » Thu, 25 Jan 2001 13:03:24






>> > In one of the messages about automaticly rebooting I noticed someone was
>> > talking about hacking so I started to wonder.. how can you tell if your
>> > system is hacked?  Which logs can provide information etc..

>> First, you can set this option

>> log_in_vain="YES"               # YES to log connects to ports w/o
>> listeners.
>> in /etc/rc.conf. Then, all failed connection attempts to your
>> box will be logged via syslogd, so the output will show up in
>> /var/log/messages.
>Just to be pedantic, I'd like to point out that this technique (and
>many others, such as verbose TCP wrappers, firewall logging,
>honeypots, and so on) will give you information on people who tried
>and *failed* to contact your system (often, but not remotely always,
>implying a hack attempt), but may well not show anything if a hack
>attempt succeeded.  
>Any kind of logs that are kept on the machine under attack can be
>cleaned up afterwards.

Take a look at init 8 and the secure levels. Then set the log files
to be append only with chflags. The way I read it you can do a
pretty good job of keeping the files intact. Am I missing something.

Quote:>Logging to another machine (or, say, a hard-copy printer) is the
>only way to be remotely sure you get that information. Other than
>that, the only thing I can think of is trusted checksums of key
>files; Tripwire does this, and with enough preparation you could do
>the same with mtree.

Whats wrong with TCT - The Coroners Toolkit.  You can turn it loose
and get MD5 checksums on ever file in the system if you want, or
aren't careful :-)  I was amazed by the volume of information.

Using "lazarus" to resurect erased files - or portions of them -
was quite insightful too.

Bill
--

 
 
 

about hacking

Post by Dinesh Nai » Thu, 25 Jan 2001 15:31:39



> Whats wrong with TCT - The Coroners Toolkit.  You can turn it loose
> and get MD5 checksums on ever file in the system if you want, or
[..snipped..]
> Using "lazarus" to resurect erased files - or portions of them -
> was quite insightful too.

half the problem of being away from the edge for 18 months, is that you still do
things the same old way, totally oblivious of new tools which have made it oh so
much easier. thanks, bill.

--
Regards,                           /\_/\   "All dogs go to heaven."

+==========================----oOO--(_)--OOo----============================+
| for a in past present future; do                                          |
|   for b in clients employers associates relatives neighbours pets; do     |
|   echo "The opinions here in no way reflect the opinions of my $a $b."    |
| done; done                                                                |
+===========================================================================+
   http://pgp.ai.mit.edu/htbin/pks-extract-key.pl?op=get&search=0x230096E9

 
 
 

about hacking

Post by Daniel Rud » Fri, 26 Jan 2001 17:47:13





> > > In one of the messages about automaticly rebooting I noticed someone was
> > > talking about hacking so I started to wonder.. how can you tell if your
> > > system is hacked?  Which logs can provide information etc..

> > First, you can set this option

> > log_in_vain="YES"               # YES to log connects to ports w/o
> > listeners.

> > in /etc/rc.conf.  Then, all failed connection attempts to your box will
> > be logged via syslogd, so the output will show up in /var/log/messages.

> Just to be pedantic, I'd like to point out that this technique (and
> many others, such as verbose TCP wrappers, firewall logging,
> honeypots, and so on) will give you information on people who tried
> and *failed* to contact your system (often, but not remotely always,
> implying a hack attempt), but may well not show anything if a hack
> attempt succeeded.

> Any kind of logs that are kept on the machine under attack can be
> cleaned up afterwards.  Logging to another machine (or, say, a
> hard-copy printer) is the only way to be remotely sure you get that
> information.  Other than that, the only thing I can think of is
> trusted checksums of key files; Tripwire does this, and with enough
> preparation you could do the same with mtree.

> That said, Donn Miller's advice is still the first way to go (although
> I prefer using ipfw logging, to the same purpose, because it makes it
> easier for me to be selective, and also because the firewall is a
> fairly easy way to tighten down the machine anyway).  The reason for
> this is that detecting *failed* attacks is one of the best ways to stop
> *successful* ones.  So it's not exactly the answer to what the original
> poster asked, but it's the best advice to give him (?) anyway.

>  - Lowell Gilbert
> --
> "Computers make it easier to do a lot of things, but most of the things
> they make it easier to do don't need to be done."
>                 -- Andy Rooney

Unix and clones has several lines of defense.  One is the last login
message that is displayed everytime you login to the system.  If it
shows that you last logged in at 3am when you were asleep during that
time, and you are the only one with the password, root or otherwise, you
had better go check it out.  If you are root on the system, then check
user home directories for files and directories that start with .. or
... (other than the legitimate ..) because that is an indication that
someone is trying to hide something.  One of the things that I like
about FreeBSD is that during the nightly maintenance, you get emails
about what accounts that have been added or removed.  If you see an
account that has been added and you didn't do it, and you are the only
one who can, then you know two things - 1.  Someone was INSIDE your box
and 2 - They gained root access.  Also watch user profiles.  If you see
Joe the Accountant who has trouble powering up his WindowsNT box in a
telnet session from a host in Puto Rico issuing commands like a pro,
then you need to look into it.  Using John the Accountant again, if you
see john logged in from his computer across the hall, and see him again
logged in from Austrailia, guess what?  You've been cracked.  Another
good indication is the shell history file.  If you see the file has been
truncated to a number of entries that is less than the system max and
the user is a unix pro with telnet, check it out.  If you find that the
history file is linked to /dev/null, then you really do have a problem.
A big problem.  This means that commands are not being recorded.  This
is a clear sign that someone was INSIDE your box.  Assuming that root
access hasn't been broken yet, start checking logs.  If root access has
been broken, you may or may not be able to find it.  If a root kit was
installed, then various commands such as ls, top, ps, login, su, as well
as others may have been replaced with hacked versions that log their use
to a file.  Imagine yourself using a hacked version of su when you su to
root.  The root password gets logged into a file.  If the hacker
downloads that file later, guess what?  You have just given him/her the
keys to your system.  Also try to use ssh whenever possible.  You never
know when a sniffer has been installed on a machine that is watching and
recording network traffic.  This requires promiscuous mode so compile
you FreeBSD kernel without the psudo-device bpf.  Speaking of compilers,
remove all source code and compilers from any system that is directly
connected to the internet.  Many times, a hacker will load source code
onto a machine and compile and run said program remotely.  Some root
kits are installed as easily as make and make install when you unzip and
untar the files.  A book that I would advise that any system
administrator to read is Maximum Linux Security.  It was written by an
anonymous hacker who was busted and is now reformed.  The ISBN is
0-672-31670-6 by SAMS publishing.  Needless to say, this book was a real
eye-opener for me.

Hope this Helps.

--
Daniel Rudy

Remove "0123456789." and ".invalid" to reply.
Please reply to dcrudy at aol dot com.

 
 
 

1. how can i stop hacks?

1) Start using a fire wall...
2) go into /etc/inetd.conf and comment out all services you
don't absolutely need.
3) since the connects are from someone one your own subnet (rr.com)
email the postmaster (or it could be rr.com doing security scans)



2. xmodmap

3. Logs Lost....Hacked? Or syslogd crapped out?

4. DHCP and ip assigning

5. Hack Attacks to my Servers!

6. Getting an error when using ifconfig to add an IP alias.

7. I've been hacked - now what?

8. vi FAQ, where to get it.

9. About the hack execve system call.....?

10. Have I been Hacked?

11. hacking routers

12. Hacked via imapd

13. Strange packet log: hacked?