[opensuse] More dictionary attacks
Just when I thought it might have been over <frown> First, China, then France and now Iran..... First things first: My SysConfig settings that I ended up with from the first thread that actually got into IPTABLES Sysconfig settings:FW_SERVICES_ACCEPT_EXT 0/0,tcp,22,,hitcount=3,blockseconds=120,recentname=badssh Next the output from 'iptables -L |less' showing that the 'recent' feature of iptables *is* implemented (this is in all of my machines which are either 10.2 or 10.3A5 SUSE) LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:ssh state NEW recent: CHECK seconds: 120 hit_count: 3 name: badssh side: source LOG level warning tcp-options ip-options prefix `SFW2-INext-DROPr ' DROP tcp -- anywhere anywhere tcp dpt:ssh state NEW recent: UPDATE seconds: 120 hit_count: 3 TTL-Match name: badssh side: source LOG tcp -- anywhere anywhere tcp dpt:ssh state NEW limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix `SFW2-INext-ACC ' ACCEPT tcp -- anywhere anywhere tcp dpt:ssh state NEW recent: SET name: badssh side: source ACCEPT tcp -- anywhere anywhere tcp dpt:ssh A few hours after this 'protection' was installed, IRAN knocked with an hour or so of multiiple machine probing.... Log entries with this in place: Jul 17 22:09:54 ASUS sshd[18491]: Invalid user pgsql from 217.11.27.19 Jul 17 22:09:59 ASUS sshd[18495]: Invalid user adm from 217.11.27.19 Jul 17 22:10:02 ASUS sshd[18497]: Invalid user ident from 217.11.27.19 Jul 17 22:10:04 ASUS sshd[18499]: Invalid user webpop from 217.11.27.19 Jul 17 22:10:07 ASUS sshd[18501]: Invalid user susan from 217.11.27.19 Jul 17 22:10:09 ASUS sshd[18503]: Invalid user sunny from 217.11.27.19 Jul 17 22:10:12 ASUS sshd[18505]: Invalid user steven from 217.11.27.19 Jul 17 22:10:15 ASUS sshd[18507]: Invalid user ssh from 217.11.27.19 Jul 17 22:10:17 ASUS sshd[18509]: Invalid user search from 217.11.27.19 Jul 17 22:10:20 ASUS sshd[18511]: Invalid user sara from 217.11.27.19 Jul 17 22:10:22 ASUS sshd[18513]: Invalid user robert from 217.11.27.19 whois 217.11.27.19 % Information related to '217.11.27.0 - 217.11.27.127' inetnum: 217.11.27.0 - 217.11.27.127 netname: Shahrdari descr: Wireless Link country: IR admin-c: CUS200-RIPE tech-c: CUS200-RIPE status: ASSIGNED PA mnt-by: AFRA-MNT-NESH-1 mnt-lower: AFRA-MNT-NESH-1 mnt-routes: AFRA-MNT-NESH-1 source: RIPE # Filtered person: Afra Customer address: No. 20 . , Beheshti Ave. , Tehran, Iran I managed to turn on WIRESHARK ... a newer invocation of ETHEREAL and captured a portion of the interaction between my 10.3a5 machine and my "guest". Of interest to me was the fact that the incoming SRC port kept changing from time to time...this exerpt starts with a reply from me to them from port 22 to port 38381 in answer to a previous frame....my machine name is ASUS in this exchange and his apparently reverse lookups to NETOPIA despite the whois info above for the IP provided by the header info. Exerpt from Wireshark showing port changes during this time: Frame 20 (134 bytes on wire, 134 bytes captured) Ethernet II, Src: 00:1a:92:b9:c3:21 (00:1a:92:b9:c3:21), Dst: Netopia_54:7e:0c (00:0f:cc:54:7e:0c) Internet Protocol, Src: ASUS.ricreig.com (70.46.31.229), Dst: 217.11.27.19 (217.11.27.19) Transmission Control Protocol, Src Port: ssh (22), Dst Port: 38381 (38381), Seq: 1281, Ack: 469, Len: 68 SSH Protocol No. Time Source Destination Protocol Info 21 2.609922 217.11.27.19 ASUS.ricreig.com SSHv2 Encrypted request packet len=52 Frame 21 (118 bytes on wire, 118 bytes captured) Ethernet II, Src: Netopia_54:7e:0c (00:0f:cc:54:7e:0c), Dst: 00:1a:92:b9:c3:21 (00:1a:92:b9:c3:21) Internet Protocol, Src: 217.11.27.19 (217.11.27.19), Dst: ASUS.ricreig.com (70.46.31.229) Transmission Control Protocol, Src Port: 38381 (38381), Dst Port: ssh (22), Seq: 469, Ack: 1349, Len: 52 SSH Protocol No. Time Source Destination Protocol Info 22 2.610377 217.11.27.19 ASUS.ricreig.com TCP 38381 > ssh [FIN, ACK] Seq=521 Ack=1349 Win=8816 Len=0 TSV=3091501397 TSER=89777291 Frame 22 (66 bytes on wire, 66 bytes captured) Ethernet II, Src: Netopia_54:7e:0c (00:0f:cc:54:7e:0c), Dst: 00:1a:92:b9:c3:21 (00:1a:92:b9:c3:21) Internet Protocol, Src: 217.11.27.19 (217.11.27.19), Dst: ASUS.ricreig.com (70.46.31.229) Transmission Control Protocol, Src Port: 38381 (38381), Dst Port: ssh (22), Seq: 521, Ack: 1349, Len: 0 No. Time Source Destination Protocol Info 23 2.610526 ASUS.ricreig.com 217.11.27.19 TCP ssh > 38381 [FIN, ACK] Seq=1349 Ack=522 Win=7936 Len=0 TSV=89777367 TSER=3091501397 Frame 23 (66 bytes on wire, 66 bytes captured) Ethernet II, Src: 00:1a:92:b9:c3:21 (00:1a:92:b9:c3:21), Dst: Netopia_54:7e:0c (00:0f:cc:54:7e:0c) Internet Protocol, Src: ASUS.ricreig.com (70.46.31.229), Dst: 217.11.27.19 (217.11.27.19) Transmission Control Protocol, Src Port: ssh (22), Dst Port: 38381 (38381), Seq: 1349, Ack: 522, Len: 0 No. Time Source Destination Protocol Info 24 2.611140 217.11.27.19 ASUS.ricreig.com TCP 38484 > ssh [SYN] Seq=0 Len=0 MSS=1408 TSV=3091501397 TSER=0 WS=2 Frame 24 (74 bytes on wire, 74 bytes captured) Ethernet II, Src: Netopia_54:7e:0c (00:0f:cc:54:7e:0c), Dst: 00:1a:92:b9:c3:21 (00:1a:92:b9:c3:21) Internet Protocol, Src: 217.11.27.19 (217.11.27.19), Dst: ASUS.ricreig.com (70.46.31.229) Transmission Control Protocol, Src Port: 38484 (38484), Dst Port: ssh (22), Seq: 0, Len: 0 No. Time Source Destination Protocol Info 25 2.611234 ASUS.ricreig.com 217.11.27.19 TCP ssh > 38484 [SYN, ACK] Seq=0 Ack=1 Win=741376 Len=0 MSS=1460 TSV=89777367 TSER=3091501397 WS=7 Frame 25 (74 bytes on wire, 74 bytes captured) Ethernet II, Src: 00:1a:92:b9:c3:21 (00:1a:92:b9:c3:21), Dst: Netopia_54:7e:0c (00:0f:cc:54:7e:0c) Internet Protocol, Src: ASUS.ricreig.com (70.46.31.229), Dst: 217.11.27.19 (217.11.27.19) Transmission Control Protocol, Src Port: ssh (22), Dst Port: 38484 (38484), Seq: 0, Ack: 1, Len: 0 No. Time Source Destination Protocol Info 26 2.911702 217.11.27.19 ASUS.ricreig.com TCP 38381 > ssh [ACK] Seq=522 Ack=1350 Win=8816 Len=0 TSV=3091501699 TSER=89777367 Frame 26 (66 bytes on wire, 66 bytes captured) Ethernet II, Src: Netopia_54:7e:0c (00:0f:cc:54:7e:0c), Dst: 00:1a:92:b9:c3:21 (00:1a:92:b9:c3:21) Internet Protocol, Src: 217.11.27.19 (217.11.27.19), Dst: ASUS.ricreig.com (70.46.31.229) Transmission Control Protocol, Src Port: 38381 (38381), Dst Port: ssh (22), Seq: 522, Ack: 1350, Len: 0 So, Something isn't working still...on multiple machines despite the 'recent' function in IPTABLES on stable and alpha versions of SUSE and the firewall isn't apparently stopping the attack because the log entry suggests the SSHD is logging the attack, not the firewall. I'll be honest, I am out of my league when it comes to this type of a problem and I appreciate any help you guys and gals can provide. I also appreciate all of the help that has already been provided. I know I am not the only one with this problem so if success does show its' ugly face around here, I'm sure a lot of hackers around the world will be disappointed because I will spread the word to all of you that care to listen. Richard -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wed, Jul 18, 2007 at 06:15:16AM -0400, Richard Creighton wrote:
Just when I thought it might have been over <frown>
First, China, then France and now Iran.....
First things first: My SysConfig settings that I ended up with from the first thread that actually got into IPTABLES
This is a SSH worm. The origin is pretty irrelevant. Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Marcus Meissner wrote:
On Wed, Jul 18, 2007 at 06:15:16AM -0400, Richard Creighton wrote:
Just when I thought it might have been over <frown>
First, China, then France and now Iran.....
First things first: My SysConfig settings that I ended up with from the first thread that actually got into IPTABLES
This is a SSH worm. The origin is pretty irrelevant.
Ciao, Marcus
OK, I'll bite...what worm and what can I do about it? ....and where is it coming from....from one of my systems (all Linux) or one of the destination IP's.... What defenses will work? Richard -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wed, Jul 18, 2007 at 07:05:44AM -0400, Richard Creighton wrote:
Marcus Meissner wrote:
On Wed, Jul 18, 2007 at 06:15:16AM -0400, Richard Creighton wrote:
Just when I thought it might have been over <frown>
First, China, then France and now Iran.....
First things first: My SysConfig settings that I ended up with from the first thread that actually got into IPTABLES
This is a SSH worm. The origin is pretty irrelevant.
Ciao, Marcus
OK, I'll bite...what worm and what can I do about it? ....and where is it coming from....from one of my systems (all Linux) or one of the destination IP's.... What defenses will work?
Well, it tries to break into your system, but is very likely not in any of your machines if you only see external ips. Since it / they have infected thousands of machines in the internet already you will see their scans from there. Good passwords, having SSH on a different port, or even disabling ssh from the outside are good help. Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Marcus Meissner wrote:
<snip>
OK, I'll bite...what worm and what can I do about it? ....and where is it coming from....from one of my systems (all Linux) or one of the destination IP's.... What defenses will work?
Well, it tries to break into your system, but is very likely not in any of your machines if you only see external ips.
So far, only external IP's, so that is good.
Since it / they have infected thousands of machines in the internet already you will see their scans from there.
So the trick is to recognize the attacks and *temporarily* ban that IP address from further access. Then, after the attack, to reinstate the IP. This is what I *thought* that the entry in IPTABLES was going to do, but obviously, it doesn't in my case. However, others have suggested it should work, so I figure something is still left undone in my configuration, which is what prompted my rather long original post, which I would be happy to send as a file to anyone that requests it via E-Mail rather than tying up this forum additionally.
Good passwords, having SSH on a different port, or even disabling ssh from the outside are good help.
I believe the reason I have not been compromised, only 'annoyed', so far, is because I do have good account AND password schemes in effect, but the best practice is to prevent the person with the axe from using in against the door in the first place, no matter if the door is made of iron or balsa wood, don't you think? Now, previously, I have stated it is impractical for me to change to a non-standard ssh port due to the number of outside systems I support that are NOT part of my network. I am a consultant (not for Linux security, unfortunately) and while I am trying desperately to educate the 'unwashed masses' to vacate Windoze, many do still use that so-called OS and some even may be infected with all kinds of evil virus and wormy critters that my systems so far have resisted. Previously, I tried 'fail2ban' and while it ran, it failed to detect any attacks. I thought I had correctly installed it, but obviously I had not and disabled it when I "discovered" the 'recent' feature of iptables, pointed out to me by several members of this forum. IPTABLES appears to support this feature, it shows up in the iptables -L printout but Wireshark shows it is not being effective against whatever is attacking. Thus, I probably will need to re-try fail2ban unless you or others have additional thoughts on the IPTABLES solution, which would be my first choice, if it could be made to work. Thanks Richard
Ciao, Marcus
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Richard Creighton wrote:
resisted. Previously, I tried 'fail2ban' and while it ran, it failed to detect any attacks. I thought I had correctly installed it, but obviously I had not and disabled it when I "discovered" the 'recent' feature of iptables, pointed out to me by several members of this forum. IPTABLES appears to support this feature, it shows up in the iptables -L printout but Wireshark shows it is not being effective against whatever is attacking. Thus, I probably will need to re-try fail2ban unless you or others have additional thoughts on the IPTABLES solution, which would be my first choice, if it could be made to work.
I have not tried fail2ban yet, but I'm running denyhosts on one of my boxes and it works really great. Even managed to get myself blacklisted when my muscle memory got out of sync while switching back and forth between UK and US keyboards. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Richard, Try to congigure your router, actually ban intruders IP in router., if possible depends on manufacture. This wil save you a lot of time and it's much more relaible. Kind regards, Zoran On Wednesday 18 July 2007 14:35, koffiejunkie Schreef:
Richard Creighton wrote:
resisted. Previously, I tried 'fail2ban' and while it ran, it failed to detect any attacks. I thought I had correctly installed it, but obviously I had not and disabled it when I "discovered" the 'recent' feature of iptables, pointed out to me by several members of this forum. IPTABLES appears to support this feature, it shows up in the iptables -L printout but Wireshark shows it is not being effective against whatever is attacking. Thus, I probably will need to re-try fail2ban unless you or others have additional thoughts on the IPTABLES solution, which would be my first choice, if it could be made to work.
I have not tried fail2ban yet, but I'm running denyhosts on one of my boxes and it works really great. Even managed to get myself blacklisted when my muscle memory got out of sync while switching back and forth between UK and US keyboards. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
zoran wrote:
Richard,
Try to congigure your router, actually ban intruders IP in router., if possible depends on manufacture. This wil save you a lot of time and it's much more relaible.
Kind regards, Zoran <snip>
I feel this is probably impractical simply because the IP of the attacker never repeats so every attack would be from an IP that is not in the list. What I need is a DYNAMICly created list, which is what I thought the 'recent' feature of iptables was supposed to do. I still haven't given up hope that this worm (if that is what it is) is stoppable using this feature but it appears to come in from a different IP *and* a different PORT each attack, making it hard to trap until the attack actually starts. In fact, the port changes *during* the attack. So far, I have not seen anything I can get my teeth into but the router seems to be too low a level to detect/trap this beast. Richard -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (4)
-
koffiejunkie -
Marcus Meissner -
Richard Creighton -
zoran