1

I log and drop packets send to specific IP/domain name. I would like to be able to log url parameters for these dropped packet.

This is an example url:

http://somedomain.com/test.php?param1=test1&param2=test2

This is what i'm doing e.g:

iptables -A OUTPUT -p tcp -d somedomain.com --dport 80 -m string --string 'param1=' --algo bm -j LOGGING

In LOGGING chain:

iptables -A LOGGING -j LOG --log-prefix "somedomain.com Packet Dropped: " --log-level 7

I tried these options without any success:

--log-ip-options
--log-tcp-options

Basically, i'd like to be able to get same relevant info as from tcpdump but because i drop packets, you know the story, i cannot use tcpdump here (as i understand it)...

Is it possible using iptables log (to a text file?!) to get URL query string of dropped packet? In this example, it would be:

param1=test1&param2=test2

My knwoledge about all of this is near the zero so excuse me if it's a silly question.

Thx

Improve this question
5
  • URLs are not on IP/TCP level. You would need a plugin which can assemble and log application level content. (Some NIDS can do that with diverted packages from NF). When you drop sun packets for new connections you will never see the URL containing packets anyway. But generally you can also write the dropped packages to a user mode queue for logging. ULOGD can write them in pcap format: stearns.org/doc/iptables-ulog.v0.1.html
    – eckes
    Jun 9, 2017 at 9:34
  • @eckes I heard before about ulog, i will look at it. But would it be possible to get the output (only GET query in my case) in text format?
    – rostM
    Jun 9, 2017 at 9:40
  • Unlikely (for the reasons mentioned above)
    – eckes
    Jun 9, 2017 at 9:42
  • @eckes Ok i guess i better understand what you meant. Thank you
    – rostM
    Jun 9, 2017 at 9:45
  • What is serving these urls? nginx, apache, haproxy, other? Is TLS being used?
    – Aaron
    Jun 9, 2017 at 14:29

1 Answer 1

Reset to default
2

You won't be able to achieve that correctly with iptables alone, if only for the fact that the request URL might be fragmented across several packets.

Since you are filtering on OUTPUT, probably a more robust and easier way would be to install a local HTTP proxy, such as Squid, and add your filtering rules to squid.

For the sake of completeness, you can then use iptables to block everything but the squid proxy to connect to this forbidden host.

According to the following Config example, you should have in your squid.conf

http_port 3129 intercept

and then intercept requests with

iptables -t nat -A OUTPUT -p tcp -d somedomain.com --dport 80 -m owner  --uid-owner squid -j ACCEPT
iptables -t nat -A OUTPUT -p tcp -d somedomain.com --dport 80 -j DNAT --to-destination 127.0.0.1:3129

The first rule is required so that squid itself can proxy the request to the original host, if you want to let some through.

You can observe the URLs of the requests by consulting the default access.log file produced by squid. For actually blocking URLs you should setup some ACLs in squid.conf:

acl blocktestphp url_regex test.php
http_access deny blocktestphp
Improve this answer
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .