Date: Sun, 8 Jul 2018 07:43:16 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> To: "Andrey V. Elsukov" <bu7cher@yandex.ru> Cc: supportsobaka@mail.ru, freebsd-ipfw@freebsd.org Subject: Re: ipfw uid/gid debugging, tcpdump relation with ipfw and how to block direct access to port 25 Message-ID: <201807081443.w68EhGD0061784@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <d6fcbc8c-8b10-7890-f23a-dde9b9932b0b@yandex.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 04.07.2018 15:28, supportsobaka--- via freebsd-ipfw wrote:
> > Could you please explain whether tcpdum should see a packet dropped
> > on ipfw?
In general NO, ipfw well not see a packet that is "deny" or "drop"
by ipfw, as the bpf code is called after ipfw.
>
> tcpdump is not related to ipfw.
> ipfw(4) has ability to send packets,
> that are matched by rules with "log" opcode to special ipfw0 pseudo
> interface. This interface can be created at run-time. Then, you can add
> "log" keyword to the deny rule and see such packets in `tcpdump -ni
> ipfw0` output.
One of the reasons to have the ipfw0 pseudo device is so that these
dropped packets can be seen by tcpdump.
> Simple example:
>
> # ifconfig ipfw0 create
> # ipfw add 1 deny log icmp from me to any
> # ping 127.1
> # tcpdump -ni ipfw0
> 12:21:19.222133 IP 127.0.0.1 > 127.0.0.1: ICMP echo request, id 64151,
> seq 0, length 64
> 12:21:20.230762 IP 127.0.0.1 > 127.0.0.1: ICMP echo request, id 64151,
> seq 1, length 64
>
> > Does it look before or after ipfw? tcpdump -vvv port 25
> > shows nothing when port is blocked on ipfw (security log shows droped
After ipfw
> tcpdump works at layer2 level. The kernel sends packets to BPF when it
> goes through ethernet handling routines.
> ipfw(4) usually works at layer3 level, i.e. when Ethernet layer already
> did, or not yet did its work. Anyway, you can not see dropped packets if
> you did not prepared to this like I described.
IIRC tcpdump hooks at the same points as ipfw, just ipfw hooks first.
ipfw(3) works at both layer2 and 3 depending on the rule as you can
do mac level filtering, and there is even a layer2 option keyword
so you can control if your rule is applied at when the packet
traverses certain points in the kernel.
NOTE that ipfw can see the same packet up to 4 times so you have
to be careful if you turn on certain options and start to do layer2
filtering. There is a description of this in the man page ipfw(4)
in the PACKET FLOW section.
> > packets). Also, is there a way to to see uid/gid on the packet in
> > ipfw log? Alternatively, can tcpdump show uid/gid of the packet
> > (before ipfw)? I don't see uid/gid when use tcpdump -vvv port 25. Is
> > there a way to understand if packet does't have uid/gid or it just
> > not shown? I can't figure out a good rule to protect access to port
>
> tcpdump has not such ability or knowledge.
And it appears as if ipfw does not log this info when it does have
it avaliable and a rule that matches with the log option is present.
This should probably be added as a feature to assist in debugging.
> > 25 for other than sendmail (yep, native sendmail). The obvious
> > ${ipfw} add allow tcp from me to any 25 out gid smmsp setup
> > keep-state :emailfromme doesn't work (email is not sent out,but
> > dropped on the ipfw by the last deny rule). Seems like the packet
>
> how do you test this?
>
> > sent by sendmail doesn't belong to snmmsp group. I have tried gid
> > operator gid mail gid smmsp gid wheel - won't help. How to debug?
>
> --
> WBR, Andrey V. Elsukov
--
Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201807081443.w68EhGD0061784>