really need your help about iptables

really need your help about iptables

[J. Bakshi]

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

[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

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

[Patrick McHardy]

John Lister wrote:
> 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??

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

[John Lister]

----- Original Message ----- 
From: "Patrick McHardy" <kaber@trash.net>
To: "John Lister" <john.lister@kickstone.com>
Cc: <netfilter@vger.kernel.org>
Sent: Tuesday, August 25, 2009 1:48 PM
Subject: Re: Problem with statistic module nth mode


> John Lister wrote:
>> 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??
>
> 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> ...
> --


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

[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/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

[Gáspár Lajos]

Hi!

I have written a target for this:  www.glsys.eu/iface

Swifty

John Lister írta:
> 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/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
> -- 
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Checking line status

[John Lister]

> 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

> Swifty
>
> John Lister írta:
>> 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/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

[Thomas Jacob]

[-- Attachment #1: Type: text/plain, Size: 1458 bytes --]

On Wed, 2009-09-02 at 10:23 +0100, John Lister wrote:
> 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

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5414 bytes --]

Re: Checking line status

[John Lister]

>On Wed, 2009-09-02 at 10:23 +0100, John Lister wrote:
>> 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


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

[John Lister]

>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

[Pascal Hambourg]

Hello,

John Lister a écrit :
> 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)".

[...]
> 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

Isn't something missing in that rule ?
Also, I can see no iptables rule setting mark 222.

> 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

[John Lister]

>John Lister a écrit :
>> 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 :)

>[...]
>> iptables -t mangle -A OUTPUT -m mark --mark 0 -m state --state
>>     -j MARK --set-mark 111

>Isn'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..

>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

[Pascal Hambourg]

John Lister a écrit :
> 
> 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.

>>> iptables -t mangle -A OUTPUT -m mark --mark 0 -m state --state
>>>     -j MARK --set-mark 111
> 
>> Isn'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

[John Lister]

> And the state after --state too.
>   
copy and pasting without looking...
> 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

[Thomas Jacob]

[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]

On Wed, 2009-09-02 at 15:02 +0100, John Lister wrote:
> >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.

> 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

Google dragged up this:

http://rumytaulu.wordpress.com/2009/05/23/linux-loadbalancing-with-two-adsl-modems/


> 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...



[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5414 bytes --]

Re: Checking line status

[John Lister]

>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...


>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

[Tormod Nygård]

Hi

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
> /dev/null 2>&1

      switch=0
  fi

  # Sleep for $interval seconds
  sleep $interval

done

exit 0



Tormod Nygård




On Wed, 2009-09-02 at 10:23 +0100, John Lister wrote:
> 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/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 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: really need your help about iptables

[Oskar Berggren]

Use a higher limit for SYN packets to those services. IIRC your
ruleset from before.

/Oskar


2009/8/25 J. Bakshi <joydeep@infoservices.in>:
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: really need your help about iptables

[J. Bakshi]

Oskar Berggren wrote:
> 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


>
> 2009/8/25 J. Bakshi <joydeep@infoservices.in>:
>   
>> 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 majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>     
>
>   

Re:[possible solution] really need your help about iptables

[J. Bakshi]

J. Bakshi wrote:
> Oskar Berggren wrote:
>   
>> 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
>
>   

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


>   
>> 2009/8/25 J. Bakshi <joydeep@infoservices.in>:
>>   
>>     
>>> 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 majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>>     
>>>       
>>   
>>     
>
>
>