IPFW How to temporarily disconnect all incoming IPs except mine?

I'm looking for a command I can use via ssh to temporarily disconnect or block all IP connections except for mine. Something similar to blackholing, but for all connections rather than individual IPs.
I found this command, which does disconnect all incoming IPs, but it also disconnects my ssh connection:
echo "block in all" | pfctl -f -

I tried adding a pass in for my IP, but it returns a stdin:1: syntax error:
echo "block in all" "pass in from <my IP> to any" | pfctl -f -

Is there a way to modify this to maintain my ssh connection whilst temporarily disconnecting all other IPs?
Thanks in advance.
 
A friend suggested changing the | to a / and that would do the trick.
echo "block in all" / pfctl -f -

When I try it, I don't get disconnected, but I'm not sure it's disconnecting all other IPs??
 
A friend suggested changing the | to a / and that would do the trick.
No, replacing a pipe with a slash has an entirely different meaning, and i don't know why anyone who knows what they're doing would suggest that:
Code:
$ echo "block in all" / pfctl -f -
block in all / pfctl -f -

Try this:
Code:
(echo "block in all"; echo "pass in from <my IP> to any") | pfctl -f -

However, that replaces the entire ruleset, and also doesn't kill any of the open states.
 
What shell are you using? Try this, and make sure it prints two lines:
Code:
 echo -e "block in all\npass in from <my IP> to any"

If it does you can then pipe it to pfctl -f -. You definitely want a pipe "|" and not a slash.
 
What shell are you using? Try this, and make sure it prints two lines:
Code:
 echo -e "block in all\npass in from <my IP> to any"

If it does you can then pipe it to pfctl -f -. You definitely want a pipe "|" and not a slash.
shell: csh
The command returns one line:
-e block in all\npass in from <my IP> to any

Also, I was mistaken about which firewall they're running. It's actually ipfw, not pf (pfctl -s info returns pfctl: command not found).
 
Regardless of "which firewall" and "which shell" you must be aware of "state".

If a state is already established, a "block all rule" will not affect established flows, just new flows.
There are commands to "drop existing connections and block new connections" you also need to be aware of "in vs out"
 
Regardless of "which firewall" and "which shell" you must be aware of "state".

If a state is already established, a "block all rule" will not affect established flows, just new flows.
There are commands to "drop existing connections and block new connections" you also need to be aware of "in vs out"
I'm only interested in disconnecting or blocking existing incoming, not out or new. Is there a way to do that?
 
What shell are you using? Try this, and make sure it prints two lines:
Code:
 echo -e "block in all\npass in from <my IP> to any"

If it does you can then pipe it to pfctl -f -. You definitely want a pipe "|" and not a slash.
Jose, I took some of your recommendations and modified the original command, which is definitely working to disconnect incoming connections:
echo "block in all" | ipf -f -

But if I try this (exempting my IP from being disconnected):
echo "block in all\npass in from <my IP> to any" | ipf -f -

I get this error:
ipf: -: parse error (-1), quitting
 
Also you have named three different firewall systems in this post. Are they using ipfw, ipf, of pf?

Finally, you are not running the commands that either Jose or I have suggested: Jose suggests passing the -e option to echo, whereas I suggest using a subshell. you are running echo without options, which will not interpret the \n escape to create new lines.
 
To disconnect existing incoming connections, you'll want to clear the state tables — that causes the open connections to drop.
Yes, I thought it was something like that (ipf -FS?), but how do I do that without disconnecting my ssh connection?
 
Unfortunately it seems that you can't be that selective with IPF, you can only clear the entire state table.

If we had to do this for some reason we would use PF, not IPF, because pf offers pfctl -k, and with careful application of the label keyword to classify connections, you can accomplish your goal.

Is this a FreeBSD machine? FreeBSD should have PF...
 
Also you have named three different firewall systems in this post. Are they using ipfw, ipf, of pf?

Finally, you are not running the commands that either Jose or I have suggested: Jose suggests passing the -e option to echo, whereas I suggest using a subshell. you are running echo without options, which will not interpret the \n escape to create new lines.
Hi atax1a and thanks again for your input!

Sorry for the confusion, I'm a bit out of practice on freebsd.
Anyway, they're definitely running IPFW (ipfw list outputs the current rules and /etc/rc.conf contains "firewall_enable="YES").

This seems to work:
echo "block in all" | ipf -f -

...but adding the "-e" returns: ipf: -: parse error (-1), quitting

Hopefully, that's (a bit) less confusing.
 
If we had to do this for some reason we would use PF, not IPF, because pf offers pfctl -k, and with careful application of the label keyword to classify connections, you can accomplish your goal.

Is this a FreeBSD machine? FreeBSD should have PF...
It's freebsd.
I apologize if this is a silly question, but can I just comment out the "firewall_enable="YES" in /etc/rc.conf and add "pf_enable="YES"....then reboot so I can implement the pf commands?

Actually, nix that last question. Their /etc/ipf.rules contains a number of custom commands that (among other things) blocks all ssh logins (now, I'm just trying to disconnect IP connections that're overloading their web server) with the exception of one IP (which is what they use use to login). And since I don't feel confident to modify the pf.conf similarly, I should probably leave the firewall at ipfw. I'd rather not confuse things further.
 
ok, so, what you're doing is enabling both IPFW and IPF. Don't do that, running two firewalls at once is not a normal configuration. Reboot that machine to get it back into its normal state.

i don't know how to manipulate the IPFW state table in the way you want. Our recommendation remains to switch to pf. It's not as simple as switching the rc.conf around, because you have to rewrite the rules from ipfw language to pf, which requires knowing what you're doing. But we know you're just going to ask chatgpt, so good luck.
 
ok, so, what you're doing is enabling both IPFW and IPF. Don't do that, running two firewalls at once is not a normal configuration. Reboot that machine to get it back into its normal state.

i don't know how to manipulate the IPFW state table in the way you want. Our recommendation remains to switch to pf. It's not as simple as switching the rc.conf around, because you have to rewrite the rules from ipfw language to pf, which requires knowing what you're doing. But we know you're just going to ask chatgpt, so good luck.
For the record, I don't use chat ais. But, otherwise, I've left ipfw running.
 
What shell are you using? Try this, and make sure it prints two lines:
Code:
 echo -e "block in all\npass in from <my IP> to any"

If it does you can then pipe it to pfctl -f -. You definitely want a pipe "|" and not a slash.

Jose, after rebooting (still running ipfw), if I run this:
echo -e "block in all";echo "pass in from <my IP> to any" | ipf -f -

It prints two lines:
-e block in all
pass in from <my IP> to any


....and my ssh remains connected.
 
i think at this point you would be better off restarting the program to which people are connecting, instead of mucking with the firewall rules.
 
i think at this point you would be better off restarting the program to which people are connecting, instead of mucking with the firewall rules.
Interestingly, the last command I tried may've done the trick.

The normal load on this server rarely rises above 0.55 or so; and anything above that is unusual. However, for the past week or so, the server load often shoots up to 15.+ in just minutes and, then, the server freezes, requiring a hard (power off/on) reboot. And this process has been repeating multiple times/day since this began around last weekend. I'm guessing some type of DoS attack.

But since I ran that last command, the server's load immediately dropped down to 0.02-ish (i.e., normal), web pages're being served without issue and the server's load hasn't exceeded 0.05-ish for the past hour or so. That's the first time the server load hasn't skyrocketed, resulting in a frozen server, in a week! I'll monitor it for another day or two before I declare this "solved", but whatever's been going on has definitely been mitigated....or stopped.

Thanks again to all for your knowledge, patience and help! I'll report back with an update if the load problem reappears.
 
I suggest you find a copy of the "Book of PF" and learn rate-limiting and tables for black-holeing DDoS'ers.

The fact that you are running a system in questionable state would lead me to say "Delete everything and start over" Write down you configs and start again.

You were running a public facing website without a good firewall for at least some period of time. That means trouble. How deep we can only guess.

What Would John Lennon Do?
 
I suggest you find a copy of the "Book of PF" and learn rate-limiting and tables for black-holeing DDoS'ers.

The fact that you are running a system in questionable state would lead me to say "Delete everything and start over" Write down you configs and start again.

You were running a public facing website without a good firewall for at least some period of time. That means trouble. How deep we can only guess.

What Would John Lennon Do?
Lennon would've had people for this.

Thanks for the Book of PF recommendation. I'll have to check that out.
In spite of my initial confusion, the server's always had a firewall (ipfw) and logins require RSA keys (password-login disabled), so I don't think starting over's realistic or warranted. Anyroads, my *nix skills aren't what they used to be, so rebuilding their server isn't an option. But I appreciate your input!

Update: It's been a coupla hours since my previous post and all remains well with the server.
 
Update: It's been a few days since I implemented the fix and all remains well with the server. Legitimate visitors're gettin' in and there've been 0 problems.
So, for anyone seeking a similar solution in the future, I'm gonna call this issue SOLVED.
 
Back
Top