Page 3 of 6 FirstFirst 12345 ... LastLast
Results 21 to 30 of 52

Thread: Hacker attempts

  1. #21

    Default

    oh ..I ll be careful now.
    --------------

  2. #22

    Default

    It would be really good if the next release for Quadro PBX's could incorporate automatic IP blocking similar to fail2ban does for Asterix... We really need something like this nowdays

  3. #23
    Quadro Architect
    Join Date
    Jun 2006
    Location
    Around myself
    Posts
    2,075

    Default

    Quote Originally Posted by person View Post
    We have a public IP being served to the epygi. The worrying thing is the only rules in the firewall are in "allowed sip access" and those are specific ip addresses of our VSP and a few remote extensions only... so this appeared to go through the firewall??

    I'm using firmware 5.1.19 configured as Static IP...
    There is a problem in the firewall of 5.1.19 (and actually all versions prior to 5.1.38), which is the following: if in the "SIP Access" list you allow access from a range of IP addresses, which includes the Quadro's own IP address, the SIP requests from all addresses get accepted...

    This could be the case with your configuration. Please check it and make sure that you don't open a SIP access to any IP range, which includes Quadro's own IP address...
    The fix for this will be published soon (version 5.1.39).

    Best regards,
    David

  4. #24
    Quadro Architect
    Join Date
    Jun 2006
    Location
    Around myself
    Posts
    2,075

    Default

    Quote Originally Posted by person View Post
    It would be really good if the next release for Quadro PBX's could incorporate automatic IP blocking similar to fail2ban does for Asterix... We really need something like this nowdays
    This kind of feature is going to be published in the 5.2.x releases. It will be in the experimental stage yet, so will be placed on a hidden page, until we feel it is mature enough.

  5. #25

    Lightbulb block ip list

    Hello to all,
    As there's an increasing amount of sip attacks, Here is a list of IP attackers, detected by the epygi's IDS system.
    As you may see, some of them are local (Israel) and some of them are part of the Amazon cloud service (temp. assigned to their customers).
    Once we entered those IPs to a block list, and at the same time, allowed sip connection only to those we know, all the system problem were solved.

    94.75.236.41
    92.48.119.37
    85.211.97.87
    85.211.67.143
    82.151.87.59
    81.174.57.62
    76.9.9.215
    76.9.16.171
    76.89.148.245
    62.50.134.34
    62.219.186.7
    221.12.160.198
    217.132.91.51
    212.199.78.17
    212.12.160.198
    196.213.177.250
    195.81.186.202
    195.143.135.194
    192.117.235.237
    192.117.235.235
    188.105.17.11
    184.73.16.184
    174.120.159.130
    121.12.118.162

  6. #26

    Default

    It would be silly to allow SIP access to everyone (unless it is not practical for you to implement - ie. you provide SIP services to roaming customers). If you are maintaining the box for a company's internal use then I would go as far to suggest that a SIP best practice would be to lock it down and only allow SIP connections from a specific list of IP's - hopefully your remote extensions can get static IP addresses assigned to them.

    A recommendation for Epygi would be to allow hostnames and not just IP addresses and subnets as this would allow dyndns services to update the entry accordingly.

  7. #27

    Thumbs up allow hostnames in firewall rules

    Quote Originally Posted by juanhf View Post

    A recommendation for Epygi would be to allow hostnames and not just IP addresses and subnets as this would allow dyndns services to update the entry accordingly.
    I also vote for hostnames implementation to allow roaming and dynamic IP clients.

  8. #28

    Default

    Yes I would love this hostnames feature! Please implement it if possible

  9. #29

    Default

    Can you please elaborate on the new "SIP IDS" feature in v.5.2.9
    From release notes:
    Security enhancement. Protection against certain SIP DoS attacks has been added by enabling the "SIP IDS" feature in the hidden menu generalconfig.cgi. Enabling this option will automatically block malicious IPs in the firewall.

    I enabled SIP IDS with Security Level set to default 'Medium'.
    However, I'm still getting dozens of attacks like these:

    New Wed Jun 30 08:36:29 2010 3 SIP ip phone registration rejected IP phone user 399 [67.205.52.172:5092]: registration failed. Reason: No Such Line Configured. IP Lines Registration Status
    New Wed Jun 30 08:36:29 2010 3 SIP ip phone registration rejected IP phone user 398 [67.205.52.172:5092]: registration failed. Reason: No Such Line Configured. IP Lines Registration Status
    New Wed Jun 30 08:36:29 2010 3 SIP ip phone registration rejected IP phone user 397 [67.205.52.172:5092]: registration failed. Reason: No Such Line Configured. IP Lines Registration Status
    New Wed Jun 30 08:36:28 2010 3 SIP ip phone registration rejected IP phone user 396 [67.205.52.172:5092]: registration failed. Reason: No Such Line Configured. IP Lines Registration Status
    New Wed Jun 30 08:36:28 2010 3 SIP ip phone registration rejected IP phone user 395 [67.205.52.172:5092]: registration failed. Reason: No Such Line Configured. IP Lines Registration Status
    New Wed Jun 30 08:36:28 2010 3 SIP ip phone registration rejected IP phone user 394 [67.205.52.172:5092]: registration failed. Reason: No Such Line Configured. IP Lines Registration Status
    New Wed Jun 30 08:36:27 2010 3 SIP ip phone registration rejected IP phone user 393 [67.205.52.172:5092]: registration failed. Reason: No Such Line Configured. IP Lines Registration Status
    New Wed Jun 30 08:36:27 2010 3 SIP ip phone registration rejected IP phone user 392 [67.205.52.172:5092]: registration failed. Reason: No Such Line Configured. IP Lines Registration Status
    New Wed Jun 30 08:36:27 2010 3 SIP ip phone registration rejected IP phone user 391 [67.205.52.172:5092]: registration failed. Reason: No Such Line Configured. IP Lines Registration Status
    New Wed Jun 30 08:36:27 2010 3 SIP ip phone registration rejected IP phone user 390 [67.205.52.172:5092]: registration failed. Reason: No Such Line Configured. IP Lines Registration Status
    New Wed Jun 30 08:36:26 2010 3 SIP ip phone registration rejected IP phone user 389 [67.205.52.172:5092]: registration failed. Reason: No Such Line Configured. IP Lines Registration Status
    New Wed Jun 30 08:36:26 2010 3 SIP ip phone registration rejected IP phone user 388 [67.205.52.172:5092]: registration failed. Reason: No Such Line Configured. IP Lines Registration Status
    New Wed Jun 30 08:36:26 2010 3 SIP ip phone registration rejected IP phone user 387 [67.205.52.172:5092]: registration failed. Reason: No Such Line Configured. IP Lines Registration Status
    New Wed Jun 30 08:36:26 2010 3 SIP ip phone registration rejected IP phone user 386 [67.205.52.172:5092]: registration failed. Reason: No Such Line Configured. IP Lines Registration Status
    New Wed Jun 30 08:36:25 2010 3 SIP ip phone registration rejected IP phone user 385 [67.205.52.172:5092]: registration failed. Reason: No Such Line Configured. IP Lines Registration Status
    New Wed Jun 30 08:36:25 2010 3 SIP ip phone registration rejected IP phone user 384 [67.205.52.172:5092]: registration failed. Reason: No Such Line Configured. IP Lines Registration Status
    New Wed Jun 30 08:36:25 2010 3 SIP ip phone registration rejected IP phone user 383 [67.205.52.172:5092]: registration failed. Reason: No Such Line Configured. IP Lines Registration Status


    An idea of an easy fix:
    Temporary disable an IP when consecutive failed registration attempts are detected

    Also, because such registration attacks generate hundreds of event logs, it would be good to increase size of System Events and to have an ability to auto-download System Events, similar to Call Statistics

    Thank you

  10. #30

    Default

    Hi afuchs,

    When SIP IDS treats SIP registrations as an attack, the IP address sending this Registrations to Quadro(in your case 67.205.52.172) will be added to "Blocked IP" list of Firewall. Do you see 67.205.52.172 there?
    In all cases, Quadro needs time to analyze SIP registers and to detect SIP IDS, all the Registrations came in that time period will generate an appropriate event in the Quadro "Events". So, you can see near a 100 or so events like "SIP ip phone registration rejected".
    We don't like the huge amount of this events and are working on improving this mechanism(we want to decrease this amount of events). As for now, if you see the hackers IP address was added to "Blocked IP" list you have nothing to worry about.

    Regards.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •