Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: IPTables configuration questions

  1. #1
    Join Date
    May 2012
    Beans
    72

    IPTables configuration questions

    I have an IPTables script that I wrote myself. I will paste the relevant parts of the script below:

    Code:
    ## Default policies
    #
    iptables -P INPUT DROP
            # Drops all but approved input
    iptables -P OUTPUT ACCEPT
            # See output filtering rules below
    iptables -P FORWARD ACCEPT
            # Forward has to be set to accept for the connections to go through to the other side to the LAN
            # See forward filtering rules below
    Code:
    # FTP
    iptables -A OUTPUT -p tcp -s 10.1.10.71 --dport 21 -j ACCEPT
    iptables -A FORWARD -p tcp -s 10.1.10.71 --dport 21 -j ACCEPT
    
    iptables -A OUTPUT -p tcp -s 10.1.10.72 --dport 21 -j ACCEPT
    iptables -A FORWARD -p tcp -s 10.1.10.72 --dport 21 -j ACCEPT
    
    # SMTP
    iptables -A OUTPUT -p tcp -s 10.1.10.71 --dport 25 -j ACCEPT
    iptables -A FORWARD -p tcp -s 10.1.10.71 --dport 25 -j ACCEPT
    
    iptables -A OUTPUT -p tcp -s 10.1.10.72 --dport 25 -j ACCEPT
    iptables -A FORWARD -p tcp -s 10.1.10.72 --dport 25 -j ACCEPT
    The two internal IPs having access to SMTP/FTP is intentional. No other IPs on the LAN do.

    Code:
    ## Dropped outgoing ports
    #
    iptables -A OUTPUT -p tcp --dport 21 -j DROP
    iptables -A OUTPUT -p tcp --dport 22 -j DROP
    iptables -A OUTPUT -p tcp --dport 23 -j DROP
    iptables -A OUTPUT -p tcp --dport 25 -j DROP
    iptables -A OUTPUT -p tcp --dport 43 -j DROP
    iptables -A OUTPUT -p tcp --dport 53 -j DROP
    iptables -A OUTPUT -p tcp --dport 79 -j DROP
    iptables -A OUTPUT -p tcp --dport 80 -j DROP # HTTP
    iptables -A OUTPUT -p tcp --dport 110 -j DROP
    iptables -A OUTPUT -p tcp --dport 115 -j DROP
    iptables -A OUTPUT -p tcp --dport 119 -j DROP
    iptables -A OUTPUT -p tcp --dport 143 -j DROP
    iptables -A OUTPUT -p tcp --dport 389 -j DROP
    iptables -A OUTPUT -p tcp --dport 443 -j DROP # HTTPS
    Code:
    ## Dropped forwarding ports
    #
    iptables -A FORWARD -p tcp --dport 21 -j DROP
    iptables -A FORWARD -p tcp --dport 22 -j DROP
    iptables -A FORWARD -p tcp --dport 23 -j DROP
    iptables -A FORWARD -p tcp --dport 25 -j DROP
    iptables -A FORWARD -p tcp --dport 43 -j DROP
    iptables -A FORWARD -p tcp --dport 53 -j DROP
    iptables -A FORWARD -p tcp --dport 79 -j DROP
    iptables -A FORWARD -p tcp --dport 80 -j DROP # HTTP
    iptables -A FORWARD -p tcp --dport 110 -j DROP
    iptables -A FORWARD -p tcp --dport 115 -j DROP
    iptables -A FORWARD -p tcp --dport 119 -j DROP
    iptables -A FORWARD -p tcp --dport 143 -j DROP
    iptables -A FORWARD -p tcp --dport 389 -j DROP
    iptables -A FORWARD -p tcp --dport 443 -j DROP # HTTPS
    Code:
    ## Allowed users
    #
    iptables -A INPUT -s xx.xxx.xx.xx -j ACCEPT # Allowed Person 1
    iptables -A INPUT -s xx.xxx.xx.xx -j ACCEPT # Allowed Person 2
    ## Permanent allowed users (LAN)
    #
    iptables -A INPUT -s 127.0.0.1 -j ACCEPT
    iptables -A INPUT -s localhost -j ACCEPT
    iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
    ----------------------

    The script is actually quite long, so let me know if something doesn't make sense and I'll try to check and see if i left an important chunk of it out.

    The goal here is that I have the following setup

    Internet ->
    Modem/Router (only one physical port enabled)->
    Ubuntu x64 server with OpenVPN (eth0 in and eth1 out, configured to br0 bridge adapter in tap0) ->
    Switch ->
    Client machines

    The idea behind the IPTables config here is to disallow any inputs at all under any circumstances from the outside unless i explicitly allow their IP, no matter what circumstances/programs. If I allow their IP, they should be able to connect to my OpenVPN (port 5556) and SSH (port 5555).

    Once the connection is established, these outside systems will have access to port 80 traffic (ONLY the IPs that are reserved for the VPN, not the internal LAN clients). They need access to Windows network drives, but I don't have an explicit rule for that (it's just not blocked once the connection to the VPN is established). I have the rules written and working for that. The systems on the internal LAN, however, I really only need them to be able to use whatever port is used for windows networked drive access/activity (which I admittedly don't know).


    My main question though, is about the FORWARD rules I have above. Does forwarding in IPTables mean forwarding from CLIENT#1 the inside of the LAN through the linux box into the outside world, into the Linux box from the outside world on the way to CLIENT#1, or both? Ideally, what I'm trying to do with the above script, is to, again, not allow ANY traffic under any circumstance from the outside world (not even access to SSH/OpenVPN) unless I explicitly allow their IP.

    Someone suggested I try the following forwarding rule instead of the one I have at the very top:
    Code:
    iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
    iptables -A FORWARD -s 10.1.10.0/24 -j ACCEPT
    iptables -P FORWARD -j REJECT
    The only problem with this rule is that when I enable it, all the internal LAN client computers have access to the ports that I blocked (like port 80 for internet access). I'm not sure why, but I suspect that it has to do with the first line about an established connection being allowed (though admittedly it doesn't make any sense in light of the fact that my original rule is merely ACCEPT).

    Sorry if this seems a bit confusing, and I might already have it right, but something I read the other day kind of made me skittish about what could be a misconception about the IPTables forwarding principles.

    Thanks for looking!
    Last edited by jwright8; September 13th, 2012 at 03:13 PM.

  2. #2
    Join Date
    May 2012
    Beans
    72

    Re: IPTables configuration questions

    Quote Originally Posted by jwright8 View Post

    My main question though, is about the FORWARD rules I have above. Does forwarding in IPTables mean forwarding from CLIENT#1 the inside of the LAN through the linux box into the outside world, into the Linux box from the outside world on the way to CLIENT#1, or both? Ideally, what I'm trying to do with the above script, is to, again, not allow ANY traffic under any circumstance from the outside world (not even access to SSH/OpenVPN) unless I explicitly allow their IP.

    Does anyone have any idea if the forwarding above is applied in the correct way?

    I was pretty confident up until recently, and I was hoping someone might be able to tell me if I've been under a false assumption that I had things configured the way I envisioned them.

    Thanks in advance!

  3. #3
    Join Date
    May 2010
    Beans
    462
    Distro
    Ubuntu Development Release

    Re: IPTables configuration questions

    I think it is better for you to place your whole script here otherwise nobody can pinpoint to your right direction. If your script is more 50 lines, then i will suggest you to use a gui firewall software such as Firewall Builder to help you and it is so much easier that way.

  4. #4
    Join Date
    May 2012
    Beans
    72

    Re: IPTables configuration questions

    As I said in my previous posts, my question is conceptual with respect to how the FORWARD rule works in the context of the two snippets above (or even as a generalization, as the man pages, to me, don't answer the question completely). The snippets above should be more than sufficient to convey how I was using the FORWARD rule and why (hence my long-winded, thorough explanation about my implementation).


    If you had stopped to read what I was saying and thought about it, instead of trying to be condescending and spamming the LOL emoticons over and over to try to assert some (false) form of superiority, you might have actually been able to help with my question. If you don't understand what I'm asking, then you were more than welcome to ask me to clarify, and I'd have been happy to do so. Then again, I understand that certain people would rather use than actually help. That's their prerogative, but I was genuinely hoping someone that cared to assist others would see this and post to at least clarify or attempt to help. In short, I would greatly appreciate it if you whored your post count somewhere else and saved the replies for someone that can, and wants, to help.
    Last edited by jwright8; September 21st, 2012 at 06:16 PM.

  5. #5
    Join Date
    Sep 2007
    Location
    Oklahoma, USA
    Beans
    2,042
    Distro
    Xubuntu 12.04 Precise Pangolin

    Re: IPTables configuration questions

    Quote Originally Posted by jwright8 View Post
    The idea behind the IPTables config here is to disallow any inputs at all under any circumstances from the outside unless i explicitly allow their IP, no matter what circumstances/programs.
    If I take this literally, achieving that goal would make communication impossible, since "any circumstances" would include packets in reply to your outgoing connection requests. It would even include responses to your DNS requests!

    I think your intent, though, is probably to prevent NEW connection inputs, while accepting inputs that are part of an established or related connection. The usual way to do this is with the
    Code:
    iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
    rule that you already have in your script. However I would put it at the very top of the chain, so that such packets need not traverse all the other rules to reach it.

    To address your question about the FORWARD chain, just keep in mind that INPUT and OUTPUT apply only to packets to or from the specific machine that is running iptables. Any packets that come through this machine en route to or from other machines on your LAN will go through FORWARD instead. This implies that FORWARD is meaningful only if on a machine that is serving as a router or a firewall for the entire LAN. If your machine is not one of these, then the FORWARD chain should never be reached; "iptables -L" will show you the packet count for each rule and if it's "0:0" that confirms the rule is never used.

    If FORWARD is applicable to your system, then it should duplicate the rules that you establish for INPUT and also for OUTPUT, since any packet addressed to another machine will never reach the INPUT chain, nor will those coming from another place on your LAN get to OUTPUT. The simplest way to do this is to put the rules into new user-defined chains such as "MyIn" and "MyOut" and then put single rules into INPUT and OUTPUT, and two rules into FORWARD, to jump to the appropriate MyIn or MyOut chains for the actual tests. This, incidentally, is pretty much what UFW does behind the scenes to work its magic, although it adds several layers of additional complexity.

    EDIT--To answer your more specific later question, it applies to BOTH. I see that you really are using the server box as a firewall and router, so FORWARD will be quite essential to achieve your goals. You may also need to look at the prerouting and postrouting areas, although in my router/firewall system they are both pretty minimal and FORWARD does all the heavy work.
    Last edited by JKyleOKC; September 21st, 2012 at 06:24 PM. Reason: To be more specific.
    --
    Jim Kyle in Oklahoma, USA
    Linux Counter #259718
    Howto mark thread: https://wiki.ubuntu.com/UnansweredPo.../SolvedThreads

  6. #6
    Join Date
    May 2012
    Beans
    72

    Re: IPTables configuration questions

    Quote Originally Posted by JKyleOKC View Post
    The usual way to do this is with the
    Code:
    iptables -A INPUT -m state --state RELATED,ESTABLISHED -j  ACCEPT
    rule that you already have in your script. However I would put it at the very top of the chain, so that such packets need not traverse all the other rules to reach it..
    This makes a ton of sense, and I was actually wondering why I hadn't done that before. Thank you!


    Quote Originally Posted by JKyleOKC View Post
    To address your question about the FORWARD chain, just keep in mind that INPUT and OUTPUT apply only to packets to or from the specific machine that is running iptables. Any packets that come through this machine en route to or from other machines on your LAN will go through FORWARD instead. This implies that FORWARD is meaningful only if on a machine that is serving as a router or a firewall for the entire LAN. If your machine is not one of these, then the FORWARD chain should never be reached; "iptables -L" will show you the packet count for each rule and if it's "0:0" that confirms the rule is never used.

    If FORWARD is applicable to your system, then it should duplicate the rules that you establish for INPUT and also for OUTPUT, since any packet addressed to another machine will never reach the INPUT chain, nor will those coming from another place on your LAN get to OUTPUT. The simplest way to do this is to put the rules into new user-defined chains such as "MyIn" and "MyOut" and then put single rules into INPUT and OUTPUT, and two rules into FORWARD, to jump to the appropriate MyIn or MyOut chains for the actual tests. This, incidentally, is pretty much what UFW does behind the scenes to work its magic, although it adds several layers of additional complexity.
    Okay, so it seems as if in my application that FORWARD does matter, since the setup is currently:

    Internet -> Modem -> Ubuntu Server (the one in question) -> Switch/hub -> client computers

    So essentially all the traffic (in/out) goes through the eth1 and eth0 of the box in both directions.

    My current application in this instance that I'm testing out is an OpenVPN server on the Ubuntu box; there is nothing else on there except DenyHosts, SSH (other than the default stuff from a Ubuntu install, of course). I want to be able to connect remotely to the OpenVPN server and be able to mount a network drive of a client computer behind the OpenVPN server on the LAN and do stuff with it (run programs, copy files, etc.).

    I only want this ability for computers I specifically allow. To address part of this, I have certificates for each computer that validate when connecting to OpenVPN; however, I'd like the additional capacity for if they went to another network, they would be blocked as well (certificate or no certificate), from communicating with clients behind the OpenVPN server.

    Sorry if this rambles on a bit, but I'm still kind of struggling to grasp how I need to change my forwarding rules to achieve what I want. I assumed that the INPUT/OUTPUT also had a place in it; I'm glad I asked for clarification instead of operating under a false premise.

    Thanks for your help so far!


    EDIT:

    Upon further thought, I guess the reason it seems like it works now is because the OpenVPN clients are connecting TO the Linux box first; it is not trying to communicate directly to the client computers behind it (that comes later when I mount the network drives). How would I go about using forward in the same way?

    Could I use DROP for all forwarding, then allow exceptions for LAN IPs only? Since, when they connect to OpenVPN, the remote client computers are assigned a local IP.


    EDIT 2:

    Code:
    iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT 
    iptables -A FORWARD -s 10.1.10.0/24 -j ACCEPT 
    iptables -P FORWARD -j REJECT
    The iptables lines above actually seem like they seek to accomplish that. The only problem is that even with my DROP rules for the forward ports later, everything is still allowed (I don't want the client LAN computers to have access to port 80, 443, 25, 21, 22, etc. traffic, as in the rules from the initial post). If this solves the forwarding problem from the outside going inward, then that's great, but how do I stop what I want to stop from the inside IP's going out?
    Last edited by jwright8; September 21st, 2012 at 07:20 PM. Reason: Additional thoughts

  7. #7
    Join Date
    Sep 2007
    Location
    Oklahoma, USA
    Beans
    2,042
    Distro
    Xubuntu 12.04 Precise Pangolin

    Re: IPTables configuration questions

    Quote Originally Posted by jwright8 View Post
    Code:
    iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT 
    iptables -A FORWARD -s 10.1.10.0/24 -j ACCEPT 
    iptables -P FORWARD -j REJECT
    The iptables lines above actually seem like they seek to accomplish that. The only problem is that even with my DROP rules for the forward ports later, everything is still allowed (I don't want the client LAN computers to have access to port 80, 443, 25, 21, 22, etc. traffic, as in the rules from the initial post). If this solves the forwarding problem from the outside going inward, then that's great, but how do I stop what I want to stop from the inside IP's going out?
    That second rule accepts everything coming in from your LAN; I'm not clear yet as to what, specifically, you want the LAN users to be able to do. However to block them from port 80, for instance, you would need to add (after the first tule above) a rule such as
    Code:
    iptables -A FORWARD -s 10.1.10.0/24 --dport 80 -j REJECT
    This might be the "later DROP rules" but they would have to precede the ACCEPT rule to have any effect for the LAN users.

    It's usually much simpler to establish what you want to allow, create rules to ACCEPT those cases, and REJECT or DROP everything else. It's also helpful to create a "LOG_DROP" chain and jump to it, so that you know what got rejected. Here's an example, as part of a configuration file to be loaded via "iptables-restore":
    Code:
    # define optional chain to log dropped packets
    :LOG_DROP - [0:0]
    # define rules for optional LOG_DROP chain
    -A LOG_DROP -j LOG  --log-prefix "[IPTABLES DROP] : " 
    # next rule not needed; policy for INPUT will handle it
    -A LOG_DROP -j DROP
    This will put a line into /etc/syslog every time a packet gets dropped, telling you the source and destination IP and ports plus other information. Especially while getting the rules set up, this is nice to have, since it can alert you to other things you need to let through...

    I would do the filtering a bit differently, something like this (untested) addition to allow outbound traffic to port 443, only:
    Code:
    # define chain to filter LAN traffic
    :CHECK_LAN - [0:0]
    # define rules for LAN filtering chain
    -A CHECK_LAN --dport 443 -j ACCEPT
    # next rule drops everything else
    -A CHECK_LAN -j LOG_DROP
    
    # place as second and third rules in FORWARD chain and delete all after it in that chain
    -A FORWARD -s 10.1.10.0/24 -j CHECK_LAN
    -A FORWARD -j LOG_DROP
    This applies the filtering only to outbound traffic from the LAN, and rejects everything coming in from outside except what's allowed by the ESTABLISHED rule.

    Hope this helps!
    --
    Jim Kyle in Oklahoma, USA
    Linux Counter #259718
    Howto mark thread: https://wiki.ubuntu.com/UnansweredPo.../SolvedThreads

  8. #8
    Join Date
    May 2012
    Beans
    72

    Re: IPTables configuration questions

    Okay, that all makes sense. That is, in fact, what the DROP rules were supposed to be for. I guess I've just been getting things backwards in the order they need to go in (I just assumed the default policies would be first, but I know now it's the opposite).

    I had thought about disallowing everything and only allowing what I want to allow for forwarding, but I was presented with a problem. I'm not sure how Windows network drive activity works. Is it a set port, or does it change? The primary reason of the VPN is to allow me to run programs that typically only go across the LAN remotely (they don't communicate with the outside world at all, just computer to computer on the LAN).

    The goal is to allow users to communicate however they want as long as it is only LAN to LAN connections; I don't want anything going out other than the two very specific computers I allow to communicate on those two ports outgoing. I also don't want anyone communicating inward from outside other than the windows network drive traffic (running programs over the network) from those that will already have a local IP assigned, since the OpenVPN authentication would have already happened.

    Thank you for all of your help so far, I think I'm finally beginning to understand it.
    Last edited by jwright8; September 21st, 2012 at 08:28 PM.

  9. #9
    Join Date
    Sep 2007
    Location
    Oklahoma, USA
    Beans
    2,042
    Distro
    Xubuntu 12.04 Precise Pangolin

    Re: IPTables configuration questions

    We're getting there, I think. The Windows "file and printer sharing" services use ports 137, 138, 139, and 445 to establish their network connections. They use both tcp and udp, so I would put specific rules to allow those ports -- a total of 8 rules in all, although you could group the first three as 137:139 and reduce it to just four. I also oversimplified my examples earlier. The ACCEPT rules in CHECK_LAN should look like this, I believe:
    Code:
    -A CHECK_LAN -p tcp -m tcp --dport 137:139 -j ACCEPT
    -A CHECK_LAN -p udp -m udp --dport 137:139 -j ACCEPT
    -A CHECK_LAN -p tcp -m tcp --dport 445 -j ACCEPT
    -A CHECK_LAN -p udp -m udp --dport 445 -j ACCEPT
    This ought to allow full interior traffic on the LAN but not allow anything at all with the outside world.

    "Not allow anything" however probably means that the VPN server's traffic would also be rejected, if it passes through FORWARD. However since that server is on the single machine that runs iptables, traffic from the LAN destined for the VPN server should come through INPUT, and traffic from the VPN server to the outside world should go through OUTPUT, so this just may do what you are looking for...

    One trick that may help getting it working is to create some more LOG_DROP style chains, each with its own unique name and that name in the label that is passed to LOG. Then when you find items in the syslog file, you can tell which group of rules rejected them...

    EDIT--Just realized that it could be much simpler, even, by checking for both source and destimation IPs. If both are on the LAN, jump to ACCEPT, otherwise LOG_DROP or REJECT. Port numbers and tcp/udp considerations would not even need to be considered!
    Last edited by JKyleOKC; September 21st, 2012 at 09:00 PM. Reason: Additional idea.
    --
    Jim Kyle in Oklahoma, USA
    Linux Counter #259718
    Howto mark thread: https://wiki.ubuntu.com/UnansweredPo.../SolvedThreads

  10. #10
    Join Date
    May 2012
    Beans
    72

    Re: IPTables configuration questions

    Wonderful! That actually makes a lot of sense... thank you for all of your help, I was beginning to go crazy trying to wrap my head around it.

    How would you write the rule to just check and see if an IP was on the LAN, then? I kind of figured it would turn out simpler when you could safely assume that ALL IP's of relevance would actually already be a LAN IP (since OpenVPN would take care of that, and I do know how to limit the IP's on that side using input/output). The lines above do seem like they will do what I want (I'll have to test at a later date), but if I were to be able to allow LAN to LAN traffic independent of individual port considerations, it would be opportune to say the least.
    Last edited by jwright8; September 22nd, 2012 at 12:26 AM.

Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •