Topic: Will SME work for this problem.

[sal1504]

I have two law firms that share the same building. They recently went together and bought an expensive Sharp Multi-function copier and are wanting to share it. They need to be able to print to the copier and send scanned images back to the individual workstations. The problem is they are on seperate subnets, law1 = 192.168.0.XXX and law2 = 10.1.10.1. They are completely seperate companies and do NOT share any other networking functions outside of wanting to share this copier. They need to keep each side seperate for confidentiality purposes, so they will not allow me to put them on one subnet. Law2 has a newbie tech just out of college that thinks he knows everything and has law2 convinced you could not protect the network if they use one subnet. What I was wondering is if there was a way to use SME Server with three network cards, one with and ip address of 192.168.0.1, one with an ip address of 10.1.10.1, and one with an ip address of 192.168.100.1 for the copier. I would then route 0.1 and 10.1 to 100.1 to allow access to the copier/scanner. I already have Law1 setup on SME server and everything works great. I have used SME on several occasions but this one has me confused.

          192.168.0.XXX network                                                       10.1.10.1 network                                                   
                           |                                                                                  |
                           |                                                                                  |
                           ---------firewall---- 192.168.100.1---------firewall---------
                                                                 |
                                                                 |
                                                        printer/scanner

Is this possible to do this with SME Server or can someone recommend another solution that will work? I hope I have given enough information.

Sal

[mmccarn]

Your options are likely to be limited by how the scanner sends the scanned data to your users.

I've seen several different methods:
- email to recipient (watch out for large scans)
- smb share on the server
- ftp upload to a server
- smb share on each workstation
- custom scanner software on each workstation
- internal hard drive with local "mailboxes" on the scanner itself

You could get pretty good results just by doing this:

Code: [Select]

          192.168.0.XXX network                                       10.1.10.1 network                                                   
                           |                                                  |
                           |                <LAN                              |
                           ------------------linksys befsr41-------------------
                           |                           >WAN
                           |
                  printer/scanner

* Set the LAN IP of the linksys to be the default gateway for the printer/scanner
* Set the printer/scanner to be the DMZ for the Linksys
* Configure the printer/scanner on the 10.1.10.x network (in this diagram) using the WAN IP on the Linksys
* Close down as many "outbound" ports on the Linksys as you can
* Point the "LAN" port of the linksys towards the paranoiac's network, so you can reassure him that you can't break in.

The down-side is that for this to work and keep the paranoiac complacent, the printer/scanner has to be physically connected to his network (assuming the scanner is pushing the scans to the users via SMB - it will be able to push out to the "WAN", but couldn't push from the WAN into the LAN)

Because the Linksys does NAT, the workstations on 10.1.10.x have no trouble talking to it (since they think it's local at 10.1.10.?).

If you have spare PCs with extra NICs floating around, you could set up m0n0wall - low hardware requirements (CDROM, floppy drive, 3 NICs), simple install (burn a 10MB CD, then boot from it) you could set up the firewall in your diagram pretty easily.

If you do setup your firewall, you either need to use NAT so that everyone thinks the printer is on their local network, or you need to modify your current routers to know to send traffic for 192.168.100.x to the new firewall - and if you do that, you need to be careful to make sure you don't start inadvertently breaking in to the other law firm...

The short answer to your original question is: "There isn't much in the way of 3rd NIC support in SME".

[arne]

I believe that any Linux distro can do this, but not as "all automatic" or "out of the box".

Something like this, I think:


192.168.0.XXX network--eth0--<printer server with bridge and bridge mode firewall>--<eth1>--10.1.10.1 network

Should't this work ?

The SME server could have done it, after some modifications, like any other Linux distro, it if doing such modifications were allowed in the forum.

If it can work, which It can it would require some "hand-configuration" of a Linux bridge mode firewall.

I wonder if this couldn't be done  .. I would guess yes, but not "out of the box".

It would eventually require "handmade" configuration and also a "tailored" security check of the bridge mode firewall and the two networks after. So it might still not be a practical solution, even though it could hva been done.

Does anyone see a problem, that I do not see, so it could not have worked this way?

[sal1504]

arne

thanks for the reply. The only problem I see with the setup you provided is that one of the law firms will be able to see information to the second law firm. There needs to be complete data seperation between the two law firms. I sure I could do this with an expensive Cisco Router but I am trying to keep the cost down. The second problem is, the printing is not the issue it's the scanning of documents that need to be sent to the individual workstations. Documents scanned by Law1 need to go only to Law1Workstation, Documents scanned by Law2 need to go to only Law2Workstation. That is why there is two subnets.

bill

[sal1504]

mmccarn and arne

mmccarn
thanks for your response also. I have never looked at monowall. from what i read in your reply it will support the configuration i want. will download and try today.

arne
after rereading your post it makes sense also. i will setup my test machines and try it also.

Thanks to both

Sal
 

[arne]

Alternative firewalls is a quite hot potato, in this forum, so I guess it will eventuelly be tested on an other Linux distro than the SME server. But any how, here is some notes I wrote down once doing some tests with a bridge mode firewall.

To make the bridge itself, with or without an IP:


ifconfig eth0 0.0.0.0
ifconfig eth1 0.0.0.0

brctl addbr br0
brctl addif br0 eth0
brctl addif br0 eth1

# ifconfig br0 10.0.0.35 netmask 255.255.255.0

ifconfig br0 up

And then a firewall for a bridge as experiementet/tested it out:


### ESTABLISHING FIREWALL RULES

# Flushing out the old firewall rules.
iptables -F
iptables -X
iptables -Z

# Samtlige policies settes til drop, dvs stengt.
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# Preventing DOS attack (May be not needed)
iptables -N syn-flood
iptables -A FORWARD -p tcp –syn -j syn-flood
# iptables -A FORWARD -p tcp –tcp-flags SYN SYN -j syn-flood
iptables -A syn-flood -m limit –limit 4/s –limit-burst 8 -j RETURN
iptables -A syn-flood -j DROP

# Drop spoofed packets (May be not needed)
iptables -A FORWARD -p tcp –tcp-flags ALL NONE -j DROP
iptables -A FORWARD -p tcp –tcp-flags SYN,FIN SYN,FIN -j DROP
iptables -A FORWARD -p tcp –tcp-flags SYN,RST SYN,RST -j DROP
iptables -A FORWARD -p tcp –tcp-flags FIN,RST FIN,RST -j DROP
iptables -A FORWARD -p tcp –tcp-flags ACK,FIN FIN -j DROP
iptables -A FORWARD -p tcp –tcp-flags ACK,PSH PSH -j DROP
iptables -A FORWARD -p tcp –tcp-flags ACK,URG URG -j DROP

# Statefull inspection, for return traffic
iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT

# Drop spoofed packed releated to statefull inspection
iptables -A FORWARD -m state –state INVALID -j DROP

# Full open for traffic out
# iptables -A FORWARD -s 10.0.0.0/24 -j LOG –log-prefix “TESTREG:”
iptables -A FORWARD -s 10.0.0.55/24 -j ACCEPT

# Fitrering of trafick i inbound trafick direction
iptables -A FORWARD -d 10.0.0.2/24 -p tcp –dport 25 -j ACCEPT
iptables -A FORWARD -d 10.0.0.2/24 -p udp –dport 53 -j ACCEPT
iptables -A FORWARD -d 10.0.0.2/24 -p tcp –dport 80 -j ACCEPT
iptables -A FORWARD -d 10.0.0.2/24 -p tcp –dport 110 -j ACCEPT
iptables -A FORWARD -d 10.0.0.2/24 -p tcp –dport 143 -j ACCEPT
iptables -A FORWARD -d 10.0.0.2/24 -p tcp –dport 443 -j ACCEPT

# SSH remote logon + web server on the firewaLL MACHINE
iptables -A INPUT -s 10.0.0.55/24 -p tcp –dport 22 -j ACCEPT
iptables -A INPUT -s 10.0.0.55/24 -p tcp –dport 80 -j ACCEPT
iptables -A INPUT -s 10.0.0.55/24 -p tcp –dport 443 -j ACCEPT
iptables -A OUTPUT -m state –state ESTABLISHED,RELATED -j ACCEPT


I guess that a bridge mode firewall/gateway/printer server can be local to both networks, and still separating them using configuration of the bridge mode firewall.

I don't remeber my setup completely, but this are my notes. Configuring a bridgemode firewall is slightly different from a routing firewall as specifying adapters like eth0 and eth1 will not work. It will have to be used network numbers / ip-addresses instead.

Establishing experimental security systems for two lawyer companies might be two more hot potatos

[arne]

By the way to set up a "double local web server" and to block all traffic between the bridge segments should be something like this, I believe:

To make the bridge itself, with or without an IP:


ifconfig eth0 0.0.0.0
ifconfig eth1 0.0.0.0

brctl addbr br0
brctl addif br0 eth0
brctl addif br0 eth1



### ESTABLISHING FIREWALL RULES

# Flushing out the old firewall rules.
iptables -F
iptables -X
iptables -Z

# Set policiet to drop.
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# web server on the firewaLL MACHINE
iptables -A INPUT -s 10.1.10.0/24 -p tcp –dport 80 -j ACCEPT
iptables -A INPUT -s 192.168.0.0/24 -p tcp –dport 80 -j ACCEPT
iptables -A INPUT -s 10.1.10.0/24 -p tcp –dport 443 -j ACCEPT
iptables -A INPUT -s 192.168.1.24/24 -p tcp –dport 443 -j ACCEPT
iptables -A OUTPUT -m state –state ESTABLISHED,RELATED -j ACCEPT

eth0 and eth1 should have a local address for each lan.
The bridge itself should have no ip address.

Web server ports have to be replaced with tha actual printer server ports.

Shouldn't cost more than a low performing PC.

Please make a post if it should work !
 

[electroman00]

I have two law firms that share the same building. They recently went together and bought an expensive Sharp Multi-function copier and are wanting to share it. They need to be able to print to the copier and send scanned images back to the individual workstations. The problem is they are on seperate subnets, law1 = 192.168.0.XXX and law2 = 10.1.10.1. They are completely seperate companies and do NOT share any other networking functions outside of wanting to share this copier. They need to keep each side seperate for confidentiality purposes, so they will not allow me to put them on one subnet. Law2 has a newbie tech just out of college that thinks he knows everything and has law2 convinced you could not protect the network if they use one subnet. What I was wondering is if there was a way to use SME Server with three network cards, one with and ip address of 192.168.0.1, one with an ip address of 10.1.10.1, and one with an ip address of 192.168.100.1 for the copier. I would then route 0.1 and 10.1 to 100.1 to allow access to the copier/scanner. I already have Law1 setup on SME server and everything works great. I have used SME on several occasions but this one has me confused.

          192.168.0.XXX network                                                       10.1.10.1 network                                                   
                           |                                                                                  |
                           |                                                                                  |
                           ---------firewall---- 192.168.100.1---------firewall---------
                                                                 |
                                                                 |
                                                        printer/scanner

Is this possible to do this with SME Server or can someone recommend another solution that will work? I hope I have given enough information.

Sal

law2 convinced you could not protect the network if they use one subnet.

Simply not a true statement, protecting and creating a secure network is dependent on setting up the network correctly.
While on the other hand you would not be able to provide network isolation on the same subnet which is a prudent requirement
between two law firms or businesses that require shared resources.

Your simplest solution would be to use a vlan switch between the two networks and the printer.

Depending on the number of nodes on each network would determine the best method of vlan switch deployment.

You might be able to use a single switch or more likely two vlan switches trunked together on a giga bit trunk.

It would be suggested you investigate the reasoning for the 10.1.10.1 network, not sure that is correct, looks like you poked the modem and not the lan.

Usually the 10.x.x.x is deployed on very large networks as the need requires i.e. your ISP.

The 10.1.10.1 instead of 10.1.10.x lends itself to a clue to it possibly not being correct.

It's not usual for small independent networks to use the 10.x.x.x address space unless there is some compelling reason.

For one example, the small network connects to a larger network internally or externally.

A through understanding of both networks is required to provide a solution.

I would highly suggest the law firms consult an experienced network security specialist due to the extremely
sensitive nature of their business, else they may need independent legal representation at some time in the future.

The law firms need to realize the ramifications of a systems security breach to the network and how that relates to their ability to practice law.

The Blind leading the Blind isn't exactly prudent within a law firm where personally identifiable information is stored.

The widget factory or doughnut factory doesn't usually fall within the personally identifiable information storage category and
therefore lends itself to the Blind lead the Blind... till it works approach.

The keywords are experienced and knowledgeable and it appears that, that is lacking in your situation I'm sorry to say,
with yourself and the newbie grad. JMO

That statement is not meant to offend you or the newbie grad, simply to make you aware that you may not be playing in the correct league.

There are amateur baseball leagues for a very good reason and someday they play in the big leagues.

Personally identifiable information storage makes law firms big league network baseball..!!

Lawyers are licensed professionals in all states and are required under that license to protect client information more so then most all other licensed professionals.

It's extremely easy to create by design and configuration a network vulnerability, thus exposing client information, thus exposing a license to suspension or revocation.

I think you may agree, that you may not want to associate your name to that vulnerability.

For a new customer I document the entire system configuration and verify that there is no existing vulnerability.

Then and only then, do I advise, change, modify any part of that system.

That approach is simply called CYA.

10-4 ??

hth

[sal1504]

electomann

no insult taken. I am the one who is pointing out the security issues they will be facing and trying to convince the two law firms that if security is really a key issue then they should have consulted a network security guru to begin with. I personally would NOT have recommended the solution they bought. With that being said I was just looking to see if there is a solution of any kind that will work for what they bought. I have come to the conclusion that there is not a simple fix and they need to go back to the company that sold them the copier, who told them they could share the copier, and have them either provide the solution or refund their money. I have had the misfortune of being asked to resolve this problem and will not get reimbursed for my troubles so I will be dropping efforts being made by myself and let the company who sold the copier, the law firms and the newbie tech work out what they are going to do.  I would like to thank everyone who offered suggestions. Of all the forums I have used I have found that this is the most informative and the most supportive. SME rules.

Sal

[arne]

Technically I think a bridge mode firewall arrangement would have worked. As for the use/environment/customer, I think the conclusion above is 100 % correct. There would be only one point of failure security and this single point will be of some "experimental nature". Conclusion: Could work, but can not be used.

[gis]

Arne, sorry for contacting you this way, but I can't quote or reply to your post on http://forums.contribs.org/index.php/topic,42157.0.html

I wondered whether you made any progress with this issue? I totally agree with you that SME server needs a decent built-in firewall, not just simple NAT. I just tried to implement SSH brute force login on iptables level as described on http://www.debian-administration.org/articles/187 and http://wiki.contribs.org/Firewall#Block_incoming_IP_address, but it doesn't seem to work.

What frustrates me is that I have no idea about how to make the changes to its "firewall".

Thanks.

[warren]

off topic from OP but ...
 

I totally agree with you that SME server needs a decent built-in firewall, not just simple NAT

I just tried to implement SSH brute force login on iptables level as described on http://www.debian-administration.org/articles/187 ...

Why not use public-private keys to really secure your access to SSH

[Stefano]

I totally agree with you that SME server needs a decent built-in firewall, not just simple NAT.

What frustrates me is that I have no idea about how to make the changes to its "firewall".

Thanks.

If you need a different kind of firewall, use a different one.. out there there are many solutions, open and closed source..
a better|different firewall implementation is not necessary IMHO on SME.

BTW, Arne was told a billion times to post his code on bugzilla.. and he did it, but it seems he has not clear what he wants to achieve (search bugzilla for reference)

finally, if you wish to understand how iptables work on SME, you should read the documentation to understand how templating system works.

My 2€c

Ciao
Stefano

[electroman00]

gis

This might be of some interest to you.

http://wiki.contribs.org/Denyhosts

[arne]

gis ->

Yes, all relevant and open questions related to smeserver firewall and configuration tools including diverse perl scripts were traced down.

I had a list of things I liked to do and test out, and everything were done. (That's the reason I have been a bit lazy during the later time. Have done some other projects not related to SME server during the latest time.)

The sme server is not much different from any other Linux distroes and everything can be done, including multible netrwork interfaces, tree port solutions, wireless access point, clien, everything. I had them on a "excersise list" so I did them, and none were left unsolved. I also made an light variant of the SME server that could run on 64 MB ram, I belive it was. Everything, or the major hings was sendt to the "proposal pool".

Personally I think the firewall configuration options of the standard SME server is a bit restricted and difficult to work with, but actually all the options of the Netfilter is available, for those who would like it.

On the other hand I think I have found a method or way of doring thing that works even bether. This is to run it all as virtual installations under vmware, and then to set up a virtual installation of Smothwall "in front" of the virtual sms server, and then run the SME server as "server only", even though technically on a gateway.

If I runned tha sme server only and a customized firewall arrangement or a virtual smothwall gateway and a virtual sme server, the net result is allmost the same for me (from a practical point of view.)

The virtual alternative has the great advantage, that is gives the option of having a number of test intallations to experiment with, without the risk of destroying anything.

One other good thing is the ease of use and userfriendliness of the Smotthwal. There is no need for thinking at all, when you need some quick reconfigurations.

The third good thin is moving all the firewall problem out of the sme server and over to the virtual Smoothwall should end all problems releated to sme server firewall.

My opinion has allways been tht the SME server should have a some kind of easy to manage graphical interface for the firewall like the Smoothwall, and running the both installations as vitual installations gives this solution.

If I can imagine some firewall releated problem related to the sme server that is not already solved, I might try to do something again, but at the moment I don't know what this could be.