really need your help about iptables
Dear list,
I really really need your help to configure iptables to cope with "connection time out problem" Here what actually the situation is.
I have configured iptables to drop nmap and other port scanning techniques ( collected from internet, like XMAS scan, FIN scan etc...). If I run nmap against the server ( like nmap -P0 <myserver> or nmap -P0 -sT <myserver> ) then the firewall successfully dropping the scan packets and make the nmap scan to wait for *looooong* . Good. But on the other hand the http and mail server running on the server providing "time out error" hence it is not possible to connect the mail /apache and other services running on that server during port scanning against it. Could any one kindly suggest how to cope with this situiation ?
Thanks for your time.
Problem with statistic module nth mode
Hi, I have a set of rules as follows
iptables -t nat -N SNAT1
iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 0 -j SNAT --to-source 87.194.x.1 iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 1 -j SNAT --to-source 87.194.x.2 iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 2 -j SNAT --to-source 87.194.x.3 iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 3 -j SNAT --to-source 87.194.x.4 iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 4 -j SNAT --to-source 87.194.x.5
iptables -t nat -A POSTROUTING -o eth1 -j SNAT1
...
iptables -t nat -A POSTROUTING -o eth1 -j LOG --log-prefix "Failed to nat"
The last rule is occasionally triggered, is this a bug? I could put a catch all there, but the 5 "nth" rules should cover all possible cases or have I missed something obvious??
I'm running ubuntu hardy, kernel 2.6.24-24 and iptables 3.8
Thanks
John
Re: Problem with statistic module nth mode
Quoted 14 lines · John Lister
Hi, I have a set of rules as follows
iptables -t nat -N SNAT1
iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 0 -j SNAT --to-source 87.194.x.1
iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 1 -j SNAT --to-source 87.194.x.2
iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 2 -j SNAT --to-source 87.194.x.3
iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 3 -j SNAT --to-source 87.194.x.4
iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 4 -j SNAT --to-source 87.194.x.5
Quoted 8 lines
iptables -t nat -A POSTROUTING -o eth1 -j SNAT1
...
iptables -t nat -A POSTROUTING -o eth1 -j LOG --log-prefix "Failed to nat"The last rule is occasionally triggered, is this a bug? I could put a catch all there, but the 5 "nth" rules should cover all possible cases or have I missed something obvious??
This is a common misunderstanding - the counters are not shared and since the rules are all terminal, the second rule will only see the packets not caught by the first rule etc. So the proportions need to be adjusted for the "missing" packets:
... --mode nth --every 5 ...
... --mode nth --every 4 ...
... --mode nth --every 3 ...
... --mode nth --every 2 ...
... <unconditional> ...
Re: Problem with statistic module nth mode
----- Original Message ----- From: "Patrick McHardy" <[email protected]>
To: "John Lister" <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, August 25, 2009 1:48 PM
Subject: Re: Problem with statistic module nth mode
Quoted 29 lines
Quoted 14 lines · John Lister
Hi, I have a set of rules as follows
iptables -t nat -N SNAT1
iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 0 -j SNAT --to-source 87.194.x.1
iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 1 -j SNAT --to-source 87.194.x.2
iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 2 -j SNAT --to-source 87.194.x.3
iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 3 -j SNAT --to-source 87.194.x.4
iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 4 -j SNAT --to-source 87.194.x.5Quoted 8 lines
iptables -t nat -A POSTROUTING -o eth1 -j SNAT1
...
iptables -t nat -A POSTROUTING -o eth1 -j LOG --log-prefix "Failed to nat"The last rule is occasionally triggered, is this a bug? I could put a catch all there, but the 5 "nth" rules should cover all possible cases or have I missed something obvious??
This is a common misunderstanding - the counters are not shared and since the rules are all terminal, the second rule will only see the packets not caught by the first rule etc. So the proportions need to be adjusted for the "missing" packets:
Quoted 6 lines
... --mode nth --every 5 ...
... --mode nth --every 4 ...
... --mode nth --every 3 ...
... --mode nth --every 2 ...
... <unconditional> ...
--
Thanks for that, I was slightly confused - I had originally done it using "random" with decreasing percentages but wanted to use nth.
I'll let you know how I get on...
JOHN
Checking line status
In reply to Patrick McHardyHi, I have a multihomed machine to which i'd like to check the status of each line periodically. I want to do this so that I can modify the iptables rules and send new connections out over the active lines and restore service when the line comes back up.
I thought I could use ping with the -I option, but that doesn't seem to work, it always uses the default route. However if I get rid of the default route and modify the rules to match the packets I get a "network unreachable" message without it ever hitting iptables. For example adding something like this never gets matched for the ping.
iptables -t mangle -I OUTPUT -j LOG --log-prefix "output: "
Normally ping results in ICMP messages being traversed, but not this time.
Could someone explain what is going on and I'd be grateful if there were any suggestions on other ways to detect if a line is down - simply looking in /proc/net/dev or similar wouldn't help as the local connection is likely to be up, but the physical line to the ISP may be down.
Thanks
John
Re: Checking line status
Hi!
I have written a target for this: www.glsys.eu/iface
Swifty
John Lister írta:
Quoted 19 lines
Hi, I have a multihomed machine to which i'd like to check the status of each line periodically. I want to do this so that I can modify the iptables rules and send new connections out over the active lines and restore service when the line comes back up.
I thought I could use ping with the -I option, but that doesn't seem to work, it always uses the default route. However if I get rid of the default route and modify the rules to match the packets I get a "network unreachable" message without it ever hitting iptables. For example adding something like this never gets matched for the ping.
iptables -t mangle -I OUTPUT -j LOG --log-prefix "output: "
Normally ping results in ICMP messages being traversed, but not this time.
Could someone explain what is going on and I'd be grateful if there were any suggestions on other ways to detect if a line is down - simply looking in
/proc/net/devor similar wouldn't help as the local connection is likely to be up, but the physical line to the ISP may be down.Thanks
John
Signature · 3 lines
To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Checking line status
Quoted 1 line
I have written a target for this: www.glsys.eu/iface
Thanks for your reply, I'm not sure this would help me in my situation for 2 reasons:
Firstly doesn't it just report on the state of the interface, I need to know if any intermediary router/line is down after the interface, this is why i was using ping to check known remote sites.
Secondly my rules are fairly complex and trying to design in dynamic checks in the ruleset is probably too complicated. For example i have 4 lines at the minute which are load balanced, i would need to repeat the rules 15 times to cover all combinations of lines up/down. It seems simpler to generate a new ruleset based on the active lines when a change is detected.
any other ideas gratefully received
Quoted 23 lines
Swifty
John Lister írta:
Quoted 20 lines
Hi, I have a multihomed machine to which i'd like to check the status of each line periodically. I want to do this so that I can modify the iptables rules and send new connections out over the active lines and restore service when the line comes back up.
I thought I could use ping with the -I option, but that doesn't seem to work, it always uses the default route. However if I get rid of the default route and modify the rules to match the packets I get a "network unreachable" message without it ever hitting iptables. For example adding something like this never gets matched for the ping.
iptables -t mangle -I OUTPUT -j LOG --log-prefix "output: "
Normally ping results in ICMP messages being traversed, but not this time.
Could someone explain what is going on and I'd be grateful if there were any suggestions on other ways to detect if a line is down - simply looking in
/proc/net/devor similar wouldn't help as the local connection is likely to be up, but the physical line to the ISP may be down.
Thanks
John
Re: Checking line status
In reply to John ListerQuoted 10 lines · John Lister
Hi, I have a multihomed machine to which i'd like to check the status of each line periodically. I want to do this so that I can modify the iptables rules and send new connections out over the active lines and restore service when the line comes back up.
I thought I could use ping with the -I option, but that doesn't seem to work, it always uses the default route. However if I get rid of the default route and modify the rules to match the packets I get a "network unreachable" message without it ever hitting iptables. For example adding something like this never gets matched for the ping.
You need to ensure that your ping packets come from the right IP and get routed to the right interface. Useless comment maybe, but without you posting your details here it is difficult to say more specific things ;)
Binding to the right IP is accomplished with ping -I <IP>, just as you do. But then you need some sort of route to send this packet to the right interface (-I has nothing to do with that). One way to achieve this could be using things like scapy where basically roll your own ping tool and just force the packet out on the right interface.
Or you could use policy routing like this:
/sbin/ip rule add from <Secondary Interface IP> pref 10000 table 100
/sbin/ip route add default via <Secondary Next HOP IP> table 100
Thomas
Re: Checking line status
Quoted 24 lines · John Lister
Quoted 10 lines
Hi, I have a multihomed machine to which i'd like to check the status of each line periodically. I want to do this so that I can modify the iptables rules and send new connections out over the active lines and restore service when the line comes back up.
I thought I could use ping with the -I option, but that doesn't seem to work, it always uses the default route. However if I get rid of the default route and modify the rules to match the packets I get a "network unreachable" message without it ever hitting iptables. For example adding something like this never gets matched for the ping.
You need to ensure that your ping packets come from the right IP and get routed to the right interface. Useless comment maybe, but without you posting your details here it is difficult to say more specific things ;)
Binding to the right IP is accomplished with ping -I <IP>, just as you do. But then you need some sort of route to send this packet to the right interface (-I has nothing to do with that). One way to achieve this could be using things like scapy where basically roll your own ping tool and just force the packet out on the right interface.
Quoted 5 lines
Or you could use policy routing like this:
/sbin/iprule add from <Secondary Interface IP> pref 10000 table 100
/sbin/iproute add default via <Secondary Next HOP IP> table 100
Cheers, that did the trick, didn't realise that was possible.. Just got to make sure all my other rules (both firewall and routing) are still working -
John
Re: Checking line status
In reply to Thomas JacobQuoted 4 lines
You need to ensure that your ping packets come from the right IP and get routed to the right interface. Useless comment maybe, but without you posting your details here it is difficult to say more specific things ;)
One more thing, I had this (simplified) configuration, but none of the rules seem to be triggered, I thought local packets went through this chain
mangle(OUTPUT) -> nat (OUTPUT) -> OUTPUT -> routing decision -> mangle (POSTROUTING) -> nat (POSTROUTING)
ip route add 87.194.A.B/22 dev eth1 table 111 ip route add 192.168.2.0/24 dev eth0 table 111 ip route add default via 87.194.a.b dev eth1 table 111
ip route add 94.30.X.Y/29 dev eth4 table 222 ip route add 192.168.2.0/24 dev eth0 table 222 ip route add default via 94.30.x.y dev eth4 table 222
ip rule add fwmark 111 table 111
ip rule add fwmark 222 table 222
iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark
iptables -t mangle -A OUTPUT -m mark --mark 0 -m state --state NEW -m statistic --mode nth --every 2 --packet 0 -j MARK --set-mark 111 iptables -t mangle -A OUTPUT -m mark --mark 0 -m state --state
-j MARK --set-mark 111
iptables -t mangle -A OUTPUT -j CONNMARK --save-mark
iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source 87.194.a.b iptables -t nat -A POSTROUTING -o eth4 -j SNAT --to-source 94.30.x.y
I would hope that the first set of iptables rules mark the packets before the routing rules forward them on their way (via a bit of SNATting), however it looks like the mangle OUTPUT table is skipped and no marks are added...
Thanks
John
Re: Checking line status
Hello,
Quoted 4 lines · John Lister
I thought local packets went through this chain
mangle(OUTPUT) -> nat (OUTPUT) -> OUTPUT -> routing decision -> mangle (POSTROUTING) -> nat (POSTROUTING)
Actually there is an initial decision routing when the packet is created before the OUTPUT chains, in order to select the output interface and source address. Also after "nat (OUTPUT)" it should be "filter (OUTPUT)".
[...]
Quoted 8 lines
ip rule add fwmark 111 table 111
ip rule add fwmark 222 table 222iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark iptables -t mangle -A OUTPUT -m mark --mark 0 -m state --state NEW -m statistic --mode nth --every 2 --packet 0 -j MARK --set-mark 111 iptables -t mangle -A OUTPUT -m mark --mark 0 -m state --state
-j MARK --set-mark 111
Isn't something missing in that rule ? Also, I can see no iptables rule setting mark 222.
Quoted 2 lines
I would hope that the first set of iptables rules mark the packets before the routing rules forward them on their way
This is normally what happens.
Re: Checking line status
Quoted 9 lines
Quoted 4 lines · John Lister
I thought local packets went through this chain
mangle(OUTPUT) -> nat (OUTPUT) -> OUTPUT -> routing decision -> mangle (POSTROUTING) -> nat (POSTROUTING)
Actually there is an initial decision routing when the packet is created before the OUTPUT chains, in order to select the output interface and source address. Also after "nat (OUTPUT)" it should be "filter (OUTPUT)".
Ah, that sort of makes sense... I'd assumed the source address wasn't set until the routing decision later in the list...
I'd shortened it without the filter part as you don't need to specify the table :)
Quoted 5 lines
[...]
Quoted 2 lines
iptables -t mangle -A OUTPUT -m mark --mark 0 -m state --state
-j MARK --set-mark 111Isn't something missing in that rule ?
I'm guessing you mean the statistic bit? It isn't needed as the first will have set the mark to be non zero, but i guess it should be there for consistency..
Quoted 1 line
Also, I can see no iptables rule setting mark 222.
cut and paste error, last line should be 222
Thanks
John
Re: Checking line status
Quoted 3 lines · John Lister
I'd shortened it without the filter part as you don't need to specify the table :)
Only in the userland tools. In the kernel there is no default table.
Quoted 5 lines
Quoted 4 lines
Quoted 2 lines
iptables -t mangle -A OUTPUT -m mark --mark 0 -m state --state
-j MARK --set-mark 111Isn't something missing in that rule ?
I'm guessing you mean the statistic bit?
And the state after --state too.
Do your MARK rules match some packets (counters increase) ?
Re: Checking line status
Quoted 3 lines
And the state after --state too.
copy and pasting without looking...
Quoted 2 lines
Do your MARK rules match some packets (counters increase) ?
I haven't checked this, but i did have similar rules which wrote to the log file and these were never triggered...
Re: Checking line status
In reply to John ListerQuoted 9 lines · John Lister
Quoted 4 lines
You need to ensure that your ping packets come from the right IP and get routed to the right interface. Useless comment maybe, but without you posting your details here it is difficult to say more specific things ;)
One more thing, I had this (simplified) configuration, but none of the rules seem to be triggered, I thought local packets went through this chain
mangle(OUTPUT) -> nat (OUTPUT) -> OUTPUT -> routing decision -> mangle (POSTROUTING) -> nat (POSTROUTING)
Nope: The (initial) routing decision is taken first and then the chains are traversed as follows.
http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html#section3
But apparently when you set fwmarks the kernel then reconsiders its routing decision later on, don't ask me how that works, maybe some of the developers can answer that.
Quoted 11 lines
ip route add 87.194.A.B/22 dev eth1 table 111 ip route add 192.168.2.0/24 dev eth0 table 111 ip route add default via 87.194.a.b dev eth1 table 111
ip route add 94.30.X.Y/29 dev eth4 table 222 ip route add 192.168.2.0/24 dev eth0 table 222 ip route add default via 94.30.x.y dev eth4 table 222
ip rule add fwmark 111 table 111
ip rule add fwmark 222 table 222
Quoted 6 lines
iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark iptables -t mangle -A OUTPUT -m mark --mark 0 -m state --state NEW -m statistic --mode nth --every 2 --packet 0 -j MARK --set-mark 111 iptables -t mangle -A OUTPUT -m mark --mark 0 -m state --state
-j MARK --set-mark 111iptables -t mangle -A OUTPUT -j CONNMARK --save-mark
Google dragged up this:
http://rumytaulu.wordpress.com/2009/05/23/linux-loadbalancing-with-two-adsl-modems/
Quoted 7 lines
iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source 87.194.a.b iptables -t nat -A POSTROUTING -o eth4 -j SNAT --to-source 94.30.x.y
I would hope that the first set of iptables rules mark the packets before the routing rules forward them on their way (via a bit of SNATting), however it looks like the mangle OUTPUT table is skipped and no marks are added...
Re: Checking line status
Quoted 4 lines
Nope: The (initial) routing decision is taken first and then the chains are traversed as follows.
http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html#section3
Odd, the diagram I was using differed in where the routing decision was made. But that seems to fit more with what is happening...
Quoted 7 lines
But apparently when you set fwmarks the kernel then reconsiders its routing decision later on, don't ask me how that works, maybe some of the developers can answer that.
Google dragged up this:
http://rumytaulu.wordpress.com/2009/05/23/linux-loadbalancing-with-two-adsl-modems/
Cheers for the link, I think i'd read that before and others. My rules are similar (if expanded for more interfaces), that works fine for forwarded packets (as does mine) but not locally generated ones - unless you have a default route in. I've had trouble load balancing locally sourced packets - although I will only be using them to test the lines and modify the rules if a line goes down..
I'll post the script once i've tested things.
Thanks
Re: Checking line status
In reply to John ListerHi
I do what you try at a couple of networks.
I have one IP-address outside my networks that I use to ping to check if a link is good. I do some counting of packet loss before switching routes. The IP-address I use to check routes is always routed out of the preferred route and not the default route. I switch route based on packet loss.
The script I use is meant to choose between two bad links where I prefer one of them, you should change and tune it to fit your needs. This is not a script to check if an interface is down. The script never stops, you have to use <ctrl-c>. It could probably be done more elegant, but it fit my needs.
#!/bin/sh
# An IP-address outside our net, used to check the link. target=xxx.xxx.xxx.xxx
# Preferred route
route1=xxx.xxx.xxx.xxx
# Backup route
route2=xxx.xxx.xxx.xxx
interval=1
pingfail=5
switchback=100
# Internal variables
switch=0
successcounter=0
# Delete any existing route to $target and add one trought $route1 if ( ip route | grep $target ) ; then
ip route del $target
fi
ip route add $target via $route1
if ( ip route | grep "default via $route1" > /dev/null 2>&1 ) ; then
echo $(date) - Starting on $route1
else
echo $(date) - Starting on $route2
fi
while [ 1 ] ; do
if ( ! ping -c $pingfail $target > /dev/null 2>&1 ) ; then
if ( ip route | grep "default via $route1" > /dev/null 2>&1 ) ;
then
# We are using the prefered route, switch to route2 switch=1
fi
successcounter=0
else
successcounter=$( echo $successcounter+1 | bc )
if ( ip route | grep "default via $route2" > /dev/null 2>&1 ) ;then
# We are not using the prefered route
if [ $switchback == $successcounter ] ; then
# We have enough success pings to switch back switch=1
fi
fi
fi
if [ $switch == 1 ] ; then
# Switch route
if ( ip route | grep "default via $route2" > /dev/null 2>&1 ) ;
then
echo $(date) - Switching to $route1
ip route del default via $route2
ip route add default via $route1
else
echo $(date) - Switching to $route2
ip route del default via $route1
ip route add default via $route2
fi
# Flush routing cache
ip route flush cache
# HUP openvpn to reset connection
ps ax | grep [o]penvpn | awk '{ print $1 }' | xargs kill -HUP
Quoted 1 line
/dev/null2>&1
switch=0
fi
# Sleep for $interval seconds
sleep $interval
done
exit 0
Tormod Nygård
Quoted 29 lines · John Lister
Hi, I have a multihomed machine to which i'd like to check the status of each line periodically. I want to do this so that I can modify the iptables rules and send new connections out over the active lines and restore service when the line comes back up.
I thought I could use ping with the -I option, but that doesn't seem to work, it always uses the default route. However if I get rid of the default route and modify the rules to match the packets I get a "network unreachable" message without it ever hitting iptables. For example adding something like this never gets matched for the ping.
iptables -t mangle -I OUTPUT -j LOG --log-prefix "output: "
Normally ping results in ICMP messages being traversed, but not this time.
Could someone explain what is going on and I'd be grateful if there were any suggestions on other ways to detect if a line is down - simply looking in
/proc/net/devor similar wouldn't help as the local connection is likely to be up, but the physical line to the ISP may be down.Thanks
John
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Use a higher limit for SYN packets to those services. IIRC your ruleset from before.
/Oskar
2009/8/25 J. Bakshi <[email protected]>:
Quoted 21 lines
Dear list,
I really really need your help to configure iptables to cope with "connection time out problem" Here what actually the situation is.
I have configured iptables to drop nmap and other port scanning techniques ( collected from internet, like XMAS scan, FIN scan etc...). If I run nmap against the server ( like nmap -P0 <myserver> or nmap -P0 -sT <myserver> ) then the firewall successfully dropping the scan packets and make the nmap scan to wait for *looooong* . Good. But on the other hand the http and mail server running on the server providing "time out error" hence it is not possible to connect the mail /apache and other services running on that server during port scanning against it. Could any one kindly suggest how to cope with this situiation ?
Thanks for your time.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 5 lines · Oskar Berggren
Use a higher limit for SYN packets to those services. IIRC your ruleset from before.
/Oskar
Hello,
Thanks for your hint. I have googled based on your hint and found a lot of solution for rate limit incoming connection. one ruleset valid for me are
```````````````````````` iptables -I INPUT -p tcp --dport 995 -i eth0 -m state --state NEW -m recent \ --set iptables -I INPUT -p tcp --dport 995 -i eth0 -m state --state NEW -m recent \ --update --seconds 60 --hitcount 4 -j DROP iptables -I INPUT -p tcp --dport 995 -i eth0 -j ACCEPT `````````````````````````````````
But the problem with my iptables is default policy--> drop. I have also tested with
```````````` iptables -A INPUT -i eth0 -m state --state NEW -p tcp --dport 995 -m limit --limit 1/minute --limit-burst 2 -j ACCEPT ``````````
This works fine and limiting the connection 1/min but a brute force attack ( like nmap scan) make the port not useable any more.
What can be the solution for such an iptables ?
Thanks
Quoted 27 lines
2009/8/25 J. Bakshi <[email protected]>:
Quoted 22 lines
Dear list,
I really really need your help to configure iptables to cope with "connection time out problem" Here what actually the situation is.
I have configured iptables to drop nmap and other port scanning techniques ( collected from internet, like XMAS scan, FIN scan etc...). If I run nmap against the server ( like nmap -P0 <myserver> or nmap -P0 -sT <myserver> ) then the firewall successfully dropping the scan packets and make the nmap scan to wait for *looooong* . Good. But on the other hand the http and mail server running on the server providing "time out error" hence it is not possible to connect the mail /apache and other services running on that server during port scanning against it. Could any one kindly suggest how to cope with this situiation ?
Thanks for your time.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 34 lines · J. Bakshi
Quoted 6 lines · Oskar Berggren
Use a higher limit for SYN packets to those services. IIRC your ruleset from before.
/Oskar
Hello,
Thanks for your hint. I have googled based on your hint and found a lot of solution for rate limit incoming connection. one ruleset valid for me are
```````````````````````` iptables -I INPUT -p tcp --dport 995 -i eth0 -m state --state NEW -m recent \ --set iptables -I INPUT -p tcp --dport 995 -i eth0 -m state --state NEW -m recent \ --update --seconds 60 --hitcount 4 -j DROP iptables -I INPUT -p tcp --dport 995 -i eth0 -j ACCEPT `````````````````````````````````But the problem with my iptables is default policy--> drop. I have also tested with
```````````` iptables -A INPUT -i eth0 -m state --state NEW -p tcp --dport 995 -m limit --limit 1/minute --limit-burst 2 -j ACCEPT ``````````
Quoted 8 lines
This works fine and limiting the connection 1/min but a brute force attack ( like nmap scan) make the port not useable any more.
What can be the solution for such an iptables ?
Thanks
One possible solution might be for a default *dropped* firewall; placing the incoming rate limit rules before syn flood protection and port scanner protection rules. Like
```````````````````` rules set to make default polict drop ## limiting incoming pop3s connection iptables -A INPUT -i eth0 -m state --state NEW -p tcp --dport 995 -m limit --limit 10/minute --limit-burst 2 -j ACCEPT limiting other incoming connection ruleset for syn-flood prevention ruleset to delayed nmap scan etc... ````````````````````````
Please suggest if my approach is right.
Thanks
Quoted 32 lines
Quoted 29 lines
2009/8/25 J. Bakshi <[email protected]>:
Quoted 23 lines
Dear list,
I really really need your help to configure iptables to cope with "connection time out problem" Here what actually the situation is.
I have configured iptables to drop nmap and other port scanning techniques ( collected from internet, like XMAS scan, FIN scan etc...). If I run nmap against the server ( like nmap -P0 <myserver> or nmap -P0 -sT <myserver> ) then the firewall successfully dropping the scan packets and make the nmap scan to wait for *looooong* . Good. But on the other hand the http and mail server running on the server providing "time out error" hence it is not possible to connect the mail /apache and other services running on that server during port scanning against it. Could any one kindly suggest how to cope with this situiation ?
Thanks for your time.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html