Hi,
I believe I meesed up a little and are asking you for help. I re-
installed shorewall from scratch and have following network
ISP provides DHCP "net" in Shorewall
$FW = my firewall
loc is my local network with the server being the firewall also at
address 192.168.2.1
My server (Soekris
Erwin Geuens wrote:
When I change the port in SSHD_CONFIG to 2 and protocol being 2.
then I can not get the SSH running. Neither via local network, neither
via wan.
Which rules should I add to "rules"?
This is covered in the two-interface HOWTO at
http://www.shorewall.net/two-inter
I've uploaded RC2. It corrects several problems that have been discovered in
RC1.
Cheers,
-Tom
--
Tom Eastep\ Nothing is foolproof to a sufficiently talented fool
Shoreline, \ http://shorewall.net
Washington USA \ [EMAIL PROTECTED]
PGP Public Key \ https://lists.shorewall.net/teastep.
Tom Eastep wrote:
I've uploaded RC2. It corrects several problems that have been
discovered in RC1.
No, I haven't introduced a new release naming convention. That should have
been 4.2.0, not r.2.0.
-Tom
--
Tom Eastep\ Nothing is foolproof to a sufficiently talented fool
Shoreline, \
hello all. I have a strange problem with my firewall...always i have to
do a shorewall restart, the internet go slow and i have to disconnect and
reconnect the internet connection(in my case poff and pon dsl-provider). Anyone
got this problem yet? thanks.
PS: sorry about my english :)
Fabio R C
> ...I only need to open SSH to the outside world and to my local
> network: this works fine with the ssh/ACCEPT in rules
> However I would like to use another port for SSH since my ISP blocks
> all ports lower then a certain number. I would like to use a port such
> as 2 ...
Although the c
I have an environment where I have openvpn and shorewall on the same
node. Given that I want different rules applied based who the peer is
and given that IP addresses given out by openvpn can be different from
time to time (I don't want to get into statically allocating addresses
as peers come and
Brian J. Murrell wrote:
I have an environment where I have openvpn and shorewall on the same
node. Given that I want different rules applied based who the peer is
and given that IP addresses given out by openvpn can be different from
time to time (I don't want to get into statically allocating a
Hi,
I run an older version of shorewall (1.4.2) and need some helping setting up
some rules.
I received an abusenet notification that one of my servers is being used to
hack elsewhere. I don't know if anyone here is familiar with
Linux.Backdoor.Small.o, any help would be greatly appreciated.
Brian J. Murrell wrote:
> I have an environment where I have openvpn and shorewall on the same
> node. Given that I want different rules applied based who the peer is
> and given that IP addresses given out by openvpn can be different from
> time to time (I don't want to get into statically alloca
On Mon, 2008-09-08 at 14:57 -0700, Tom Eastep wrote:
> Define the rules in terms of dynamic zones (preferably defined using ipsets
> rather than the deprecated DYNAMIC_ZONES=Yes), then simply add an address to
> the appropriate set when the client logs on and remove it from the set when
> the cl
Brian J. Murrell wrote:
I did take a peek at dynamic zones. Just to be sure I understand
completely, if every one of my peers had different rulesets, I'd need a
dynamic zone for each peer, yes? Are there any scaling issues
associated with having a lot of dynamic zones?
The complexity of the
Ricardo Kleemann wrote:
Hi,
I run an older version of shorewall (1.4.2) and need some helping
setting up some rules.
I received an abusenet notification that one of my servers is being used
to hack elsewhere. I don't know if anyone here is familiar with
Linux.Backdoor.Small.o, any help wou
Thank you very much ! That was it ! That rule was lost somewhere.
Thanks again.
> CHAUSSEE Pierre wrote:
>> It seems the file is not easy to download, and it's to big to just
>> be printed in the message.
>> Here's a link which allows you to download it :
>> http://www.clyl.net/dump.shorewall.
On Mon, 2008-09-08 at 14:57 -0700, Tom Eastep wrote:
>
> Define the rules in terms of dynamic zones (preferably defined using ipsets
> rather than the deprecated DYNAMIC_ZONES=Yes),
Giving this a go, I found a couple of things:
* WARNING: SAVE_IPSETS=Yes is not supported by Shorewall-perl
Brian J. Murrell wrote:
On Mon, 2008-09-08 at 14:57 -0700, Tom Eastep wrote:
Define the rules in terms of dynamic zones (preferably defined using ipsets
rather than the deprecated DYNAMIC_ZONES=Yes),
Giving this a go, I found a couple of things:
* WARNING: SAVE_IPSETS=Yes is not support
On Mon, 2008-09-08 at 16:41 -0700, Tom Eastep wrote:
>
> Shorewall has nothing to do with set creation or maintenance.
I wonder what the philosophical problem is with Shorewall creating an
empty ipset if one doesn't exist already.
Certainly I could put commands into the "init" (I think that woul
Brian J. Murrell wrote:
On Mon, 2008-09-08 at 16:41 -0700, Tom Eastep wrote:
Shorewall has nothing to do with set creation or maintenance.
I wonder what the philosophical problem is with Shorewall creating an
empty ipset if one doesn't exist already.
Certainly I could put commands into the "i
On Mon, 2008-09-08 at 16:50 -0700, Tom Eastep wrote:
>
> I'm not spending one minute on any new ipset functionality until ipsets are
> a part of official kernel.org kernels. And I'm not going to spend any time
> discussing the issue either.
Fair enough. I just got the impression that you were
Brian J. Murrell wrote:
Fair enough. I just got the impression that you were (in a previous
message) promoting ipsets as if they were the way to go and the way
Shorewall was heading in terms of future direction.
I think that ipsets are the greatest thing since sliced bread -- I just wish
tha
So, I think I almost have it but for whatever reason I'm not getting my
loc2vpn1 (where vpn1 is a dynamic zone) rule high enough in the _fwd
chain:
Chain br-lan_fwd (1 references)
pkts bytes target prot opt in out source destination
2005 167K dynamicall
On Mon, 2008-09-08 at 17:19 -0700, Tom Eastep wrote:
>
> I think that ipsets are the greatest thing since sliced bread -- I just wish
> that the Netfilter team would get off of their collective asses and get
> ipsets into the mainstream.
Heh. Now, that I cannot argue with. :-)
b.
signatur
Brian J. Murrell wrote:
What governs the order of the rules that go into the _fwd tables and how
can I get the loc2vpn1 rule assessed higher than the loc2all(tun0) rule?
man shorewall-zones
-Tom
--
Tom Eastep\ Nothing is foolproof to a sufficiently talented fool
Shoreline, \ http://s
Tom,
I know you said you were not going to do any more work with ipsets, so
feel free to ignore this, but just for the historical record (somebody
else might run across this and search) Shorewall[-perl 4.0.6] is
rejecting the name of an ipset which the ipset command itself appears to
like perfectl
Brian J. Murrell wrote:
Tom,
I know you said you were not going to do any more work with ipsets, so
feel free to ignore this, but just for the historical record (somebody
else might run across this and search) Shorewall[-perl 4.0.6] is
rejecting the name of an ipset which the ipset command itsel
On Mon, 2008-09-08 at 17:53 -0700, Tom Eastep wrote:
>
> From the Shorewall 4.0 release notes:
>
> h) Shorewall-perl insists that ipset names begin with a letter and
> be composed of alphanumeric characters and underscores (_). When
> used in a Shorewall configuration file,
Brian J. Murrell wrote:
On Mon, 2008-09-08 at 17:53 -0700, Tom Eastep wrote:
From the Shorewall 4.0 release notes:
h) Shorewall-perl insists that ipset names begin with a letter and
be composed of alphanumeric characters and underscores (_). When
used in a Shorewall config
Tom Eastep wrote:
Brian J. Murrell wrote:
On Mon, 2008-09-08 at 17:53 -0700, Tom Eastep wrote:
From the Shorewall 4.0 release notes:
h) Shorewall-perl insists that ipset names begin with a letter and
be composed of alphanumeric characters and underscores (_). When
used in
Hello Tom,
I appreciate you pointing out the error of my ways. And you are
absolutely correct.
However, lack of resources prevent me from doing this in a production
environment in a timely manner.
Therefore I need an immediate solution in the meantime, and it would be
great to have someone willi
Ricardo Kleemann wrote:
However I understand I need to also block outbound for those ports as
being sources as well. How would I go about doing that?
I have no idea what you are talking about. The rules that you posted looked
adequate to me (or at least as adequate as is possible in your case
On Mon, 2008-09-08 at 20:01 -0400, Brian J. Murrell wrote:
>
> I will try to write some combination of extension scripts to do this
> part automatically. If all else fails, I will just list my ipsets in a
> simple extension script.
Again, for the current and future followers of this thread here
On Mon, 2008-09-08 at 23:14 -0400, Brian J. Murrell wrote:
> here is the
> compile script (for Shorewall-perl)
I hate it when I do this, but here's the cleaned up version...
cut
use File::Temp qw/ tempfile tempdir /;
print "Finding used ipsets\n";
my @ipsets;
open(HOSTS, "hosts") ||
Brian J. Murrell wrote:
On Mon, 2008-09-08 at 23:14 -0400, Brian J. Murrell wrote:
here is the
compile script (for Shorewall-perl)
I hate it when I do this, but here's the cleaned up version...
Which assumes that the only type of ipset worth creating is iphash --
beware.
-Tom
--
Tom Easte
I apologize for my lack of knowledge.
Ok, but I have some doubts as far as how I would go about first blocking
all traffic "anywhere" from the servers lan except for the few ports
allowed.
For example, won't dns requests use random source ports when queries are
made? Something like (from lsof on
Sorry for so many questions, but also for example, I can see valid smtp
sessions in netstat like this:
tcp0 0 server1.americasnet.co:smtp 89.165.43.31:17761
SYN_RECV
Would this traffic be blocked since it has a random destination port of
17761?
On Mon, 2008-09-08 at 20:56 -0700, R
On Mon, 2008-09-08 at 20:32 -0700, Tom Eastep wrote:
>
> Which assumes that the only type of ipset worth creating is iphash --
> beware.
Indeed.
As an aside, by the time the compile script is executed, have all of the
config files been opened and their data enumerated into perl vars? i.e.
coul
36 matches
Mail list logo
