Hi Readers ;) I have to thank you guys, both of you solved my problem ;) Precisely Mr. Jan Engelhardt has post the solution ;) In fact what I was thinking to do in INPUT, thanks to my NON EXPERIENCE, in my case is done in FORWARD as suggested by Jan, and it works MAGNIFICENTLY ;). The request enter the machine in eth0 pass in PREROUTING, enter FORWARD witch DROPs the entered request if the IP match the rule, if not it forward the request to the designeted Apache server. The last question after solution is, FORWAR chain acts same as INPUT whan filtering? Will the header be filtere at the same way as it is setted in INPUT chain? Example iptables -A FORWARD -p tcp --syn -m limit --limit 1/s --limit-burst 4 -j ACCEPT iptables -A FORWARD -p tcp --syn -j DROP Will those rules stop the syn-flooding attack? Another time meny many thanks to both of you ;). Best regards, Auro B. 2011/6/23 Oskar Berggren <oskar.berggren@xxxxxxxxx>: > Eh no.... I'm still not entirely sure what you are trying to achieve > or why you think it cannot be done. > > /Oskar > > > 2011/6/23 Auro Benas <ebay.omg@xxxxxxxxx>: >> Hi Readers, >> thanks you Oskar, so in simple words you are saying that IPTables >> can't do what I have in mind to accive with it. >> >> I'm really sorry about that but at least I know now that I need to >> rethink my server configuration ;). >> >> Many thanks Oskar for your kind help ;) >> >> Best regards, >> Auro B. >> >> 2011/6/22 Oskar Berggren <oskar.berggren@xxxxxxxxx>: >>> No packet will ever traverse more than one of INPUT, FORWARD and >>> OUTPUT. If you DNAT in PREROUTING to divert the traffic to an internal >>> server, it will pass through FORWARD, but not INPUT. Input is for >>> traffic that terminates at the same host. >>> >>> Your log shows the packet in FORWARD, with the modified destination as >>> per you DNAT. >>> >>> /Oskar >>> >>> >>> 2011/6/21 Auro Benas <ebay.omg@xxxxxxxxx>: >>>> Hi Readers, >>>> as first thank you Oskar for your fast reply. >>>> >>>> Maybe I wrote too much stuff on previouse message. >>>> >>>> As first I'll reply to questions you asked me. >>>> >>>>> Are you saying that xx1, xx2, etc. resolve to different IP that are >>>>> all present on interfaces of the FW itself? >>>>> Or are you saying that incoming connections that originate from the IP >>>>> corresponding to xx1 should reach one server, originating from xx2 >>>>> another server, etc.? >>>> >>>> The second one, each third level domain is correlated to a single and >>>> specific server inside the DMZ zone behind the FW, as example: >>>> xx1.domain.com ---> IPGServer 10.10.0.1 >>>> xx2.domain.com ---> IPGServer 10.10.0.2 >>>> xx1.domain.com ---> IPGServer 10.10.0.3 >>>> ---- >>>> x30.domain.com ---> 10.10.0.30 >>>> >>>> >>>> >>>>> If your FW public IP is 1.2.3.4, directing traffic to an internal >>>>> server is simply: >>>>> -t nat -A PREROUTING -j DNAT --to 10.10.0.1 >>>> >>>> Yep that is what I have accived right now. >>>> I need AT LEAST 2 layers of security before going on-line and that >>>> will be accived with the IPGServer AKA FW with IPTables ONLY installed >>>> as >>>> first layer od defence/restriction, after that all the WEB Servers >>>> behind the main FW will have IPTAbles installed to onborad with >>>> EXTREMLY >>>> restrictive rules even more than FW, that will be my second layer of >>>> defence/restrictions. >>>> The first point in all that is that I need as first to filter and LOG >>>> all what comes in from the Internet with FW and to DROP all the IPs >>>> that will dinamically be inserted in the black list rule in filter >>>> table in INPUT chain. >>>> The second point in all this is that WEB Servers behind FW will have >>>> their job to do with Apache/MySQL/PHP installed on board and I >>>> can't waste servers' performances for something that must be done by >>>> the FW that is there simply to execute that kind of work. >>>> >>>>> This handles connection, i.e. traffic in both directions. You do not >>>>> need a separate SNAT rule to handle response traffic for such >>>>> connections. For incoming traffic, the FILTER part and the web server >>>>> will see the original source IP. As long as the servers default >>>>> gateway point to your FW, return traffic will be handled properly >>>>> without hiding/translating the true source address. >>>>> >>>>> SNAT rules will be needed to make connections initiated from your >>>>> servers, (such as apt-get update), work. >>>> >>>> Well that is something that I haven't know before, I'm a rookie, thanks ;) >>>> >>>> >>>>> PREROUTING does not make traffic skip the FILTER chains. Note that you >>>>> also have the raw table to filter before connection tracking and nat >>>>> occurs. >>>> I'm sorry but I think that I don't understand that point. >>>> From what I see from my logs and what have I tried I see that the >>>> filter table and >>>> INPUT chanin restrictions even if setted aren't taken in consideration. >>>> I copy/paste you here my logs: >>>> ================================================= >>>> Jun 21 20:20:54 ggout001 GG-PREROUTING IN=eth0 OUT= >>>> MAC=00:0f:1f:f9:33:aa:00:09:41:42:b8:46:08:00 SRC=192.168.1.106 >>>> DST=192.168.1.90 LEN=64 TOS=00 PREC=0x00 TTL=128 ID=9509 DF PROTO=TCP >>>> SPT=3285 DPT=80 SEQ=2153389899 ACK=0 WINDOW=65535 SYN URGP=0 >>>> Jun 21 20:20:54 ggout001 GG-FORWARD IN=eth0 OUT=eth1 >>>> MAC=00:0f:1f:f9:33:aa:00:09:41:42:b8:46:08:00 SRC=192.168.1.106 >>>> DST=10.10.0.1 LEN=64 TOS=00 PREC=0x00 TTL=127 ID=9509 DF PROTO=TCP >>>> SPT=3285 DPT=80 SEQ=2153389899 ACK=0 WINDOW=65535 SYN URGP=0 >>>> Jun 21 20:20:54 ggout001 GG-POSTROUTIN IN= OUT=eth1 MAC= >>>> SRC=192.168.1.106 DST=10.10.0.1 LEN=64 TOS=00 PREC=0x00 TTL=127 >>>> ID=9509 DF PROTO=TCP SPT=3285 DPT=80 SEQ=2153389899 ACK=0 WINDOW=65535 >>>> SYN URGP=0 >>>> ================================================= >>>> >>>> >>>> I'll olso copy/pase my actual IPTables rules just to make easiear your >>>> eventual help ;) >>>> NOTE: >>>> I leaved the test rule that will DROP any connection entering in eth0, >>>> that was happend for >>>> my SSH connection, or SFTP connection that arent prerouted while the >>>> HTTP connections passes as no rule is setted on filter. >>>> ================================================= >>>> # Generated by iptables-save v1.4.4 on Tue Jun 21 20:37:57 2011 >>>> *filter >>>> :INPUT ACCEPT [300:34601] >>>> :FORWARD ACCEPT [5:320] >>>> :OUTPUT ACCEPT [3346:16521465] >>>> -A INPUT -j ULOG --ulog-prefix "GG-INPUT" >>>> -A INPUT -i eth0 -p tcp -j DROP >>>> -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT >>>> -A FORWARD -j ULOG --ulog-prefix "GG-FORWARD" >>>> -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT >>>> -A FORWARD -i eth1 -o eth0 -j ACCEPT >>>> -A OUTPUT -j ULOG --ulog-prefix "GG-OUTPUT" >>>> COMMIT >>>> # Completed on Tue Jun 21 20:37:57 2011 >>>> # Generated by iptables-save v1.4.4 on Tue Jun 21 20:37:57 2011 >>>> *nat >>>> :PREROUTING ACCEPT [148:18297] >>>> :POSTROUTING ACCEPT [1:64] >>>> :OUTPUT ACCEPT [3:216] >>>> -A PREROUTING -j ULOG --ulog-prefix "GG-PREROUTING" >>>> -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT >>>> --to-destination 10.10.0.1 >>>> -A POSTROUTING -j ULOG --ulog-prefix "GG-POSTROUTIN" >>>> -A POSTROUTING -o eth0 -j MASQUERADE >>>> COMMIT >>>> # Completed on Tue Jun 21 20:37:57 2011 >>>> ================================================= >>>> >>>> NOTE: >>>> That's a working DMZ zone, but I need something more from this >>>> configuration and from the server that will host that configuration. >>>> Filter as first >>>> after filtering routing to the destinaion web server, that's all. >>>> >>>> I hope that you will understand what I need and you will point me in >>>> the right direction. >>>> >>>> Thank you in advanced for your kind help ;). >>>> >>>> Best regards, >>>> Auro B. >>>> >>>> >>>> >>>> >>>> 2011/6/21 Oskar Berggren <oskar.berggren@xxxxxxxxx>: >>>>> Are you saying that xx1, xx2, etc. resolve to different IP that are >>>>> all present on interfaces of the FW itself? >>>>> Or are you saying that incoming connections that originate from the IP >>>>> corresponding to xx1 should reach one server, originating from xx2 >>>>> another server, etc.? >>>>> >>>>> If your FW public IP is 1.2.3.4, directing traffic to an internal >>>>> server is simply: >>>>> -t nat -A PREROUTING -j DNAT --to 10.10.0.1 >>>>> >>>>> This handles connection, i.e. traffic in both directions. You do not >>>>> need a separate SNAT rule to handle response traffic for such >>>>> connections. For incoming traffic, the FILTER part and the web server >>>>> will see the original source IP. As long as the servers default >>>>> gateway point to your FW, return traffic will be handled properly >>>>> without hiding/translating the true source address. >>>>> >>>>> SNAT rules will be needed to make connections initiated from your >>>>> servers, (such as apt-get update), work. >>>>> >>>>> >>>>> PREROUTING does not make traffic skip the FILTER chains. Note that you >>>>> also have the raw table to filter before connection tracking and nat >>>>> occurs. >>>>> >>>>> /Oskar >>>> >>> >> > -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
