[email protected] wrote: > I seem to have picked up a bug, but am unable to trace it. Lots of > these: > > [55415.513723] Shorewall:fw2net:DROP:IN= OUT=wlan0 SRC=192.168.1.1 > DST=97.107.134.150 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=28176 DF > PROTO=TCP SPT=55445 DPT=3333 WINDOW=14600 RES=0x00 SYN URGP=0 > [55420.348527] Shorewall:fw2net:DROP:IN= OUT=wlan0 SRC=192.168.1.1 > DST=97.107.134.150 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=27353 DF > PROTO=TCP SPT=55447 DPT=3333 WINDOW=14600 RES=0x00 SYN URGP=0 > Two possible solutions and a bit of advice:
1. Deploy SELinux in Enforcing mode (if you don't use it already) and then place a rule with the AUDIT target matching any packet which goes to destination port 3333, protocol udp. That way, you will be able to trace the process, thread and user credentials used to create that packet. You are "lucky" in a way that the packet originates on your machine - that allows you to see process, thread and user credentials - if this packet was from the outside you won't be able to see that. You can place this in the NEW section of "rules" or, if you have no joy (i.e. no matches), then you have to recreate that same rule in either the "raw" or "mangle" tables. Once you do get a match (check the counters when you execute "iptables -L -vn" or "shorewall show"), then check your audit.log file (usually in /var/log/audit). You can use "ausearch -m NETFILTER_PKT -i" (further filtering can be done with the "-ts" option) to see what matches you have received and that will give you a hint as to who/what creates that packet. 2. If you would like to grab the whole packet (header+payload), then you have to use ulogd2 and activate one of its numerous plugins which are able to capture and dump whole packets depending on what matches you have set up in iptables. To activate ulogd2 use the NFLOG iptables target to create the appropriate matching rule - either un "rules" or in raw/mangle tables as indicated above. If you are fairly certain that your Konqueror browser is to blame, or you picked up a rogue plug-in, then if you are allowed, try to deactivate the various plugins you have in use in this browser - one by one - and see whether you get a repeat of the "volley". If not, and you are certain what causes it, then just remove the plugin and be done with it. On a personal note, for this kind of thing I always use Tor, combined with Privoxy, both installed separately on one of my dmz machines. They are accessed over ssh tunnel from my desktop machines to filter out the stuff from "rogue" html page elements I do not need. That way, the browser *always* uses a proxy (redirected to the ssh tunnel port on my desktop machine - i.e. 127.0.0.1:XXXX) and I have explicitly blocked in my SELinux policy any "web" traffic (ports 21, 80, 443 and the like). That way, if something misbehaves, SELinux immediately raises an alert and I catch the bastard with his pants down more or less instantly. Hope that helps. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
