Solved deny ip from any to any

F

Fbsdnew

I copied the commands/ruleset from the ipfw handbook page and issued the command "ipfw list" and "65535 deny IP from any to any" was the running rule, which I did not include in the ipfw.rules script. I'm worried about locking myself out and am not willing to risk it. Was this supposed to happen when copying the ruleset? Did I make a mistake by copying all of it, maybe you're only supposed to copy certain sets of rules.
 
You didn't set firewall_script in rc.conf:

Code: 
        if [ -r "${firewall_script}" ]; then
                /bin/sh "${firewall_script}" "${_firewall_type}"
                echo 'Firewall rules loaded.'
        elif [ "`ipfw list 65535`" = "65535 deny ip from any to any" ]; then
                echo 'Warning: kernel has firewall functionality, but' \
                    ' firewall rules are not enabled.'
                echo '           All ip services are disabled.'
        fi


Fbsdnew said:
I'm worried about locking myself out
Click to expand...
That's always a risk, especially if you work remotely. Even seasoned firewall users make mistakes every now and then. Heck, I've locked myself out countless times due to stupid typos. Make sure you have console access (through a KVM or IPMI for example) in case you do lock yourself out.
 
Console access? I'm not sure what IPMI or KVM is. Couldn't I just mount the filesystem read and write from single user mode and change the configuration. There should be an error message too stating what needs to be fixed right?
 
Fbsdnew said:
Couldn't I just mount the filesystem read and write from single user mode and change the configuration.
Click to expand...
You need console access for that. By console access I mean the keyboard and display directly attached to the computer. A KVM or IPMI is a way to get that console access over the network. You don't need to boot to single user mode for a firewall, it only blocks network access, not local access.
 
SirDice said:
You didn't set firewall_script in rc.conf:

Code: 
        if [ -r "${firewall_script}" ]; then
                /bin/sh "${firewall_script}" "${_firewall_type}"
                echo 'Firewall rules loaded.'
        elif [ "`ipfw list 65535`" = "65535 deny ip from any to any" ]; then
                echo 'Warning: kernel has firewall functionality, but' \
                    ' firewall rules are not enabled.'
                echo '           All ip services are disabled.'
        fi



That's always a risk, especially if you work remotely. Even seasoned firewall users make mistakes every now and then. Heck, I've locked myself out countless times due to stupid typos. Make sure you have console access (through a KVM or IPMI for example) in case you do lock yourself out.
Click to expand...
I have firewall_script="/etc/ipfw.rules" written exactly in rc.conf. "ipfw list" still reads the same "deny ip from any to any" when it's started and stopped. I've made the file executable and cant ping an address or update pkg when ipfw is running.
 
Fbsdnew said:
I've made the file executable
Click to expand...
Doesn't need to be but doesn't hurt either.

Fbsdnew said:
and cant ping an address or update pkg when ipfw is running.
Click to expand...
Yes, because only that block rules appears to be applied. That rule blocks everything.

If you want to create custom rules put those in /etc/ipfw.rules. Not exactly sure what you copied (don't copy /etc/rc.firewall) but in order to use that you need to set this:
Code: 
firewall_enable="YES"
firewall_type="/etc/ipfw.rules"

Don't set firewall_script. You can set this if you want to use an alternate /etc/rc.firewall script. You don't need to do this if all you want is a custom ruleset (the current /etc/rc.firewall script can already take care of this).
 
Isn't type supposed to be open? Should I change this to /etc/ipfw.rules?

I copied the rule sets in the syntax section of the ipfw article in the handbook I think I need them all. The rc.conf looks like this...(all sysrc commands that were listed)

firewall_enable="YES"
firewall_type="open"
firewall_logging="YES"
firewall_script""/etc/ipfw.rules

The ipfw.rules is the copied rulesets exactly. Maybe I should post how the config file looks inside. I did type it no copy paste. Here's the link to the article.

www.freebsd.org

Chapter 33. Firewalls

FreeBSD has three firewalls built into the base system: PF, IPFW, and IPFILTER. This chapter covers how to define packet filtering rules, the differences between the firewalls built into FreeBSD and how to use them
www.freebsd.org www.freebsd.org
 
SirDice said:
...
That's always a risk, especially if you work remotely. Even seasoned firewall users make mistakes every now and then. Heck, I've locked myself out countless times due to stupid typos. Make sure you have console access (through a KVM or IPMI for example) in case you do lock yourself out.
Click to expand...
There exist a script which helps to prevent locking us out ourselfs:
/usr/src/share/examples/ipfw/change_rules.sh

This worked so very well for me, that I just hard coded the name of my firewall ruleset script and I copied it to /root/bin/edfw. Thus a single call to it opens the ipfw script in my favorite editor and when closed, change_rules takes care of applying the ruleset, and when there is no confirmation afterwards, it reverts to the previous working one.

I guess this one is as useful as unknown.
 
That's very convenient. What rules should I be looking to remove if I want to get rid of the deny any to any ip? And gain access to the network with a firewall running? They all look good to me. Also when ipfw is started all rules are not found. Why?
 
SirDice said:
Doesn't need to be but doesn't hurt either.


Yes, because only that block rules appears to be applied. That rule blocks everything.

If you want to create custom rules put those in /etc/ipfw.rules. Not exactly sure what you copied (don't copy /etc/rc.firewall) but in order to use that you need to set this:
Code: 
firewall_enable="YES"
firewall_type="/etc/ipfw.rules"

Don't set firewall_script. You can set this if you want to use an alternate /etc/rc.firewall script. You don't need to do this if all you want is a custom ruleset (the current /etc/rc.firewall script can already take care of this).
Click to expand...
So I changed the type to the filename after looking closer at the docs, every rule is working now when I restart ipfw. The problem now is bad "ipfw" command on line 2. So that's the only thing keeping me from resolving. When I change line 2 it just changes to bad command in line 3. These commands are here...
Code: 
#!/bin/sh
2.ipfw -q -f flush
3.$cmd="ipfw -q add"
4.pif="em0"
5 and on are all rules I see to be working.
 
obsigna said:
I guess this one is as useful as unknown.
Click to expand...
Yes, I certainly wasn't aware. But I don't use IPFW so never looked for it either, for PF I typically use something like pfctl -f /etc/pf.newrules.conf && sleep 30 && pfctl -f /etc/pf.conf. This loads the new rules, sleeps for 30 seconds then loads the old rules again. Those 30 seconds are enough to test if I locked myself out or not. If I do get locked out I just have to wait 30 seconds and the old rules are loaded, giving me access again. You have to lock yourself out at least once before you start using these kinds of solutions :D
 
Debian's iptables has a great script 'iptables-apply', if you don't press 'y' then it'll rollback after 10s. It may provide some hints / inspiration.
 
Fbsdnew said:
What do I put in place of the x.x.x.x in the rules?
Click to expand...
That would be the destination IP address in this case. Going by the example you've given it's a rule to allow outgoing DNS queries. With a regular ISP or hosting that would be the ISP or hosting provider's DNS server IPs (because the DNS queries are sent to those addresses). That does assume you're not using some other way to resolve DNS (like unbound or BIND).
 
Yes, and it's going to depend how you configured unbound. You can have it forward (and cache) requests to your ISP's DNS servers or allow it to query the root DNS servers and the various DNS servers that host the TLDs. So you will need to allow the right outgoing addresses or else this will stop working. When you want to configure a firewall you really need to know what kind of access should be allowed and what doesn't. But this does mean you need to understand how the different parts of a "connection" actually work. DNS is a small but important part of this process. Without DNS you won't be able to resolve hostnames to IP addresses.
 
Fbsdnew said:
What if I'm using unbound? Then do I use a different ip than the DNS servers in resolve.conf?
Click to expand...
You can allow port 53 to anywhere, both udp and tcp. If you then choose explicit DNS servers you can futher restrict to those IP addresses with those ports.

That will get you started and you can add complexity later, by which time you'll understand things better.
 
SirDice said:
Yes, I certainly wasn't aware. But I don't use IPFW so never looked for it either, for PF I typically use something like pfctl -f /etc/pf.newrules.conf && sleep 30 && pfctl -f /etc/pf.conf. This loads the new rules, sleeps for 30 seconds then loads the old rules again. Those 30 seconds are enough to test if I locked myself out or not. If I do get locked out I just have to wait 30 seconds and the old rules are loaded, giving me access again. You have to lock yourself out at least once before you start using these kinds of solutions :D
Click to expand...


When testing PF rules that save my life million of times[
 
SirDice said:
Yes, and it's going to depend how you configured unbound. You can have it forward (and cache) requests to your ISP's DNS servers or allow it to query the root DNS servers and the various DNS servers that host the TLDs. So you will need to allow the right outgoing addresses or else this will stop working. When you want to configure a firewall you really need to know what kind of access should be allowed and what doesn't. But this does mean you need to understand how the different parts of a "connection" actually work. DNS is a small but important part of this process. Without DNS you won't be able to resolve hostnames to IP addresses.
Click to expand...
I'm learning about what makes a part of a connection as I run into these problems. It's working out well. I set up unbound during installation but don't know how to use this DHCP to get ip addresses as you have stated above. I will check the handbook though. I really want to study a small office firewall setup and chose ipfw because it's for FreeBSD and more complicated than PF. What are TLD's?
 
tux2bsd said:
You can allow port 53 to anywhere, both udp and tcp. If you then choose explicit DNS servers you can futher restrict to those IP addresses with those ports.

That will get you started and you can add complexity later, by which time you'll understand things better.
Click to expand...
Yeah I'm still trying to analyze all of this and get the picture of the connection. What exactly is the function of the port though. When that rule is included is the packet traffic which is udp or tcp only being routed out through one port? And all other ports are blocked? I don't get it?
 
Fbsdnew said:
When that rule is included is the packet traffic which is udp or tcp only being routed out through one port?
Click to expand...
Nothing is being routed, routing is something else entirely. A firewall doesn't route, remember that. A firewall can translate packets, source NAT, destination NAT (redirection) or allow/block packets, nothing more.

Block or pass rules allow or prevent a packet to pass in or out of an interface. All IP packets have a source address and port, and a destination address and port. The rules simply restrict the matching. "If packet with source address A; port X and destination address B; port Y comes by you need to do some action". The keyword any can be thought of as a wildcard, it matches any and all IP addresses.
 
Fbsdnew said:
When that rule is included is the packet traffic which is udp or tcp only being routed out through one port
Click to expand...
udp and tcp are different protocols, they can be firewalled independantly but a lot of firewalls can do rules spanning tcp and udp

DNS goes to port 53, it happens that DNS uses both udp and tcp (udp in the main)

For your purposes just blanket allow port 53 out.
picture of the connection. What exactly is the function of the port though
Click to expand...
Watching some youtube tutorials on the fundamentals of basic networking and firewalling would be a good idea.

This looks OK re firewalling:
View: https://www.youtube.com/watch?v=kDEX1HXybrU
 
You must log in or register to reply here.
Back
Top