Brouteforce attack detection at port 22?

[kach]

In regular Linux OS I can detected ssh brouteforce attack by:

vi /var/log/auth.log

But, in ESX I can see auth.log. Is there any place I can do the same thing?

What are the best solution to prevent these kind of attack without closing port 22?

[Rumple]

One of the best ways to mitigate an attack against the service console is to create a management network and use ACL's to prevent access to the management vlan without a vpn connection or being on specific machine/network.

That is the best practice for any management network. Since the service console is based upon Red Hat AS 3 or something it should have the same functional capabilities for ssh logging. Its probably just not been enabled.

[RParker]

Incorrect. The service console is NOT based on red hat. The only thing that is based on red hat inside ESX is the boot loader. The service console is passing commands to the ESX kernel which EMULATES red hat commands, that's it.

So it's not red hat at all, which is one reason they are dumping it in 3.5, they don't need red hat anymore. The service console loads as a separate process once the red hat boot loader is started, after that it runs as a very small program.

[larstr]

I think you're causing some confuzion here now, RParker. The Service Console is indeed based on RHEL3. How would you otherwise explain the following sequence:

$ cat /etc/redhat-release

Red Hat Enterprise Linux ES release 3 (Taroon)

$

$ rpm -qa|grep -i RHEL

shadow-utils-4.0.3-26.RHEL3

logrotate-3.6.9-2.RHEL3

tar-1.13.25-15.RHEL3

man-1.5k-13.rhel3

laus-libs-0.1-70RHEL3

perl-DateManip-5.42a-0.rhel3

cpio-2.5-4.RHEL3

gzip-1.3.3-13.rhel3

man-pages-1.60-5.rhel3

The Service Console is clearly based on RHEL3, but it has been modified so only a few rpms remain as original RH rpms. This because all utilities that need to access the vmfs file system will need to be modified. You can download them here: http://www.vmware.com/download/vi/open_source.html

There are however a few utilities that are now based on *bsd code instead of linux. esxtop in 3.0 is one of these, while on 2.x it was based on gnu (and probably the one shipped in RH 7.2).

The kernel of the Service Console is also a modified linux kernel, but as the Service Console is in reality a virtual machine, it's not that kernel that is handling the virtualization. That work is done by the vmkernel, and that kernel is not based on anything else than itself.

Anything unclear?

Lars

[RParker]

Well I am only going to mention 2 things, and then you can go and look for yourself.

ESX 2.5 Architecture guide CLEARLY states, ESX is NOT derived from linux, it is NOT based on Linux, and ESX is NOT Linux.

I went to a Install Configure VM class, and they mentioned this fact, and also told us that the common misconception is ESX is some Linux hybrid, it's not.

The ONLY thing Red hat does is boot. That's it. ESX kernel is a process that runs on it's own, and the service console is nothing more than a simple translator for Redhat Linux commands.

Those messages you see are passed to the Redhat boot loader, and it interprets for the ESX kernel, that's why some commands don't work like top. You can't "see" the VM's using basic Redhat commands, you need to use the VM programs for this.

So I am not going to argue or discuss it. I already know HOW ESX works, and what it is, it was explained in class and the book. If you want to know the truth, then I suggest you take the class or read it for yourself.

I am not confused, you need to catch up and learn about what ESX is all about.

Like I said, 3.5 drops the console ALL TOGETHER anyway, so it will be a moot point. This is done because they don't need ANY part of Red hat any longer for booting or otherwise.

" The kernel of the Service Console is also a modified linux kernel, but as the Service Console is in reality a virtual machine, it's not that kernel that is handling the virtualization" - Tells me you are guessing at HOW ESX works, to say that the SC is a "VM" is an obvious guess by you, because that's how you understand it to work. It's not a VM, its a separate program.

"Anything unclear?"

Only your understanding of ESX

[larstr]

sigh....

I think we agree on things here, but currently a bit more than the boot loader related with RHEL3. Please read my previous posting more carefully. I feel I have a very good understanding on how things have been put together.

We all agree on that ESX is not derived from linux. But the original question here was regarding the ssh daemon in the Service Console. The Service Console is not ESX, but the ssh daemon still runs in the Service Console and as the Service Console is derived from RHEL3, tuning of the ssh daemon will be similar in the Service Console as it is in RHEL3.

According to a recent webex, the Service Console as we know it will probably be dropped totally in two years time. Dropping the Service Console is something VMware have been planning for quite some time. I think the first posting in here regarding it by JMills was more than 3 years ago (these fantastic search abilities of the forums didnt find it). However, the hardware vendors need to port their hw management agents so can get prefailure stats in IBM Director, HP Insight manager, etc before we can start dropping the SC.

Even then we will have a linux based VM that can manage the ESX servers similar to what we can do from the SC today.

Thanks for your time and understanding.

Lars

[larstr]

And to answer the original question:

Some linux distros use auth.log for this purpose. As the Service Console is based on RHEL3, such info gets logged[/url] to /var/log/secure instead.

The best solution is however as adviced earlier in this thread to seperate the Service Console network to a non internet accessible management network that only has access from the hosts that need to.

Hope this helps!

Lars

[RParker]

oh, ok. My fault. Thanks for setting me straight.

Yes, that is a good solution.