iptables doesn't work
 

hello,
it seems that i'm missing smth simple here.
The objective is to let the traffic from and to router and local machine ( static ip ).
The log seems not to work and all connections are blocked.

Any tips will be appreciated:

Your OUTPUT rule for ESTABLISHED and RELATED packets wouldn't apply to packets coming from $win_host or $router, since those aren't on the 192.168.0.0/24 subnet ($local_net). You probably just need to change 192.168.0.0/24 to 192.168.1.0/24 at the top, where you set the variable. That is, assuming 192.168.1.0/24 is the correct subnet.

right, i missed that one.
Thank you!

but seems that there is smth else :
hmmm.

You need to get rid of the DROP rules before your LOG rules in order to see what is happening. That said, there are some discrepancies between your config and your script. For starters, your policies are set to ACCEPT in your active config, while in the script they are supposed to get set to DROP. You also didn't correct the subnet in your OUTPUT chain, so the packets run smack into the DROP rule.

There we go - one of the reasons why i have a rule not to work after 9pm - spend too much time on simple mistakes.

Thank you.
The discrepancies were because of the silly error in the script, causing the rules not to apply to the firewall.
here is the new script and new status output:
still no loging. I'm curios is the "0.0.0.0/0" different from "192.xxx/24" causing the log to ignore the action ?

I had read your ending DROP rules as policy settings for some reason. My bad. I have the flu. I'm not sure why it's not working. I can't see any reason why it wouldn't. Are you sure you are looking at the right log file? Are you sure 192.168.1.204 is the LAN IP of the box these rules are running on? The 0.0.0.0/0 should catch anything.

This should work:

Get better - i had a cold a week ago , really nasty one.
i did checked that IP is the right one, same with the network mask and the other ( win_host) IP.

what if i have a traffic from router and 204 machine goes to the router to the external machine to get the info


Here is the new rules and status from the "Status" command. I'm a bit confused with that allow on 0.0 ( see highlighted in bold):

and the script is :
Please note multiple lines for port 80 and 443 ...i'm not sure if i need them. Confused with dport an sport.

I really appreciate your help.
A few questions :

What's with this right below:

what is with the port 138? - 138 and notice it's "moving " to 137 ?
http://www.auditmypc.com/port/udp-port-138.asp
What is this PROTO=2 and 224 address ?
Also i'm not sure how to add YUM support. i found heremthat it should work on 80 and 443, but doesn't seem so:
Thank you.

Thanks.

Cool.

My guess is its the loopback interface rule. You can check by doing a:This just says that box 192.168.1.205 sent you an echo request (ping).

This is just NetBIOS packets generated by the Windows box.

This is your router doing a multicast. IIRC the "2" is IGMP (I am not sure about this). Perhaps it's misconfigured? In any case, if you don't care about multicast then you don't have anything to worry about. You could add a DROP rule for this if you don't want to have your log file cluttered, though.


Hmmm. Not sure I understand. This might be the perfect time to ask you if you could provide a brief description of just what exactly this box is and what you need it to do. So far I just know it's a server on a LAN. Is it only supposed to be available to LAN clients? Is it allowed to start connections to the LAN? To the WAN? What services are running on it? I've noticed that you seem to "pair up" your INPUT and OUTPUT rules for some reason. This isn't necessary with iptables, and it makes the rules harder to read. You don't need to make an OUTPUT rule for every INPUT rule, or vice versa.

that's simple : one server that has httpd server and should be available to internal and external connections. I prefer to have ssh available only from within internal net. That's it. Nothing really fancy or complicated as you can see.
the reason of that question was - the app on the web server is not coded properly - so when i access it from withing the local net it has references to the "external" name.

The "pairing": i just thought to group them ( rules ) by the protocol/port, which is not the best idea, but it helps me to understand how each protocol works. i never got through this task in such a detailed way, just used shorewall to do the background work.

Great.

I see. Well, this is dependant on the router, not the server.

I understand. But my concern isn't for the grouping itself - it's for the fact that you are creating unnecessary rules in the first place. For example:In this case, both of those OUTPUT should be unnecessary, because you sould already have a separate rule to deal with packets in states RELATED or ESTABLISHED. You could use a rule allowing them for this service only (some people do this), but that still leaves us with bogus state NEW matches in the OUTPUT. That NEW is basically punching a hole in the firewall, allowing the SSH daemon to start connections with the LAN - something which doesn't fit the description you've given above (HTTP/S service for everyone, SSH service only for LAN).

Here's a script I've written for you from scratch based on the description you've given above - notice how no --sport rules were necessary, and only one rule for RELATED and ESTABLISHED packets was used per-chain. Also note that the OUTPUT chain contains no matches for packets in state NEW, as your description did not include the server needing to initiate any connections on its own.

not trying to be a hard here, but I was thinking about exactly that - allow outbound by SSH, but only for local net... Or i wrote it incorrectly ?
Appreciate you writing a script. And a few questions:
all discussed rules explicitly covered www/s and ssh, but i have to allow the dns, ntp and yum to be able to communicate too. I know i didn't mentioned that explicitly - that is the reason to add "NEW" state in the ourbound connections.
thus combining 2 scripts:
allowing to establish only new connections on only selected ports...

Does this make sense ?
Thank you

Don't worry, I figured you left-out stuff like this in your description. :)

So basically you'd need to add rules for outgoing SSH connections to your LAN, outgoing HTTP/FTP connections to your WAN, and NTP connections to your WAN. Right? Well, here's an example of how that would look when added to the script:There's four rules added - they appear in bold. The first one allows user "dbabo" on the server to start SSH connections to the LAN. If you want him to be able to start SSH connections to the WAN too then remove the "-d 192.168.1.0/24" match. The second, third, and fourth rules allow user "root" (I'm assuming Yum runs as root) to access HTTP, FTP, and DNS servers (respectively) on the WAN and LAN.

What about NTP? Well, that depends on how you've got NTP set up. Is this box the NTP server for clients on the LAN? Or does it just synchronize for itself and nobody else? What user does your NTP daemon run as? Does it synchronize to a server on the WAN or LAN?

just a simple synchronization with whatever i'm getting from pool.ntp.whatever.the.address.is.org

and : the output on 80/22:
it will/might have more then just one user-id: i can try to wget or/and ssh to as regular user, might do yum as root and run apache as "apache" user... not sure how that would work..

Okay, well, then a rule something like this would be in order:This assumes your NTP daemon runs as user "ntp". Also, notice that the rule does NOT allow it to connect to the LAN. Oh, and I think you'd need a rule allowing incoming connections to your NTP daemon also, right? Then:I do think the incoming connection in these situations should always come from port 123. If that's the case, then you should definitely make the rule more specific, like:
No problem at all, just copy/paste the relevant rules and edit the username. Remember, you'll only need to use OUTPUT rules for this - no edits or additions need to be made to the INPUT chain for this.

I don't think there's much of a choice there.

Yeah, Apache should definitely be running as "apache". But there is no need for any OUTPUT rules for it unless you need it to start outgoing connections. Do you? Because if you don't, I'd suggest leaving the rules as they are. That way if your Apache install gets exploited, the attacker won't be able to use it to attack your LAN/WAN (unless he rooted the box).


EDIT: On second thought, having specific rules for root might now be the best approach. I mean, if an attacker gets root you're pretty much screwed anyway (barring mandatory access controls). So I'd probably just replace these rules:With this one rule:Now root can connect to anything he/she pleases, and you don't need to worry about adding any more rules for root.

For clarity's sake, here's an example script with all this incorporated:Note that in this example I added a rule allowing your server to be pinged by hosts on the LAN, as that is usually a good idea. I also gave user "dbabo" full access (WAN/LAN) to ports 21 (FTP), 22 (SSH), and 80 (HTTP), while user "foobar" only has access to SSH services on the LAN.

I do realize that these type of rules can be kinda tedious to implement when you aren't used to them. So here's a somewhat simpler example. In theory, this script should "just work" for you. Although this example is a lot less tighter than the one above, it still tries to minimize the impact which a user-level server compromise (Apache, for example) would have on the LAN.Keep in mind that starting SSH connections from a public server such as this is probably not a good idea. If the server has been compromised before you SSH into it, then whatever SSH connections you start from it could be easily compromised as well.