PfSense not blocking attacker (FIXED)
-
If the traffic is coming in through the WAN:
1. You are allowing it, perhaps inadvertently
or
2. The connection was established before you made the rule to block it and you never rebooted pfsense.
Or perhaps you are running uPNP on something on your lan that is forwarding ports?
-
If the traffic is coming in through the WAN:
1. You are allowing it, perhaps inadvertently
Not sure were else to look.
2. The connection was established before you made the rule to block it and you never rebooted pfsense.
I have rebooted after every change made.
Or perhaps you are running uPNP on something on your lan that is forwarding ports?
I have removed all other devices from the network, so I only have.
Modem -> pfsense box -> Server box. Nothing else is on the network.Still able to gain access through firewall to server.
Your avatar says it all! lol
Star.
-
1. Are you accessing the "WAN" from inside or outside your network to test blocking? (I have to ask)
2. Have you put a "pass" rule on the WAN as if its a LAN? floating rule? (Gotta ask)
I see you answered that before… Sigh.
Makes me wonder if the IP accessing your WAN and the IP you put on your firewall block rule are in fact the same IP.
-
This is what I have in my webserver logs.
80.82.78.166 - - [08/Oct/2014:12:02:52 +0100] "POST /xmlrpc.php HTTP/1.0" 403 1122 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
This IP is making 6 requests a second.Here is the Rule I added on the WAN
Is this correct? Am I missing something?
Thanks
Star.
-
This should make no difference, however, under "destination" put WAN address, then try.
-
No it made no difference at all.
I even added a Rule to Block everything coming in >Still able to access my services from outside of my network.
Star.
-
Do you have multiple WANs?
See, you don't have to add "Block all" rules on the WAN. Dropping inbound unsolicited packets is the default unless you allow them.
So, is there another way into your network?
-
No. only 1 WAN.
The Block ALL was just a test.The only other way in was openVPN and PPTP. But I disabled them both.
Thanks for your help btw. I do appreciate it.
Star.
-
I don't know.
My feeling is that pfsense isn't the problem because simple allow/block rules work fine usually.
In situations like this, I normally go with a wipe and reinstall.
Also. Has anyone added firewalls directly to packet filter in the command line of pfsense?
-
Can you check that your rules are showing up in /tmp/rules.debug, especially that Torguard / OpenVPN / PPTP VPN really are disabled?
Anything look strange in that file?
-
Mine is doing the same thing in an attempt to block 1452. It simply will not.
-
I'm interested in this problem and will look into this setup myself as soon as I get the time to experiment in my test environment.
@staroflaw Will you post when you find a solution to your problem? Often after solving the problem, nothing is heard thereafter ;-) -
Hi charliem
Can you check that your rules are showing up in /tmp/rules.debug, especially that Torguard / OpenVPN / PPTP VPN really are disabled?
Anything look strange in that file?After looking in the rules.debug file I don't see anything relating to Torguard or PPTP VPN. I do see some reference to OpenVPN
#System aliases loopback = "{ lo0 }" WAN = "{ re1 }" LAN = "{ re0 }" WIFI = "{ em0 }" OpenVPN = "{ openvpn }" anchor "relayd/*" anchor "openvpn/*" anchor "ipsec/*"
I do see the blocked rule.
# User-defined rules follow anchor "userrules/*" block in quick on $WAN reply-to ( re1 XX.XX.XXX.1 ) inet from 80.82.78.166 to any label "USER_RULE: Block Attack"
The IP re1 XX.XX.XXX.1 is not my IP. All the X are correct but mine ends in 204 not 1?
This is all the Rules I have set.
I also have my 4G mobile IP and my mates IP blocked but both can still access my services.
Thank you
Star.
-
Whatever you do, don't wipe it and reinstall it…
If you did that, it might fix it without ever satisfying the curiosity of the masses.
-
staroflaw Will you post when you find a solution to your problem? Often after solving the problem, nothing is heard thereafter ;-)
I know what you mean, I will deferential post if I fix it.
Whatever you do, don't wipe it and reinstall it…
If you did that, it might fix it without ever satisfying the curiosity of the masses.I also want to understand why its not working correctly, just in case I see the happen again.
This attack has now been going for 5 days, they have made over 1,728000 requests.
I have reported it to my ISP and Ecatel LTD the owner of that IP.My ISP says they cannot do anything about it unless they have a large amount of complaints relating to that IP. I totally understand that.
Ecatel LTD say….... "Nothing" I have had no response from them at all. I have contacted them two times now with LOG's and nothing.Star.
-
Star:
On your WAN rule to block this guy-
Make sure that Logging is checked…
On the pass/block/recject option at the top of the rule- set to reject (just to test) and see what the firewall logs show...
Set "Destination" to your server LAN IP address.
-
so how exactly is he getting in and hitting your webserver. I don't see any rules that would be there from a port forward - your wan rules don't show any allows other than icmp from one IP.
So only inbound traffic would be from a state that client on lan created the connection.
look at your state table and filter for his IP and what do you see for states?
-
I don't see any rules that would be there from a port forward
johnpoz you are absolutely correct. I assumed the wan rule was created automatically for you but as it is clearly not there, obviously not. The answer was in front of me all along. My HTTP Filter rule association was set to PASS. That’s why it just ignored my Block WAN rule.
I don’t know how I missed this!I can now confirm it is blocking.
A BIG thank you to all who participated in the discussion and for all help offered.Star.
-
Here is how I setup my HTTP NAT correctly.
Filter rule association > Create new associated filter rule.
Apply changes.
Then under Rules add your block rule.
Make sure the block rule is above everything else.
You can also see the new rule added NAT HTTP_Server
Star.
-
jimp? I don't see anywhere where jimp pointed out anything ;)