Exactly.
If one's external access control is set correctly, you should basically
never see any outside attack traffic at your Asterisk box (you've see it in
the firewall logs instead).
Following the concept of "least privileges" is where you should start if
you have Asterisk attached to a SIP
Hi David, Tim,
Try to use Bail2Ban at last resort. Fail2Ban is a ractive approach, that
permit the traffinc AND ONLY BLOCK them after certain level triggered.
Use iptables to block the unused services faced to public networks like
Internet. And configure these services properly, so they listen o
Is that IP in your network or outside (I can ping it so I'm guessing it's
outside your network)? Do you have a firewall between your asterisk box
and the internet? Is there a WHITELIST of IP addresses that only allow
your provider's limited IP pool to connect to your asterisk box from
outside?
I
Hi, Jerry,
I don't know what S.O. you have in the Server, but you can check the man
page (https://linux.die.net/man/8/in.tftpd) for tftpd and use the options
--address, so you can tell tftp from what interface/port this service
listen request.
>From the IP in your logs (69.64.57.18) the request c
This is old news. They use Shodan and then try to connect. Set up Fail2Ban
that say after 10 404's to ban the IP.
On Fri, Apr 21, 2017 at 12:27 PM, Jerry Geis wrote:
> I "justed" happened to look at /var/log/messages...
>
> I saw:
> Apr 21 12:18:40 in.tftpd[22719]: RRQ from 69.64.57.18 filename
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Jerry Geis
Sent: Friday, April 21, 2017 12:28 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: [asterisk-users] Hack attempt sequential config file read looking
I "justed" happened to look at /var/log/messages...
I saw:
Apr 21 12:18:40 in.tftpd[22719]: RRQ from 69.64.57.18 filename
0004f2034f6b.cfg
Apr 21 12:18:40 in.tftpd[22719]: Client 69.64.57.18 File not found
0004f2034f6b.cfg
Apr 21 12:18:40 in.tftpd[22720]: RRQ from 69.64.57.18 filename
0004f2034f6c
Hi John,
do you have a line in your sip.conf saying "match_auth_username=yes" ?
It needs to be in the "general" context or (I think) inside the peer
configuration.
I need to use this with user based auth, don't know if it's mandatory
for IP based auth also.
Greetings,
Max
signature.asc
Desc
On 10/17/13 23:06, John T. Bittner wrote:
Today I was hacked but caught it very quickly. This is the weird part,
they hacked an IP Auth based account by simply knowing the account name.
How is this possible? I am running Asterisk 11.5.0. Now it’s my fault I
used a dictionary based account name
Hi Steve,
Not using real-time.
John
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Steven Howes
Sent: Friday, October 18, 2013 4:30 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] Hack
On 18 Oct 2013, at 04:06, John T. Bittner wrote:
> Today I was hacked but caught it very quickly. This is the weird part, they
> hacked an IP Auth based account by simply knowing the account name.
>
> How is this possible? I am running Asterisk 11.5.0. Now it’s my fault I used
> a dictionary ba
Today I was hacked but caught it very quickly. This is the weird part, they
hacked an IP Auth based account by simply knowing the account name.
How is this possible? I am running Asterisk 11.5.0. Now it's my fault I used a
dictionary based account name but how did they bypass the set ip I had un
[your-context]
include => app-canadian-weather
[app-canadian-weather]
exten => *55,1,Answer()
exten => *55,2,Playback(pls-wait-connect-call)
exten => *55,3,System(/etc/asterisk/weather.sh | text2wave -o
/var/lib/asterisk/sounds/weather.ulaw -otype ulaw -)
exten => *55,4,Playback(weather)
/etc
Jeremy McNamara wrote (on Jul 24):
> Chris Luke wrote:
> >The chan_h323 in CVS and chan_oh323 both exhibited the same behaviour.
>
>
> I have setup chan_h323 to talk to CCM without any trouble, after someone
> informed me we had to override the External RTP object, which is part of
> cvs -head
Chris Luke wrote:
The chan_h323 in CVS and chan_oh323 both exhibited the same behaviour.
I have setup chan_h323 to talk to CCM without any trouble, after someone
informed me we had to override the External RTP object, which is part of
cvs -head now. I highly doubt the obsolete -stable has it.
The hack below is for OpenH323, not Asterisk. This is not an Asterisk
problem AFAICT. I am posting it here so that any other Asterisk user with a
similar problem might benefit from it. I may or may not post it to an
OpenH323 list, but since both variants of the H.323 channel in Asterisk
use non-cur
16 matches
Mail list logo