Re: Babysitting on iptables requested :-)
From: Peet Grobler (peetgr)
Date: 04/25/03
- Next message: leslie: "Re: Linksys BEFSX41 firewall/router & Linux?"
- Previous message: MyndPhlyp: "Re: Linksys BEFSX41 firewall/router & Linux?"
- In reply to: Juha Laiho: "Re: Babysitting on iptables requested :-)"
- Next in thread: Carlos Moreno: "Re: Babysitting on iptables requested :-)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: peetgr at absa dot co dot za (Peet Grobler) Date: Fri, 25 Apr 2003 06:01:22 GMT
On Thu, 24 Apr 2003 17:17:01 GMT, Juha Laiho <Juha.Laiho@iki.fi>
wrote:
>peetgr@absa.co.za (Peet Grobler) said:
>>On Wed, 23 Apr 2003 17:30:01 -0400, Carlos Moreno
>><moreno_at_mochima_dot_com@xx.xxx> wrote:
>>>Shields Up reports my machine 100% stealth, and I do have the
>>>usual functionality (i.e., I can do whatever I want from my LAN).
>
>Actually Shields Up isn't testing that thoroughly..
>
>>>So, that seems like good news, but I was wondering if I might
>>>be doing something the wrong way, or if there may be holes that
>>>Shields Up is not seeing/reporting. Any comments on the following
>>>script will be appreciated:
>
>>>iptables -P INPUT DROP
>>>iptables -P OUTPUT ACCEPT
>>>
>>> # A policy of ACCEPT worries me... But I guess it can't be that
>>> # harmful if it is in the OUTPUT chain?
>>
>>Not harmful at all. Unless you want to restrict output from your
>>machine to the internet?
>
>There might be set-ups where you want to restrict even the outgoing
>traffic. But it requires some monitoring to find out what all
>outbound traffic is needed (I'm maintaining some systems where I
>want to be absolutely certain about what kind of traffic can go
>out of the host, so the first level is restricting the outgoing
>traffic on the host itself, and the next level is the firewall
>external to the machine).
Yes, I was assuming he doesn't want to do that. I'm at the moment
behind a firewall that blocks almost everything
>
>>>iptables -P FORWARD DROP
>>>
>>>iptables -A INPUT -i eth1 -j ACCEPT
>>>iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>>>
>>> # Now that I think about it, I guess I should also add a rule
>>> # to accept anything that comes through the lo interface??
>>> # i.e., iptables -A INPUT -i lo -j ACCEPT ??
>>
>>Yes, you should. Unless you want to drop all localhost traffic. Add a
>>similar OUTPUT rule as well.
>
>I think the '-o lo' is redundant; if it is going to 'lo', it had to
>come from 'lo'. But the '-i lo -j ACCEPT' is needed. I also seem to
>have "-m state --state INVALID -j DROP" always just before the
>"-m state --state ESTABLISHED,RELATED -j ACCEPT".
Now that sounds like a good idea! I have to remember that.
>
>>>iptables -A INPUT -p tcp --dport 22 -j ACCEPT
>>>iptables -A INPUT -p tcp --dport 10112:10115 -j ACCEPT
>>>
>>> # Ports 10112 to 10115 are used by a custom application that I
>>> # developed, and I often use my home machine for debugging tests.
>>
>>You should specify it like this:
>>iptables -A INPUT -p tcp -i eth0 --dport 22 -j ACCEPT
>>iptables -A INPUT -p tcp -i eth0 --dport 10112:10115 -j ACCEPT
>>
>>e.g. add the source interface aswell. Makes it simpler to manage.
>
>If I read his set-up correctly, the interface is redundant here;
>everything else but eth0 is already handled. However, what is missing
>is that here you should only accept SYN packets, i.e. "--syn" should
>be added to flags. This is to prevent some forms of not-so-visible
>scanning.
Yeah, the interface is redundant, but I find it easier to manage when
I explicitly list the interfaces.
>
>>>iptables -A FORWARD -i eth1 -j ACCEPT
>
>This depends on what kind of machines you have in your local LAN, but
>if there's anything from Microsoft, you might like to block anything
>that is destined to port range 137-139, tcp as well as udp, incoming
>as well as outgoing. These ports are used for authentication services
>between Windows machines, so without this a Windows machine in your
>internal network might leak sensitive data to outside your network.
>However, this also prevents the Windows file/printer sharing protocols
>across your firewall machine, so if this is something you're depending
>on, you'll have to reconsider.
Interesting.
>
>>>iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
>>>iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
>>>
>>>iptables -t nat -A PREROUTING -p tcp --dport 1234 -j REDIRECT --to-ports 80
>>>
>>> # My ISP blocks incoming packets to port 80, so I want to be able to
>>> # use my own machine as a web server
>>>
>>>iptables -A INPUT -p tcp --dport 80 -j ACCEPT
>>
>>Add the -i eth0 as well.
>>
>>>
>>> # This one seemed necessary, or apache would not respond (is there
>>> # a way to set it up such that it would accept it, but only if it
>>> # came through port 1234, and not if it came directly to port 80?)
>>
>>Dunno. Probably.
>
>Haven't tried this, but would it work to drop or reject packets destined
>to port 80 in nat PREROUTING table before you do the redirect?
>
>>>Thanks for any comments!! I know there are aesthetic flaws,
>>>but I'm mainly worried about possible red flags that I might be
>>>overlooking due to my lack of knowledge on this.
>
>No major problems; my suggestions can be considered to be fine-tuning.
>
>>I would, however, add rules at the bottom to '-j LOG' everything else.
>>Just so you know you're dropping traffic.
>
>Agreed, but this needs to be divided in two: things that you just drop,
>and things that you log before dropping. If you log everything, you'll
>drown in log files.
I noticed :( I only recently started playing with firewalling. I've
basically setup a firewall on my modem dial-up to the internet. I just
LOG everything. I remember putting in rules to DROP some traffic
before logging, though...
>
>Here's a rule sturcture I've developed along the time; this is in
>"iptables-save" -syntax, but should be readable without too much
>problems.
Thanks. Another day another lesson :)
>
>I'll skip mangle and nat tables; nothing special in them.
>
>In filter table, the INPUT ruleset (policy DROP);
>the "common" table I discuss later.
>
>###
>#
># Incoming:
>#
># Sanity check; allow return packets
>-A INPUT -j common
># Allow ICMP echo (ping) requests
>-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
>#
># Specify here the accepted incoming sessions; example: allow ssh in
># -A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
>#
># Specify here the incoming requests you want to actively reject
># and not log (f.ex. ident queries from upstream SMTP servers)
># -A INPUT -p tcp -m tcp --dport 113 --tcp-flags SYN,RST,ACK SYN -j REJECT --reject-with icmp-port-unreachable
># Log&drop all the rest
>-A INPUT -j LOG --log-prefix "Forbidden incoming session: "
>#
># Specify here the incoming requests you want to actively reject
># after they've been logged
>#
>###
>
>
>In filter table, the OUTPUT ruleset (policy DROP);
>
>###
>#
># Outgoing:
>#
># Sanity check; allow return packets
>-A OUTPUT -j common
># Accept ICMP echo (ping) requests
>-A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
>#
># Specify here the accepted outgoing sessions; example: allow pop3 out
># -A OUTPUT -d my-pop-serv-ip -p tcp -m tcp --dport 110 -j ACCEPT
># Allow DNS out; fill in the provider DNS serv ip
>-A OUTPUT -d my-dns-serv-ip -p tcp -m tcp --dport 53 -j ACCEPT
>-A OUTPUT -d my-dns-serv-ip -p udp -m udp --dport 53 -j ACCEPT
>#
># Log all the rest
>#
>-A OUTPUT -j LOG --log-prefix "Forbidden outbound session: "
>#
># Actively reject all the rest
># (no "DROP" here; it'd just cause a delay; REJECT terminates the
># session immediately)
>#
>-A OUTPUT -p tcp -j REJECT --reject-with icmp-port-unreachable
>-A OUTPUT -p udp -j REJECT --reject-with icmp-port-unreachable
>#
>###
>
>
>
>The "common" chain then (can't have a policy, as it is a user-defined chain;
>this returns control back to the calling chain if none of the rules matched):
>
>###
>#
># Common: rules common for both incoming and outgoing sessions;
># - acceptance of return packets for allowed sessions
># - dropping of packets in nonsense session states
># - acceptance of all localhost traffic
>-A common -m state --state RELATED,ESTABLISHED -j ACCEPT
>-A common -p tcp -m state --state NEW -m tcp ! --tcp-flags SYN,RST,ACK SYN -j LOG --log-prefix "New not SYN: "
>-A common -p tcp -m state --state NEW -m tcp ! --tcp-flags SYN,RST,ACK SYN -j DROP
>-A common -m state --state INVALID -j LOG --log-prefix "Invalid state: "
>-A common -m state --state INVALID -j DROP
>-A common -i lo -j ACCEPT
># If needed, this would be good place to accept also interface traffic
># to/from local network adapters.
>-A common -j RETURN
>#
>###
>
>
>Here I've allowed ICMP ECHO (ping) packets in both directions; it might
>be good idea to rate-limit these (at least incoming). Other needed ICMP
>protocols are already accepted with the 'RELATED,ESTABLISHED' rule. Ping
>is good to have allowed for connectivity troubleshooting purposes - it
>confuses the hell out of people if they can't ping but still can connect.
>
>On some hosts I've done things like splitting the INPUT chain to several
>sub-chains, most often by protocol (tcp, udp, icmp), but anyway the
>basic order is that first accept what you want to accept; then reject or
>drop unwanted traffic that you know you don't want to see in your logs;
>then log what is left and leave the packets to the "DROP" policy - or
>reject them - whatever you wish.
>
>The sub-chains for processing packets per protocol could improve
>efficiency (you're not going through piles of TCP rules when handling
>an UDP packet; instead you check once in INPUT against the protocol,
>and just don't branch to the chain containing all the TCP rules). For
>me the main reason has been safety: when I set up such a system, 'ssh'
>is allowed (from some known addresses) somewhere before the actual
>per-protocol sub-chains. All further changes I do happen within these
>sub-chains, but regardless of how badly I mangle them, I always keep my
>ssh connection.
>
>As for improving efficiency, this design doesn't leave much room for
>optimization; for each connection only one packet (the one initiating
>the connection) goes somewhere beyond the rules in the 'common' chain;
>so most packets that you want to allow are allowed at second rule line
>(the first being the branch to the "common" chain).
Mmmh. Interesting reading.
>--
>Wolf a.k.a. Juha Laiho Espoo, Finland
>(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
> PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
>"...cancel my subscription to the resurrection!" (Jim Morrison)
- Next message: leslie: "Re: Linksys BEFSX41 firewall/router & Linux?"
- Previous message: MyndPhlyp: "Re: Linksys BEFSX41 firewall/router & Linux?"
- In reply to: Juha Laiho: "Re: Babysitting on iptables requested :-)"
- Next in thread: Carlos Moreno: "Re: Babysitting on iptables requested :-)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
