i also noticed some of the entries are coming from my ISP DNS server which are fine...but them other ones...grr
Ok, show some of them other entries and we can try to analyze it.
also what is a "nefarious program"? a malicious program?
Yeah.
thanks for those sites i will do some research into it now.
Np, here's the rest :-]
Netfilter+Iptables HOWTO:
LQ search: iptables+howto,
Linuxguruz.org,
Netfilter.org Packetfiltering HOWTO,
Linuxsecurity.com Iptables tutorial,
Andreasson's Iptables tutorial,
Iptables Connection tracking.
Ipchains HOWTO:
TLDP Ipchains HOWTO,
Flounder.net Ipchains HOWTO.
Other resources/misc stuff:
Assigned ports > 1024,
Port designations,
FAQ: Firewall Forensics (What am I seeing?),
Linux Firewall and Security Site,
Auditing Your Firewall Setup (old, still usefull),
TLDP: Firewall Piercing mini-HOWTO"],
Something called the "Home PC Firewall Guide",
Vendor/Ethernet MAC Address Lookup,
Netfilter Iptabes/Ipchains Log Format,
Dshield (find out if IP was marked as used in attacks),
(Snort) Port search,
Neohapsis Port search,
(IPMasq) P2P ports,
Infosyssec's Firewall Security and the Internet (badly updated site).
dont suppose u know of what i can add (if possible) to my firewall script to drop these scans, would i just use an entry to drop packets from the particular port?
Wonder why don't u spose that?..
Anyway, scans could be detected (not all occasions) by looking at the packets src/dest addresses, protocols, flags, port range, rate and payload.
Flags/addresses: default fw scripts usually have a section that drop packets with the wrong combination of flags, or those coming from private/multi/broadcast class addresses or inbound from apparently your own MAC/IP address.
Looking back at your 1st example for instance, you don't want to block those if they where part of a connection (and src port > 1024 and dest port > 1024), so there you would just drop the
logging if you don't want to see those.
About payload and for ports you run servers on, I suggest running Snort to try and determine what's malicious or not. It can't catch every possible form of malicious activity but it can catch a lot. Use it with a 3rd part app like Guardian to block access.
Looking back at your 1st example Snort's builtin portscan preprocessor will also take care of the portrange and portrate thingie and will alert when the scan goes over the treshold.
Beyond that, dropping for closed ports depends on your default policy. If you've got a default ALLOW, you've got to add a lot of ports if you want to explicitly drop access to them, but you don't have to configure allowed in/fwd/outbound access.
If OTOH you've got a default paranoid policy of DENY then you don't have to add drop rules for every port you don't want ppl to have access to, but you'll have to explicitly configure allowed in/fwd/outbound access. Haven't seen scripts that explicitly exclude protocols, but scripts usually will define a port rate limit.
There's a 3rd possibility and that's just ignoring port access you don't run services on. It usually goes with a default policy of ALLOW.
One a final note there's something to be said about scan detectors.
Some ppl suggest running Portsentry as it's included in distro's.
My first argument against running Portsentry (in the most paranoid setting) is that it will trip on access to about EVERY PORT. While this is fine if someone sweeps a port range, you can do this with your fw script as well. Besides that you might suffer from log blindness in a while if you're in a spot that get's scanned a lot by those Roadrunner, @Home and other large cable ISP connected skiddies.
My second argument against running Portsentry is that it can't determine what's malicious and what's not. It just trips on ACCESS, not payload. Snort can, Snort will and Snort does make that distinction.
HTH somehow.
the reason i asked was 'cause my FW and iptables skills are not 100%
2:2A:67 type:0x800 len:0x3C
