Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I replaced an IVR machine for incoming call after going down. It is running asterisk 1.4.23 on ubunutu 10.04 I decided to put the server behind iptables because my server was under brute force attack. eth0 is my private card and eth1 is the public one.

Here are my rules :

# only allow PING on PRIVATE NET
iptables -A INPUT -p icmp -i eth0 -j ACCEPT
# allow all the lo traffic on loopback.
iptables -A INPUT -i lo -j ACCEPT
# START OPEN PORTS
#=================
#SSH (22)
iptables -A INPUT -p tcp -i eth0 --dport 22 -j ACCEPT
#iptables -A INPUT -p tcp -i eth1 --dport 22 -j ACCEPT
#SAMBA: netbios (139) , microsoft-ds (445) -- only on internal
iptables -A INPUT -p tcp -i eth0 --dport 139 -j ACCEPT
iptables -A INPUT -p tcp -i eth0 --dport 445 -j ACCEPT
#ASTERISK
  # SIP (UDP 5060)
      #Port 5060 must be open for SIP.
      #Ports 1024 - 64000 should be open for Media.
  #iptables -A INPUT -p tcp -m tcp -i eth1 --dport 5060 -j ACCEPT
  #iptables -A INPUT -p udp -m udp -i eth1 --dport 1024:64000 -j ACCEPT

      iptables -A INPUT -p udp -m udp -i eth1 --dport 10000:20000 -j ACCEPT
      #iptables -A INPUT -p udp -m udp --dport 5060 -j ACCEPT

      iptables -A INPUT -p udp -m udp -i eth1 -s xxx.xx.xx.xx --dport 5060 -j ACCEPT
      iptables -A INPUT -p udp -m udp -i eth1 -s xx.xx.xx.xxx --dport 5060 -j ACCEPT

      iptables -A INPUT -p tcp -m tcp -i eth1 -s xxx.xx.xx.xx --dport 5060 -j ACCEPT
      iptables -A INPUT -p tcp -m tcp -i eth1 -s xx.xx.xx.xxx --dport 5060 -j ACCEPT      
#END ASTERISK

# END OPEN PORTS
#Deny everything else
iptables -A INPUT -p all -i eth1 -j DROP

xxx.xx.xx.xx and xx.xx.xx.xxx are the IP of my SIP providers, I pinged the The SIP domains

Our customer are experiencing busy signal when dialing our numbers, I checked the logs and I saw various warnings. Here are some issues I noticed in the logs:

[Jan 24 05:02:00] WARNING[939] chan_sip.c: Maximum retries exceeded on transmission 245102dwdw45f4f51f5df5s3@xx.xx.xx.xxx for seqno 102 (Critical Response) -- See doc/sip-retransmit.txt.
[Jan 24 05:02:00] WARNING[939] chan_sip.c: Hanging up call 245102dwdw45f4f51f5df5s3@xx.xx.xx.xxx - no reply to our critical packet (see doc/sip-retransmit.txt).
[Jan 24 06:29:37] WARNING[939] chan_sip.c: Got 200 OK on REGISTER, but there isn't a registry entry for 'mpdhbf867' (we probably already got the OK)
[Jan 24 06:34:07] WARNING[939] chan_sip.c: Got 200 OK on REGISTER, but there isn't a registry entry for 'mpdhbf867' (we probably already got the OK)
[Jan 24 17:00:32] NOTICE[939] chan_sip.c:    -- Registration for 'mpdhbf867@provider-domain.com' timed out, trying again (Attempt #1)

When I turn off my iptables, everything goes back to normal , and the phone call never drops or ring busy. It's a hard trade off because I do not want to leave my server open to the public internet. I am open to alter

share|improve this question
    
Somebody is saving you "huge revenue losses" for free. Would you mind, please, to accept the answer at least? –  jap1968 Jan 24 '13 at 23:15

1 Answer 1

up vote 3 down vote accepted

You're missing a rule to accept traffic based on existing traffic (the rule that makes iptables stateful). This should be your very first rule:

-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

While you're at it, you should also check to make sure you have the correct IP addresses for the incoming SIP traffic you're expecting. If the upstream provider ever changes them, you're in trouble.

share|improve this answer
    
Thank you so much, I didnt have much rep at the time. You have no idea how this helped me. Thanks again god bless you –  meda Feb 5 at 18:01

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.