hellow,
I want to access the Ethernet port of Soekris net5501 but i am having
some problems. when ever i plug Ethernet wire into the eth0 port.
Soekris detects that and a message appears indicating that it is
detected . but when try to access it by pinging the default
192.168.101.1. it replies wit
I have a bit of a problem here with backups:
I have a number of phone firmware loads in the tftpboot directory along with
phone configuration files.
Unfortunately the only backup options for this directory is all /mnt/kd which
ends up at around 16M in my situation.
Thats not actually the bigges
If these are the only chains that are impacted by this problem then it
sounds good. Will give us the flexibility we need.
Thanks
David
On Mon, Jul 16, 2012 at 6:30 PM, Lonnie Abelbeck
wrote:
> Hi David,
>
> Well, I wouldn't necessarily call it a "dumb idea" :-) and I explained
> Arno's reasoni
Hi David,
Well, I wouldn't necessarily call it a "dumb idea" :-) and I explained Arno's
reasoning years ago.
I have commit privileges to the AIF SVN, so with Arno's approval we and
implement any great idea we can come up with.
One idea Arno and I had was to add 3 new variables to AIF:
--
# (1
Oh dear, I opened a can of worms. I have to say that changing default
behavior as a side effect of adding an allow rule feels like a dumb idea.
How hard would it be for iptables to be modified such that a final default
chain rule can be specified -- which could override a hard coded default
rule f
Sigh, now I remember why we didn't previously support "Pass LAN->EXT" and "Pass
DMZ->EXT" in the Firewall tab...
First, my suggestion to David in this thread for using LAN_INET_HOST_OPEN_UDP
does what you expect *but* has the side effect of changing the LAN->EXT default
policy from ALLOW to DRO
Thanks to all. I think it was inbound IAX listening on 0/0 (I had failed to
narrow it down only to our own boxes), coupled presumably with not amply
strong password, and the IAX landing context not being secured against
outbound calls, as you say. Adaptive ban was in place, so I'm hopeful it
wasn't
David,
Arno's Firewall (AIF) automatically places the "Pass LAN->EXT" rules (if any)
before the "Deny LAN->EXT" rules.
So, no ordering by the user is required.
Lonnie
On Jul 16, 2012, at 9:16 AM, David Kerr wrote:
> When this is all implemented does it matter in what order the rules are
> e
When this is all implemented does it matter in what order the rules are
entered? For example if iptables comes across a deny that matches the
request does it keep on going through the table looking for a rule that
might never-the-less permit the request or does it stop -- in which case
the rule pe
You would start by analyse the CDR log and looking to see from which
context the calls are originating.
Make sure that you don't have a "default" context, but if you do need it
(to receive legitimate inbound calls) then make sure that this context only
permits access to internal extensions, not an
On Jul 16, 2012, at 2:53 AM, Michael Keuter wrote:
>
> Am 16.07.2012 um 01:39 schrieb Lonnie Abelbeck:
>
>> David,
>>
>> With the general DNS block in place...
>>
>> LAN_INET_HOST_OPEN_UDP="192.168.1.99>0/0~53"
>>
>> will allow the internal 192.168.1.99 device to access any external DNS
>>
Sorry to hear this... A few notes from the voice of experience:
Probable cause:
hacked SIP password from an unauthorized IP address. problem could be
an overly simplistic or nonexistent SIP secret. look at your logs and
see what the source channel(s) are/is and shut that channel or channels
do
Hello all
It's finally happened, and our Astlinux box has been compromised, with many
premium/unauthorized calls being made. Would someone be willing to help out
diagnose what happened and rectify the vulnerability? Obviously, this can be
paid work. If anyone is interested, and can get back to me
Am 16.07.2012 um 01:39 schrieb Lonnie Abelbeck:
> David,
>
> With the general DNS block in place...
>
> LAN_INET_HOST_OPEN_UDP="192.168.1.99>0/0~53"
>
> will allow the internal 192.168.1.99 device to access any external DNS server.
>
> Lonnie
>
> PS: In the web interface we don't support "Pa
14 matches
Mail list logo
