Re: [CentOS] IPTABLES question
James B. Byrne byrnejb@... writes: Would someone please explain to me the difference in effect between the following two IPTABLES conditions and the significance thereof in concurrent connection limiting? --tcp-flags SYN,ACK,FIN,RST SYN -j REJECT \ --connlimit-above 3 --connlimit-mask 32 --state NEW -j REJECT \ --connlimit-above 3 --connlimit-mask 32 Your first example will review only TCP packets and ensure out of SYN,ACK,FIN, and RST the only flag set is SYN (it doesn't care about the URG flag). The --state NEW example on the other hand matches ANY new packet. This will capture protocols including OSPF, UDP, etc.. An easy way to see what it captures is to set the target to LOG: [13982781.141620] IN= OUT=homework0 SRC=192.168.254.2 DST=224.0.0.5 LEN=84 TOS=0x00 PREC=0xC0 TTL=1 ID=64815 PROTO=89 [13982784.953439] IN= OUT=br0 SRC=192.168.2.206 DST=8.8.8.8 LEN=63 TOS=0x00 PREC=0x00 TTL=64 ID=65012 PROTO=UDP SPT=58492 DPT=53 LEN=43 I hope that's of help to you, Matthew Gillespie CTI Networks ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
+1 On Tue, Jun 17, 2014 at 9:41 AM, James B. Byrne byrn...@harte-lyne.ca wrote: On Mon, June 16, 2014 23:34, Chuck Campbell wrote: I appreciate you restating this. I'll try to go make sense of iptables, given the insight, Keep in mind that there are three default chains, INPUT, OUTPUT and FORWARD that are used to initiate the packet path through IPTABLES and that they are mutually exclusive. INPUT deals ONLY with packets that arrive from off of AND are destined for the host running IPTABLES. OUTPUT deals only with packets that originate from the host running IPTABLES regardless of where they are destined. And FORWARD deals only with packets that arrive from and are destined off of the host running IPTABLES. A packet starts in only one of these based solely on its origin/destination pairing and it does not cross over automatically into either of the others. For example, if a forwarded packet is detected then the INPUT and OUTPUT chains are not used at all. I have seen chain misconfiguration where IPTABLES rules evidently assume that a packet is to pass from the INPUT chain or the OUTPUT chain to the FORWARD chain automatically. In some cases it seems that the rules writer has implicitly assumed that INPUT - FORWARD - OUTPUT is the default routing of all packet paths. This is not the case and it does not happen unless the other chain is specifically called from within the originating chain. My practice is to place general rules that I wish to apply to all packets, regardless of source or destination, into a chain called GENERAL and simply call that chain as the last instruction in each of the default chains. Actually I put very little else in the default chains and route from the GENERAL chain to other chains dedicated to specific rule sets, like for port knocking (FWKNOP_ALLOW); or for assured access (ALWAYS_ALLOW); or for blacklists: ALWAYS_DENY and FAIL2BAN_DENY for example. -- *** E-Mail is NOT a SECURE channel *** James B. Byrnemailto:byrn...@harte-lyne.ca Harte Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
On Mon, June 16, 2014 23:34, Chuck Campbell wrote: I appreciate you restating this. I'll try to go make sense of iptables, given the insight, Keep in mind that there are three default chains, INPUT, OUTPUT and FORWARD that are used to initiate the packet path through IPTABLES and that they are mutually exclusive. INPUT deals ONLY with packets that arrive from off of AND are destined for the host running IPTABLES. OUTPUT deals only with packets that originate from the host running IPTABLES regardless of where they are destined. And FORWARD deals only with packets that arrive from and are destined off of the host running IPTABLES. A packet starts in only one of these based solely on its origin/destination pairing and it does not cross over automatically into either of the others. For example, if a forwarded packet is detected then the INPUT and OUTPUT chains are not used at all. I have seen chain misconfiguration where IPTABLES rules evidently assume that a packet is to pass from the INPUT chain or the OUTPUT chain to the FORWARD chain automatically. In some cases it seems that the rules writer has implicitly assumed that INPUT - FORWARD - OUTPUT is the default routing of all packet paths. This is not the case and it does not happen unless the other chain is specifically called from within the originating chain. My practice is to place general rules that I wish to apply to all packets, regardless of source or destination, into a chain called GENERAL and simply call that chain as the last instruction in each of the default chains. Actually I put very little else in the default chains and route from the GENERAL chain to other chains dedicated to specific rule sets, like for port knocking (FWKNOP_ALLOW); or for assured access (ALWAYS_ALLOW); or for blacklists: ALWAYS_DENY and FAIL2BAN_DENY for example. -- *** E-Mail is NOT a SECURE channel *** James B. Byrnemailto:byrn...@harte-lyne.ca Harte Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
On 06/17/2014 10:41 AM, James B. Byrne wrote: On Mon, June 16, 2014 23:34, Chuck Campbell wrote: I appreciate you restating this. I'll try to go make sense of iptables, given the insight, Keep in mind that there are three default chains, INPUT, OUTPUT and FORWARD that are used to initiate the packet path through IPTABLES and that they are mutually exclusive. INPUT deals ONLY with packets that arrive from off of AND are destined for the host running IPTABLES. OUTPUT deals only with packets that originate from the host running IPTABLES regardless of where they are destined. And FORWARD deals only with packets that arrive from and are destined off of the host running IPTABLES. A packet starts in only one of these based solely on its origin/destination pairing and it does not cross over automatically into either of the others. For example, if a forwarded packet is detected then the INPUT and OUTPUT chains are not used at all. I have seen chain misconfiguration where IPTABLES rules evidently assume that a packet is to pass from the INPUT chain or the OUTPUT chain to the FORWARD chain automatically. In some cases it seems that the rules writer has implicitly assumed that INPUT - FORWARD - OUTPUT is the default routing of all packet paths. This is not the case and it does not happen unless the other chain is specifically called from within the originating chain. My practice is to place general rules that I wish to apply to all packets, regardless of source or destination, into a chain called GENERAL and simply call that chain as the last instruction in each of the default chains. Actually I put very little else in the default chains and route from the GENERAL chain to other chains dedicated to specific rule sets, like for port knocking (FWKNOP_ALLOW); or for assured access (ALWAYS_ALLOW); or for blacklists: ALWAYS_DENY and FAIL2BAN_DENY for example. Hi, Here is a reasonable diagram that show the packet flow. http://xkr47.outerspace.dyndns.org/netfilter/packet_flow/packet_flow10.png -- Stephen Clark *NetWolves Managed Services, LLC.* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
On 6/16/2014 11:08 PM, John R Pierce wrote: On 6/16/2014 8:52 PM, Chuck Campbell wrote: I ran a script after fail2ban was started. It looks like this: #!/bin/sh iptables -A INPUT -s 116.10.191.0/24 -j DROP iptables -A INPUT -s 183.136.220.0/24 -j DROP iptables -A INPUT -s 183.136.221.0/24 -j DROP iptables -A INPUT -s 183.136.222.0/24 -j DROP iptables -A INPUT -s 183.136.223.0/24 -j DROP iptables -A INPUT -s 122.224.11.0/24 -j DROP iptables -A INPUT -s 219.138.0.0/16 -j DROP so, how do I get them in front of the RH-Firewall-1-INPUT, or do I add them to that chain? use -I (insert) rather than -A (append). OR specify chain RH-Firewall-1-INPUT rather than INPUT I used the RH-Firewall-1-INPUT chain, and -I, defaulting to position 1, and all is working as I had anticipated. It is working as expected, killing all of those rolling ip attempts. I was loathe to use system-config-firewall, because I wasn't sure it wouldn't drop something I needed, or forgot to include, and it would have wiped out the existong ruleset. I'll experiment with that when I am physically in front of the server, instead of remote from it. I would have had no quick remedy if I messed it up. Thanks you for the clear concise explanation. -chuck -- ACCEL Services, Inc.| Specialists in Gravity, Magnetics | (713)993-0671 ph. | and Integrated Interpretation | (713)993-0608 fax 448 W. 19th St. #325|Since 1992 | (713)306-5794 cell Houston, TX, 77008 | Chuck Campbell | campb...@accelinc.com | President Senior Geoscientist | Integration means more than having all the maps at the same scale! ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
On 6/17/2014 2:14 PM, Chuck Campbell wrote: I'll experiment with that when I am physically in front of the server, instead of remote from it. I would have had no quick remedy if I messed it up. thats why all my servers have remote consoles :) -- john r pierce 37N 122W somewhere on the middle of the left coast ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
On 6/16/2014 15:58, Chuck Campbell wrote: If they keep going through this ip block, they will still get 255 attempts at the root password and 1020 attempts at other login/password combinations before they are blocked by fail2ban. I'm glad you got your firewall problem sorted out, but I can't let this comment slide. If removing a thousand possibilities from the pool of available credentials puts your servers at significant risk, your passwords are too weak. Let's say you're using 12-character alphanumeric passwords, mixed case, no symbols, 3/4 alphabetic. That gives a search space of 3.28 x 10^21 possible passwords.[1] Knocking off 1,000 passwords on each pass means you need 3.28 x 10^18 passes to explore all options. Since there are only 3.7 x 10^9 public IPv4 addresses, total,[2] that means if every single public machine (or NAT) on the Internet were gathered into a massive zombie net, the chance of them cracking one of your passwords is 1 in a billion. My state lottery offers better odds. And we haven't even added symbols yet. But, I hear you say, fail2ban doesn't ban an IP forever. True. What it does is greatly stretch out the time between hammer blows, above that of ssh's own attack mitigation timers. Let's say you set the ban expiration time to 5 minutes. Let's also say you really annoyed someone, so they rent time on a 1 million machine zombie net, just to try and break into your server. Let's also say they focus their entire attack on a single account, rather than guess user names as well as passwords, as is common for SSH crackbots. The zombie net factor drops the 10^18 pass count magnitude above to the order of 10^12. 10^12 * 5 minutes is about 10 million years. If you start using pre-shared keys and configure sshd to accept keys only,[3] you turn lottery odds into astronomical odds. The twelve character passwords above have about 71 bits of entropy, if you pick them randomly. A generated SSH key is as close to random as you're likely to get, and it will have a *minimum* of 1,024 bits of entropy. Every bit of entropy doubles the required attack time, so you turn 10^9 into 10^ridiculous. (Well known exponent in number theory, that.) What if we're willing to settle for human time scales, rather than astronomical ones? Using the information above, I have come to the realization that if I can hold off the crackbot hordes for just another 100 years, I can stop caring about the risks, on account of the fact that I expect someone else will be taking care of my remaining CentOS 3 servers by then, and they will change the passwords shortly after handover. It turns out that 8 random lowercase letters is sufficient to buy me those 100 years. I can then go play Tetris in my centenarian dotage without a care for the security of my old Linux boxen. So, unless your passwords are weaker than 8 lowercase random letters, you're literally wasting time manually banning IPs. Let fail2ban do its job, while you go off and do something a dumb computer can't. I've used fail2ban myself, but only to cut down on log noise, not because it adds any real security. In the end, I've found that moving ssh to a nonstandard port is just as effective at reducing log noise. [1] https://www.grc.com/haystack.htm [2] http://goo.gl/7LtFvE [3] http://goo.gl/02oksG ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
On 6/17/2014 6:39 PM, Warren Young wrote: On 6/16/2014 15:58, Chuck Campbell wrote: If they keep going through this ip block, they will still get 255 attempts at the root password and 1020 attempts at other login/password combinations before they are blocked by fail2ban. I'm glad you got your firewall problem sorted out, but I can't let this comment slide. If removing a thousand possibilities from the pool of available credentials puts your servers at significant risk, your passwords are too weak. Let's say you're using 12-character alphanumeric passwords, mixed case, no symbols, 3/4 alphabetic. That gives a search space of 3.28 x 10^21 possible passwords.[1] Knocking off 1,000 passwords on each pass means you need 3.28 x 10^18 passes to explore all options. Since there are only 3.7 x 10^9 public IPv4 addresses, total,[2] that means if every single public machine (or NAT) on the Internet were gathered into a massive zombie net, the chance of them cracking one of your passwords is 1 in a billion. My state lottery offers better odds. And we haven't even added symbols yet. But, I hear you say, fail2ban doesn't ban an IP forever. True. What it does is greatly stretch out the time between hammer blows, above that of ssh's own attack mitigation timers. Let's say you set the ban expiration time to 5 minutes. Let's also say you really annoyed someone, so they rent time on a 1 million machine zombie net, just to try and break into your server. Let's also say they focus their entire attack on a single account, rather than guess user names as well as passwords, as is common for SSH crackbots. The zombie net factor drops the 10^18 pass count magnitude above to the order of 10^12. 10^12 * 5 minutes is about 10 million years. If you start using pre-shared keys and configure sshd to accept keys only,[3] you turn lottery odds into astronomical odds. The twelve character passwords above have about 71 bits of entropy, if you pick them randomly. A generated SSH key is as close to random as you're likely to get, and it will have a *minimum* of 1,024 bits of entropy. Every bit of entropy doubles the required attack time, so you turn 10^9 into 10^ridiculous. (Well known exponent in number theory, that.) What if we're willing to settle for human time scales, rather than astronomical ones? Using the information above, I have come to the realization that if I can hold off the crackbot hordes for just another 100 years, I can stop caring about the risks, on account of the fact that I expect someone else will be taking care of my remaining CentOS 3 servers by then, and they will change the passwords shortly after handover. It turns out that 8 random lowercase letters is sufficient to buy me those 100 years. I can then go play Tetris in my centenarian dotage without a care for the security of my old Linux boxen. So, unless your passwords are weaker than 8 lowercase random letters, you're literally wasting time manually banning IPs. Let fail2ban do its job, while you go off and do something a dumb computer can't. I've used fail2ban myself, but only to cut down on log noise, not because it adds any real security. In the end, I've found that moving ssh to a nonstandard port is just as effective at reducing log noise. [1] https://www.grc.com/haystack.htm [2] http://goo.gl/7LtFvE [3] http://goo.gl/02oksG ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos I concur with all you've said, and I haven't done the load stats, but it appears to me that a hundred of these crackers hitting my machine at these rates is likely to deny my legit users some resources. That is still a concern, but I've already seen that 20 banned ip ranges out of china has dropped the incidence from about 100 to 3. That's worth the effort to gain a better understanding of iptables in managing my servers anyway. I've noticed (unquantified) a bit better login response and interactive response without the resource drain, unless I'm just imagining it... Besides, just because the odds are against you, sometimes luck is all it takes. I'm looking into the shared keys approach, so I can do away with passwords. thanks, -chuck -- ACCEL Services, Inc.| Specialists in Gravity, Magnetics | (713)993-0671 ph. | and Integrated Interpretation | (713)993-0608 fax 448 W. 19th St. #325|Since 1992 | (713)306-5794 cell Houston, TX, 77008 | Chuck Campbell | campb...@accelinc.com | President Senior Geoscientist | Integration means more than having all the maps at the same scale! ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
On 6/17/2014 19:35, Chuck Campbell wrote: I haven't done the load stats, but it appears to me that a hundred of these crackers hitting my machine at these rates is likely to deny my legit users some resources. So increase the fail2ban time from the default (5 minutes, as I recall) to 1 hour, or 1 day. Besides, just because the odds are against you, sometimes luck is all it takes. That sort of thinking is why governments have started to levy taxes on people who are bad at math. (i.e. lotteries) Some risks simply aren't worth worrying about. Go play with the haystack calculator I linked from my previous email. If 8 random printable ASCII characters doesn't make you sleep well at night, make it nine. Now the attack space is about 2 orders of magnitude larger. If the risk with 8 was sometime in my career, which cannot stand a single breach, the risk with 9 becomes sometime after I have shuffled off this mortal coil. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
On Mon, 2014-06-16 at 16:58 -0500, Chuck Campbell wrote: I'm running fail2ban to attempt to block malicious brute-force password dictionary attacks against ssh. You could:- (1) Change the SSHD port to something obscure. (2) Restrict access to the SSHD port, using iptables, to a group of approved IP addresses. Regards, -- Paul. England, EU. Centos, Exim, Apache. Linux is the future. Micro$oft is the past. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
On Mon, 16 Jun 2014 16:58:18 -0500 Chuck Campbell wrote: Why is this ip range still able to attempt connections? Have I done something wrong with my address ranges, or added them in the wrong place? Have you considered taking the opposite approach and allowing only the IP addresses that you want to allow and blocking everything else? That would be a lot easier to keep track of and manage. I personally don't allow password logins on any of the ssh connections that I look after. -- MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
On 6/16/2014 2:58 PM, Chuck Campbell wrote: Chain INPUT (policy ACCEPT) target prot opt source destination fail2ban-VSFTPD tcp -- anywhere anywheretcp dpt:ftp fail2ban-SSH tcp -- anywhere anywheretcp dpt:ssh RH-Firewall-1-INPUT all -- anywhere anywhere DROP all -- 116.10.191.0/24 anywhere DROP all -- 183.136.220.0/24 anywhere DROP all -- 183.136.221.0/24 anywhere DROP all -- 183.136.222.0/24 anywhere DROP all -- 183.136.223.0/24 anywhere DROP all -- 122.224.11.0/24 anywhere DROP all -- 219.138.0.0/16 anywhere ... Chain RH-Firewall-1-INPUT (2 references) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT icmp -- anywhere anywhereicmp any ACCEPT esp -- anywhere anywhere . . . Yet in my logwatch emails, I see this, long after the iptables rules are in place to drop some ip ranges: RH-Firewall-1-INPUT is being invoked prior to your DROP rules, and is ACCEPTing all packets. -- john r pierce 37N 122W somewhere on the middle of the left coast ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
On 06/17/2014 01:11 AM, John R Pierce wrote: On 6/16/2014 2:58 PM, Chuck Campbell wrote: Chain INPUT (policy ACCEPT) target prot opt source destination fail2ban-VSFTPD tcp -- anywhere anywheretcp dpt:ftp fail2ban-SSH tcp -- anywhere anywheretcp dpt:ssh RH-Firewall-1-INPUT all -- anywhere anywhere DROP all -- 116.10.191.0/24 anywhere DROP all -- 183.136.220.0/24 anywhere DROP all -- 183.136.221.0/24 anywhere DROP all -- 183.136.222.0/24 anywhere DROP all -- 183.136.223.0/24 anywhere DROP all -- 122.224.11.0/24 anywhere DROP all -- 219.138.0.0/16 anywhere How did you added these rules? using manual command line tools or automatically by fail2ban? Eliezer ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
On 06/17/2014 01:46 AM, Bret Taylor wrote: Get rid of fail2ban, it's not needed. Just write a proper firewall. Are you series?? There are applications that fail2ban offers them things which others just can't.. If you can email me the ip for your servers and also the root password and allow me in your INPUT all over the place I will leave you a message in the server.(hope you understand jokes) All The Bests, Eliezer ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
[previous article hasn't appeared on gmane yet] On 2014-06-16, Eliezer Croitoru elie...@ngtech.co.il wrote: On 06/17/2014 01:46 AM, Bret Taylor wrote: Get rid of fail2ban, it's not needed. Just write a proper firewall. Are you series?? There are applications that fail2ban offers them things which others just can't.. Indeed, fail2ban and their ilk (e.g. my new favorite, sshguard) modify iptables rules in response to excessive failed login attempts. A ''proper firewall'' with just static iptables rules can't do that. And with so many pwn3d hosts out there being used to bounce attacks off of, it is foolish to rely on static rules alone to fend off these attacks. Much better of course are static firewall rules that blocks off all but a few whitelisted hosts. But that is much less flexible for users. --keith -- kkel...@wombat.san-francisco.ca.us (try just my userid to email me) AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt see X- headers for PGP signature information ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
All of the suggestions are graciously accepted, however, I was actually asking what I was doing wrong with iptables, and why, with the rules I put in place, someone was still able to connect to my machine. I understand there might be better ways, but if I don't understand what I did wrong last time, how am I going to figure out how to deny all, then allow selected, ehrn I can't seem to allow all and deny selected. There must be a misunderstanding on my part about how iptables are supposed to work. -chuck -- ACCEL Services, Inc.| Specialists in Gravity, Magnetics | (713)993-0671 ph. | and Integrated Interpretation | (713)993-0608 fax 448 W. 19th St. #325|Since 1992 | (713)306-5794 cell Houston, TX, 77008 | Chuck Campbell | campb...@accelinc.com | President Senior Geoscientist | Integration means more than having all the maps at the same scale! ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
On Mon, 2014-06-16 at 21:42 -0500, Chuck Campbell wrote: All of the suggestions are graciously accepted, however, I was actually asking what I was doing wrong with iptables, and why, with the rules I put in place, someone was still able to connect to my machine. I understand there might be better ways, but if I don't understand what I did wrong last time, how am I going to figure out how to deny all, then allow selected, ehrn I can't seem to allow all and deny selected. There must be a misunderstanding on my part about how iptables are supposed to work. -chuck As John R Pierce mentioned one of your first rule in the chain is RH-Firewall-1-INPUT all -- anywhere anywhere, this simply mean everything with DROP after it will be ignored. iptables will work its way down the chain, therefore you have to options 1. remove that line or 2. move it at the bottom of the chain. -- Kind Regards Earl Ramirez GPG Key: http://trinipino.com/PublicKey.asc signature.asc Description: This is a digitally signed message part ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
On 6/16/2014 9:44 PM, Earl Ramirez wrote: On Mon, 2014-06-16 at 21:42 -0500, Chuck Campbell wrote: All of the suggestions are graciously accepted, however, I was actually asking what I was doing wrong with iptables, and why, with the rules I put in place, someone was still able to connect to my machine. I understand there might be better ways, but if I don't understand what I did wrong last time, how am I going to figure out how to deny all, then allow selected, ehrn I can't seem to allow all and deny selected. There must be a misunderstanding on my part about how iptables are supposed to work. -chuck As John R Pierce mentioned one of your first rule in the chain is RH-Firewall-1-INPUT all -- anywhere anywhere, this simply mean everything with DROP after it will be ignored. iptables will work its way down the chain, therefore you have to options 1. remove that line or 2. move it at the bottom of the chain. I am clearly missing some emails, because I didn't see a reply from John R Pierce. My apologies. I appreciate you restating this. I'll try to go make sense of iptables, given the insight, thanks, -chuck -- ACCEL Services, Inc.| Specialists in Gravity, Magnetics | (713)993-0671 ph. | and Integrated Interpretation | (713)993-0608 fax 448 W. 19th St. #325|Since 1992 | (713)306-5794 cell Houston, TX, 77008 | Chuck Campbell | campb...@accelinc.com | President Senior Geoscientist | Integration means more than having all the maps at the same scale! ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
As John R Pierce mentioned one of your first rule in the chain is RH-Firewall-1-INPUT all -- anywhere anywhere, this simply mean everything with DROP after it will be ignored. iptables will work its way down the chain, therefore you have to options 1. remove that line or 2. move it at the bottom of the chain. I am clearly missing some emails, because I didn't see a reply from John R Pierce. My apologies. I appreciate you restating this. I'll try to go make sense of iptables, given the insight, thanks, -chuck OK, I went to the list archive and found the email in question. Also, one after it that asked how I added these rules. I ran a script after fail2ban was started. It looks like this: #!/bin/sh iptables -A INPUT -s 116.10.191.0/24 -j DROP iptables -A INPUT -s 183.136.220.0/24 -j DROP iptables -A INPUT -s 183.136.221.0/24 -j DROP iptables -A INPUT -s 183.136.222.0/24 -j DROP iptables -A INPUT -s 183.136.223.0/24 -j DROP iptables -A INPUT -s 122.224.11.0/24 -j DROP iptables -A INPUT -s 219.138.0.0/16 -j DROP so, how do I get them in front of the RH-Firewall-1-INPUT, or do I add them to that chain? -chuck -- ACCEL Services, Inc.| Specialists in Gravity, Magnetics | (713)993-0671 ph. | and Integrated Interpretation | (713)993-0608 fax 448 W. 19th St. #325|Since 1992 | (713)306-5794 cell Houston, TX, 77008 | Chuck Campbell | campb...@accelinc.com | President Senior Geoscientist | Integration means more than having all the maps at the same scale! ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
On 6/16/2014 8:52 PM, Chuck Campbell wrote: I ran a script after fail2ban was started. It looks like this: #!/bin/sh iptables -A INPUT -s 116.10.191.0/24 -j DROP iptables -A INPUT -s 183.136.220.0/24 -j DROP iptables -A INPUT -s 183.136.221.0/24 -j DROP iptables -A INPUT -s 183.136.222.0/24 -j DROP iptables -A INPUT -s 183.136.223.0/24 -j DROP iptables -A INPUT -s 122.224.11.0/24 -j DROP iptables -A INPUT -s 219.138.0.0/16 -j DROP so, how do I get them in front of the RH-Firewall-1-INPUT, or do I add them to that chain? use -I (insert) rather than -A (append). OR specify chain RH-Firewall-1-INPUT rather than INPUT OR, better use system-config-firewall rather than running your own iptables commands.this manages the rules used by the RH firewall scripts invoked by the iptables service which is run at boot time. also, if you do manually add iptables rules, you can use `service iptables save` to remember these changes, instead of running them from your own scripts. these changes get saved to /etc/sysconfig/iptables -- john r pierce 37N 122W somewhere on the middle of the left coast ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question.
On Mon, Feb 21, 2011, Stephen Harris wrote: On Mon, Feb 21, 2011 at 03:32:40PM -0800, Bill Campbell wrote: My problem is that occassionally an IP addresses doesn't appear to be blocked as we continue to see the e-mail messages after the blocks are in place. Most frequently these occur from courier-imap failed login attempts, less frequently from sshd. To start, iptables is initialized by setting up a named rule set, say on eth0: # these two set up the rule set. iptables -N csblocks iptables -A csblocks -j RETURN # now add it to input, check csblocks on all new connections. iptables -i eth0 -m state --state NEW -j csblocks With all that incoming attempts still seem to get by for a few IP addresses, but certainly not all. Can anybody point out what I'm doing wrong, or why this may happen? Connections that are already established may be blocked but traffic will continue to flow because you're only blocking on NEW traffic. eg connection made login fail login fail login fail BLOCK HAPPENS - perhaps it's the 5th set of connections and it's just tripped the threshold login fail login fail login fail too many failed attempts, disconnected by server daemon new connection blocked You'll see 3 login failures after the block occured because the connection was still open. That makes sense, and was one of the first things I thought of. On the other hand lsof -n -i doesn't show any open connections to the IP address, and I would think that the forwarding and null route would prevent that. Bill -- INTERNET: b...@celestial.com Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way Voice: (206) 236-1676 Mercer Island, WA 98040-0820 Fax:(206) 232-9186 Skype: jwccsllc (206) 855-5792 Historically, inflation is a classic game of legal plunder, more effective than taxes since the legalized theft is concealed. -- T. Hunt Tooley http://mises.org/story/3292 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
Kai Schaetzl wrote: Bowie Bailey wrote on Mon, 19 Oct 2009 17:18:16 -0400: The destination address is the private IP of the server. These seem to be related to outgoing email connections based on the source IPs Is 195.140.240.6 the public IP of that machine? Why do you obfuscate a private IP number? Do you want to say that these are internal mail server connections? If not, the explanation about the IP numbers doesn't make sense to me. No, 195.140... is the IP of the remote machine. I obfuscated the private IP of the mail server (and MAC address) on general principles since they are not relevant to the question. What I am seeing is a remote server trying to make a connection from port 25 to a high-numbered port on my mail server. Iptables rejects the connection since it is not on an allowed port or part of an established conversation. The question is: why are all of these remote servers trying to make connections back to me on high-numbered ports? Should I be allowing these connections somehow? For clarity's sake, here are a few non-obfuscated examples: Oct 20 11:42:27 bnofmail kernel: REJECT: IN=eth0 OUT= MAC=00:50:8d:59:60:2e:00:90:27:c2:79:77:08:00 SRC=209.27.55.194 DST=172.16.17.169 LEN=107 TOS=0x00 PREC=0x00 TTL=52 ID=56970 DF PROTO=TCP SPT=25 DPT=40312 WINDOW=62928 RES=0x00 ACK PSH FIN URGP=0 Oct 20 11:42:49 bnofmail kernel: REJECT: IN=eth0 OUT= MAC=00:50:8d:59:60:2e:00:90:27:c2:79:77:08:00 SRC=203.17.219.68 DST=172.16.17.169 LEN=52 TOS=0x00 PREC=0x00 TTL=117 ID=19851 DF PROTO=TCP SPT=25 DPT=40289 WINDOW=64167 RES=0x00 ACK FIN URGP=0 Oct 20 11:43:01 bnofmail kernel: REJECT: IN=eth0 OUT= MAC=00:50:8d:59:60:2e:00:90:27:c2:79:77:08:00 SRC=204.127.217.16 DST=172.16.17.169 LEN=72 TOS=0x00 PREC=0x20 TTL=50 ID=15125 DF PROTO=TCP SPT=25 DPT=40346 WINDOW=64296 RES=0x00 ACK URGP=0 172.16.17.169 is the private IP of one of my mailservers. The other IPs are remote servers not under my control. About 20% of them are servers that have received outbound email from my server recently. I have no idea where the others come from. I have gotten over 83,000 of these connection attempts so far today from 267 unique IP addresses. -- Bowie ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
conversation. The question is: why are all of these remote servers trying to make connections back to me on high-numbered ports? Should I be allowing these connections somehow? The remote server probably thinks that it's still supposed to be making connections back to you -- a couple of the lines you posted showed FIN flags indicating that the TCP connection was being shut down. At that point, the mail message has already been sent. If you get REJECT messages for all SMTP connections, look at your iptables rules and see if you have a specific rule for smtp that only permits NEW conns. One possibility is that iptables no longer thinks that the connection is active -- possibly the connection tracking database has already pushed that connection out. You can check your conntrack max value with the command cat /proc/sys/net/ipv4/ip_conntrack_max Yet another possibility is that these are duplicated packets (for whatever reason) and the connection has already been closed out. M ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
Meenoo Shivdasani wrote: conversation. The question is: why are all of these remote servers trying to make connections back to me on high-numbered ports? Should I be allowing these connections somehow? The remote server probably thinks that it's still supposed to be making connections back to you -- a couple of the lines you posted showed FIN flags indicating that the TCP connection was being shut down. At that point, the mail message has already been sent. If you get REJECT messages for all SMTP connections, look at your iptables rules and see if you have a specific rule for smtp that only permits NEW conns. But these aren't SMTP connections. The source is port 25, but the destination is not. The mail server is running normally. I'm allowing new SMTP connections and traffic for established connections. ACCEPT all -- 0.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:25 One possibility is that iptables no longer thinks that the connection is active -- possibly the connection tracking database has already pushed that connection out. You can check your conntrack max value with the command cat /proc/sys/net/ipv4/ip_conntrack_max # cat /proc/sys/net/ipv4/ip_conntrack_max 63480 Yet another possibility is that these are duplicated packets (for whatever reason) and the connection has already been closed out. Possible, I guess, but I don't know what would be duplicating them. -- Bowie ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
Meenoo Shivdasani wrote: But these aren't SMTP connections. The source is port 25, but the destination is not. The mail server is running normally. I'm allowing new SMTP connections and traffic for established connections. They are SMTP connections -- your server initiates a connection to port 25 on the remote server. Thus, when the connection is set up the remote server will be responding with source port 25 and destination port = source port of the initiated connection. I understand that. What I meant was that iptables will not see them as SMTP connections since the destination is not port 25. ACCEPT all -- 0.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:25 I think the ACCEPT all line should catch these, but you might try adding RELATED,ESTABLISHED specifically to the dpt:25 line. Which will not match these connections since the dest port is not 25. I could put a RELATED, ESTABLISHED line in for source port 25, but as you said, the ACCEPT all line should catch them anyway. -- Bowie ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
Bowie Bailey wrote on Mon, 19 Oct 2009 17:18:16 -0400: The destination address is the private IP of the server. These seem to be related to outgoing email connections based on the source IPs Is 195.140.240.6 the public IP of that machine? Why do you obfuscate a private IP number? Do you want to say that these are internal mail server connections? If not, the explanation about the IP numbers doesn't make sense to me. Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
On Monday 19 October 2009 17:18, Bowie Bailey wrote: The logs on my mail server are filling up with this kind of thing: Oct 19 17:03:51 bnofmail kernel: REJECT: IN=eth0 OUT= MAC=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX SRC=195.140.240.6 DST=XX.XX.XX.XX LEN=189 TOS=0x00 PREC=0x00 TTL=52 ID=6284 DF PROTO=TCP SPT=25 DPT=32776 WINDOW=65535 RES=0x00 ACK PSH URGP=0 The source port is always 25 and the destination is a high-numbered port. The destination address is the private IP of the server. These seem to be related to outgoing email connections based on the source IPs, but I don't know why they are not part of an established connection. The mail server seems to be running just fine regardless of these blocked connections. Any ideas? Are you running a mixed firewall rule set? Stateful and Connection or just one or the other? Since you state a private address, I'm going to assume you mean something in the 192.168 or similar space, is NATting an issue? -- Regards Robert Linux User #296285 http://counter.li.org ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
I've added the following and it still isn't working iptables -t nat -I PREROUTING -p tcp -m tcp --dport 8443 -j DNAT --to-destination 192.168.0.2:8443 iptables -A FORWARD -d 192.168.0.1 -p tcp -m tcp --dport 8443 -j ACCEPT I've enabled forwarding - not sure if it's needed but it's there just in case. -Original Message- From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On Behalf Of Dan Carl Sent: Friday, February 20, 2009 10:24 AM To: CentOS mailing list Subject: Re: [CentOS] iptables question Try this tutorial its long but thorough . http://iptables-tutorial.frozentux.net/iptables-tutorial.html There are several examples that you should be able to craft to fit your needs. First you make a forward chain and then prerouting chain with DNAT. Be advised if you don't have console access you can cut off your access very easy with iptables. Dan ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
ward.p.fonte...@wellsfargo.com wrote: I've added the following and it still isn't working iptables -t nat -I PREROUTING -p tcp -m tcp --dport 8443 -j DNAT --to-destination 192.168.0.2:8443 iptables -A FORWARD -d 192.168.0.1 -p tcp -m tcp --dport 8443 -j ACCEPT I've enabled forwarding - not sure if it's needed but it's there just in case. Yes, you do need forwarding enabled. In that second rule, the match address should be 192.168.0.2 since the translation has already been applied. What does the rest of your FILTER chain look like? If the packet matches a REJECT rule prior to reaching your ACCEPT rule, that will be the end of it. -- Bob Nichols NOSPAM is really part of my email address. Do NOT delete it. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
Filipe Brandenburger wrote: Hi Ward, On Thu, Feb 19, 2009 at 20:27, ward.p.fonte...@wellsfargo.com wrote: I add that and telnet to the port on BOX A and get Trying 192.168.0.1... telnet: connect to address 192.168.0.1: Connection refused I can telnet to that port on BOX B and get a successful connection. The problem is that when BOX B responds, it will respond with a 192.168.0.2 source IP, and that will only work if it goes through BOX A again (for the DNAT to do the address translation back to 192.168.0.1). In short, this will only work if traffic goes back to the source through BOX A. For instance, this will NOT happen if the host that is connecting to the forwarded port is in the same subnet as hosts BOX A and BOX B. This will also NOT happen if BOX A is not the default gateway of BOX B, or there is somehow another configuration that routes the return packets through BOX A (like using an SNAT combined with the DNAT to make the connections look like they are coming from BOX A). A Connection refused response indicates that the reply path is working. If there is no response, telnet will just sit and wait, eventually displaying a Connection timed out message when the connection times out from the SYN_SENT state (typically about 3 minutes). -- Bob Nichols NOSPAM is really part of my email address. Do NOT delete it. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
ward.p.fonte...@wellsfargo.com wrote: Hi, I have two servers in the same subnet, one has this arrangement: BOX A [3 ips, one real two vips] BOX B [1 ip] I need to redirect input from one of the vips (192.168.0.1:8080) on BOX A to BOX B (192.168.0.2:8080) and I'm about to pull my hair out. Can anyone lend a hand? All my searching leads me to home firewall type arrangements using DNAT. I tried to bend one of those to fit my situation but it was a no go (most likely due to my lack of knowledge with iptables) Paul Fontenot snip signature Try this tutorial its long but thorough . http://iptables-tutorial.frozentux.net/iptables-tutorial.html There are several examples that you should be able to craft to fit your needs. First you make a forward chain and then prerouting chain with DNAT. Be advised if you don't have console access you can cut off your access very easy with iptables. Dan ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
On Thu, 2009-02-19 at 18:46 -0600, ward.p.fonte...@wellsfargo.com wrote: Hi, I have two servers in the same subnet, one has this arrangement: BOX A [3 ips, one real two vips] BOX B [1 ip] I need to redirect input from one of the vips (192.168.0.1:8080) on BOX A to BOX B (192.168.0.2:8080) and I'm about to pull my hair out. Can anyone lend a hand? All my searching leads me to home firewall type arrangements using DNAT. I tried to bend one of those to fit my situation but it was a no go (most likely due to my lack of knowledge with iptables) Why not keep the vip and move it over to the other box? Heartbeat is perfectly suited to such a task... -I ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
On Thu, 19 Feb 2009 ward.p.fonte...@wellsfargo.com wrote: Hi, I have two servers in the same subnet, one has this arrangement: BOX A [3 ips, one real two vips] BOX B [1 ip] I need to redirect input from one of the vips (192.168.0.1:8080) on BOX A to BOX B (192.168.0.2:8080) and I'm about to pull my hair out. Can anyone lend a hand? All my searching leads me to home firewall type arrangements using DNAT. I tried to bend one of those to fit my situation but it was a no go (most likely due to my lack of knowledge with iptables) iptables -t nat -I PREROUTING -d 192.168.0.1 -p tcp --dport 8080 -j DNAT --to 192.168.0.2 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
I add that and telnet to the port on BOX A and get Trying 192.168.0.1... telnet: connect to address 192.168.0.1: Connection refused I can telnet to that port on BOX B and get a successful connection. -Original Message- From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On Behalf Of Barry Brimer Sent: Thursday, February 19, 2009 5:38 PM To: CentOS mailing list Subject: Re: [CentOS] iptables question On Thu, 19 Feb 2009 ward.p.fonte...@wellsfargo.com wrote: Hi, I have two servers in the same subnet, one has this arrangement: BOX A [3 ips, one real two vips] BOX B [1 ip] I need to redirect input from one of the vips (192.168.0.1:8080) on BOX A to BOX B (192.168.0.2:8080) and I'm about to pull my hair out. Can anyone lend a hand? All my searching leads me to home firewall type arrangements using DNAT. I tried to bend one of those to fit my situation but it was a no go (most likely due to my lack of knowledge with iptables) iptables -t nat -I PREROUTING -d 192.168.0.1 -p tcp --dport 8080 -j DNAT --to 192.168.0.2 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
On Thu, Feb 19, 2009 at 7:46 PM, ward.p.fonte...@wellsfargo.com wrote: I need to redirect input from one of the vips (192.168.0.1:8080) on BOX A to BOX B (192.168.0.2:8080) and I'm about to pull my hair out. While i haven't done this before, i believe the answer you're looking for lies in SNAT. It would seem the requirements would be that the traffic needs to wind up at the right destination (NAT would get you that far) but the return traffic must also appear to come from the original VIP or else the source device would not already think it has an open session with that device. Take a look here: http://www.linuxtopia.org/Linux_Firewall_iptables/x4658.html Good luck! -- Jake Paulus jakepau...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
On Thu, 19 Feb 2009 ward.p.fonte...@wellsfargo.com wrote: I add that and telnet to the port on BOX A and get Trying 192.168.0.1... telnet: connect to address 192.168.0.1: Connection refused I can telnet to that port on BOX B and get a successful connection. I assume that you are not telnetting from Box A .. as that will most likely not work. Are there any additional firewall rules on Box A? Barry -Original Message- From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On Behalf Of Barry Brimer Sent: Thursday, February 19, 2009 5:38 PM To: CentOS mailing list Subject: Re: [CentOS] iptables question On Thu, 19 Feb 2009 ward.p.fonte...@wellsfargo.com wrote: Hi, I have two servers in the same subnet, one has this arrangement: BOX A [3 ips, one real two vips] BOX B [1 ip] I need to redirect input from one of the vips (192.168.0.1:8080) on BOX A to BOX B (192.168.0.2:8080) and I'm about to pull my hair out. Can anyone lend a hand? All my searching leads me to home firewall type arrangements using DNAT. I tried to bend one of those to fit my situation but it was a no go (most likely due to my lack of knowledge with iptables) iptables -t nat -I PREROUTING -d 192.168.0.1 -p tcp --dport 8080 -j DNAT --to 192.168.0.2 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
There are a few on there and I'm telnetting from a different box on that network. I'll dig around some more and eventually figure it out. Thanks for pointing me in the right direction. -Original Message- From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On Behalf Of Barry Brimer Sent: Thursday, February 19, 2009 6:22 PM To: CentOS mailing list Subject: Re: [CentOS] iptables question On Thu, 19 Feb 2009 ward.p.fonte...@wellsfargo.com wrote: I add that and telnet to the port on BOX A and get Trying 192.168.0.1... telnet: connect to address 192.168.0.1: Connection refused I can telnet to that port on BOX B and get a successful connection. I assume that you are not telnetting from Box A .. as that will most likely not work. Are there any additional firewall rules on Box A? Barry -Original Message- From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On Behalf Of Barry Brimer Sent: Thursday, February 19, 2009 5:38 PM To: CentOS mailing list Subject: Re: [CentOS] iptables question On Thu, 19 Feb 2009 ward.p.fonte...@wellsfargo.com wrote: Hi, I have two servers in the same subnet, one has this arrangement: BOX A [3 ips, one real two vips] BOX B [1 ip] I need to redirect input from one of the vips (192.168.0.1:8080) on BOX A to BOX B (192.168.0.2:8080) and I'm about to pull my hair out. Can anyone lend a hand? All my searching leads me to home firewall type arrangements using DNAT. I tried to bend one of those to fit my situation but it was a no go (most likely due to my lack of knowledge with iptables) iptables -t nat -I PREROUTING -d 192.168.0.1 -p tcp --dport 8080 -j DNAT --to 192.168.0.2 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
-Original Message- From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On Behalf Of Barry Brimer Sent: Thursday, February 19, 2009 5:38 PM To: CentOS mailing list Subject: Re: [CentOS] iptables question On Thu, 19 Feb 2009 ward.p.fonte...@wellsfargo.com wrote: Hi, I have two servers in the same subnet, one has this arrangement: BOX A [3 ips, one real two vips] BOX B [1 ip] I need to redirect input from one of the vips (192.168.0.1:8080) on BOX A to BOX B (192.168.0.2:8080) and I'm about to pull my hair out. Can anyone lend a hand? All my searching leads me to home firewall type arrangements using DNAT. I tried to bend one of those to fit my situation but it was a no go (most likely due to my lack of knowledge with iptables) iptables -t nat -I PREROUTING -d 192.168.0.1 -p tcp --dport 8080 -j DNAT --to 192.168.0.2 Hi. DNAT is what you would be wanting. As can be seen, DNAT is processed in the PREROUTING chain in the nat table, thus it happens before packets hit the filter table and all you are doing is changing the destination address. You will still need rules in your forward chain of your filter table (it is still forward even if the packets enter and exit the same network card). This rule will need to allow the original source to talk to the new destination. Regards, Andrew. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Iptables Question
Makes sense to me. Is the host that you are wanting to bypass your proxy on the same segment as the $LAN interface defined in your rulesets? On Wed, Dec 10, 2008 at 1:22 PM, Joseph L. Casale [EMAIL PROTECTED] wrote: I have a squid proxy running transparently, so in my firewall script I run the following fairly early: iptables -A PREROUTING -t nat -i $LAN -p tcp -m multiport --dports 80,443 -j REDIRECT --to-port 3128 This is a multihomed server so after this change the masquerading was removed (as only web access on the lan side of this server was needed). I now need to masq cleanly one device so that it can bypass the squid proxy. As order is important, would it be correct to put the following _in front_ of the PREROUTING command above: iptables -A POSTROUTING -t nat -o $WAN -j MASQUERADE iptables -A FORWARD -i $LAN -o $WAN -m mac --mac-source mac addr -m state --state NEW,ESTABLISHED,RELATED -p tcp -m multiport --dports 443 -j ACCEPT iptables -A FORWARD -i $WAN -o $LAN -m state --state RELATED,ESTABLISHED -j ACCEPT Where is the best place to filter for the mac in this scenario? I am hoping anything w/o this mac will skip the whole masq setup and enter the PREROUTING command below, resulting in the traffic being proxied through squid. Thanks! jlc ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos -- Thx Joshua Gimer ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Iptables Question
Makes sense to me. Yea, I just don't know technically speaking where the -m mac should appear, in the POSTROUTING line, or the first FORWARD line. Ultimately I would only masq'ing to be done for this one device on port 443. Is the host that you are wanting to bypass your proxy on the same segment as the $LAN interface defined in your rulesets? It is, how comes? I could filter by ip instead of mac but this is easier and although a non issue really, more secure. Thanks! jlc ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
On 28 Aug 2008, at 15:22, Joseph L. Casale wrote: I tried writing out a FWBuilder script but man that thing was something messy to look at, geesh... Since you mentioned a FWBuilder script you might want to look at FireHOL as well (http://firehol.sourceforge.net/). I've been using it for a couple of years now. The config is dead simple and allows for custom rules where needed. Jeremiah ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
On Wednesday 27 August 2008 19:27, Joseph L. Casale wrote: http://iptables.rlworkman.net/chunkyhtml/index.html Nice doc, any ideas on how to print it (or many chapters easily) so I can haul with me on my plane ride this weekend? Nope, but I'm open to suggestions. :) -- Regards Robert Smile... it increases your face value! Linux User #296285 http://counter.li.org ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
RE: [CentOS] iptables question
Nope, but I'm open to suggestions. :) Scott provided a PDF a link to a non chunky html version that worked! I have it printed on my desk right now! That will make for some good dry reading on my plane ride Saturday. IPTables is something for me that has a few to many core holes and I need to develop a better grasp of this. I tried writing out a FWBuilder script but man that thing was something messy to look at, geesh... Nice tool though! Back to my original script that works, but needs the fancy touches added... Thanks! jlc ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
Joseph L. Casale wrote: When do you know you need the -m multiport option? I see examples with -dport xx:xxx for example that sometimes use it and sometimes don't? I have read the man page and see what -m multiport requires, but don't see the requirement involving its use. Thanks! jlc I'll take a guess but am happy to be corrected if someone knows better... My understanding is that --dport can only specify a single port (--dport 80) or port range (--dport 137:139) inclusive. Use of the multiport module allows up to 15 ports (or port ranges) to be specified. As for a potential usage - off the top of my head, suppose you wanted to open ports 137-139 and 445 for SMB/Samba. This could be achieved with a single rule using the multiport module whereas 2 individual rules would otherwise be needed. Again, suppose you wanted to open ports 21 (FTP), 22 (SSH) and 110 (POP3) to a select IP address - you could do this in a single rule rather than 3 individual rules which opens up possibilities for optimizing/minimizing the number of iptables rules within a chain. Ned ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
RE: [CentOS] iptables question
My understanding is that --dport can only specify a single port (--dport 80) or port range (--dport 137:139) inclusive. Use of the multiport module allows up to 15 ports (or port ranges) to be specified. Ned, So to write --dport 5060,1:6 you need to write: -m multiport -p udp -dport 5060,1:6 Correct? Thanks for the help! jlc ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
Joseph L. Casale wrote: My understanding is that --dport can only specify a single port (--dport 80) or port range (--dport 137:139) inclusive. Use of the multiport module allows up to 15 ports (or port ranges) to be specified. Ned, So to write --dport 5060,1:6 you need to write: -m multiport -p udp -dport 5060,1:6 Correct? Thanks for the help! jlc I've not used multiport so am unsure of the exact syntax, but that looks reasonable. I'd keep the -m multiport and --dports together though (also note it's --dports, not -dport), so something like this: iptables -A INPUT -p udp -m multiport --dports 5060,1:6 -j ACCEPT would accept all UDP packets destined for ports 5060 and 1-6. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
On Thu, 2007-09-20 at 14:55 -0400, Ray Leventhal wrote: Hi all, With SELinux in permissive mode and iptables running, I'm unable to retrieve directory listings with ftp. stop iptables, and all appears again. This seems to be unrelated to passive/port modes for ftp client. Depending how you configured your iptables rules, you'll probably anyway need the ip_conntrack_ftp iptables module. You can modprobe it, or even better, declare it in /etc/sysconfig/iptables-config ... -- Fabian Arrotin [EMAIL PROTECTED] Solution ? echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq' | dc signature.asc Description: This is a digitally signed message part ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
Fabian Arrotin wrote: On Thu, 2007-09-20 at 14:55 -0400, Ray Leventhal wrote: Hi all, With SELinux in permissive mode and iptables running, I'm unable to retrieve directory listings with ftp. stop iptables, and all appears again. This seems to be unrelated to passive/port modes for ftp client. Depending how you configured your iptables rules, you'll probably anyway need the ip_conntrack_ftp iptables module. You can modprobe it, or even better, declare it in /etc/sysconfig/iptables-config ... Thanks, Fabian. I'll have at the iptables-config ~Ray ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
Dear Salam, Try to add following enteries in table. /sbin/iptables -A INPUT -p tcp --dport 20 -j ACCEPT /sbin/iptables -A INPUT -p udp --dport 20 -j ACCEPT /sbin/iptables -A INPUT -p tcp --dport 21 -j ACCEPT /sbin/iptables -A INPUT -p tcp --dport 21 -j ACCEPT Then use iptables -L command to show the enteries. Regards, Umair Shakil ETD On 9/20/07, Ray Leventhal [EMAIL PROTECTED] wrote: Hi all, With SELinux in permissive mode and iptables running, I'm unable to retrieve directory listings with ftp. stop iptables, and all appears again. This seems to be unrelated to passive/port modes for ftp client. If this is off topic, please let me know offlist and I'll take my question elsewhere. Otherwise I'll repost with output of # iptables status TIA, ~Ray ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
RE: [CentOS] iptables question
Something along these lines should do the job for ya. iptables -A INPUT -s 0.0.0.0/0 -d x.x.x.x/32 -m hashlimit --hashlimit 200 --hashlimit-mode dstip -j LOG iptables -A INPUT -s 0.0.0.0/0 -d x.x.x.x/32 -j DROP Dig around on this site for more details. http://iptables-tutorial.frozentux.net/iptables-tutorial.html -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ann kok Sent: Wednesday, June 20, 2007 10:46 AM To: centos@centos.org Subject: [CentOS] iptables question Hi all Can iptables have log and deny rule together? if no. how can I make a deny rule and log rule and the log rule can limit the log entry eg: 200 if yes, how can I make it I am using freebsd ipfw. eg: ipfw add 22 deny log all from any to x.x.x.x thank you Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos more. http://mobile.yahoo.com/go?refer=1GNXIC ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
RE: [CentOS] iptables question
I believe that iptables is different than freebsd's ipfw.
I don't think the rules would be expressed the same way.
Am I wrong?
-chaz
Charles L. Sliger, Information Systems Engineer
[EMAIL PROTECTED] {Yahoo: chaz_sliger} {Google: chaz.sliger}
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of ann kok
Sent: Wednesday, June 20, 2007 7:46 AM
To: centos@centos.org
Subject: [CentOS] iptables question
Hi all
Can iptables have log and deny rule together?
if no. how can I make a deny rule and log rule
and the log rule can limit the log entry eg: 200
if yes, how can I make it
I am using freebsd ipfw.
eg: ipfw add 22 deny log all from any to x.x.x.x
thank you
__
__
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail,
news, photos more.
http://mobile.yahoo.com/go?refer=1GNXIC
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
