On 4/20/2011 12:34 PM, Rob wrote:
>> I use a Netopia DSL/Router box that is BSD-based, and is packed
>> with all sorts of really nice software, including a packet filter,
>> for controlling what is and what is not permitted to enter/leave
>> the internal network.
>>
>
> How does this work? And how would this stop malware?
>
Brief example: the PF packet filter has a 'keep state' command. If
included in the ruleset, it sets up a 'state table' which keeps a record
of what transactions are ongoing for the various open ports, which have
daemons listening for incoming requests.
So I have my web browser open, and I request a web page, and my request
is filed in the state table. So when the web page I requested is sent to
my browser's port, PF checks to make sure that a request for that web
page was issued by me. If it was not, then the packets are dropped.
Lots of interesting stuff here:
http://www.openbsd.org/faq/pf/filter.html
Another ruleset I use, filters by IP address and user name. I am running
servers, so I lease static IP addresses. When one of the users on my LAN
attempts to log into a shell account, or upload content via ssh, PF
checks to confirm their IP address and username. If both do not match
correctly, the request is dropped.
>> I have an OpenBSD server on my LAN, that handles web services and
>> email, and because that machine permits remote logins for shell
>> accounts, and uploading/downloading web content, I run the OpenBSD
>> PF packet filter on that box as well, with a very strict ruleset.
>>
>
> You mean you close open ports?
No. OpenBSD has all ports that are not absolutely necessary for minimum
default operation closed already... basically, this means that there is
no daemon listening on that port. If there is no daemon listening, to
receive incoming traffic, the port is closed.
PF rulesets operate one level *above* ports, so that there *is* a daemon
listening for incoming traffic, but that the PF ruleset functions
*behind* the port, so that the daemon receives the incoming request, and
passes it to PF, which then decides whether whatever rules PF has in
place... (for example, whitelisting, greylisting and blacklisting IP
addresses and ranges, known to be malicious, or blocked for other
various reasons, like when business block websites like Facebook, so
their employees will not be messing around when they are supposed to be
working) ... will permit the packet to be passed, or dropped.
> What OS are you running? And are all these firewalls hardware or some
> software?
>
OpenBSD, CentOs Linux, Windows 2000, and Windows Vista/Windows 7 USGCB,
aka 'U.S. Government Configuration Baseline'.
I don't run any hardware firewalls, but my employer does.
> Some software firewalls will give you real time pop ups if port
> scanning is going on or program trys to connect to the internet where
> a router firewall cannot to this.
>
> Or lock your computer when you go to the bathroom or Lunch break so
> all ports even port 80 will be close when you lock it gone to the
> bathroom or Lunch break .
>
> Some people even shut down the modem and router also unplug the
> ethernet cable at night.
>
> Some people jut use the router firewall some people want software
> fire wall and some people both.
>
> Some people use program snort that the ability to perform real-time
> traffic analysis and packet logging on Internet Protocol (IP)
> networks. Snort performs protocol analysis, content searching, and
> content matching. The program can also be used to detect probes or
> attacks,buffer overflows, server message block probes, and stealth
> port scans.
>
It all depends what the job requires. The more security one needs, the
less freedom of access the users will be permitted to have. If the
security level does not permit you to do your job, it is too high. :)
> In past 10 years of using computer 6 times people tried to hack me.
>
In any 24 hour period, my home LAN receives somewhere around 100
requests, looking for the existence of various filenames that do not
exist on my server... filenames that have known vulnerabilities
associated with them, and that also serve some sort of useful purpose to
the attacker (running an automated script), if the vulnerability is
unpatched, and the attacker can gain control of the process.
Most of these land up (predictably) in my root HTTP directory, as
opposed to my virtuser directories, because the script is searching by
IP addy as opposed to URL's
--
http://www.robertwittig.com/
http://robertwittig.net/
http://robertwittig.org/
.
No comments:
Post a Comment