Host denied: sshd from 43.255.189.72(unknown)-43.255.189.72
Hi This is a strange problem as it is on a machine behind a DMZ and "chained" FIREWALL (CentOS). I have a "/etc/hosts.deny" that has following line: ALL : ALL : spawn ( /usr/sbin/safe_finger -l @%h | /usr/bin/Mail -s "THE_HOSTNAME\: Host denied\: %d from %c(%u)-%h" some@domain.com) & which delivers following email every random minutes: THE_HOSTNAME: Host denied: sshd from 43.255.189.72(unknown)-43.255.189.72 Normally it would not bother me, but the fact this machine is behind a DMZ and a FIREWALL makes this "interesting". I, too, know the machine (and network) in question are quite wellknown ;-) Now the thing is that "hosts.deny" sits before I can see the traffic with tcpdump/ngrep/iptraf, so this makes it a little harder to debug. This is what I know: - only I have shell access (passwd file is full of /bin/false and /bin/nologin) and it's ONLY via keys. - rkhunter, chkrootkit and so on have no warnings - the machines sendmail has clamav attached - external firewall disallows access to that machine (only from internal network) - external firewall blocks the entire network of 43.0.0.0/24 - the machine is my Samba Server - the machine is fully up to date and rebooted - it is my webdevelopment server for some domains - it has some internal webserver tasks - I have turned off ALL internal devices that could be hacked (nas drives, wifi, etc) - the messages come up even if NO workstation is on - external ssh is firewalled I have tried all the standard utils (tcpump,lsof,fuser,netstat and so on) but this one has me baffled. Any ideas anyone? Jobst -- Howard's conjecture: The total dinner check of a party eating dutch will never equal the total of what each diner admits to having eaten. | |0| | Jobst Schmalenbach, jobst@barrett.com.au, General Manager | | |0| Barrett Consulting Group P/L & The Meditation Room P/L |0|0|0| +61 3 9532 7677, POBox 277, Caulfield South, 3162, Australia
On Wed, 1 Jul 2015 12:41:10 PM Jobst Schmalenbach wrote:
Now the thing is that "hosts.deny" sits before I can see the traffic with tcpdump/ngrep/iptraf, so this makes it a little harder to debug.
No, you should still the initial 3 way handshake (SYN, SYN+ACK, ACK) as that's required to set up the connection that tcp_wrappers is reacting to. Worth capturing traffic with: tshark -w /root/bad-ssh.pcap -i any host 43.255.189.72 The "any" interface is a pseudo interface that will capture traffic coming in on any interface, just in case it's arriving over an unexpected one (a tunnel for instance). Then once you've seen a couple of those deny messages ^C it and read it back with: tshark -r /root/bad-ssh.pcap
- external firewall blocks the entire network of 43.0.0.0/24
Was that meant to be 43.0.0.0/8 instead? It won't match the IP in question otherwise (though I realise that you have other rules that should be blocking the traffic in question). Good luck! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
On Wed, Jul 01, 2015 at 07:34:17PM +1000, Chris Samuel (chris@csamuel.org) wrote:
On Wed, 1 Jul 2015 12:41:10 PM Jobst Schmalenbach wrote:
- external firewall blocks the entire network of 43.0.0.0/24
Was that meant to be 43.0.0.0/8 instead? It won't match the IP in question otherwise (though I realise that you have other rules that should be blocking the traffic in question).
I made a mistake in the email - yes it is 8 in the rule table. I will try your other suggestions ... thanks Jobst -- The computer is your friend. It never argues until Gates squeezed Chilly through the CDROM door! | |0| | Jobst Schmalenbach, jobst@barrett.com.au, General Manager | | |0| Barrett Consulting Group P/L & The Meditation Room P/L |0|0|0| +61 3 9532 7677, POBox 277, Caulfield South, 3162, Australia
participants (2)
-
Chris Samuel -
Jobst Schmalenbach