Free check web software for linux

Check Your Network Address Translator for Compatibility with Peer-to-Peer Protocols.
If you are accessing the Internet from behind a Network Address Translator (NAT) of some kind, I would appreciate your help in surveying the behavior of different NATs, in terms of how and whether they support a certain technique for enabling peer-to-peer communication between NATted hosts (particularly when both endpoints are behind NATs). Down, you can understand what NAT is.
Suppose there are three communicating hosts: A, B, and C. Host A is a "well-known" Internet server with a permanent IP address, which acts as an "introducer" for the other two nodes. (For example, Host A might be a well-known ultrapeer or a game catalog server of some kind.) Host B, using Host As "introduction" services, would like to establish a direct peer-to-peer connection with host C. Both B and C, however, are behind (probably different) network address/port translators, and neither of them has exclusive use of any public IP address.
To initiate a peer-to-peer connection with host C, host B first sends A a message requesting an "introduction" to host C. A sends B a reply message containing Cs IP address and UDP port number as reported by host C, in addition to Cs IP address and UDP port number as observed by A. (If C is behind a NAT, then these two address/port combinations will be different.) At the same time, host A sends host C a message containing Bs IP address and UDP port numbers - again, both the ones reported by B and the ones observed by A, which will be different if B is behind a NAT.
Now B and C each know that they want to initiate a connection with each other, and they know each others public (NATted) as well as original IP addresses and UDP port numbers. Both B and C now start attempting to send UDP messages directly to each other, at each of the available addresses. If B and C happen to be behind the same NAT, then they will be able to communicate with each other directly using their "originally reported" IP addresses and UDP port numbers.
In the more common case where B and C are behind different NATs, the "originally reported" addresses will be useless because they will both be private IP addresses in different addressing domains. Instead, the IP address/UDP port combinations observed by A can be used in this case to establish direct communication. Although Bs NAT will initially filter out any UDP packets arriving from Cs public (NATted) UDP port directed at Bs public port, the first UDP message B sends to C will cause Bs NAT to open up a new UDP session keyed on Cs public port, allowing future incoming traffic from C to pass through the NAT to B. Similarly, the first few messages from B to C may be filtered out by Cs NAT, but will be able to start passing through the firewall as soon as Cs first message to B causes Cs NAT to open up a new session. In this way, each NAT is tricked into thinking that its respective internal host is the "initiator" of this new session, when in fact the session is fully symmetrical and was initiated (with As help) simultaneously in each direction.
Required NAT Behavior
There is one important requirement that the NATs must satisfy in order for this technique to work: the NATs must be designed so that they assign only one (public IP address, public UDP port) pair to each (internal IP address, internal UDP port) combination, rather than allocating and assigning a new public UDP port for each new UDP session. Recall that a "session" in Internet terminology is defined by the IP addresses and port numbers of both communicating endpoints, so host Bs communication with host A is considered to be one session while host Bs communication with host C is a different session. If Bs NAT, for example, assigns one public UDP port for Bs communication with A, and then assigns B a different public UDP port for the new session B tries to open up with C, then the above technique for peer-to-peer communication will not work because Cs messages to B will be directed to the wrong UDP port.
RFC 3022 explicitly allows and suggests that NATs behave in the former, "desirable" fashion, by maintaining a single (public IP, public port) mapping for a given (internal IP, internal port) combination independent of the number of active sessions involving this mapping. This behavior is not only good for compatibility with UDP applications, but it also helps to conserve the NATs scarce pool of public port numbers. Maintaining a consistent public port mapping does not adversely affect security in any way, either, because incoming traffic can still be filtered on a per-session basis regardless of how addresses are translated. There in fact appears to be no good reason not to implement the desirable behavior in a NAT, except perhaps for the implementation simplicity of naively allocating a new public port for every new session. Unfortunately, RFC 3022 does not require NATs to implement the desirable behavior, which has led me to wonder just how many real NATs actually do, and hence this page.
What NAT Check Does
The program natcheck.c is basically just a program that "pings" a well-known UDP port at two different servers that are publically accessible on the Internet. Both of these servers run the program natserver.c, with the command-line arguments "1" and "2" respectively. In addition, there a third "conspiring" server runs natserver with the command-line argument "3". Whenever each of the first two servers receives a UDP request, it not only sends a reply directly to the sender of that request, but also sends a message to the third server, which in turn "bounces" the reply back to the original client. The effect is that the client will receive not only solicited "ping" replies from the server the request was directed to, but also "unsolicited" replies from the third server.
To determine if the network address translator in use is implementing the desirable behavior of maintaining a single (public IP address, public port) mapping for a given (client IP address, client port), the client program natcheck.c basically just initiates a sequence of simultaneous pings to the first two servers (in case some of the requests or replies are lost in transit) and checks that the clients address and UDP port as reported by both servers is the same. If the NAT naively allocates a new public port for each new session, then the source port as reported by the two servers will be different, and its time to upgrade your NAT.
The replies echoed from the third server are used only to check whether the NAT properly filters out unsolicited incoming traffic on a per-session basis. Since the client never sends any messages to the third server, if the NAT is properly implementing firewall functionality, the client should never see the third servers echoed replies even after opening up active communication sessions with the first two servers.
Enhancements:
- The NAT Check client no longer attempts to guess whether you have Basic NAT or Network Address/Port Translation (NAPT). It turns to be quite difficult to test for this property reliably, because many NAPTs attempt to bind a private UDP port to a public port with the same port number if that port number is available, causing NAT Check to falsely report Basic NAT. The only way to test for this property reliably would be to run NAT Check on at least two client machines simultaneously, and since this property isnt terribly important to P2P apps its just not worth the trouble.
- The NAT Check client now tests for one additional NAT feature, which I call loopback translation. If a NAT supports loopback translation, it means that a host on the private network behind the NAT can communicate with other hosts on the same private network using public (translated) port bindings assigned by the NAT. Most NATs probably do not support this feature yet, but it may become increasingly important in the future where P2P clients may be located behind a common ISP-deployed NAT as well as individual home NATs. More details on loopback translation will appear in the next version of my Internet-Draft, to be released soon.
- The NAT Check client program now has a command-line option, "-v", which turns on verbose messages during the test.

pppcheck can help you to check usage of shared ppp accounts and limit ppp users by hrs/day and hrs/month.

Devialog is a behavior/anomaly-based syslog intrusion detection system which detectsattacks via anomalies in syslog.

Present log-based IDS:

Nearly all present log-based intrusion detection systems operate using a pre-defined known signature base, usually painstakingly created by hand. They can work well if the creator knows exactly all error and informational messages the software on a system(s) will write to syslog. Most overworked administrators wish there was an easier way to handle system logfiles in a sane, time-saving fashion. Present log-based intrusion detection systems have difficulty in detecting new attacks.

How devialog Differs:

devialog makes syslog parsing far less of a chore than it previously has been. It is functionally the inverse of standard log monitoring software. devialog, by default, reports on what is not know in its signature base, i.e. anomalous. This type of intrusion detection system is considered behavior-based, or anomaly detection. Reporting can be in the form of an email for each anomalous log, or an email for all the logs sent within a pre-defined time window. devialog can also execute commands, or simply write all anomalies to a file for periodical review.

Signature Creation:

For log-based anomaly detection to operate effectively, one must create an extremely large signature base. With an included utility, devialogsig, the signatures are created automatically. Future signature additions are ver simple, like a copy from the alert email.

ht://Check is more than a link checker. Its a console application written for GNU/Linux systems in C++ and derived from the best search engine available on the Internet for free: ht://Dig.
It is very useful for Webmasters who want to control and monitor their Websites, in order to discover unexpected broken links, but also interesting information from the data they have in the form of HyperText documents.
Also, ht://Check builds a very useful and extremely complete data source in MySQL, it is very flexible and easily improvable as it is an opensource project. Anyway, for more info, you are strongly suggested to give a look at the General Info and the Features sections.
General info
ht://Check is more than a link checker. Its a console application written for GNU/Linux systems in C++ and derived from the best search engine available on the Internet for free: ht://Dig.
It can retrieve information through HTTP/1.1 and store them in a MySQL database, and its particularly suitable for small Internet domains or Intranet.
Its purpose is to help a Webmaster managing one or more related sites: after a "crawl", ht://Check creates a powerful data source made up of information based on the retrieved documents. The kind of information available to the ht://Check user includes:
- single documents attributes such as: content-type, size, last modification time, etc.;
- information regarding the retrieval process of a resource, like for instance whether the resource was succesfully retrieved, or not, showing the various results (the so-called HTTP status codes, as ht://Check uses this protocol for crawling the Web);
- information regarding the structure of a document, basically its HTML link tags, and the relationships they issue, in a whole process view: basically, ht://Check is able to crawl a Web domain or set (in the algebrical meaning), and links create sort of inter-documents relationships in it. This feature, allows the user to get further information from the domain regarding:
- link results: if it either working or broken or redirected; also at the current status, it checks whether a link is actually an anchor that does not work, or it is a javascript or an e-mail;
- the relationships between documents, in terms of incoming links and outgoing ones; in the future, particular attention in the development will be given to the Web structure mining activity.
A skinny report is given by the program htcheck, however at the current situation most of the information is given by the PHP interface which comes with the package and that is able to query the database built by the htcheck program in a previously made crawl. It goes without saying that you need a Web server to use it, and of course PHP with the MySQL connectivity module.
By the way, as long as after a crawl ht://Check produces a database on a MySQL server, its needless to say that every user theoretically could build its own information retrieval interface to this database; you only need to know the structure of it, its tables and fields, and the relationships among them.
Other solutions are represented by independent scripts written by using common scripting languages with MySQL connectivity modules (i.e. Perl and Python), or faster programs written in C or C++ using MySQL API or wrapper libraries (such as MySQL++ or dbconnect), or other Web driven solutions like JSP, ColdFusion. There exists an interface to ht://Check for the Roxen Web server written by Michael Stenitzer (stenitzer@eva.ac.at).
Main features:
The "Spider" or "Crawler"
- HTTP/1.1 compliant with persistent connections and cookies support
- HTTP Basic authentication supported
- HTTP Proxy support (basic authentication included)
- Crawl customisable through many configuration attributes which let the user
- limit the digging on URLs pattern matchings and distance ("hops") from the first URL.
- MySQL databases directly created by the spider
- MySQL connections through user or general option files as defined by the
- database system (/etc/my.cnf or ~/.my.cnf)
- No support for Javascript and other protocols like HTTPS, FTP, NNTP and local files.
The "Analyser"
- Just a preface: as long as all of the data after a crawl are all stored into a MySQL database, it is pretty easy to get your desired info by querying the database. The spider, anyway, is included into the htcheck application, which at the end shows by itself a small text report. In a second time you can always retrieve info from that database by building your own interface (PHP, Perl for instance) or by just using the default one written in PHP.
- I also believe that ht://Check builds a data source that can be used for Web structure mining, revealing knowledge about the relationships within and between documents. Also Web usage mining tools can find interesting information from ht://Check, and use it as auxiliary data source in order to build a sort of site map.
- htcheck (the console appllication) gives you a summary of broken links, broken anchors, servers seen, content-types encountered.
- The PHP interface lets you perform:
- Queries regarding URLs, by choosing many discrimineting criterias such as
- pattern matching, status code, content-type, size.
- Queries regarding links, with pattern matching on both source and destination
- URLs (also with regular expressions), the results (broken, ok, anchor not found,
- redirected) and their type (normal, direct, redirected).
- Info regarding specific URLs (outgoing and incoming links, last modify
- datetime, etc ...
- Info regarding specific links (broken or ok) and the HTML instruction that
- issued it
- Statistics on documents retrieved

Check4Change is a simple Firefox extension that allows you to periodically check a web-page for updates.

Have you ever found yourself pressing the reload button frantically, waiting for something in the web page to change?

Well reload no further! with C4C youll just mark the relevant text, set a time interval (e.g. every 1 minute), and youre done!

Usage:

1. Select the text you want monitored for updates.

2. Right-Click. On the Check4Change context menu, select the time interval. The tab icon will indicate this page is being monitored by changing to C4C.

Thats it! Sit back, and wait for the notifications, which include:

* Little dancing C4C letters in the tab icon. Clicking the tab indicates youve seen it, and the icon changes back to the original.
* Pop-up alert notification.
* Sound notification. Can you make out who it is?

Note: C4C currently only works with open tabs. It does not continue to monitor tabs that have closed, nor does it remember running jobs between FireFox restarts. These features will be implemented in an upcoming release.

Bandwidth Check is a small utility that helps an administrator measure the available bandwidth. In order to make use of this utility, you will need to turn on the chargen service, which is provided in many inetd implementations.

In order to make use of this utility, you will need to turn on chargen protocol.

To enable chargen on Linux:

create the following file /etc/xinetd.d/charge
service chargen
{
type = INTERNAL
id = chargen-stream
socket_type = stream
protocol = tcp
user = root
wait = no
disable = no
}
service xinetd restart

To Compile bwcheck

gcc -o bwcheck bwcheck.c

To execute

./bwcheck

./bwcheck 172.16.11.2
Throughput: 73390.74 kb

Pretty Code Web is a syntax highlighter for publishing code, written in any programming language, to the web.
Written in php it uses syntax files separate from the main code to highlight a specified language.
Main features:
- Syntax highlighting for (potentially) any language.
- User defined syntax files.
- User defined colors
- Separate colors for:
- 6 Keyword Groups
- Text Strings
- Operators
- Block and Line Comments
- Bracket Characters