* allow range syntax - perplexed
@ 2004-06-15 17:00 Jonathan Villa
2004-06-15 17:19 ` Cedric Blancher
` (2 more replies)
0 siblings, 3 replies; 22+ messages in thread
From: Jonathan Villa @ 2004-06-15 17:00 UTC (permalink / raw)
To: netfilter
To my understanding the following will allow any address in the x.x.x.0
block access
$IPTABLES -A INPUT -p tcp --dport 22 -s xxx.xxx.xx.0/24 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 3306 -s xxx.xxx.xx.0/24 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 80 -s xxx.xxx.xx.0/24 -j ACCEPT
It of course is not working...
my temporary solution : looping through 1-254
not very nice when I need to show someone the current rules.
-confused
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: allow range syntax - perplexed 2004-06-15 17:00 allow range syntax - perplexed Jonathan Villa @ 2004-06-15 17:19 ` Cedric Blancher 2004-06-15 17:47 ` Jonathan Villa 2004-06-15 17:52 ` Jonathan Villa 2004-06-15 17:58 ` allow range syntax - perplexed John A. Sullivan III 2004-06-15 18:52 ` Antony Stone 2 siblings, 2 replies; 22+ messages in thread From: Cedric Blancher @ 2004-06-15 17:19 UTC (permalink / raw) To: Jonathan Villa; +Cc: netfilter Le mar 15/06/2004 à 19:00, Jonathan Villa a écrit : > my temporary solution : looping through 1-254 As someone pointed out yesterday, you can use iprange match from POM : http://www.netfilter.org/patch-o-matic/pom-base.html#pom-base-iprange -- http://www.netexit.com/~sid/ PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE >> Hi! I'm your friendly neighbourhood signature virus. >> Copy me to your signature file and help me spread! ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: allow range syntax - perplexed 2004-06-15 17:19 ` Cedric Blancher @ 2004-06-15 17:47 ` Jonathan Villa 2004-06-15 17:52 ` Jonathan Villa 1 sibling, 0 replies; 22+ messages in thread From: Jonathan Villa @ 2004-06-15 17:47 UTC (permalink / raw) To: netfilter > Le mar 15/06/2004 à 19:00, Jonathan Villa a écrit : >> my temporary solution : looping through 1-254 > > As someone pointed out yesterday, you can use iprange match from POM : > > http://www.netfilter.org/patch-o-matic/pom-base.html#pom-base-iprange > thanks, I saw that post. However I just started working with iptables and have never patched it. I've just updated when new RPMS became available. I guess I'll look into it. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: allow range syntax - perplexed 2004-06-15 17:19 ` Cedric Blancher 2004-06-15 17:47 ` Jonathan Villa @ 2004-06-15 17:52 ` Jonathan Villa 2004-06-16 13:31 ` Relay to DNS Server ? Akao 1 sibling, 1 reply; 22+ messages in thread From: Jonathan Villa @ 2004-06-15 17:52 UTC (permalink / raw) To: netfilter > Le mar 15/06/2004 à 19:00, Jonathan Villa a écrit : >> my temporary solution : looping through 1-254 > > As someone pointed out yesterday, you can use iprange match from POM : > > http://www.netfilter.org/patch-o-matic/pom-base.html#pom-base-iprange > > -- I've just read that using POM is not considered safe by the dev team. http://www.lowth.com/howto/add-iptables-modules.php This is for a running system that needs to stay up right now. Any other options? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Relay to DNS Server ? 2004-06-15 17:52 ` Jonathan Villa @ 2004-06-16 13:31 ` Akao 2004-06-16 13:53 ` Patrick Leslie Polzer 0 siblings, 1 reply; 22+ messages in thread From: Akao @ 2004-06-16 13:31 UTC (permalink / raw) To: netfilter Hello I have set up a netfilter box as a gateway. The network lookis like this: subnet ---- eth1 - Netfilter box - eth0 --- modem/router --- FAI The forwarding/masquerading is working fine, subnet boxes can ping external ip like. But they can' t resolve domain names, because there isn' t any DNS server in the subnet. I d like to use DNS Servers of the ISP, or another DNS Server I would set up OUTSIDE the subnet. The netfilter box has the ISP DNS servers in resolv.conf and its gateway is the router.It resolves domains names without problems. Is it possible to use netfilter rules to "relay" clients DNS requests ? Sorry but I m new to netfilter. Thanks in advance. Regards Axel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Relay to DNS Server ? 2004-06-16 13:31 ` Relay to DNS Server ? Akao @ 2004-06-16 13:53 ` Patrick Leslie Polzer 2004-06-16 17:30 ` Antony Stone 0 siblings, 1 reply; 22+ messages in thread From: Patrick Leslie Polzer @ 2004-06-16 13:53 UTC (permalink / raw) To: netfilter On Wed, 16 Jun 2004 15:31:37 +0200 Akao <technique@akao.fr> wrote: > Is it possible to use netfilter rules to "relay" clients DNS requests ? Masquerading does that, but you must allow packets to port 53 tcp/udp to pass through to your ISP's DNS servers and their related packets back. Leslie ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Relay to DNS Server ? 2004-06-16 13:53 ` Patrick Leslie Polzer @ 2004-06-16 17:30 ` Antony Stone 2004-06-16 17:44 ` Mark Anacker 0 siblings, 1 reply; 22+ messages in thread From: Antony Stone @ 2004-06-16 17:30 UTC (permalink / raw) To: netfilter On Wednesday 16 June 2004 2:53 pm, Patrick Leslie Polzer wrote: > On Wed, 16 Jun 2004 15:31:37 +0200 > > Akao <technique@akao.fr> wrote: > > Is it possible to use netfilter rules to "relay" clients DNS requests ? > > Masquerading does that, but you must allow packets to port 53 tcp/udp to > pass through to your ISP's DNS servers and their related packets back. This is a completely correct and accurate answer to your question, however I think you would get much better performance for very little effort if you set up a simple caching-only name server somewhere on your network (possibly even on the firewall itself, but don't tell anyone I suggested that :) Regards, Antony. -- "640 kilobytes (of RAM) should be enough for anybody." - Bill Gates Please reply to the list; please don't CC me. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Relay to DNS Server ? 2004-06-16 17:30 ` Antony Stone @ 2004-06-16 17:44 ` Mark Anacker 2004-06-17 7:11 ` Akao 0 siblings, 1 reply; 22+ messages in thread From: Mark Anacker @ 2004-06-16 17:44 UTC (permalink / raw) To: netfilter Antony Stone wrote: > On Wednesday 16 June 2004 2:53 pm, Patrick Leslie Polzer wrote: > > >>On Wed, 16 Jun 2004 15:31:37 +0200 >> >>Akao <technique@akao.fr> wrote: >> >>>Is it possible to use netfilter rules to "relay" clients DNS requests ? >> >>Masquerading does that, but you must allow packets to port 53 tcp/udp to >>pass through to your ISP's DNS servers and their related packets back. > > > This is a completely correct and accurate answer to your question, however I > think you would get much better performance for very little effort if you set > up a simple caching-only name server somewhere on your network (possibly even > on the firewall itself, but don't tell anyone I suggested that :) > > Regards, > > Antony. > You might want to run a DNS cache like dnsmasq on the firewall box, then use a REDIRECT or DNAT rule to grab client's requests and force them into the cache. That way, the client's don't have to change their DNS server list, and you get the benefits of caching. -- Mark Anacker Chameleon Technology, Inc. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Relay to DNS Server ? 2004-06-16 17:44 ` Mark Anacker @ 2004-06-17 7:11 ` Akao 0 siblings, 0 replies; 22+ messages in thread From: Akao @ 2004-06-17 7:11 UTC (permalink / raw) To: netfilter Mark Anacker wrote: > Antony Stone wrote: > >> On Wednesday 16 June 2004 2:53 pm, Patrick Leslie Polzer wrote: >> >> >>> On Wed, 16 Jun 2004 15:31:37 +0200 >>> >>> Akao <technique@akao.fr> wrote: >>> >>>> Is it possible to use netfilter rules to "relay" clients DNS >>>> requests ? >>> >>> >>> Masquerading does that, but you must allow packets to port 53 >>> tcp/udp to >>> pass through to your ISP's DNS servers and their related packets back. >> >> >> >> This is a completely correct and accurate answer to your question, >> however I think you would get much better performance for very little >> effort if you set up a simple caching-only name server somewhere on >> your network (possibly even on the firewall itself, but don't tell >> anyone I suggested that :) >> >> Regards, >> >> Antony. >> > > You might want to run a DNS cache like dnsmasq on the firewall box, > then use a REDIRECT or DNAT rule to grab client's requests and force > them into the cache. That way, the client's don't have to change > their DNS server list, and you get the benefits of caching. > Ok, thanks for your answers. I managed to complete clients DNS requests with masquerading. I will look for a dns cache as you adviced me. Thanks again for your answers. Axel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: allow range syntax - perplexed 2004-06-15 17:00 allow range syntax - perplexed Jonathan Villa 2004-06-15 17:19 ` Cedric Blancher @ 2004-06-15 17:58 ` John A. Sullivan III 2004-06-15 18:41 ` Jonathan Villa 2004-06-15 18:52 ` Antony Stone 2 siblings, 1 reply; 22+ messages in thread From: John A. Sullivan III @ 2004-06-15 17:58 UTC (permalink / raw) To: Jonathan Villa; +Cc: netfilter On Tue, 2004-06-15 at 13:00, Jonathan Villa wrote: > To my understanding the following will allow any address in the x.x.x.0 > block access > > $IPTABLES -A INPUT -p tcp --dport 22 -s xxx.xxx.xx.0/24 -j ACCEPT > $IPTABLES -A INPUT -p tcp --dport 3306 -s xxx.xxx.xx.0/24 -j ACCEPT > $IPTABLES -A INPUT -p tcp --dport 80 -s xxx.xxx.xx.0/24 -j ACCEPT > > It of course is not working... > > my temporary solution : looping through 1-254 > > not very nice when I need to show someone the current rules. > > -confused I'm not doing exactly what you are doing but I do use full subnets for both source and destination and it works fine for me. What do you see that makes you believe it is not working? - John -- John A. Sullivan III Chief Technology Officer Nexus Management +1 207-985-7880 john.sullivan@nexusmgmt.com --- If you are interested in helping to develop a GPL enterprise class VPN/Firewall/Security device management console, please visit http://iscs.sourceforge.net ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: allow range syntax - perplexed 2004-06-15 17:58 ` allow range syntax - perplexed John A. Sullivan III @ 2004-06-15 18:41 ` Jonathan Villa 2004-06-15 19:04 ` Antony Stone 2004-06-15 19:15 ` allow range syntax - perplexed John A. Sullivan III 0 siblings, 2 replies; 22+ messages in thread From: Jonathan Villa @ 2004-06-15 18:41 UTC (permalink / raw) To: netfilter > I'm not doing exactly what you are doing but I do use full subnets for > both source and destination and it works fine for me. What do you see > that makes you believe it is not working? - John > -- > John A. Sullivan III > Chief Technology Officer > Nexus Management > +1 207-985-7880 > john.sullivan@nexusmgmt.com > --- > If you are interested in helping to develop a GPL enterprise class > VPN/Firewall/Security device management console, please visit > http://iscs.sourceforge.net > > Access is denied. I have more information now. Here is the background: A machine running MySQL is to be locked down for access only to a select group of people working from home and people at the office, hence the xx.xx.xx.0 I've noticed that the script works fine for anyone who is not on the network but for those who are, well the rules block access to them all the time. I have something similar to the following ALLOWIPS="array of ip addresses" for ip in $ALLOWIPS; do $IPTABLES -A INPUT -p tcp --dport 3306 -s $ip -j ACCEPT $IPTABLES -A INPUT -p tcp --dport 80 -s $ip -j ACCEPT done then I had the rules from my original post $IPTABLES -A INPUT -p tcp --dport 3306 -s xxx.xxx.xx.0/24 -j ACCEPT $IPTABLES -A INPUT -p tcp --dport 80 -s xxx.xxx.xx.0/24 -j ACCEPT the ips in the loop are fine, but then ips on the same network were being blocked regardless of my rules. That is why I thought that it was the syntax... I have added 5 ips which are on the same network as the server to the array ALLOWIPS and they get denied access while the other ips are granted access. so then I tried taking them out of the loop and doing them individually, still no access. Could it be because they are on the block? Do I need to specify that the interface is -i eth0 or something instead of specifying -s ip example use: $IPTABLES -A INPUT -p tcp --dport 3306 -i eth0 -j ACCEPT vs $IPTABLES -A INPUT -p tcp --dport 3306 -s xxx.xxx.xx.0/24 -j ACCEPT but then my question is, I only have one nic, so won't everything that is not from lo come from eth0? -very confused ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: allow range syntax - perplexed 2004-06-15 18:41 ` Jonathan Villa @ 2004-06-15 19:04 ` Antony Stone 2004-06-15 19:27 ` Jonathan Villa 2004-06-16 8:47 ` blocking all traffic in port 137/137 david 2004-06-15 19:15 ` allow range syntax - perplexed John A. Sullivan III 1 sibling, 2 replies; 22+ messages in thread From: Antony Stone @ 2004-06-15 19:04 UTC (permalink / raw) To: netfilter On Tuesday 15 June 2004 7:41 pm, Jonathan Villa wrote: > I have more information now. > > Here is the background: > A machine running MySQL is to be locked down for access only to a select > group of people working from home and people at the office, hence the > xx.xx.xx.0 Is the MySQL machine on the same subnet as the office people trying to access it, or is there a firewall in between, with the MySQL on a DMZ network? If it's the latter, are you sure your office machines aren't being masqueraded in some way by the firewall when they try to access the MySQL server, so that it sees an address on the firewall instead of the real address of the clients? > I've noticed that the script works fine for anyone who is not on the > network but for those who are, well the rules block access to them all the > time. I suggest you add a LOGging rule at the bottom of the INPUT chain and see what source address the packets which are not being ACCEPTed are coming from. Regards, Antony. -- This email is intended for the use of the individual addressee(s) named above and may contain information that is confidential, privileged or unsuitable for overly sensitive persons with low self-esteem, no sense of humour, or irrational religious beliefs. If you have received this email in error, you are required to shred it immediately, add some nutmeg, three egg whites and a dessertspoonful of caster sugar. Whisk until soft peaks form, then place in a warm oven for 40 minutes. Remove promptly and let stand for 2 hours before adding some decorative kiwi fruit and cream. Then notify me immediately by return email and eat the original message. Please reply to the list; please don't CC me. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: allow range syntax - perplexed 2004-06-15 19:04 ` Antony Stone @ 2004-06-15 19:27 ` Jonathan Villa 2004-06-16 8:47 ` blocking all traffic in port 137/137 david 1 sibling, 0 replies; 22+ messages in thread From: Jonathan Villa @ 2004-06-15 19:27 UTC (permalink / raw) To: netfilter > On Tuesday 15 June 2004 7:41 pm, Jonathan Villa wrote: > >> I have more information now. >> >> Here is the background: >> A machine running MySQL is to be locked down for access only to a select >> group of people working from home and people at the office, hence the >> xx.xx.xx.0 > > Is the MySQL machine on the same subnet as the office people trying to > access > it, or is there a firewall in between, with the MySQL on a DMZ network? Sad to say, but there is no firewall. Machines are open to the world, hence the xxx.xxx.xxx.xxx everywhere. > If it's the latter, are you sure your office machines aren't being > masqueraded > in some way by the firewall when they try to access the MySQL server, so > that > it sees an address on the firewall instead of the real address of the > clients? > >> I've noticed that the script works fine for anyone who is not on the >> network but for those who are, well the rules block access to them all >> the >> time. > > I suggest you add a LOGging rule at the bottom of the INPUT chain and see > what > source address the packets which are not being ACCEPTed are coming from. Good point. Since I am fairly new to iptables, I usually carry my book with me, unfortunately, I don't have it today. But I will implement lots of logging to help once I figure out how to :) > Regards, > > Antony. > > ^ permalink raw reply [flat|nested] 22+ messages in thread
* blocking all traffic in port 137/137 2004-06-15 19:04 ` Antony Stone 2004-06-15 19:27 ` Jonathan Villa @ 2004-06-16 8:47 ` david 2004-06-16 8:52 ` Antony Stone 2004-06-16 9:00 ` Frank Gruellich 1 sibling, 2 replies; 22+ messages in thread From: david @ 2004-06-16 8:47 UTC (permalink / raw) To: netfilter Dear all, When i look at "IPTRAF", i see lot of broadcast traffic that using port 137 and 138, how to make rules that can block all traffic in port 137 and 138, i already try to use this rules but its no works... iptables -A INPUT -p tcp --dport 137 DROP iptables -A OUTPUT -p tcp --dport 137 DROP iptables -A INPUT -p udp --dport 137 DROP iptables -A OUTPUT -p udp --dport 137 DROP iptables -A INPUT -p tcp --dport 138 DROP iptables -A OUTPUT -p tcp --dport 138 DROP iptables -A INPUT -p udp --dport 138 DROP iptables -A OUTPUT -p udp --dport 138 DROP iptables -A INPUT -p icmp DROP Thank's David Kandou ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: blocking all traffic in port 137/137 2004-06-16 8:47 ` blocking all traffic in port 137/137 david @ 2004-06-16 8:52 ` Antony Stone 2004-06-16 9:00 ` Frank Gruellich 1 sibling, 0 replies; 22+ messages in thread From: Antony Stone @ 2004-06-16 8:52 UTC (permalink / raw) To: netfilter On Wednesday 16 June 2004 9:47 am, david wrote: > Dear all, > When i look at "IPTRAF", i see lot of broadcast traffic that using port 137 > and 138, You must have Windows machines on your network, then - that's how Microsoft networking works - using broadcasts on the local subnet. > how to make rules that can block all traffic in port 137 and 138, Why bother? It's broadcast traffic - it's not going anywhere (through a router), and if your firewall doesn't listen on those ports, nothing's going to happen anyway. Regards, Antony. -- "The future is already here. It's just not evenly distributed yet." - William Gibson Please reply to the list; please don't CC me. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: blocking all traffic in port 137/137 2004-06-16 8:47 ` blocking all traffic in port 137/137 david 2004-06-16 8:52 ` Antony Stone @ 2004-06-16 9:00 ` Frank Gruellich 1 sibling, 0 replies; 22+ messages in thread From: Frank Gruellich @ 2004-06-16 9:00 UTC (permalink / raw) To: netfilter * david <david@suarapembaruan.co.id> 16. Jun 04: > Dear all, Hi, > When i look at "IPTRAF", i see lot of broadcast traffic that using port 137 > and 138, how to make rules that can block all traffic in port 137 and 138, i > already try to use this rules but its no works... Additional to Antonys statement the OUTPUT-rules should be even more useless. Are you runnig netbios at a linux-box? > iptables -A INPUT -p tcp --dport 137 DROP > iptables -A INPUT -p udp --dport 137 DROP > iptables -A INPUT -p tcp --dport 138 DROP > iptables -A INPUT -p udp --dport 138 DROP > iptables -A INPUT -p icmp DROP And ICMP is _not_ bad. Don't DROP it. HTH, regards, Frank. -- Sigmentation fault ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: allow range syntax - perplexed 2004-06-15 18:41 ` Jonathan Villa 2004-06-15 19:04 ` Antony Stone @ 2004-06-15 19:15 ` John A. Sullivan III 2004-06-15 19:30 ` Jonathan Villa 1 sibling, 1 reply; 22+ messages in thread From: John A. Sullivan III @ 2004-06-15 19:15 UTC (permalink / raw) To: Jonathan Villa; +Cc: netfilter On Tue, 2004-06-15 at 14:41, Jonathan Villa wrote: > > I'm not doing exactly what you are doing but I do use full subnets for > > both source and destination and it works fine for me. What do you see > > that makes you believe it is not working? - John > > -- > > John A. Sullivan III > > Chief Technology Officer > > Nexus Management > > +1 207-985-7880 > > john.sullivan@nexusmgmt.com > > --- > > If you are interested in helping to develop a GPL enterprise class > > VPN/Firewall/Security device management console, please visit > > http://iscs.sourceforge.net > > > > > > Access is denied. > > I have more information now. > > Here is the background: > A machine running MySQL is to be locked down for access only to a select > group of people working from home and people at the office, hence the > xx.xx.xx.0 > > I've noticed that the script works fine for anyone who is not on the > network but for those who are, well the rules block access to them all the > time. > > I have something similar to the following > > ALLOWIPS="array of ip addresses" > > for ip in $ALLOWIPS; > do > $IPTABLES -A INPUT -p tcp --dport 3306 -s $ip -j ACCEPT > $IPTABLES -A INPUT -p tcp --dport 80 -s $ip -j ACCEPT > done > > then I had the rules from my original post > > $IPTABLES -A INPUT -p tcp --dport 3306 -s xxx.xxx.xx.0/24 -j ACCEPT > $IPTABLES -A INPUT -p tcp --dport 80 -s xxx.xxx.xx.0/24 -j ACCEPT > > the ips in the loop are fine, but then ips on the same network were being > blocked regardless of my rules. That is why I thought that it was the > syntax... > > I have added 5 ips which are on the same network as the server to the > array ALLOWIPS and they get denied access while the other ips are granted > access. > > so then I tried taking them out of the loop and doing them individually, > still no access. > > Could it be because they are on the block? Do I need to specify that the > interface is -i eth0 or something instead of specifying -s ip > > example > > use: > > > $IPTABLES -A INPUT -p tcp --dport 3306 -i eth0 -j ACCEPT > > vs > > > $IPTABLES -A INPUT -p tcp --dport 3306 -s xxx.xxx.xx.0/24 -j ACCEPT > > > but then my question is, I only have one nic, so won't everything that is > not from lo come from eth0? > > -very confused Hmmm . . . that is very confusing. It should work which makes me think something else is going on. I would suggest it is time to do a little tracing to find out where the problem really is. I would suggest that the first order of business be ensure that the packets are making it to the MySQL server. One could enable all traffic and see if you are still denied (if so, a good sign that the packets never make it there in the first place) or, if that is impractical or you really want to be sure, put a protocol analyzer on the line (e.g., http://www.ethereal.com). If the server is on a switch, you can either insert a hub, use port mirroring or use ettercap (http://ettercap.sourceforge.net) to insert yourself into the packet stream. If you do not see the packets arriving, we know the problem is somewhere else in the network. If the packets arrive at the MySQL server, then I would start placing log rules at various points in the iptables rules set to see where the packets are dropped. If they are not dropped before the ACCEPT rule, then see if they are still in the chain after the ACCEPT rule (in which case something is wrong with the match portion of the rule). If not, they have been ACCEPTED and are either being DROPped or mangled in another POSTROUTING chain or, more likely, there is an application layer problem. Regarding interface versus subnet, it depends on which you fear most! The interface allows you to add new subnets and they will all be allowed based upon port regardless of IP. If that kind of free access scares you, then restrict it to specific addresses and subnets (which seems like it is what you want to do anyway). The downside there is that you must change the rules for any subnets or addresses you later add. If that kind of maintenance scares you, go back to allowing everything from the allowed ports on the interface. Hope this helps - John -- John A. Sullivan III Chief Technology Officer Nexus Management +1 207-985-7880 john.sullivan@nexusmgmt.com --- If you are interested in helping to develop a GPL enterprise class VPN/Firewall/Security device management console, please visit http://iscs.sourceforge.net ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: allow range syntax - perplexed 2004-06-15 19:15 ` allow range syntax - perplexed John A. Sullivan III @ 2004-06-15 19:30 ` Jonathan Villa 0 siblings, 0 replies; 22+ messages in thread From: Jonathan Villa @ 2004-06-15 19:30 UTC (permalink / raw) To: netfilter > Hmmm . . . that is very confusing. It should work which makes me think > something else is going on. I would suggest it is time to do a little > tracing to find out where the problem really is. > > I would suggest that the first order of business be ensure that the > packets are making it to the MySQL server. One could enable all traffic > and see if you are still denied (if so, a good sign that the packets > never make it there in the first place) or, if that is impractical or > you really want to be sure, put a protocol analyzer on the line (e.g., > http://www.ethereal.com). If the server is on a switch, you can either > insert a hub, use port mirroring or use ettercap > (http://ettercap.sourceforge.net) to insert yourself into the packet > stream. If you do not see the packets arriving, we know the problem is > somewhere else in the network. > > If the packets arrive at the MySQL server, then I would start placing > log rules at various points in the iptables rules set to see where the > packets are dropped. If they are not dropped before the ACCEPT rule, > then see if they are still in the chain after the ACCEPT rule (in which > case something is wrong with the match portion of the rule). If not, > they have been ACCEPTED and are either being DROPped or mangled in > another POSTROUTING chain or, more likely, there is an application layer > problem. > > Regarding interface versus subnet, it depends on which you fear most! > The interface allows you to add new subnets and they will all be allowed > based upon port regardless of IP. If that kind of free access scares > you, then restrict it to specific addresses and subnets (which seems > like it is what you want to do anyway). The downside there is that you > must change the rules for any subnets or addresses you later add. If > that kind of maintenance scares you, go back to allowing everything from > the allowed ports on the interface. Packets are making it to the server just fine for ip addresses not on the same network. For example, I am 3 hours away and can access the machine via port 80, 3306, and 22. When I create the rules for ips on the same network, they can't even access port 80 for phpMyAdmin. But once I remove the ip check and allow access for the whole world, they are fine. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: allow range syntax - perplexed 2004-06-15 17:00 allow range syntax - perplexed Jonathan Villa 2004-06-15 17:19 ` Cedric Blancher 2004-06-15 17:58 ` allow range syntax - perplexed John A. Sullivan III @ 2004-06-15 18:52 ` Antony Stone 2004-06-15 19:24 ` Jonathan Villa 2 siblings, 1 reply; 22+ messages in thread From: Antony Stone @ 2004-06-15 18:52 UTC (permalink / raw) To: netfilter On Tuesday 15 June 2004 6:00 pm, Jonathan Villa wrote: > To my understanding the following will allow any address in the x.x.x.0 > block access > > $IPTABLES -A INPUT -p tcp --dport 22 -s xxx.xxx.xx.0/24 -j ACCEPT > $IPTABLES -A INPUT -p tcp --dport 3306 -s xxx.xxx.xx.0/24 -j ACCEPT > $IPTABLES -A INPUT -p tcp --dport 80 -s xxx.xxx.xx.0/24 -j ACCEPT I agree - the above rules should allow any IP within the xxx.xxx.xx.0/24 Class C range access the firewall on port 22, 80 or 3306. > It of course is not working... Huh? Why "of course"? Come to that, why isn't it working? I use that sort of netmask notation all the time... > my temporary solution : looping through 1-254 Ugh! Show us the rest of your INPUT and OUTPUT ruleset, and tell us how you are testing the system (and where from). The output from "iptables -L -nvx" would be useful, as it shows us the rules in the correct order, which interfaces they apply to, and the packet / byte counts so we can see how many times particular rules have been matched. Feel free to munge IP addresses if you want to hide things from the list archives :) Regards, Antony. -- People who use Microsoft software should be certified. Please reply to the list; please don't CC me. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: allow range syntax - perplexed 2004-06-15 18:52 ` Antony Stone @ 2004-06-15 19:24 ` Jonathan Villa 2004-06-15 19:55 ` Antony Stone 0 siblings, 1 reply; 22+ messages in thread From: Jonathan Villa @ 2004-06-15 19:24 UTC (permalink / raw) To: netfilter [-- Attachment #1: Type: text/plain, Size: 11654 bytes --] > On Tuesday 15 June 2004 6:00 pm, Jonathan Villa wrote: > >> To my understanding the following will allow any address in the x.x.x.0 >> block access >> >> $IPTABLES -A INPUT -p tcp --dport 22 -s xxx.xxx.xx.0/24 -j ACCEPT >> $IPTABLES -A INPUT -p tcp --dport 3306 -s xxx.xxx.xx.0/24 -j ACCEPT >> $IPTABLES -A INPUT -p tcp --dport 80 -s xxx.xxx.xx.0/24 -j ACCEPT > > I agree - the above rules should allow any IP within the xxx.xxx.xx.0/24 > Class > C range access the firewall on port 22, 80 or 3306. > >> It of course is not working... > > Huh? Why "of course"? Come to that, why isn't it working? I use that > sort of netmask notation all the time... I didn't meant "of course" in a bad way, I meant it in reference to my bad luck. >> my temporary solution : looping through 1-254 > > Ugh! yes, very much. > Show us the rest of your INPUT and OUTPUT ruleset, and tell us how you are > testing the system (and where from). > > The output from "iptables -L -nvx" would be useful, as it shows us the > rules > in the correct order, which interfaces they apply to, and the packet / > byte > counts so we can see how many times particular rules have been matched. > > Feel free to munge IP addresses if you want to hide things from the list > archives :) > here is the output for iptables -L -nvx. I've also attached a txt file in case you want to see a cleaner output One thing to keep in mind, since we are trying to use the machine, I had to open up some ports to everyone :( until the issue is resolved. Chain INPUT (policy ACCEPT 2403 packets, 206290 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT icmp -- eth0 * 0.0.0.0/0 0.0.0.0/0 state ESTABLISHED 23171 1256484 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 state ESTABLISHED 1 137 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 state ESTABLISHED 0 0 ACCEPT tcp -- * * 127.0.0.1 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * 127.0.0.1 0.0.0.0/0 tcp dpt:3306 28 1512 ACCEPT tcp -- * * 127.0.0.1 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xx.xx.xx.xx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xx.xx.xx.xx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xx.xx.xx.xx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xx.xx.xxx.xxx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xx.xx.xxx.xxx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xx.xx.xxx.xxx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xx.xx.xx.xxx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xx.xx.xx.xxx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xx.xx.xx.xxx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xx.xx.xxx.xx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xx.xx.xxx.xx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xx.xx.xxx.xx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xx.xx.xxx.xxx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xx.xx.xxx.xxx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xx.xx.xxx.xxx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xx.xx.xxx.xx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xx.xx.xxx.xx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xx.xx.xxx.xx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xx.xx.xxx.xx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xx.xx.xxx.xx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xx.xx.xxx.xx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xx.xx.xxx.xx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xx.xx.xxx.xx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xx.xx.xxx.xx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xx.xx.xxx.xxx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xx.xx.xxx.xxx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xx.xx.xxx.xxx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:80 99 4512 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3306 1 52 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xx.x.xxx.xxx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xx.xxx.xxx.x 0.0.0.0/0 tcp dpt:22 6442 564926 LOG all -- !lo * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/sec burst 5 LOG flags 0 level 4 8334 748621 DROP all -- !lo * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 RH-Firewall-1-INPUT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 69219 packets, 67312095 bytes) pkts bytes target prot opt in out source destination Chain RH-Firewall-1-INPUT (1 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 255 0 0 ACCEPT esp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT ah -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:3306 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited here's my script #!/bin/bash # # Allow only access to MySQL, HTTP, and SSH # IPTABLES=/sbin/iptables #flush existing rules $IPTABLES -F INPUT #This allows all data that has been sent out for the computer running the firewall # to come back #(for all of ICMP/TCP/UDP). #For example, if a ping request is made it will allow the reply back $IPTABLES -A INPUT -j ACCEPT -m state --state ESTABLISHED -i eth0 -p icmp $IPTABLES -A INPUT -j ACCEPT -m state --state ESTABLISHED -i eth0 -p tcp $IPTABLES -A INPUT -j ACCEPT -m state --state ESTABLISHED -i eth0 -p udp #list of ips allowed to access the server ALLOWIPS="127.0.0.1 etc... etc..." for ip in $ALLOWIPS; do $IPTABLES -A INPUT -p tcp --dport 22 -s $ip -j ACCEPT $IPTABLES -A INPUT -p tcp --dport 3306 -s $ip -j ACCEPT $IPTABLES -A INPUT -p tcp --dport 80 -s $ip -j ACCEPT done #$IPTABLES -A INPUT -p tcp --dport 22 -s xxx.xxx.xx.0/24 -j ACCEPT #$IPTABLES -A INPUT -p tcp --dport 3306 -s xxx.xxx.xx.0/24 -j ACCEPT #$IPTABLES -A INPUT -p tcp --dport 80 -s xxx.XXX.XX.0/24 -j ACCEPT #do not modify. Allows JV access from office, home, and from remote server for the weekends JVIPS="more ips" for jvip in $JVIPS; do $IPTABLES -A INPUT -p tcp --dport 22 -s $jvip -j ACCEPT done #Drop and log all other data #The logging is set so if more than 5 packets are dropped in #three seconds they will be ignored. This helps to prevent a DOS attack #Crashing the computer the firewall is running on $IPTABLES -A INPUT -m limit --limit 3/second --limit-burst 5 -i ! lo -j LOG #drop anything else that does not come from the localhost interface $IPTABLES -A INPUT -i ! lo -j DROP #save rules /etc/init.d/iptables save [-- Attachment #2: out.txt --] [-- Type: text/plain, Size: 8426 bytes --] Chain INPUT (policy ACCEPT 2403 packets, 206290 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT icmp -- eth0 * 0.0.0.0/0 0.0.0.0/0 state ESTABLISHED 23171 1256484 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 state ESTABLISHED 1 137 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 state ESTABLISHED 0 0 ACCEPT tcp -- * * 127.0.0.1 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * 127.0.0.1 0.0.0.0/0 tcp dpt:3306 28 1512 ACCEPT tcp -- * * 127.0.0.1 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xx.xx.xx.xx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xx.xx.xx.xx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xx.xx.xx.xx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xx.xx.xxx.xxx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xx.xx.xxx.xxx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xx.xx.xxx.xxx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xx.xx.xx.xxx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xx.xx.xx.xxx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xx.xx.xx.xxx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xx.xx.xxx.xx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xx.xx.xxx.xx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xx.xx.xxx.xx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xx.xx.xxx.xxx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xx.xx.xxx.xxx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xx.xx.xxx.xxx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xx.xx.xxx.xx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xx.xx.xxx.xx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xx.xx.xxx.xx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xx.xx.xxx.xx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xx.xx.xxx.xx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xx.xx.xxx.xx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xx.xx.xxx.xx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xx.xx.xxx.xx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xx.xx.xxx.xx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xx.xx.xxx.xxx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xx.xx.xxx.xxx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xx.xx.xxx.xxx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:3306 0 0 ACCEPT tcp -- * * xxx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:80 99 4512 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3306 1 52 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xx.x.xxx.xxx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xx.xxx.xx.xxx 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * xx.xxx.xxx.x 0.0.0.0/0 tcp dpt:22 6442 564926 LOG all -- !lo * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/sec burst 5 LOG flags 0 level 4 8334 748621 DROP all -- !lo * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 RH-Firewall-1-INPUT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 69219 packets, 67312095 bytes) pkts bytes target prot opt in out source destination Chain RH-Firewall-1-INPUT (1 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 255 0 0 ACCEPT esp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT ah -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:3306 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: allow range syntax - perplexed 2004-06-15 19:24 ` Jonathan Villa @ 2004-06-15 19:55 ` Antony Stone 2004-06-15 20:40 ` Jonathan Villa 0 siblings, 1 reply; 22+ messages in thread From: Antony Stone @ 2004-06-15 19:55 UTC (permalink / raw) To: netfilter On Tuesday 15 June 2004 8:24 pm, Jonathan Villa wrote: > > The output from "iptables -L -nvx" would be useful, as it shows us the > > rules > > in the correct order, which interfaces they apply to, and the packet / > > byte > > counts so we can see how many times particular rules have been matched. > > here is the output for iptables -L -nvx. I've also attached a txt file in > case you want to see a cleaner output Nice. The .txt file was much easier to read :) The first thing I notice about the ruleset you have posted is that none of the rules which included your network range matched any packets at all. Therefore that doesn't tell us much about what source address/es the packets you are having problems with are coming from. Maybe the timing was just unfortunate, but I can't see any TCP port 3306 packets at all. Therefore I think a LOG rule would be a good idea, to try and track down where the packets are coming from, which your carefully-crafted -s xxx.xxx.xx.0/24 rules aren't apparently matching. Try something like the following: iptables -A INPUT -p tcp --dport 3306 -j LOG The -A will ensure that the rule comes after all your other rules (which are supposed to ACCEPT the packets one way or another). However, I notice you have a default ACCEPT policy (ugh) and a final rule which DROPs all non-loopback packets. I suggest you change this to a default DROP policy and a final rule which ACCEPTs all the loopback packets. Then the rule above will become the final rule in your chain, guaranteeing that you LOG any packets destined for MySQL just before they get (unfortunately) DROPped. Regards, Antony. -- There are two possible outcomes: If the result confirms the hypothesis, then you've made a measurement. If the result is contrary to the hypothesis, then you've made a discovery. - Enrico Fermi Please reply to the list; please don't CC me. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: allow range syntax - perplexed 2004-06-15 19:55 ` Antony Stone @ 2004-06-15 20:40 ` Jonathan Villa 0 siblings, 0 replies; 22+ messages in thread From: Jonathan Villa @ 2004-06-15 20:40 UTC (permalink / raw) To: netfilter > On Tuesday 15 June 2004 8:24 pm, Jonathan Villa wrote: > >> > The output from "iptables -L -nvx" would be useful, as it shows us the >> > rules >> > in the correct order, which interfaces they apply to, and the packet / >> > byte >> > counts so we can see how many times particular rules have been >> matched. >> >> here is the output for iptables -L -nvx. I've also attached a txt file >> in >> case you want to see a cleaner output > > Nice. The .txt file was much easier to read :) > > The first thing I notice about the ruleset you have posted is that none of > the > rules which included your network range matched any packets at all. My serious bad!!!! I am so overworked that I was staring at the ip addresses and never realized that I was using xx1. rather than xx3 which is the correct one. It now works as expected. > > Therefore that doesn't tell us much about what source address/es the > packets > you are having problems with are coming from. > > Maybe the timing was just unfortunate, but I can't see any TCP port 3306 > packets at all. Therefore I think a LOG rule would be a good idea, to > try > and track down where the packets are coming from, which your > carefully-crafted -s xxx.xxx.xx.0/24 rules aren't apparently matching. > > Try something like the following: > > iptables -A INPUT -p tcp --dport 3306 -j LOG thanks, this will help > > The -A will ensure that the rule comes after all your other rules (which > are > supposed to ACCEPT the packets one way or another). However, I notice > you > have a default ACCEPT policy (ugh) I agree. When I planned the rules, it was set to DROP however with the "issue" I was having, I changed it. and a final rule which DROPs all > non-loopback packets. I suggest you change this to a default DROP policy > and a final rule which ACCEPTs all the loopback packets. Then the rule > above will become the final rule in your chain, guaranteeing that you LOG > any > packets destined for MySQL just before they get (unfortunately) DROPped. > One quick question regarding logging. Where does it get logged to? I check /var/log/messages and see lots of traffic being logged at a rapid rate. I've read that syslog takes care logging, but I would prefer to have a separate log. Again, my original issue was a silly mistake. Sorry for wasting anyone's time. ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2004-06-17 7:11 UTC | newest] Thread overview: 22+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2004-06-15 17:00 allow range syntax - perplexed Jonathan Villa 2004-06-15 17:19 ` Cedric Blancher 2004-06-15 17:47 ` Jonathan Villa 2004-06-15 17:52 ` Jonathan Villa 2004-06-16 13:31 ` Relay to DNS Server ? Akao 2004-06-16 13:53 ` Patrick Leslie Polzer 2004-06-16 17:30 ` Antony Stone 2004-06-16 17:44 ` Mark Anacker 2004-06-17 7:11 ` Akao 2004-06-15 17:58 ` allow range syntax - perplexed John A. Sullivan III 2004-06-15 18:41 ` Jonathan Villa 2004-06-15 19:04 ` Antony Stone 2004-06-15 19:27 ` Jonathan Villa 2004-06-16 8:47 ` blocking all traffic in port 137/137 david 2004-06-16 8:52 ` Antony Stone 2004-06-16 9:00 ` Frank Gruellich 2004-06-15 19:15 ` allow range syntax - perplexed John A. Sullivan III 2004-06-15 19:30 ` Jonathan Villa 2004-06-15 18:52 ` Antony Stone 2004-06-15 19:24 ` Jonathan Villa 2004-06-15 19:55 ` Antony Stone 2004-06-15 20:40 ` Jonathan Villa
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.