Date: Sun, 8 Jul 2018 12:45:08 +0300 From: "Andrey V. Elsukov" <bu7cher@yandex.ru> To: 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: <d6fcbc8c-8b10-7890-f23a-dde9b9932b0b@yandex.ru> In-Reply-To: <1530707289.696086711@f198.i.mail.ru> References: <1530707289.696086711@f198.i.mail.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--QrmUWCyEz9kqhaL93FWmWLaaBG8luEmxq
Content-Type: multipart/mixed; boundary="AOSJknC0LPnGpHJvA9WIxhQqGqGSbD4qy";
protected-headers="v1"
From: "Andrey V. Elsukov" <bu7cher@yandex.ru>
To: supportsobaka@mail.ru, freebsd-ipfw@freebsd.org
Message-ID: <d6fcbc8c-8b10-7890-f23a-dde9b9932b0b@yandex.ru>
Subject: Re: ipfw uid/gid debugging, tcpdump relation with ipfw and how to
block direct access to port 25
References: <1530707289.696086711@f198.i.mail.ru>
In-Reply-To: <1530707289.696086711@f198.i.mail.ru>
--AOSJknC0LPnGpHJvA9WIxhQqGqGSbD4qy
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
On 04.07.2018 15:28, supportsobaka--- via freebsd-ipfw wrote:
> Could you please explain whether tcpdum should see a packet dropped
> on ipfw?=20
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.
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
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.
> 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.
> 25 for other than sendmail (yep, native sendmail). The obvious=20
> ${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?
--=20
WBR, Andrey V. Elsukov
--AOSJknC0LPnGpHJvA9WIxhQqGqGSbD4qy--
--QrmUWCyEz9kqhaL93FWmWLaaBG8luEmxq
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAltB3SkACgkQAcXqBBDI
oXq+GQf/X3lQIA0/gxprTTA/861IIP2Kl4h57Rsd3Cg9AjzjvkWvTLP5csMNVHgG
95Ko5z3hAGYqEM2/2/eoz2cfYtZxAQ07RSl6EpAaKACj8B7xKlwAnGLcQW0Hg8nP
qW9itzSKE8B7TuPRQGn0au+A4RJXBFaygxycRYhokVMobGSG8FePUKaEGvxtnlLj
1UTePtouSIG7g3Lf7QZ3JSRuGzIpNmnFTI9RzQS6V67cDLlgJU6KBh/cObbrzUrU
QXMzQCQsuIUy27UYI6nwDAmehKKenFOFj8zrh/MYNNQQXt0HcNAxfmDr20EQp/cq
ReTEWrdb3Z/CRiIgEGJSJtIbttyzhA==
=q8WH
-----END PGP SIGNATURE-----
--QrmUWCyEz9kqhaL93FWmWLaaBG8luEmxq--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d6fcbc8c-8b10-7890-f23a-dde9b9932b0b>