Samba Exploits? - SMB

This is a discussion on Samba Exploits? - SMB ; Our system was hacked a number a times after total reformating the drives and reinstalling the OS fresh with all new passwords. We're running RedHat 9. We were running the default installed samba, but at this time, it's changed to ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Samba Exploits?

  1. Samba Exploits?

    Our system was hacked a number a times after total reformating the
    drives and reinstalling the OS fresh with all new passwords. We're running
    RedHat 9. We were running the default installed samba, but at this time,
    it's changed to the latest tarball installation.

    We used all the most basic defaults. We have /etc/hosts.deny all,
    which we thought would exclude any connections from anywhere except for the
    few addressed added to the /etc/hosts.allow file. However we have
    connections in our logs coming from other IP's that doesn't match the few in
    the /etc/hosts.allow file.

    Can someone tell me another step that will prevent computers from other
    IP's from accessing the system. Can somone make a quick reference as to how
    a person is able to connect when there's a /etc/hosts.deny file denying all
    addresses?

    The content of the /etc/hosts.deny is:

    ALL: ALL

    If I tried to connect from any IP that's not included in the
    /etc/hosts.allow, it fails. However, some intruders are able to by-pass
    this.

    The stock RedHat samba logs has a bunch of entries as:

    -----------------------------------------------
    [2003/12/16 00:19:26, 0] smbd/service.c:make_connection(252)
    momerdadd (218.72.19.132) couldn't find service c
    [2003/12/16 06:22:10, 0] smbd/service.c:make_connection(252)
    momerdadd (81.68.140.218) couldn't find service c
    [2003/12/16 06:22:13, 0] smbd/service.c:make_connection(252)
    momerdadd (81.68.140.218) couldn't find service c
    [2003/12/16 08:10:38, 0] smbd/service.c:make_connection(252)
    momerdadd (200.79.236.93) couldn't find service c
    [2003/12/16 08:10:42, 0] smbd/service.c:make_connection(252)
    momerdadd (200.79.236.93) couldn't find service c
    [2003/12/17 04:10:40, 0] smbd/service.c:make_connection(252)
    momerdadd (220.164.30.186) couldn't find service c
    [2003/12/17 05:35:33, 0] smbd/service.c:make_connection(252)
    momerdadd (193.250.226.71) couldn't find service c
    [2003/12/17 05:35:36, 0] smbd/service.c:make_connection(252)
    momerdadd (193.250.226.71) couldn't find service c
    [2003/12/17 05:44:13, 0] smbd/service.c:make_connection(252)
    momerdadd (80.54.254.24) couldn't find service c
    [2003/12/17 05:44:16, 0] smbd/service.c:make_connection(252)
    momerdadd (80.54.254.24) couldn't find service c
    [2003/12/17 07:38:12, 0] smbd/service.c:make_connection(252)
    momerdadd (151.203.160.38) couldn't find service c
    [2003/12/17 07:38:21, 0] smbd/service.c:make_connection(252)
    momerdadd (151.203.160.38) couldn't find service c
    [2003/12/17 11:00:45, 0] smbd/service.c:make_connection(252)
    momerdadd (218.169.83.44) couldn't find service c
    [2003/12/17 14:18:34, 0] smbd/service.c:make_connection(252)
    momerdadd (200.100.212.209) couldn't find service c
    [2003/12/17 14:18:38, 0] smbd/service.c:make_connection(252)
    momerdadd (200.100.212.209) couldn't find service c

    The new tarball installation has the following type of foriegn entries:

    [2003/12/17 18:12:26, 0] lib/util_sock.c:read_socket_data(342)
    read_socket_data: recv failure for 4. Error = Connection reset by peer
    [2003/12/17 18:12:53, 0] lib/util_sock.c:read_socket_data(342)
    read_socket_data: recv failure for 4. Error = Connection reset by peer
    [2003/12/17 18:12:56, 0] lib/util_sock.c:read_socket_data(342)
    read_socket_data: recv failure for 4. Error = Connection reset by peer
    [2003/12/17 18:12:59, 0] lib/util_sock.c:read_socket_data(342)
    read_socket_data: recv failure for 4. Error = Connection reset by peer
    [2003/12/17 18:13:05, 0] lib/util_sock.c:read_socket_data(342)
    read_socket_data: recv failure for 4. Error = Connection reset by peer
    [2003/12/17 18:13:08, 0] lib/util_sock.c:read_socket_data(342)
    read_socket_data: recv failure for 4. Error = Connection reset by peer
    [2003/12/17 18:13:10, 0] lib/util_sock.c:read_socket_data(342)
    read_socket_data: recv failure for 4. Error = Connection reset by peer
    [2003/12/17 18:13:29, 0] lib/util_sock.c:read_socket_data(342)
    read_socket_data: recv failure for 4. Error = Connection reset by peer
    [2003/12/17 18:13:31, 0] lib/util_sock.c:read_socket_data(342)
    read_socket_data: recv failure for 4. Error = Connection reset by peer
    [2003/12/17 18:13:35, 0] lib/util_sock.c:read_socket_data(342)
    read_socket_data: recv failure for 4. Error = Connection reset by peer
    [2003/12/17 18:13:49, 0] lib/util_sock.c:read_socket_data(342)
    read_socket_data: recv failure for 4. Error = Connection reset by peer
    [2003/12/17 18:14:01, 0] lib/util_sock.c:read_socket_data(342)
    read_socket_data: recv failure for 4. Error = Connection reset by peer
    [2003/12/17 18:14:10, 0] lib/util_sock.c:read_socket_data(342)
    read_socket_data: recv failure for 4. Error = Connection reset by peer
    [2003/12/17 18:14:11, 0] lib/util_sock.c:read_socket_data(342)
    read_socket_data: recv failure for 4. Error = Connection reset by peer

    We haven't had a complete intruder since the tarball. However, from
    the logs, it appears that the hacker(s) have already started.

    Is there a smb.conf parameter to further plug up this leak?

    Thanks in advance for any one with suggestions or comments.

    -- L. James


    -----------------------
    L. D. James
    ljames@apollo3.com
    www.apollo3.com/~ljames




  2. Re: Samba Exploits?

    L. D. James wrote:
    > Our system was hacked a number a times after total reformating the
    > drives and reinstalling the OS fresh with all new passwords. We're running
    > RedHat 9. We were running the default installed samba, but at this time,
    > it's changed to the latest tarball installation.
    >
    > We used all the most basic defaults. We have /etc/hosts.deny all,
    > which we thought would exclude any connections from anywhere except for the
    > few addressed added to the /etc/hosts.allow file. However we have
    > connections in our logs coming from other IP's that doesn't match the few in
    > the /etc/hosts.allow file.
    >
    > Can someone tell me another step that will prevent computers from other
    > IP's from accessing the system. Can somone make a quick reference as to how
    > a person is able to connect when there's a /etc/hosts.deny file denying all
    > addresses?
    >
    > The content of the /etc/hosts.deny is:
    >
    > ALL: ALL
    >
    > If I tried to connect from any IP that's not included in the
    > /etc/hosts.allow, it fails. However, some intruders are able to by-pass
    > this.
    >
    > The stock RedHat samba logs has a bunch of entries as:
    >
    > -----------------------------------------------


    > [2003/12/17 11:00:45, 0] smbd/service.c:make_connection(252)
    > momerdadd (218.169.83.44) couldn't find service c
    > The new tarball installation has the following type of foriegn entries:




    >
    > [2003/12/17 18:14:11, 0] lib/util_sock.c:read_socket_data(342)
    > read_socket_data: recv failure for 4. Error = Connection reset by peer



    > We haven't had a complete intruder since the tarball. However, from
    > the logs, it appears that the hacker(s) have already started.
    >
    > Is there a smb.conf parameter to further plug up this leak?
    >
    > Thanks in advance for any one with suggestions or comments.
    >
    > -- L. James
    >
    >
    > -----------------------
    > L. D. James
    > ljames@apollo3.com
    > www.apollo3.com/~ljames
    >


    man smb.conf (search for 'bind interfaces only')

    --
    Regards,
    Mark
    Samba Setup Guide: www.samba.netfirms.com
    Courier-imap Tutorial: www.samba.netfirms.com/courier/courier.html
    Tikanni Server Installer: http://sourceforge.net/projects/tikanni


  3. Re: Samba Exploits?

    On Wed, 17 Dec 2003 19:41:30 -0500,
    L. D. James , in
    wrote:

    >+ We used all the most basic defaults. We have /etc/hosts.deny all,
    >+ which we thought would exclude any connections from anywhere except for the
    >+ few addressed added to the /etc/hosts.allow file. However we have
    >+ connections in our logs coming from other IP's that doesn't match the few in
    >+ the /etc/hosts.allow file.


    That only applies to anything that is aware and can take advantage of
    tcpwrappers.

    >+ We haven't had a complete intruder since the tarball. However, from
    >+ the logs, it appears that the hacker(s) have already started.


    You should probably take advantage of linux's firewall. For a
    workstation, I set it to accept any connection from the loopback
    (127.0.0.0/8) and from the "trusted" internal network (172.16.0.0/24),
    and to accept ssh connections from anywhere (I can still phone if
    necessary) and drop *anything* outside that.

    Question: are you attempting to allow smb connections from outside
    your physical network? many providers out-right block the Microsoft
    filesharing ports at their routers. IMHO, this is a good thing. You
    may want to chat with your provider and ask them what filtering, if
    any, they're doing.

    >+ Is there a smb.conf parameter to further plug up this leak?


    Read Mark's reply. That'll help. If your machine is connected to the
    commodity internet, it'll be portscanned, prodded and probed until
    hell freezes over...

    James
    --
    Consulting Minister for Consultants, DNRC
    I can please only one person per day. Today is not your day. Tomorrow
    isn't looking good, either.
    I am BOFH. Resistance is futile. Your network will be assimilated.

  4. Re: Samba Exploits?

    On Wed, 17 Dec 2003 19:41:30 -0500, "L. D. James"
    wrote:

    > Our system was hacked a number a times after total reformating the
    >drives and reinstalling the OS fresh with all new passwords. We're running
    >RedHat 9. We were running the default installed samba, but at this time,
    >it's changed to the latest tarball installation.
    >
    > We used all the most basic defaults. We have /etc/hosts.deny all,
    >which we thought would exclude any connections from anywhere except for the
    >few addressed added to the /etc/hosts.allow file. However we have
    >connections in our logs coming from other IP's that doesn't match the few in
    >the /etc/hosts.allow file.

    Actually, you want to take care of such attachs much earlier, ie
    filter them out at IP level. Using ipchains or iptables, you could
    for example block any access from the internet to any of the ports
    used by SAMBA (137,138,139,445).

    Run "netstat -an" to look at all the ports that are open (LISTENING).
    The fewer the better.

    Inaddition, within SAMBA you definitely want to use all the options
    availalbe to use. I have listed some that maybe relevant -
    - "interfaces"
    - "bind interface only"
    - "guest ok"
    - "guest account" (set this is a non-existent UNIX account to cover
    up any leaks. This way if some service is still somehow available to
    guest users, a non existent account would cause SAMBA to fail and
    print a message in the log).

    I have a setup where a Linux system running SAMBA is also connected to
    the internet and our private network. Its at my friends insurance
    company. If it was up to me (cost$) I would rather not do it this
    way.

    The one system does all the following:
    - ROUTER (only ssh allowed from outside, connects computers in the
    private network to the internet and acts as the gateway) - useful to
    administer the system from outside
    - DHCP (binds to private network only)
    - SAMBA (only to private network - file & print server, WINS Server)
    - backups all data daily to a SNAP server.


+ Reply to Thread