Dear All,

Tahnks to all you guys for immediate reply by the way i jus hav modified the firewall by explicitly specifiying a rule to block ssh traffic from outside

i will wait for sometime and check the log again

thnaks again guys apprecite your replies

Regards

Fabian

2009/6/19 Cisco-Education fabian@baladia.gov.kw:

...

Dear All,

I have the following setup running perfectly OK for a long time

CentOS release 5 (Final) sendmail-8.13.8-2.el5 MailScanner 4.76.25 bind-9.3.4-6.0.3.P1.el5_2

now i jus setup a centos box running BackupPC for backing up my my above mail server using ssh as per the instructions in backup pc site i had to enable sshd so i did it and everthing works perfect and backup works great as per my requirement

but i notice that when i do a

tail -f /var/log/secure

i see the followin very often

Jun 19 16:26:06 kmdns1 sshd[11073]: Invalid user jeka from 87.118.122.78 Jun 19 16:26:06 kmdns1 sshd[11074]: input_userauth_request: invalid user jeka Jun 19 16:26:06 kmdns1 sshd[11074]: Received disconnect from 87.118.122.78: 11: Bye Bye

...

Now both the Mail server and the backup pc server behind firewall and ssh protocol is denied to the hosts in the DMZ zone

jus wondering how a outside user could try to ssh to my mail server. if i stop the sshd daemon i dont see any messages in my secure log file

apprecite your addvice and help

regards

Fabian

Most likely answer -- your FW is not actually blocking ssh connections to the servers from outside the DMZ. The source of the traffic is a routable address, if it doesn't match your ip space then your FW isn't working correctly.

Brian _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

Linux Advocate wrote:

...

...

[Normal log stuff from dictionary attack deleted...]

This is common, and, presuming you have good passwords or only accept authorized_keys, not a real problem other than large log files.

Look at fail2ban for a method that will automatically add iptables blocks when this occurs.

yes fail2ban is very useful. but also good to change to a non standard port.

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Another quick security addition is deny root logins via ssh and also only allow from certain users. That way, they can brute-force all day and will keep getting denied.

in /etc/ssh/sshd_config, edit the following two parameters:

PermitRootLogin no AllowUsers johnny numberfive@192.168.10.*

So, root cannot directly login, if this is feasible for your environment. And also on this machine, johnny can login from anywhere but the user 'numberfive' can only login from a 192.168.10.x address.

I agree with the other users, fail2ban and others (I use DenyHosts for ssh) are excellent. You can use configure these applications to add the remote users' IP addresses into hosts.deny or even IPtables. Even further, you can have IP addresses that attempt to log in as root get blocked immediately and have attempts to other users get blocked after 3 or 5 attempts, whatever you are comfortable with.

Changing the default port to something other than 22 also works wonders to sidestep bruteforce attempts. Take a look at the output of the following command:

utmpdump /var/log/wtmp

You will see all the attempts to login to your machine, locally and remotely. If you were to change the ssh listen port to something other than 22, close to all the brute force goes away. (damn script kiddies) Going with authorized_keys only for logins eliminates password brute-force attempts altogether.

Take these and the other users' recommendations as part of your defense-in-depth approach, along with revising the firewall ssh rules for your DMZ.

Hope this helps, Giovanni

On Sun, 21 Jun 2009 00:17:30 +0300 (AST) fabian wrote:

The problem was solved after using a non standard port for ssh.

You haven't solved the problem, because you haven't solved this problem:

but wonder how it was gettin through my firewall

You should be finding this out. Traffic of unknown origin is a bad thing.