Koozali.org: home of the SME Server
Legacy Forums => General Discussion (Legacy) => Topic started by: Robert Harlow on April 28, 2003, 02:53:25 AM
-
Sirs
Looks like I need to get my old WatchGuard SoHo5 hardware firewall back into operation:-( You see it has a great mechanism to, very simply, set up and physically block *problem domains*...;~/
When my old server-only SME was converted to SME5.6u2 (server/gateway mode - providing systemic DHCP) I opted to use the SME's own firewall for simplicity. The, now unused, hardware firewall was put away into storage.
I'm not entirely sure how to effect this insertion... The hardware firewall needs to be put between the SME's internet side and the broadband's client hardware (my site uses its own static IP).
I assume I cannot just reuse the SME's setup settings?
Is it just a simple matter of amending the SME's setup so that its internet side uses one of the hardware firewall's trusted IPs instead of that of my site's static IP?
Also wondering how I am to control and monitor the hardware firewall when it is successfully installed and situated on the internet side of the SME's own internal firewall, particularly as its webserver access engine requires me to use an otherwise internal address of <192.169.111.1>.
Having some trouble thinking this through conceptually, so if someone has travelled this way before then I'd appreciate their feedback;~/
best wishes, Robert
-
Robert Harlow wrote:
>
> Sirs
>
> Looks like I need to get my old WatchGuard SoHo5 hardware
> firewall back into operation:-( You see it has a great
> mechanism to, very simply, set up and physically block
> *problem domains*...;~/
You should be able to do this with a simple iptables rule as well.
> When my old server-only SME was converted to SME5.6u2
> (server/gateway mode - providing systemic DHCP) I opted to
> use the SME's own firewall for simplicity. The, now unused,
> hardware firewall was put away into storage.
>
> I'm not entirely sure how to effect this insertion... The
> hardware firewall needs to be put between the SME's internet
> side and the broadband's client hardware (my site uses its
> own static IP).
>
> I assume I cannot just reuse the SME's setup settings?
>
> Is it just a simple matter of amending the SME's setup so
> that its internet side uses one of the hardware firewall's
> trusted IPs instead of that of my site's static IP?
Yes, and forwarding ports from the firewall to the SME for the services you need. You may wish to switch back to Server Only mode also.
> Also wondering how I am to control and monitor the hardware
> firewall when it is successfully installed and situated on
> the internet side of the SME's own internal firewall,
> particularly as its webserver access engine requires me to
> use an otherwise internal address of <192.169.111.1>.
It will work fine. I can access our cable modem's web-config at 192.168.100.1 just fine from a LAN PC.
> Having some trouble thinking this through conceptually, so if
> someone has travelled this way before then I'd appreciate
> their feedback;~/
>
> best wishes, Robert
-
>> Looks like I need to get my old WatchGuard SoHo5 hardware
>> firewall back into operation:-( You see it has a great
>> mechanism to, very simply, set up and physically block
>> *problem domains*...;~/
>
>You should be able to do this with a simple iptables rule as well.
Bill
This sounds promising, would you elaborate on this a little please?
I've looked around and found a few areas with the name iptables but none of them appear to want or need editing with anything. Is there some process for doing this properly?
When I penned the above I really did mean it was very simple to do on the hardware firewall. It's literally... make up a custom service, add the problem domain(s) and activate. It's not that I'm specifically looking for something easy, it's just I don't know how to effect what you're proposing nor where to get it done;~/
best wishes, Robert
-
Bill
is my friend:-)
My take is that I think I need to look at INPUT rules:-
.
[root@nas600 /]# iptables -L INPUT
Chain INPUT (policy DROP)
target prot opt source destination
icmpIn icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
DROP all -- BASE-ADDRESS.MCAST.NET/4 anywhere
DROP all -- anywhere BASE-ADDRESS.MCAST.NET/4
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
InputAllowLocals all -- anywhere anywhere
InboundTCP tcp -- anywhere anywhere tcp flags:SYN,RST,ACK/SYN
denylog tcp -- anywhere anywhere tcp flags:SYN,RST,ACK/SYN
ACCEPT udp -- anywhere anywhere udp spts:bootps:bootpc
gre-in gre -- anywhere anywhere
denylog gre -- anywhere anywhere
denylog all -- anywhere anywhere
.
Could you suggest the form of a command line that achieves something along the lines of DROPping all packets INPUT from 202.108.254.214 and 202.108.254.215? This whole iptables area looks as though it could be quite vulnerable to inappropriate messing around or any other similarly blundering experimentation on my part;~/
best wishes, Robert
-
>Could you suggest the form of a command line that achieves
>something along the lines of DROPping all packets INPUT
>from 202.108.254.214 and 202.108.254.215?
I'm rather hoping that the following will do the trick, as opposed to any SME damage;~/
/sbin/iptables -A -t filter -j DROP -s --source 202.108.254.214
/sbin/iptables -A -t filter -j DROP -s --source 202.108.254.214
best wishes, Robert
-
On further thought maybe I need INPUT in there as well...
/sbin/iptables -A INPUT -t filter -j DROP -s --source 202.108.254.214
/sbin/iptables -A INPUT -t filter -j DROP -s --source 202.108.254.215
best wishes, Robert
-
The above seems to be working... how do I tell!? At least nothing has fallen over which is the main thing;~/ Have plugged in my notepad's worth of cretinous domains with the wonderful PuTTY. Hopefully all things spammy will return to the merely occasional irritation.
For someone in the same situation and *searching* the database, well you might like to investigate Darrell May's mailfront rules addon...
.
http://mirror.contribs.org/smeserver/contribs/dmay/mitel/contrib/Mailrules/dmc-mitel-mailrules-0.0.1-7.noarch.rpm
.
...don't know the precise mechanism but it seems to address [ouch] the same or quite similar IP filtering.
best wishes, Robert