Page 3 of 3 FirstFirst 123
Results 21 to 26 of 26

Thread: IPTables problems

  1. #21
    Join Date
    Nov 2012
    Beans
    38

    Re: IPTables problems

    Quote Originally Posted by darkod View Post
    You have a lot of traffic on ports 7777 and 9987, not only INPUT but also OUTPUT.

    I can't judge if this is all attacks. Are you sure you don't have very high legitimate traffic too?
    The traffic on ports 7777 and 9987 are normal because 9987 = teamspeak 3 and 7777 = samp.

  2. #22
    Join Date
    Nov 2012
    Beans
    38

    Re: IPTables problems

    And again... DDoS !!

  3. #23
    Join Date
    Feb 2011
    Location
    Coquitlam, B.C. Canada
    Beans
    1,428
    Distro
    Ubuntu 12.04 Precise Pangolin

    Re: IPTables problems

    Yes, but I think the iptables rule set, such as it is, is doing the right thing. A great many Incoming packets are being dropped.

    I see that your rule set is still somewhat of a mess and the counters have not been reset since yesterday (i.e. we have to subtract yesterday counts from today to know the packets since then).

    If you want to try eliminate the incoming packets: First realize that you might not be able to; It will take a lot of work; You need to identify why they decide to pick on you in the first place; and so on... the plan would evolve based on results.

    For example, there are a lot of ICMP packets. Maybe capture and look at some as to what is going on.

    I might be tempted to directly drop 62.180.0.0/16 and 80.86.146.222 and 95.172.28.178 and 72.0.47.58. Or Just watch them for awhile looking for clues. It is likely that the source ip for 62.180.x.y is forged, maybe others also.
    Does the traffic from204.246.0.9 and 63.245.218.7 (ns2.mozilla.org) make sense to you?

    And / or get help from your hosting site admins. This attack looks pretty harsh.

    What are you running that creates the display you showed in your post # 13? I guess it captures packets much like tcpdump.
    Last edited by Doug S; November 17th, 2012 at 01:35 AM.

  4. #24
    Join Date
    Nov 2012
    Beans
    38

    Re: IPTables problems

    Quote Originally Posted by Doug S View Post
    Yes, but I think the iptables rule set, such as it is, is doing the right thing. A great many Incoming packets are being dropped.

    I see that your rule set is still somewhat of a mess and the counters have not been reset since yesterday (i.e. we have to subtract yesterday counts from today to know the packets since then).

    If you want to try eliminate the incoming packets: First realize that you might not be able to; It will take a lot of work; You need to identify why they decide to pick on you in the first place; and so on... the plan would evolve based on results.

    For example, there are a lot of ICMP packets. Maybe capture and look at some as to what is going on.

    I might be tempted to directly drop 62.180.0.0/16 and 80.86.146.222 and 95.172.28.178 and 72.0.47.58. Or Just watch them for awhile looking for clues. It is likely that the source ip for 62.180.x.y is forged, maybe others also.
    Does the traffic from204.246.0.9 and 63.245.218.7 (ns2.mozilla.org) make sense to you?

    And / or get help from your hosting site admins. This attack looks pretty harsh.

    What are you running that creates the display you showed in your post # 13? I guess it captures packets much like tcpdump.
    Iftop recommended by my VPS Host.

    Thanks.

  5. #25
    Join Date
    Nov 2008
    Location
    Metro Boston
    Beans
    8,764
    Distro
    Kubuntu 14.04 Trusty Tahr

    Re: IPTables problems

    It sounds to me like you have a fundamental misunderstanding of what a firewall can do for you. It cannot do anything about people flooding your IP with DDOS packets. The firewall can ignore them, but the only one who can do something about the traffic itself is your ISP. If people are having problems staying connected because there's too much traffic being directed at your IP, having a firewall will not help with that.

    I'm always amazed by the number of reports of people like you having DOS attacks run against them. I've run public mail and web servers for years and never see much of this sort of activity.
    If you ask for help, please have the courtesy to check for responses and thank the people who helped you.

    Blog · Linode System Administration Guides · Android Apps for Ubuntu Users

  6. #26
    Join Date
    Feb 2011
    Location
    Coquitlam, B.C. Canada
    Beans
    1,428
    Distro
    Ubuntu 12.04 Precise Pangolin

    Re: IPTables problems

    Diogo: Why did you remove that iftop screen shot from post #13?
    Anyway, did you notice the very high traffic incoming from 168.143.82.104 port 50506 to port 7777, with no outgoing traffic on that screen shot? Didn't that seem a little odd?

    Seiji is exactly right. The only reason I was suggesting perhaps continuing to investigate from your end was on the chance that the originating set of packets could be identified. If they were dropped, maybe the entire DDos attack might not start. I have succeeded with such an approach in the past, but it took a lot of work. (in my cases, the actual attack bandwidth was extremely low.)

    For your earlier question, "How to minimize missing real packets": Since your computer gets saturated with packets, I think that all you can do is try to have the most effiecient and minimal iptables rules set possible. Among other things, that means looking up and knowing exactly what ports and for which protocol need to be open. For example for the sa-mp server only 7777 udp needs to be open, so don't bother with 7777 tcp as it adds time to the iptables rule set traversal. It might not make much difference overall, but with this in mind I re-wrote my earlier suggested rule set:
    Code:
    #!/bin/sh
    FWVER=0.02
    #
    # diogo_firewall 2011.11.18 Ver: 0.02
    #       See Ubuntu forums post 12356849
    #       Modify for maximum efficency, minimum time
    #       to traverse the iptables rule set.
    #       To help push out maximum bandwidth limit.
    #
    # diogo_firewall 2011.11.15 Ver: 0.01 Attempt 1.
    #       See Ubuntu forums post 12356849
    #       Quick and dirty
    #       diogo: you might want to reduce the logging.
    echo "Loading diogo_firewall version $FWVER..\n"
    # The location of the iptables program
    #
    IPTABLES=/sbin/iptables
    #Setting the EXTERNAL and INTERNAL interfaces and addresses for the network
    #
    EXTIF="eth0"
    # Temp set to Doug s15 computer. diogo set this right.
    EXTIP="192.168.111.112"
    UNIVERSE="0.0.0.0/0"
    echo "   External Interface: $EXTIF   External IP: $EXTI"
    #Clearing any previous configuration
    #
    echo "  Clearing any existing rules and setting default policy to DROP.."
    # maybe default of ACCEPT will be used until sure things are working
    $IPTABLES -P INPUT DROP
    $IPTABLES -F INPUT
    $IPTABLES -P OUTPUT ACCEPT
    $IPTABLES -F OUTPUT
    $IPTABLES -P FORWARD DROP
    $IPTABLES -F FORWARD
    # Delete user defined chains
    $IPTABLES -X
    # Reset all IPTABLES counters
    $IPTABLES -Z
    #######################################################################
    # INPUT: Incoming traffic from various interfaces.  All rulesets are
    #        already flushed and set to a default policy of DROP.
    #
    # loopback interfaces are valid.
    #
    $IPTABLES -A INPUT -i lo -s $UNIVERSE -d $UNIVERSE -j ACCEPT
    # Block specific jerks.
    #
    # http related
    # for example. Put particular annoying IPs directly here:
    #$IPTABLES -A INPUT -i $EXTIF -s 93.170.1.53 -j DROP
    # A NEW TCP connection requires SYN bit set and FIN,RST,ACK reset.
    #$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "NEW TCP no SYN:" --log-level info
    $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
    # external interface, from any source, for ICMP traffic is valid
    #
    $IPTABLES -A INPUT -i $EXTIF -p ICMP -s $UNIVERSE -d $EXTIP -j ACCEPT
    # Allow any related traffic coming back to the server in.
    #
    #  STATEFULLY TRACKED
    #
    $IPTABLES -A INPUT -i $EXTIF -s $UNIVERSE -d $EXTIP -m state --state ESTABLISHED,RELATED -j ACCEPT
    # ----- Begin OPTIONAL INPUT Section -----
    # SA-MP server
    #
    $IPTABLES -A INPUT -i $EXTIF -m state --state NEW -p udp -s $UNIVERSE -d $EXTIP --dport 7777 -j ACCEPT
    # Teamspeak3
    #
    $IPTABLES -A INPUT -i $EXTIF -m state --state NEW -p udp -s $UNIVERSE -d $EXTIP --dport 9987 -j ACCEPT
    $IPTABLES -A INPUT -i $EXTIF -m state --state NEW -p tcp -s $UNIVERSE -d $EXTIP --dport 10011 -j ACCEPT
    $IPTABLES -A INPUT -i $EXTIF -m state --state NEW -p tcp -s $UNIVERSE -d $EXTIP --dport 30033 -j ACCEPT
    # Minecraft
    # Is it 2555 or 25555??? UDP or TCP or both?
    # Web site says 25565 TCP (???)
    #
    $IPTABLES -A INPUT -i $EXTIF -m state --state NEW -p tcp -s $UNIVERSE -d $EXTIP --dport 25565 -j ACCEPT
    # Secure Shell on port 22.
    #
    # Dynamic Badguy List. Detect and DROP Bad IPs that do password attacks on SSH.
    # Once they are on the BADGUY list then DROP all packets from them.
    $IPTABLES -A INPUT -i $EXTIF -m recent --update --hitcount 3 --seconds 5400 --name BADGUY_SSH -j LOG --log-prefix "SSH BAD:" --log-level info
    $IPTABLES -A INPUT -i $EXTIF -m recent --update --hitcount 3 --seconds 5400 --name BADGUY_SSH -j DROP
    $IPTABLES -A INPUT -i $EXTIF -p tcp -m tcp --dport 22 -m recent --set --name BADGUY_SSH -j ACCEPT
    # ----- End OPTIONAL INPUT Section -----
    #
    echo Loading OUTPUT rulesets...
    #######################################################################
    # OUTPUT: Outgoing traffic from various interfaces.  All rulesets are
    #         already flushed and set to a default policy of DROP.
    #
    # Changed to default ACCEPT policy for maximum effiecency
    # ----- End OPTIONAL OUTPUT Section -----
    #
    #######################################################################
    echo diogo_firewall $FWVER done.
    Example sudo iptables -v -x -n -L output:
    Code:
    doug@s15:~$ sudo iptables -v -x -n -L
    [sudo] password for doug:
    Chain INPUT (policy DROP 19921 packets, 1664560 bytes)
        pkts      bytes target     prot opt in     out     source               destination
         296    14800 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
           8     4744 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags:! 0x17/0x02 state NEW
           0        0 ACCEPT     icmp --  eth0   *       0.0.0.0/0            192.168.111.112
         922   124713 ACCEPT     all  --  eth0   *       0.0.0.0/0            192.168.111.112      state RELATED,ESTABLISHED
           0        0 ACCEPT     udp  --  eth0   *       0.0.0.0/0            192.168.111.112      state NEW udp dpt:7777
           0        0 ACCEPT     udp  --  eth0   *       0.0.0.0/0            192.168.111.112      state NEW udp dpt:9987
           0        0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            192.168.111.112      state NEW tcp dpt:10011
           0        0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            192.168.111.112      state NEW tcp dpt:30033
           0        0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            192.168.111.112      state NEW tcp dpt:25565
           0        0 LOG        all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            recent: UPDATE seconds: 5400 hit_count: 3 name: BADGUY_SSH side: source LOG flags 0 level 6 prefix "SSH BAD:"
           0        0 DROP       all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            recent: UPDATE seconds: 5400 hit_count: 3 name: BADGUY_SSH side: source
           2       92 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22 recent: SET name: BADGUY_SSH side: source
    Chain FORWARD (policy DROP 0 packets, 0 bytes)
        pkts      bytes target     prot opt in     out     source               destination
    Chain OUTPUT (policy ACCEPT 1771 packets, 469746 bytes)
        pkts      bytes target     prot opt in     out     source               destination
    doug@s15:~$

Page 3 of 3 FirstFirst 123

Bookmarks

Posting Permissions

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