PF Can PF be bypassed?

CAN BE BY-PASSED PF (by an intruder from network) ???

  • 1. Yes !

    Votes: 1 33.3%

  • 2. No !

    Votes: 2 66.7%
  • Total voters
    3
  • Poll closed .
S

S3TH76

Hi,

Can anyone tell me if PF can be by-passed by an outsider(intruder)? I have an IP address that has already been in my ip.blocked table for two days and still its scans reach the web platform of the site where it is blocked by a firewall add-on/plugin at application level.

Any help is welcome.
 
S3TH76 said:
Can anyone tell me if PF can be by-passed from an outsider(intruder)?
Click to expand...
Short, simple answer, no.

I have an ip address that IS allready from 2 days introduced in my ip.blocked table and still it's scans reach the web platform of the site were is blocked by a firewall add-on/plugin at application level.
Click to expand...
Either your blocking rule isn't actually blocking anything or they still have active states from a time when the traffic was allowed.
 
Ok, thank you.

The rules are good, so as root from where else can someone change and how, the configuration (order of tables at load or if it will load at all).
 
If someone else has root access to that server, yes, they can change the PF tables and rules. Or anything, really.
 
wblock@ said:
If someone else has root access to that server, yes, they can change the PF tables and rules. Or anything, really.
Click to expand...
Ok, but how or where can intervine?

Only 2 (default) locations known by me are /etc/defaults/pf.conf and /etc/pf.conf.
 
You can use kern_securelevel_enable and kern_securelevel in rc.conf(5) by setting the latter to level 3 to prevent changes to the active ruleset once the system has been started:

From securelevel(7)

Code: 
     3     Network secure mode - same as highly secure mode, plus IP packet
           filter rules (see ipfw(8), ipfirewall(4) and pfctl(8)) cannot be
           changed and dummynet(4) or pf(4) configuration cannot be adjusted.

Be aware the at this level everything is locked down to such extend that even restarting services might pose difficulties. The system running at the securelevel is also totally unusable as a workstation because you can't run X11 on it.
 
S3TH76 said:
Only 2 (default) locations known by me are /etc/defaults/pf.conf and /etc/pf.conf.
Click to expand...
There is no /etc/defaults/pf.conf. In any case, files in /etc/defaults/ should not be modified.
 
S3TH76 said:
Ok, but how or where can intervine?
Click to expand...
Only give trusted people root or physical access to the machine. This is not any different from any other security processes. If someone untrusted has root access, they can change anything.
 
S3TH76 said:
I have an IP address that has already been in my ip.blocked table for two days and still its scans reach the web platform of the site where it is blocked by a firewall add-on/plugin at application level.
Click to expand...
I have to ask. How did you add them? And how are you detecting the scans?
 
Are the rules in the right order, where a keep state won't override the ip block? set skip is usually is written to bypass lo0, which wouldn't apply for an external IP.

I once suspected that PF was bypassed, but it appeared that it was only detecting a listening port that another program was specifically listening for in my case. It being from another computer's IP wouldn't be a case of that.

Does anything show when you run pkg audit -F from root?
 
SirDice said:
I have to ask. How did you add them? And how are you detecting the scans?
Click to expand...

I added the offending ip in my ip.blocked tables in /etc/pf.conf - I didn't detected in my syslogs but in website platform logs, being blocked by firewall add-on.

wblock@ said:
If someone else has root access to that server, yes, they can change the PF tables and rules. Or anything, really.
Click to expand...

And how would I know that? I suppose that any intruder on a server want his presence to be concealed how much time is possible, hiding its trace. So where I should look?

wblock@ said:
Only give trusted people root or physical access to the machine. This is not any different from any other security processes. If someone untrusted has root access, they can change anything.
Click to expand...

Indeed exist a third party Linux support engineer but he enter very rare and I trust him, it helps me with some aspects of maintenance of server. The single aspect that I don't like at him is the fact that don't explain in great detail what and where was doing.

sidetone said:
Are the rules in the right order, where a keep state won't override the ip block? set skip is usually is written to bypass lo0, which wouldn't apply for an external IP.

I once suspected that PF was bypassed, but it appeared that it was only detecting a listening port that another program was specifically listening for in my case. It being from another computer's IP wouldn't be a case of that.

Does anything show when you run pkg audit -F from root?
Click to expand...

All the rules are in right order, an function correctlly once PF loaded. I don't have a set skip rule for lo0.

Well, yes:
Code: 
#pkg audit -F
vulxml file up-to-date
expat-2.1.0_3 is vulnerable:
expat -- denial of service vulnerability on malformed input
CVE: CVE-2016-0718
WWW: https://vuxml.FreeBSD.org/frebsd/57b3aba7-1e25-11e68dd3-002590263bf5.html

1 problem(s) in installed packages found.
#
 
S3TH76 said:
I added the offending ip in my ip.blocked tables in /etc/pf.conf - I didn't detected in my syslogs but in website platform logs, beeing blocked by firewall add-on.
Click to expand...
Did you only add it to /etc/pf.conf? Did you also reload the rules? The file isn't dynamically loaded.
 
Well, I think the situation must be looked at it from the point of view of an attacker. So I urge you to see my server as a Black Box (OS: unknow, apps: unknown, other caracteristics: not known, location: unknown) - you have just its IP address.

After an nmap scan you found most unknown data but for your PENTEST you have to by-pass the firewall. So how you would proceed?
 
S3TH76 said:
After an nmap scan you found most unknown data but for your PENTEST you have to by-pass the firewall. So how you would proceed?
Click to expand...
You don't. There's no "magical" trick you can use to bypass it.
 
S3TH76 said:
but offcourse SirDice, with service pf restart
Click to expand...

/etc/pf.conf load some tables ip.blocked and ip.permit - each table is in fact a single file with a few hundred until a few thousands ip addresses. A table like <block_cntry_zone_CN> or <block_cntry_zone_RU> are in fact an IP block net for that country.
 
wblock@ said:
If someone else has root access to that server, yes, they can change the PF tables and rules. Or anything, really.
Click to expand...
Indeed, I can't learn enough from my friend that helps sometimes to maintain my server, sometimes doesn't explain at all, sometimes is too busy to speak/write the explanaitions for what he is doing.

So, I want to find out were and how this can be done (or not).
 
SirDice said:
As you would with any other, run your updates.
Click to expand...

No effect.

Code: 
#pkg update
Updatying FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
#pkg audit -F
vulxml file up-to-date
expat-2.1.0_3 is vulnerable:
expat -- denial of service vulnerability on malformed input
CVE: CVE-2016-0718
WWW: https://vuxml.FreeBSD.org/frebsd/57b3aba7-1e25-11e68dd3-002590263bf5.html

1 problem(s) in installed packages found.
#
 
I know the diference: pkg update send you to help and pkg-update it says command not found :)

I tried:
Code: 
pkg update -f expat
Usage: pkg update [-fq] [-r reponame]

For more information, see 'pkg help update'.
I tried with the same result pkg update -fq expat
 
I know, RTFM, but before asking something I always read the instructions (readme.txt), the help of commands, programs or system MAN pages. Before these trials and errors I land on a search engine like Bing or Google and finaly I ask you guys about these problems.
 
You must log in or register to reply here.
Back
Top