multiple interfaces

[Chris Watt]

At 04:05 PM 9/8/99 +1000, Tom Priore wrote:
>I'm having a problem getting samba to work on 2 interfaces
>I have a machine set up with 2 nics. It is a red hat linux 6.0 computer
>running samba 2.0.5a. The machine is set up as a firewall so that the
>computers on the local side are protected from all those evil people on the
>@home network:)

Every cable ISP I know of blocks the ports used by smb in order to protect
their users. Many (possibly even most) Windows installations would
otherwise be totally vulnerable to anybody who wanted to mess around with
the machine (e.g. Half the systems that I see have been installed with
remote administration enabled, no password (because the user doesn't want
to enter one to login), and TCP/IP up and running). I'd suggest the first
thing to do would be to get in touch with one of the tech people at your
ISP, not to be confused with "tech support" ;), and find out what ports
they are blocking. Security concerns aside many ISPs would probably want to
block smb ports just to avoid all that traffic M$ boxes generate while
trying to find each other.

If you have smbclient (for some reason I don't have one with samba 2.0.5a)
you should be able to use it to search for other "workgroups", if your ISP
is not blocking the ports used by smb (137 to 139 afaik) you should see
dozens or hundreds of them (belonging to other @home customers) and should
be able to do remote admin and read/write file access on most of them (this
is probably illegal). n.b. Most of the vulnerable systems will probably be
in the default workgroup named "workgroup".

If (as I suspect is the case) your ISP does block these ports then you've
got a few solutions that spring to mind, none of them excessivly simple.
- You can do smb networking on non-standard ports (e.g. something in the
4x,xxx area), although if your remote client is running Windows they may
not be able to handle this.
- Much slicker version of the above, you can use SSL and some fancy
ipchains (or equivalent thereof for your platform) configuration to setup
an encrypted tunnel to the remote client and then let it operate as though
it was on the LAN (this probably requires the remote client to be running
Linux or some other real OS).
- If only file access is the issue you can get a program (freeware I think
but I can't recall the name) that will allow the remote client to map drive
letters from directories on an FTP server.
- You can convince your ISP to make an exception in your case and stop
blocking ports for you (if you actually do this I'd reccommend doing a
fairly serious security audit of Samba and puting in some fairly draconian
input/output packet filtering rules in place before bringing it online, smb
is not the world's most secure protocol).

--

The difference between genius and stupidity is that genius has its limits.