Question About Sys/Sec Logs
In my syslog (via Yast) I found the following entries: (020405B401010402) Mar 14 08:04:42 luke kernel: SFW2-INext-ACC-TCP IN=dsl0 OUT= MAC= SRC=218.153.147.92 DST=67.35.166.180 LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=41916 DF PROTO=TCP SPT=34654 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A032FB2830000000001030300) Mar 14 08:04:44 luke sshd[26285]: Invalid user test from ::ffff:218.153.147.92 Mar 14 08:04:45 luke kernel: SFW2-INext-ACC-TCP IN=dsl0 OUT= MAC= SRC=218.153.147.92 DST=67.35.166.180 LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=27312 DF PROTO=TCP SPT=34740 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A032FB3A50000000001030300) Mar 14 08:04:46 luke sshd[26287]: Invalid user guest from ::ffff:218.153.147.92 Mar 14 08:04:47 luke kernel: SFW2-INext-ACC-TCP IN=dsl0 OUT= MAC= SRC=218.153.147.92 DST=67.35.166.180 LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=61758 DF PROTO=TCP SPT=34796 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A032FB47A0000000001030300) Mar 14 08:04:49 luke sshd[26289]: Invalid user admin from ::ffff:218.153.147.92 Mar 14 08:04:49 luke kernel: SFW2-INext-ACC-TCP IN=dsl0 OUT= MAC= SRC=218.153.147.92 DST=67.35.166.180 LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=34621 DF PROTO=TCP SPT=34842 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A032FB54B0000000001030300) Mar 14 08:04:51 luke sshd[26291]: Invalid user admin from ::ffff:218.153.147.92 Mar 14 08:04:51 luke kernel: SFW2-INext-ACC-TCP IN=dsl0 OUT= MAC= SRC=218.153.147.92 DST=67.35.166.180 LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=17521 DF PROTO=TCP SPT=34909 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A032FB61C0000000001030300) Mar 14 08:04:53 luke sshd[26293]: Invalid user user from ::ffff:218.153.147.92 Mar 14 08:05:01 luke sshd[26301]: Invalid user test from ::ffff:218.153.147.92 Mar 14 08:08:20 luke kernel: SFW2-INext-DROP-DEFLT IN=dsl0 OUT= MAC= SRC=219.128.154.132 DST=67.35.166.180 LEN=48 TOS=0x00 PREC=0x00 TTL=112 ID=40245 DF PROTO=TCP SPT=3984 DPT=9898 WINDOW=65044 RES=0x00 SYN URGP=0 OPT (0204058601010402) Mar 14 08:19:59 luke kernel: SFW2-INext-DROP-DEFLT IN=dsl0 OUT= MAC= SRC=218.83.155.77 DST=67.35.166.180 LEN=364 TOS=0x00 PREC=0x00 TTL=51 ID=0 DF PROTO=UDP SPT=49964 DPT=1026 LEN=344 Mar 14 08:41:56 luke kernel: SFW2-INext-DROP-DEFLT IN=dsl0 OUT= MAC= SRC=222.88.173.5 DST=67.35.166.180 LEN=681 TOS=0x00 PREC=0x00 TTL=111 ID=62714 PROTO=UDP SPT=17219 DPT=1026 LEN=661 Mar 14 08:51:43 luke kernel: SFW2-INext-DROP-DEFLT IN=dsl0 OUT= MAC= SRC=12.6.153.198 DST=67.35.166.180 LEN=908 TOS=0x00 PREC=0x00 TTL=116 ID=13705 PROTO=UDP SPT=29582 DPT=1028 LEN=888 It appears that someone was trying to login on my system while it was connected to the 'Net. My real question is whether this indicates my defenses are working, or should I be looking elsewhere for that confirmation. There is no other activity recorded until 12:46 and I have not noticed any problems with my system. However, I also understand that wiley crackers will attempt to make themselves invisible and cover their tracks. I'm not wiley enough yet to get the really wiley ones. ;) I'm not in a state of panic, but do feel I need to spend more time understanding and applying the security monitoring stuff. Is this where Snort would be useful? Thanks for your input. Don -- evangelinux GNU Evangelist http://matheteuo.org/ http://chaddb.sourceforge.net/ "Free software is like God's love - you can share it with anyone anytime anywhere."
On Monday 14 March 2005 1:33 pm, Don Parris wrote:
In my syslog (via Yast) I found the following entries:
Mar 14 08:04:44 luke sshd[26285]: Invalid user test from ::ffff:218.153.147.92 Mar 14 08:04:45 luke kernel: SFW2-INext-ACC-TCP IN=dsl0 OUT= MAC= SRC=218.153.147.92 DST=67.35.166.180 LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=27312 DF PROTO=TCP SPT=34740 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A032FB3A50000000001030300) snip Mar 14 08:51:43 luke kernel: SFW2-INext-DROP-DEFLT IN=dsl0 OUT= MAC= SRC=12.6.153.198 DST=67.35.166.180 LEN=908 TOS=0x00 PREC=0x00 TTL=116 ID=13705 PROTO=UDP SPT=29582 DPT=1028 LEN=888 snip
It appears that someone was trying to login on my system while it was connected to the 'Net. My real question is whether this indicates my defenses are working, or should I be looking elsewhere for that confirmation. There is no other activity recorded until 12:46 and I have not noticed any problems with my system.
However, I also understand that wiley crackers will attempt to make themselves invisible and cover their tracks. I'm not wiley enough yet to get the really wiley ones. ;) I'm not in a state of panic, but do feel I need to spend more time understanding and applying the security monitoring stuff. Is this where Snort would be useful? Thanks for your input.
Don
The first is a probe of your port 22 for ssh looking for generic/common login IDs. I believe its an automated bot. If one or more of those names responded then they may be back with a password crack attempt. Make sure you have 'PermitRootLogin no' in /etc/ssh/sshd_config. Then consider changing from port 22 to something above 1024 and don't tell anybody that doesn't need to know. Closing (or not having anything listening on) port 22 eliminated those probes for me. The last example I'm not sure about since I don't recognize that one and await an answer from someone else on the list. Patrick Shanahan keeps us informed of updates on suse-linux-e of - rkhunter -1.2.1-1.noarch.rpm is available for download: http://wahoo.no-ip.org/~pat/rkhunter-1.2.1-1.noarch.rpm http://wahoo.no-ip.org/~pat/rkhunter-1.2.1-1.src.rpm http://wahoo.no-ip.org/~pat/rkhunter-1.2.1.tar.gz This can keep you informed IF a rootkit is found. Doesn't prevent them. Stan
Hi Don,
IDs. I believe its an automated bot. If one or more of those names responded then they may be back with a password crack attempt. They will be back!!!
connected to the 'Net. My real question is whether this indicates my defenses are working, or should I be looking elsewhere for that The question if your defense is working is hard to say. Your log only shows that someone was trying to connect to you system. For example: If your are protecting that service from the outside, guess then your defense is not working.
Changing sshd to another port doesn't really give security. A portscan will show the open ports. You should STOP all services not needed if your on the internet. If you (or anyone) don't need to work over the net on your machine then you can stop sshd. An intrusion detection system like AIDE helps to figure out if people gained access to your system. Ulf -- Real Users find the one combination of bizarre input values that shuts down the system for days.
The Monday 2005-03-14 at 14:33 -0500, Don Parris wrote:
In my syslog (via Yast) I found the following entries:
(020405B401010402) Mar 14 08:04:42 luke kernel: SFW2-INext-ACC-TCP IN=dsl0 OUT= MAC= SRC=218.153.147.92 DST=67.35.166.180 LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=41916 DF PROTO=TCP SPT=34654 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A032FB2830000000001030300) Mar 14 08:04:44 luke sshd[26285]: Invalid user test from ::ffff:218.153.147.92 Mar 14 08:04:45 luke kernel: SFW2-INext-ACC-TCP IN=dsl0 OUT= MAC= SRC=218.153.147.92 DST=67.35.166.180 LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=27312 DF PROTO=TCP SPT=34740 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 OPT
It is a known attempt to login into your machine, probably automated, trying to learn first if certain common user names do exist in your machine: test, guest, admin, user, etc. Then, if they think that such a user name exists, they will try to guess the password. Your system rejected those attempts. It seems they learn of the existence of those users because the sshd daemon answers with different delays depending on the user name existence. This was solved by a patch, reported in suse-security-announce on 18 Feb 2005: - openssh information leak Openssh as shipped with SUSE Linux allows a possible timing attack that could be abused remotely to determine existing users on the system by watching replies to failed password attempts. This is tracked by the Mitre CVE ID CAN-2003-0190. Additionally the output of failing PAM sessions will now be displayed and the terminal-setting for aborted login-sessions will get restored correctly. This bugfix was released for SUSE Linux 9.1, 9.2 and SUSE Linux Enterprise Server 9. -- Cheers, Carlos Robinson
participants (4)
-
Carlos E. R.
-
Don Parris
-
Stan Glasoe
-
u.rasch@seppelec.com