Samba Denial of Service Attack

[Steven E. Protter]

I just encountered a most inventive DOS attack on an HP-9000 and two linux servers.

Basically it went like this:

There were samba authentication attempts, which all failed, but generated little log files.

ipaddress.log in the directory on /var where samba stores its logs.

Honestly, I wasn't aware that samba kept logs like this, but I never bothered to look before.

There were hundreds of thousands of attempts, each creating log files. Several of the attempts managed to create rather huge log files.

So /var filled up and the systems stop accepting mail, which is how it came to my attention.

Actions taken thus far:
1) Blocked Port 137,138,139(netbios) and 901(swat) on the firewall, public Internet NIC card.

2)Analyzed the log files.

Questions:

1) Has anyone seen this before?
2) What additional security measures do I need to take? I have no need to provide samba services outside my private network.
3) General suggestions.

SEP

[Lee Hundley · Accepted solution]

This is usually caused by windows worms attempting to infect open SMB shares. Best things you can do are:

1) Add 'hosts deny' and 'hosts allow' declerations to smb.conf like so

hosts deny = ALL
hosts allow = 127.0.0.1 192.168.0. 172.16.

That would deny all requests UNLESS they came from the loopback the Class C 192.168.0.xxx subnet, or the Class B 172.16.xxx.xxx subnet.

2) Use 'listen on' decleration to bind samba to a specific ip:

listen on = 192.168.0.42

3) Keep your new firewall rules in place...just in case :)

HTH

[Geoff Wild]

Havn't seen it, but add this to smb.conf to help stop var filling up:

log file = /var/opt/samba/log.%m
max log size = 10000

Rgds...Geoff

[Steven E. Protter]

Lee, it did work.

Now I'm getting connection denied logs.

I guess the only alternative is to write a cron job to sweep the log directory on a regular basis.

The worm managed to eat 2.4 Gigabytes of disk space VERY,VERY fast.

I'm giving You a bunny because you earned it.

But this thread is OPEN!

SEP

[Steven E. Protter]

The logs all say connection denied(328) or connection denied(883)

lib/access.c:check_access(328)
or
smdb/process.c:process_smb(883)

I'm assuming these numbers are not ports I can block.

Is there a firewall port I can block to stop this activity?

SEP

[Lee Hundley]

I believe you're right, those are probably error codes, not port numbers. It seems you've already got the appropriate ports blocked at your firewall per your earlier post.

If you're still getting those errors, look towards infected machines on your network that still have access to the samba server. Maybe cron a job every hour that greps for the error phrase, pipes it through 'wc -l', and then emails you the results. Maybe it will trail off with the new access rules?

[G. Vrijhoeven]

SEP,

I found a link to a site that can provide you with more info on the subject.

http://security.wayne.edu/default/modules.php?name=News&file=article&sid=84

Have a nice weekend,

Gideon

[Steven E. Protter]

Good stuff.

I think the worm is shut off by closing the samba port, port 445

SEP

[Darren Prior]

Hi SEP,

If the attack comes from multiple clients and you have Samba configured for one log file per client, you could end up with many log files - and the log file size limits become less important. You could consider changing the log file dir to something less important, perhaps a separate filesystem...

regards,

Darren.

[Steven E. Protter]

The attack was coming from multiple clients.

It was all coming from port 445. I opened that port in hopes of doing samba mounts from outside my systems with my laptop as I travelled.

Very, bad idea. I'm working on VPN instead.

Once I shut port 445 i was okay.

ipfilters on hpux works nicely when you say block all traffic except what I authorize.

When I did that setting on the Linux boxes, iptables performance went down the tubes.

Apparently its more efficient to manually bloc the ports and leave the input setting set to ACCEPT.

That makes no sense.

This issue is resolved. Unless someone has come comments on my iptables problem which is better suited for a Linux thread.

Thanks.

SEP

[Steven E. Protter]

Right on point Darren. I had 100,000 log files, new of which were bigger than 10kb

SEP